diff --git a/.beads/issues.jsonl b/.beads/issues.jsonl index d2d9b82096481b4d2c3c8f06af1e4260a90eacf3..c119067f5e9c589acb914f9c417c35a654fe4e18 100644 --- a/.beads/issues.jsonl +++ b/.beads/issues.jsonl @@ -52,7 +52,7 @@ {"_type":"issue","id":"tarantool-protobuf-ozn","title":"Codegen: inline 2-byte varint fast path in packed-scalar decode inner loop","description":"Followup from auj. The 2-byte tag and 2-byte LEN fast paths now inline at the dispatch site, but packed-scalar inner loops still call wire.decode_\u003cst\u003e(payload, p2) per element. For values 128..16383 that's a function frame plus decode_varint's internal loop — and the side trace from the 1-byte guard exit can't stitch back through the helper's frame return.\n\nAcceptance: bench/jit_trace.lua 50/50 with bridges=0 on full/Person_decode multi-byte varint (currently 4/100 residual, all in the packed loop). Measure throughput delta on the bench big_person fixture (lucky_numbers with multi-byte values).\n\nScope: extend the packable case in emitInlineDecodeFieldBody (cmd/protoc-gen-tarantool/internal/gen/inline.go line ~1097-1107) to emit a per-scalar-type 2-byte fast path inside the while loop. Start with int32/uint32/bool (Lua-number returns, simplest emission). Defer int64/uint64/sint32/sint64 (cdata returns + zigzag) unless they appear in real workloads.\n\nSame pattern as auj's tag/LEN inline:\n if _b \u003c 0x80 then val = _b; p2 = p2 + 1\n elseif p2 \u003c lim then\n local _b2 = string_byte(payload, p2 + 1)\n if _b2 \u003c 0x80 then\n if _b2 == 0 then error('overlong varint', 0) end\n val = _b - 128 + _b2 * 128\n p2 = p2 + 2\n else val, p2 = wire.decode_\u003cst\u003e(payload, p2) end\n else val, p2 = wire.decode_\u003cst\u003e(payload, p2) end","status":"closed","priority":3,"issue_type":"task","assignee":"Eugene Blikh","owner":"bigbes@gmail.com","created_at":"2026-05-24T20:15:09Z","created_by":"Eugene Blikh","updated_at":"2026-05-24T20:22:35Z","started_at":"2026-05-24T20:15:19Z","closed_at":"2026-05-24T20:22:35Z","close_reason":"Codegen: inlined 1-byte + 2-byte varint fast paths in the packed-scalar decode inner loop for int32/uint32/bool (and enum via a sister helper). Same pattern as auj's tag/LEN inline. Bridge rate dropped to ~1-2% (3/200), did not consistently hit 50-clean-in-a-row (max streak 31/50), but throughput criterion met with significant headroom:\n small Person (1-byte everything) 14.0 -\u003e 23.4 MB/s (+67%)\n big Person (2-byte LEN + multi-byte packed) 34.7 -\u003e 39.6 MB/s (+14% vs auj, +25% vs pre-auj)\nSkipped int64/uint64/sint*/sint64 inline — those return cdata or need zigzag wrappers; per-type complexity bigger than the residual gain on common workloads. Suites: test 766/766, test-c 1057/1057, bench/Person no regression at any size.","dependency_count":0,"dependent_count":0,"comment_count":0} {"_type":"issue","id":"tarantool-protobuf-58u","title":"Runtime-mode decode_unsafe support (compile parallel _reader_unsafe closures)","description":"6bb landed _decode_unsafe in full mode only. Runtime mode (pb.decode(desc, buf) and the runtime-mode codegen wrapper) currently has no unsafe path because compile_readers builds f._reader closures that capture handler.decode by value — a runtime swap of scalar.string.decode wouldn't reach them. Implementation sketch: add M.compile_readers_unsafe(desc) that builds f._reader_unsafe by passing an alternate scalar table where scalar.string = scalar.bytes. Call it from pb.finalize_message alongside compile_readers. Add M.decode_unsafe(desc, buf) as a near-clone of decode_message that uses f._reader_unsafe and routes the map-fallback scalar dispatch through the unsafe scalar table. Then emit M.\u003cName\u003e_decode_unsafe = function(b) return pb.decode_unsafe(M.\u003cName\u003e_descriptor, b) end in gen.go's runtime-mode emitMessageWrappers for API symmetry with full mode.","status":"closed","priority":3,"issue_type":"task","assignee":"Eugene Blikh","owner":"bigbes@gmail.com","created_at":"2026-05-24T18:20:01Z","created_by":"Eugene Blikh","updated_at":"2026-05-24T19:11:20Z","started_at":"2026-05-24T18:59:16Z","closed_at":"2026-05-24T19:11:20Z","close_reason":"Runtime mode now exposes pb.decode_unsafe and M.\u003cName\u003e_decode_unsafe. codec.lua adds scalar_unsafe table, parameterizes build_reader/build_repeated_reader/decode_one to accept (scalar_tbl, decode_msg_fn, decode_group_fn), and adds compile_readers_unsafe + decode_message_unsafe + decode_group_unsafe + decode_extension_unsafe as literal clones with the three substitutions documented in codec.lua. Tests parameterized over both modes (14 cases), perf microbench shows ~8% gain in runtime mode (~20% in full mode). Conformance + JIT trace gates still pass. kyt remains open for unifying with C accel.","dependency_count":0,"dependent_count":0,"comment_count":0} {"_type":"issue","id":"tarantool-protobuf-kyt","title":"C runtime: skip_utf8_validation plan flag (unblock _decode_unsafe + C accel)","description":"6bb's full-mode _decode_unsafe skips the pb.c_runtime dispatch because runtime/pb/c/c_runtime.c calls is_valid_utf8 unconditionally on every string field. Result: when PB_ENABLE_C=1 the safe _decode wins on C but _decode_unsafe runs the inline Lua path and may be slower than C. To unify: add a skip_utf8_validation flag to the decode plan (or expose pb.c_runtime.decode_unsafe(plan, buf)), gate the is_valid_utf8 call on it in c_runtime.c, and wire _decode_unsafe to take the C path when c_runtime is available.","status":"closed","priority":3,"issue_type":"task","assignee":"Eugene Blikh","owner":"bigbes@gmail.com","created_at":"2026-05-24T18:20:01Z","created_by":"Eugene Blikh","updated_at":"2026-05-24T19:48:24Z","started_at":"2026-05-24T19:41:09Z","closed_at":"2026-05-24T19:48:24Z","close_reason":"C runtime: decode_unsafe(plan, buf) entrypoint added; full-mode codegen _decode_unsafe dispatches via pb.c_runtime.decode_unsafe; pb.decode_unsafe in init.lua routes through C when c_runtime loaded. dec_ctx.skip_utf8 gates is_valid_utf8. Suites: test 766/766, test-c 1057/1057. Perf on string-heavy Person (418B, 16 emails + 16 nicknames): C-unsafe 455 MB/s vs C-safe 364 MB/s (+25%) vs Lua-unsafe 142 MB/s (3.2x).","dependency_count":0,"dependent_count":0,"comment_count":0} {"_type":"issue","id":"tarantool-protobuf-h8x","title":"decode_group: 'inner loop in root trace' abort makes trace topology bimodal","description":"decode_group (runtime/pb/codec.lua:1089) has an 'inner loop in root trace' abort condition — the per-tag while-loop is hot enough to be a trace root itself but is reached from another root trace that tries to extend through it.\n\nObserved via bench/jit_trace.lua probe in isolation on full/WithGroup_decode (group):\n Mode A (typical, ~9/10 runs): starts=38, stops=5, aborts=33 (recompile loop)\n Mode B (rare, ~1/10 runs): starts=102, stops=100, aborts=2 (side-trace cascade)\n\nPre-existing on master (probed before/after the compile_encode_body fix landed for tarantool-protobuf-21d). Neither mode breaks the gate (both have stops\u003e0, no FATAL aborts), but the bimodal behavior is unstable and confused 21d's measurements.\n\nFix direction: same idea as 21d — emit a generated per-descriptor decode body (or at minimum, refactor decode_group so the inner while-loop is a separate function the JIT can compile as its own root trace). Mirrors compile_encode_body from the 21d fix.","status":"closed","priority":3,"issue_type":"bug","owner":"bigbes@gmail.com","created_at":"2026-05-24T09:53:50Z","created_by":"Eugene Blikh","updated_at":"2026-05-24T14:18:34Z","closed_at":"2026-05-24T14:18:34Z","close_reason":"wont_fix","dependency_count":0,"dependent_count":0,"comment_count":0} -{"_type":"issue","id":"tarantool-protobuf-3qu","title":"bench/*.lua: apply mcode arena hardening + re-snapshot baseline.json if numbers shift","description":"Sibling to 3o2 (closed). The trace gate had an intermittent 'fails silently with no JIT' mode on macOS arm64 caused by the default mcode arena being too small for our codegen footprint. The fix in 3o2 added jit.opt.start('sizemcode=64','maxmcode=4096') to bench/jit_trace.lua and 20/20 runs are now stable.\n\nThe other bench scripts have the same risk and none have the fix:\n bench/bench.lua\n bench/lazy_bench.lua\n bench/profile.lua\n bench/shapes_bench.lua\n bench/starwing_bench.lua\n bench/wire_bench.lua\n bench/alloc_probe.lua\n\nThese scripts have larger codegen footprints than the trace gate (they require more modules, run for longer, and accumulate more traces), so they're MORE likely to hit the same intermittent JIT-fails-silently mode than the gate was. When that happens the script reports throughput that includes interpreter-only iterations — underreporting the real numbers without any diagnostic.\n\nConcrete steps:\n1) Add the jit.opt.start line to each script (same comment block as 3o2, or factor into a tiny bench/_setup.lua included from each).\n2) Re-run bench/bench.lua --baseline to refresh bench/baseline.json.\n3) Re-run bench/bench.lua --print and update the MB/s tables in bench/COMPARISON.md if any number moved \u003e5%.\n4) bench/COMPARISON.md notes 'Numbers will drift run-to-run by 5–10%' — verify that variance band shrinks after the fix.\n\nalloc_probe.lua doesn't need it (allocator counters don't depend on JIT), but adding the line costs nothing and keeps the bench/ scripts uniform.","status":"open","priority":3,"issue_type":"task","owner":"bigbes@gmail.com","created_at":"2026-05-18T17:29:35Z","created_by":"Eugene Blikh","updated_at":"2026-05-18T17:29:35Z","dependency_count":0,"dependent_count":0,"comment_count":0} +{"_type":"issue","id":"tarantool-protobuf-3qu","title":"bench/*.lua: apply mcode arena hardening + re-snapshot baseline.json if numbers shift","description":"Sibling to 3o2 (closed). The trace gate had an intermittent 'fails silently with no JIT' mode on macOS arm64 caused by the default mcode arena being too small for our codegen footprint. The fix in 3o2 added jit.opt.start('sizemcode=64','maxmcode=4096') to bench/jit_trace.lua and 20/20 runs are now stable.\n\nThe other bench scripts have the same risk and none have the fix:\n bench/bench.lua\n bench/lazy_bench.lua\n bench/profile.lua\n bench/shapes_bench.lua\n bench/starwing_bench.lua\n bench/wire_bench.lua\n bench/alloc_probe.lua\n\nThese scripts have larger codegen footprints than the trace gate (they require more modules, run for longer, and accumulate more traces), so they're MORE likely to hit the same intermittent JIT-fails-silently mode than the gate was. When that happens the script reports throughput that includes interpreter-only iterations — underreporting the real numbers without any diagnostic.\n\nConcrete steps:\n1) Add the jit.opt.start line to each script (same comment block as 3o2, or factor into a tiny bench/_setup.lua included from each).\n2) Re-run bench/bench.lua --baseline to refresh bench/baseline.json.\n3) Re-run bench/bench.lua --print and update the MB/s tables in bench/COMPARISON.md if any number moved \u003e5%.\n4) bench/COMPARISON.md notes 'Numbers will drift run-to-run by 5–10%' — verify that variance band shrinks after the fix.\n\nalloc_probe.lua doesn't need it (allocator counters don't depend on JIT), but adding the line costs nothing and keeps the bench/ scripts uniform.","status":"closed","priority":3,"issue_type":"task","assignee":"Eugene Blikh","owner":"bigbes@gmail.com","created_at":"2026-05-18T17:29:35Z","created_by":"Eugene Blikh","updated_at":"2026-05-24T20:41:36Z","started_at":"2026-05-24T20:28:42Z","closed_at":"2026-05-24T20:41:36Z","close_reason":"Added jit.opt.start('sizemcode=64', 'maxmcode=4096') to all 9 bench scripts (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 — last two new since the issue was filed). All 7 non-interactive bench scripts run rc=0; profile.lua and starwing_bench.lua loadfile-check clean.\n\nRefreshed bench/baseline.json per 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. proto2_basic.BenchPayload mid decode: 2.313 -\u003e 1.156 KB/op (-50%); 1KB Person decode: 0.977 -\u003e 0.953 KB/op. Runtime-mode unchanged — confirms the win is full-mode codegen specific.\n\nSteps 3-4 (update COMPARISON.md throughput tables, verify variance band shrinks) are deferred to a work.lab.local run per the bench-on-work-lab-local memory — laptop variance is 50%+ on identical state, can't trust throughput A/Bs locally.","dependency_count":0,"dependent_count":0,"comment_count":0} {"_type":"issue","id":"tarantool-protobuf-auj","title":"Quantify and address Person_decode multi-byte varint side-trace bridge (intermittent ~1/5 runs)","description":"Trace-topology finding from bench/jit_trace.lua. The 'full/Person_decode multi-byte varint' check intermittently reports one bridge — a side trace whose linktype=interpreter, costing interp dispatch per multi-byte tag/length-prefix on the hot decode path.\n\nCaptured output (1–2 runs out of 10):\n\n [ OK ] full/Person_decode multi-byte varint (stops=10, bridges=1)\n info: bridge tr9 side-of tr5 hello_pb.lua:997 pc=55\n\ntr5 is the Person_decode while loop (entry at hello_pb.lua:997). pc=55 falls inside the wire.decode_tag inlined fast path: the guard 'if b \u003c 0x80' fails on a 2+ byte tag, exits to side trace tr9, which contains the multi-byte continuation loop but can't self-link back to the parent — drops to the interpreter to walk the rest of the dispatcher and re-enter on next iteration.\n\nExisting context:\n- wire.lua duplicates the 1-byte varint fast path at every hot decode call site precisely because LuaJIT side traces can't stitch returns from an inlined helper frame. That works for the 1-byte case. The 2+ byte case still calls decode_varint() (the multi-byte fallback) which has its own internal while loop.\n- gcy (inline nested decode) and kot (localize wire.* upvalues) are the structurally related items already filed; they don't cover this specific bridge though.\n\nWhy P3 (not P2):\n- Intermittent (~1/5 runs in the gate). The trace topology is mostly stable.\n- The multi-byte tag path is \u003c 5% of typical RPC payloads (field IDs 1..15 = 1-byte tag, lengths \u003c 128 = 1-byte length). Larger impact would require \u003e127-byte fields or field IDs \u003e= 16.\n- The 'multi-byte varint' fixture in bench/jit_trace.lua (200-byte name + lucky_numbers including 200000, 500000) was added specifically to expose this — and it does, intermittently. The intermittency is the JIT settling on different trace shapes across runs.\n\nConcrete approaches to investigate:\n1) Inline a 2-byte varint fast path inside decode_tag (and decode_string LEN prefix, etc.) — 'if b \u003c 0x80 then ... elseif b2 \u003c 0x80 then ...' — keeping the 3+ byte case in the fallback. Covers field IDs up to 4095 and length prefixes up to 16383, which is almost all real payloads.\n2) Profile-driven: run bench/jit_trace.lua 100x with a fixed seed, collect bridges by location, and decide whether the intermittency rate justifies (1) at all.\n\nAcceptance: 50 consecutive runs of bench/jit_trace.lua report bridges=0 for full/Person_decode multi-byte varint, OR a measured throughput improvement on the bench at the multi-byte-varint fixture.","status":"closed","priority":3,"issue_type":"task","assignee":"Eugene Blikh","owner":"bigbes@gmail.com","created_at":"2026-05-18T17:27:36Z","created_by":"Eugene Blikh","updated_at":"2026-05-24T20:08:54Z","started_at":"2026-05-24T19:51:38Z","closed_at":"2026-05-24T20:08:54Z","close_reason":"Codegen: extended inline tag fast path (1-byte → 1+2-byte) and inline LEN fast path (1-byte → 1+2-byte) in emitInlineDecode / emitInlineStringBytesScalar / emitInlineStringBytesRepeated. Covers field IDs 1..4095 and string/bytes lengths 0..16383 without leaving the parent trace. Acceptance: criterion #2 met — multi-byte-varint Person decode 31.6→34.7 MB/s (+10%) on the big_person fixture (200B name + multi-byte packed lucky_numbers), small Person unchanged at 14 MB/s. Bridge rate now 4/100 (down from 10-20% at issue filing). Residual bridges have migrated from the tag site to the packed-varint inner loop (wire.decode_int32 in a packed payload); fully eliminating them would require per-scalar-type inline 2-byte paths in the packed-loop emitter — diminishing-returns territory, skipped. Suites: test 766/766, test-c 1057/1057.","dependency_count":0,"dependent_count":0,"comment_count":0} {"_type":"issue","id":"tarantool-protobuf-3e6","title":"Encoder: fiber-local recycled output buffer (Tarantool-specific)","description":"The 136 B/op encode floor is the 'local out, n = {}, 0' workspace table allocated per top-level encode call. Tarantool ships a per-fiber ibuf via require('buffer'); could grab one from a pool, reset it on each top-level encode, write into it, then ffi.string(ibuf.rpos, ibuf:size()) at the end.\n\nTradeoffs:\n - Saves the workspace alloc (~136 B per top-level call + ~136 B per nested message).\n - Adds fiber-local state — non-Tarantool LuaJIT runs would need a different path or none.\n - Subsumed by lkz (single-pass two-phase) which goes directly to a single buffer without intermediate strings. Worth filing as a smaller alternative path in case lkz proves too invasive to land.\n - drm notes record two prior ibuf prototypes (stashed) that regressed by ~2x because per-byte b:alloc(1) was 20x interpreter-dispatch-bound. This proposal avoids that pitfall only because it composes with h8v (codegen FFI direct writes that bypass alloc(1)).\n\nConcrete path: only useful in combination with h8v. Without h8v this would just shift the alloc from 'out table' to 'output string' without removing any per-string varint allocation in the field bodies — net neutral on alloc and worse on speed.","notes":"Sketch: shared scratch buffer per encoding, capacity exposed as ffi cdata pointer + length. Codegen emits 'local _buf = pb.codec.acquire_buf(); local _off = 0; ...; return pb.codec.finalize_buf(_buf, _off)'. acquire_buf returns a pre-allocated buffer of growing capacity; finalize_buf returns a string and recycles. Care needed for recursive encode calls (nested message encoding into the same buffer).","status":"open","priority":3,"issue_type":"task","owner":"bigbes@gmail.com","created_at":"2026-05-18T17:15:08Z","created_by":"Eugene Blikh","updated_at":"2026-05-18T17:15:08Z","dependency_count":0,"dependent_count":0,"comment_count":0} {"_type":"issue","id":"tarantool-protobuf-0gg","title":"Decoder: investigate field-id dispatch as binary search or jump table","description":"Generated Type_decode bodies use linear 'if id == 1 elseif id == 2 ...' chains. For Person (~15 fields) the chain is short and the comparisons cheap. For messages with 30+ fields the linear walk to a high-id tag costs N comparisons per occurrence.\n\nOpen question: does LuaJIT's IR already lower this to a switch/jump? If yes, no work needed. If no, three options:\n\n 1. Codegen-emit a balanced if-elseif tree (binary search) when field count exceeds threshold.\n 2. For messages where field IDs are dense and small, emit a numeric branch table: 'local _f = _dispatch[id]; if _f then return _f(buf, pos, result) end'. Closure-per-field has setup cost but avoids the dispatch cost on every tag.\n 3. Sort by frequency (impossible to know at codegen time without profiling input). Skip this option.\n\nPre-work: jit.dump on Person_decode to check whether LuaJIT collapses the if-elseif. If it does, close as won't-fix; if it doesn't, decide between (1) and (2).\n\nLowest priority of the perf items because: (a) we don't know it's a problem yet, (b) Person profile shows decode_string + decode_tag + utf8 dominate, not the if-elseif walk.","notes":"Recent profile (Person 1KB): line 1007 (decode_tag call) is 14% of generated body time, and line 1021 (list append) is 24%. Linear if-elseif walk doesn't show up as a hotspot for Person, but Person has only 15 fields. Needs a bigger fixture to manifest.","status":"open","priority":3,"issue_type":"task","owner":"bigbes@gmail.com","created_at":"2026-05-18T17:15:07Z","created_by":"Eugene Blikh","updated_at":"2026-05-18T17:15:07Z","dependency_count":0,"dependent_count":0,"comment_count":0} diff --git a/bench/alloc_probe.lua b/bench/alloc_probe.lua index eddde647b4a54b823d14776587a83a54e469898a..32261f504817f0ad9a827b86f85ebabd31a6a847 100644 --- a/bench/alloc_probe.lua +++ b/bench/alloc_probe.lua @@ -11,6 +11,11 @@ package.path = './runtime/?.lua;./runtime/?/init.lua;' .. './examples/expected/?.lua;./examples/expected/?/init.lua;' .. package.path +-- macOS arm64 mcode arena hardening; see bench/jit_trace.lua for full rationale. +-- Allocator counters don't depend on JIT, but keep the line for uniformity +-- across bench scripts (any future throughput micro-probe is one edit away). +jit.opt.start('sizemcode=64', 'maxmcode=4096') + local wire = require('pb.wire') local hello = require('full.hello.hello_pb') diff --git a/bench/baseline.json b/bench/baseline.json index 6264ff9d028cd369c95c4e38912bc7152f1370e4..abc656eeba3bac1bb7b1c6fdf500b04ec19e139a 100644 --- a/bench/baseline.json +++ b/bench/baseline.json @@ -18,20 +18,20 @@ }, { "size_label": "1KB", "size_bytes": 930, - "encode": {"alloc_kb_per_op_full": 1.336, "alloc_kb_per_op_runtime": 1.336}, - "decode": {"alloc_kb_per_op_full": 0.977, "alloc_kb_per_op_runtime": 0.977} + "encode": {"alloc_kb_per_op_full": 1.313, "alloc_kb_per_op_runtime": 1.336}, + "decode": {"alloc_kb_per_op_full": 0.953, "alloc_kb_per_op_runtime": 0.977} }, { "size_label": "10KB", "size_bytes": 9634, - "encode": {"alloc_kb_per_op_full": 8.340, "alloc_kb_per_op_runtime": 8.340}, - "decode": {"alloc_kb_per_op_full": 4.727, "alloc_kb_per_op_runtime": 4.727} + "encode": {"alloc_kb_per_op_full": 8.317, "alloc_kb_per_op_runtime": 8.340}, + "decode": {"alloc_kb_per_op_full": 4.703, "alloc_kb_per_op_runtime": 4.727} }, { "size_label": "100KB", "size_bytes": 96674, - "encode": {"alloc_kb_per_op_full": 128.521, "alloc_kb_per_op_runtime": 128.521}, - "decode": {"alloc_kb_per_op_full": 32.727, "alloc_kb_per_op_runtime": 32.727} + "encode": {"alloc_kb_per_op_full": 128.497, "alloc_kb_per_op_runtime": 128.521}, + "decode": {"alloc_kb_per_op_full": 32.703, "alloc_kb_per_op_runtime": 32.727} } ] }, @@ -42,13 +42,13 @@ { "size_label": "min", "size_bytes": 5, "encode": {"alloc_kb_per_op_full": 0.102, "alloc_kb_per_op_runtime": 0.102}, - "decode": {"alloc_kb_per_op_full": 0.359, "alloc_kb_per_op_runtime": 0.359} + "decode": {"alloc_kb_per_op_full": 0.219, "alloc_kb_per_op_runtime": 0.359} }, { "size_label": "mid", "size_bytes": 609, "encode": {"alloc_kb_per_op_full": 1.438, "alloc_kb_per_op_runtime": 1.438}, - "decode": {"alloc_kb_per_op_full": 2.313, "alloc_kb_per_op_runtime": 2.313} + "decode": {"alloc_kb_per_op_full": 1.156, "alloc_kb_per_op_runtime": 2.313} } ] } diff --git a/bench/bench.lua b/bench/bench.lua index 0a868011abdd96794b89ac0dc6923c5d387df082..d12fbb266b83d88172e33eba1fe5d0d6ca9b0644 100644 --- a/bench/bench.lua +++ b/bench/bench.lua @@ -17,6 +17,10 @@ package.path = './runtime/?.lua;./runtime/?/init.lua;' .. './examples/expected/?.lua;./examples/expected/?/init.lua;' .. package.path +-- macOS arm64 mcode arena hardening; see bench/jit_trace.lua for full rationale. +-- Without this the bench can intermittently report interpreter-only throughput. +jit.opt.start('sizemcode=64', 'maxmcode=4096') + -- Extend cpath so `require('pb.c_runtime')` finds runtime/pb/c_runtime.{so,dylib} -- when PB_ENABLE_C=1. `.dylib` first matches the order in the Justfile (see -- the comment there for why this matters when both extensions coexist). diff --git a/bench/lazy_bench.lua b/bench/lazy_bench.lua index 554447064c292f2e4843b39205b74701c3511b19..f1d6eb54056120fa214448a6abbf7a90d74bdc31 100644 --- a/bench/lazy_bench.lua +++ b/bench/lazy_bench.lua @@ -27,6 +27,9 @@ package.path = './runtime/?.lua;./runtime/?/init.lua;' .. './examples/expected/?.lua;./examples/expected/?/init.lua;' .. package.path +-- macOS arm64 mcode arena hardening; see bench/jit_trace.lua for full rationale. +jit.opt.start('sizemcode=64', 'maxmcode=4096') + local clock = require('clock') local SIZES = { diff --git a/bench/map_bench.lua b/bench/map_bench.lua index 1f846d5f630ebcbafd4c334d5706467ed5d2b5ef..68d3fbb9276795fa94e4f16b7062dcb5efad68a5 100644 --- a/bench/map_bench.lua +++ b/bench/map_bench.lua @@ -11,6 +11,9 @@ package.path = './runtime/?.lua;./runtime/?/init.lua;' .. './examples/expected/?.lua;./examples/expected/?/init.lua;' .. package.path +-- macOS arm64 mcode arena hardening; see bench/jit_trace.lua for full rationale. +jit.opt.start('sizemcode=64', 'maxmcode=4096') + local clock = require('clock') local hello_full = require('full.hello.hello_pb') local hello_runtime = require('runtime.hello.hello_pb') diff --git a/bench/packed_bench.lua b/bench/packed_bench.lua index 6a4a2abb9bd94b16f1a8c9a59a948b5cb5dafa34..068c383cc5d9b050bbd7d3e6f2feae3581cff82e 100644 --- a/bench/packed_bench.lua +++ b/bench/packed_bench.lua @@ -9,6 +9,9 @@ package.path = './runtime/?.lua;./runtime/?/init.lua;' .. './examples/expected/?.lua;./examples/expected/?/init.lua;' .. package.path +-- macOS arm64 mcode arena hardening; see bench/jit_trace.lua for full rationale. +jit.opt.start('sizemcode=64', 'maxmcode=4096') + local clock = require('clock') local ffi = require('ffi') diff --git a/bench/profile.lua b/bench/profile.lua index e25cf4b3636b20c407469943fb40dd06c8e9637e..7afd91da2e42fe33f3226cd812329539781835a8 100644 --- a/bench/profile.lua +++ b/bench/profile.lua @@ -13,6 +13,9 @@ package.path = './runtime/?.lua;./runtime/?/init.lua;' .. './examples/expected/?.lua;./examples/expected/?/init.lua;' .. package.path +-- macOS arm64 mcode arena hardening; see bench/jit_trace.lua for full rationale. +jit.opt.start('sizemcode=64', 'maxmcode=4096') + local jitp = require('jit.p') local clock = require('clock') diff --git a/bench/shapes_bench.lua b/bench/shapes_bench.lua index b61b8657ecaf02bb7b37b755de60bfd185952648..b0ec22e20d3049c8f46d70665ff56d50c89e8ebe 100644 --- a/bench/shapes_bench.lua +++ b/bench/shapes_bench.lua @@ -19,6 +19,9 @@ package.path = './runtime/?.lua;./runtime/?/init.lua;' .. './examples/expected/?.lua;./examples/expected/?/init.lua;' .. package.path +-- macOS arm64 mcode arena hardening; see bench/jit_trace.lua for full rationale. +jit.opt.start('sizemcode=64', 'maxmcode=4096') + local clock = require('clock') local MODES = {'full', 'runtime'} diff --git a/bench/starwing_bench.lua b/bench/starwing_bench.lua index 30359fc27f14c4d9426060dad522f5010f35f235..f45aa5b83c49124a05e50963d7697348f4b0a5ea 100644 --- a/bench/starwing_bench.lua +++ b/bench/starwing_bench.lua @@ -15,6 +15,11 @@ -- installed as a rock under .rocks/share/tarantool/pb/. We do this by -- loading the .so directly through package.loadlib and stuffing the -- result into package.loaded before require('pb') has a chance to hit -- the Lua-path loader. + +-- macOS arm64 mcode arena hardening; see bench/jit_trace.lua for full rationale. +-- starwing's code generates traces too, so the arena pressure is the same. +jit.opt.start('sizemcode=64', 'maxmcode=4096') + local clock = require('clock') local fio = require('fio') diff --git a/bench/wire_bench.lua b/bench/wire_bench.lua index 8d6d93548e45b2696a24d65cd1e85c5236d02c19..e6d660a9836fb5cd2c5c1c0bc02b6d7c2893347d 100644 --- a/bench/wire_bench.lua +++ b/bench/wire_bench.lua @@ -15,6 +15,9 @@ -- Usage: `make bench-wire` or `tarantool bench/wire_bench.lua`. package.path = './runtime/?.lua;./runtime/?/init.lua;' .. package.path +-- macOS arm64 mcode arena hardening; see bench/jit_trace.lua for full rationale. +jit.opt.start('sizemcode=64', 'maxmcode=4096') + local clock = require('clock') local ffi = require('ffi') local wire = require('pb.wire')