~bigbes/tarantool

tarantool-protobuf

ref: 55f0c318230172882b5b8b2bcb7460f69578c406 tarantool-protobuf/bench/packed_bench.lua -rw-r--r-- 2.3 KiB
7b3d6901 — Eugene Blikh 2 months ago
bench: apply mcode arena hardening across all bench scripts (3qu)

Added jit.opt.start('sizemcode=64', 'maxmcode=4096') to all 9 bench
scripts. Same fix 3o2 landed in bench/jit_trace.lua, propagated to the
rest. Without it, the macOS arm64 mcode allocator intermittently fails
to find an executable page in the signed-32-bit offset window and the
bench reports interpreter-only throughput with no diagnostic — visible
as silent regressions. The risk is higher in scripts with larger codegen
footprints than the trace gate.

Files touched: bench.lua, lazy_bench.lua, profile.lua, shapes_bench.lua,
starwing_bench.lua, wire_bench.lua, alloc_probe.lua, map_bench.lua,
packed_bench.lua. All 7 non-interactive scripts run rc=0; profile and
starwing loadfile-check clean.

Also refreshed bench/baseline.json per the issue's step 2. Surprise win:
full-mode decode allocations dropped 0.5-50% as a side-effect of auj/ozn
that was only visible after the snapshot. Most notable: proto2_basic
BenchPayload mid decode 2.313 -> 1.156 KB/op (-50%), Person 1KB decode
0.977 -> 0.953 KB/op. Runtime-mode unchanged — confirms the alloc
reduction is full-mode codegen specific.

Steps 3-4 (refresh COMPARISON.md throughput tables, verify the variance
band shrinks below the documented 5-10% drift) are deferred to a
work.lab.local run — laptop variance is 50%+ on identical state, can't
trust throughput A/Bs locally.
dbbfaf35 — Eugene Blikh 2 months ago
codegen: inline 1-byte varint fast path for packed scalar elements (aah)

Per-element wire.encode_<type>(v) calls in packed-repeated fields paid a
full function-call boundary even though encode_varint's small-positive-int
hot path is a single CHARS[n] lookup. Inline the check + lookup at
codegen time at every packed emit site:

  - Repeated packed scalar (mode=full)
  - Repeated packed enum (after string->int resolve)
  - Proto2 extension packed scalar + enum

For varint scalars (int32/int64/uint32/uint64): fast path triggers when
v is a Lua number in [0, 128). For sint32/sint64: 7-bit zigzag range
-64..63 is inlined with bit ops. For bool: always 1 byte via
CHARS[v and 1 or 0] (no fast/slow split). Fixed-width scalars keep the
wire.encode_<type> call shape — already optimal.

Also pre-sizes the parts accumulator with table_new(#v, 0) instead of
{}; same pattern qwt+2sn used decode-side. Eliminates rehash cascade
as elements push.

Tests: 752/752 pass. JIT trace gate: 37/37.

Bench (work.lab.local, median of 3, c_repeated.Holder packed N elems):
  packed_int32:  +90% / +113% / +106%  (N=10/100/1000)
  packed_sint32: +66% / +236% / +156%
  packed_uint32: +73% / +105% / +102%
  packed_bool:   +44% / +51% / +39%
  packed_int64:  +22% / +21% / +23%  (cdata; gain from table_new only)

Headline hello.Person 1KB +3.6%, proto2 BenchPayload mid +10.5%.

See bench/PERF_LOG.md 2026-05-24 aah entry for the full breakdown
including the sint32 +236% mid-size analysis (three function layers
collapsed into one CHARS lookup).