#bench/c_accel — C acceleration spike

Spike work for tarantool-protobuf-04c (benchmark which Lua↔C boundary wins for protobuf codec work). Not part of the shipping codec; lives under bench/ because its only purpose is measurement.

#Strategies (per the parent ticket)

The acceleration design question is where the Lua↔C boundary should sit. Four candidate boundaries:

1. Pure Lua (baseline) — current mode=full generated code, no C involved. Measured via the existing bench/bench.lua.
2. Per-primitive FFI — wire.lua's encode_varint, decode_string, etc. become ffi.C.<fn> calls. The dispatch loop stays in Lua; only the inner bit-twiddling is in C.
3. One generic C call per message — a C module gets the descriptor and the input table once and owns the inner loop.
4. Hand-written C codec for hello.Person — upper bound. No dispatch, no descriptor walk. Tells us the ceiling.

All four strategies are wired into spike_bench.lua:

• prim.c + prim_ffi.lua — Strategy 2 (FFI primitives)
• generic_codec.c — Strategy 3 (one generic C call, descriptor-walking)
• person_codec.c — Strategy 4 (hand-written for hello.Person)

#Scope

Both person_codec.c and generic_codec.c implement only the Person fields exercised by bench/bench.lua's payload builder: name, age, emails, address (with street/city/zip), lucky_numbers. The spike measures perf, not coverage.

generic_codec.c walks a hand-built message_desc_t / field_desc_t. A real ra6 would build these descriptors from the Lua descriptor at pb.finalize_message time and pass them through a registered userdata.

The generic decode caches per-field stack indices for repeated / packed arrays for the duration of decode_message, so each lua_setfield of the array root into the result table happens once, not per element. That matches person_codec.c's pattern; the naive "lazy lookup per element" version (initial commit) was ~2× slower than hand-written at 100 KB.

#Build and run

make -C bench/c_accel               # builds pb_c_person.dylib
tarantool bench/c_accel/spike_bench.lua

Override the Tarantool include dir if auto-detection fails:

make -C bench/c_accel TT_INC=/path/to/include/tarantool

#Results — 2026-05-18

Apple M-series, Tarantool 3.8.0-entrypoint-49 / LuaJIT 2.1.0-beta3. Throughput msg/s; bandwidth MB/s. ×L columns are speedup vs the pure-Lua baseline.

#Encode

#Decode

#What the numbers say

• The C boundary is cheap; per-primitive FFI is not. Crossing the C boundary once per message wins 3–11×. Crossing it tens of times per message (S2) loses — pure-Lua decode is 3× faster than FFI-primitive decode because LuaJIT inlines its own wire helpers but a ffi.load'd library's per-call dispatch is several hundred ns.
• S3 ≈ S4 within ±15% at every size, and S3 beats S4 on encode at 1 KB+ (the descriptor-walk loop is uniformly branch- predictable; the hand-written codec has more divergent per-field paths).
• C encode plateaus at ~2.5–2.9 GB/s from 1 KB upward. The bottleneck moves to Lua table reads and output string allocation, not wire formatting.
• C decode degrades much more gracefully than Lua decode. Pure-Lua decode is per-byte cliff-y (158 k msg/s @ 1KB → 2.3 k @ 100KB); C decode degrades roughly linearly with size, hitting 2.5 GB/s at 100KB.
• The cache-the-repeated-array-stack-idx pattern is required: the naive lazy-getfield version was ~2× slower than hand-written at 100 KB. ra6 must encode this.

#What this means for the architecture (pf6)

• Ship ra6 (generic C runtime, one C call per message). It's the message-level boundary and S3 lands within noise of the hand-written ceiling. 3–11× over pure Lua at every size.
• Drop c0i (codegen-emitted per-message C). ≤15% headroom over ra6, going the wrong way at scale. The codegen complexity isn't justified.
• Drop per-primitive FFI as an architecture. S2 loses to pure Lua at every size ≥1 KB on encode and at every size on decode. The boundary is too chatty.
• The result-table allocation in C still goes through the Lua runtime, so very-small-message C wins are capped (~3× at 10B encode). Worth knowing for ra6 — the floor is the Lua side of the boundary, not the wire layer.