Parent: #50 Related: #47, #48, #52
Problem
The accepted comparison is reproducible and symmetric, but its four kernels deliberately exercise paths zig-js has already specialized. Winning those rows does not prove broader call/object/allocation throughput, and a geometric mean over only those kernels is too easy to over-read.
Scope
- add directly comparable workloads for ordinary direct calls, method calls with
this, closure creation/capture, andarguments; - keep recursion as a separate observable workload and retain arithmetic/property/array baselines;
- use the exact same host-API-free source and invocation bytes in both engines;
- return exact deterministic checksums across direct, independent steady/cold, and zig-js shared modes;
- calibrate equal job counts so every full-run engine/mode row clears the publication timing floor without making development runs impractical;
- report per-workload results before aggregates and describe what each kernel does;
- prohibit source text, function-name, or benchmark-name recognition in optimizations.
Acceptance criteria
- Add focused call, method, closure, and
argumentsworkloads with semantic checksums. - Extend harness validation so missing/extra rows and checksum drift fail deterministically.
- Capture initial symmetric evidence and link every losing row to an optimization issue.
- Optimize semantics-preserving general engine paths until zig-js beats JSC in every direct and independent-context row.
- Keep no-GIL shared scaling above 1.0x at every reported lane count.
- Publish one clean full report/TSV and generated README summary only after the expanded matrix passes all gates.
- Batch the expensive full matrix; use focused runner A/B and quick structural validation during development.