bench/boundary: the host-boundary microbench - #56
Merged
Merged
Conversation
The standing instrument behind #17's jco-vs-deltic baseline, #54's lift-throughput finding, and #8's cost ledger: a wit-bindgen guest looping echo-shaped host imports (send / recv / sync-lowered control, immediate and microtask-settled host modes, 0 and 1200 B payloads), driven on the SAME engine for every lane - plain node runs the callback ABI with no flag; the jco lane and deltic's jspi mode share the JSPI flag - so engine variables cancel and the clock sees lift/lower + dispatch + suspension machinery. just bench-boundary # deltic lanes vs the CURRENT tree just bench-boundary with-jco # + the incumbent jco lane The deltic lanes build the local embedder bundle and translator, so the same lane tracked across commits is a boundary-perf regression sentinel (the recv@1200 rows watch #54's fix). Baseline table and reading recorded in bench/boundary/README.md; headline: deltic callback ABI sustains 0.4-1.2M async crossings/s where jco's async import path costs ~3ms per call flat, and #54's per-element list<u8> lift caps host->guest payloads at ~22 MB/s against ~6.4 GB/s the other way. Manual instrument, not a gate (numbers are box-relative). The jco lane pins the family's own toolchain tarballs + the vendored wrapper and retires with the jco era.
lann
enabled auto-merge
August 10, 2026 21:49
lann
disabled auto-merge
August 10, 2026 21:49
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The standing instrument behind #17's jco-vs-deltic baseline, #54's lift-throughput finding, and #8's cost ledger — a wit-bindgen guest looping echo-shaped host imports, all lanes on the same engine (plain node = callback ABI, no flag; jco + deltic-jspi share the JSPI flag), so what the clock sees is lift/lower + dispatch + suspension machinery, not engine or harness deltas.
just bench-boundary— deltic lanes (node callback + jspi, deno) against the current tree (local bundle + translator): the cross-commit regression sentinel,recv@1200rows watching cabi: host->guest list<u8> lift is per-element (~22 MB/s ceiling); guest->host lower is bulk (~6.4 GB/s) #54's fix.just bench-boundary with-jco— adds the incumbent jco lane (the family's own toolchain tarballs + vendored wrapper + polymorph-testbindImports; retires with the jco era).Baseline (README): deltic callback sustains 0.4–1.2 M async crossings/s; jco's async import path costs ~3 ms/call flat (sync path healthy — it's the task loop, i.e. the lann/jco#11 machinery); #54's per-element
list<u8>lift caps host→guest at ~22 MB/s vs ~6.4 GB/s the other way; jspi runs ~2× behind callback on deferred settlements (for #8's ledger).Manual instrument, not a gate — numbers are box-relative; nothing joins
gates/CI.