Skip to content

feat(benchmarks): the boundary ladder, every rung, with rate and callers sweeps - #9

Closed
Immanuel-Fowler wants to merge 1 commit into
feat/sandbox-crash-and-grantsfrom
feat/boundary-ladder-benchmark
Closed

Immanuel-Fowler wants to merge 1 commit into
feat/sandbox-crash-and-grantsfrom
feat/boundary-ladder-benchmark

Conversation

@Immanuel-Fowler

Copy link
Copy Markdown
Owner

Stacked on #8 (feat/sandbox-crash-and-grants); merge that first.

What

benchmarks/landline_latency measures every rung of the boundary ladder with the same echo handlers, keeping the methodology (warm-up, then measured calls; p50, p90, p99, max; per-payload cases):

  • Rungs: in-process, sandboxed (WASM), secret, Python landline, TypeScript landline, and below a serverlet call, shared let and a plain let, timed per batch of 1,000 statements because clock_micros has microsecond resolution.
  • Payload sweep: int, a 1 KB string, a 1,000-element int[].
  • Call-rate sweep: the int payload paced at 100 Hz and 1 kHz (the caller sleeps between calls, so the actor or child really idles, as under a ticking host) and at 10 kHz (spinning), beside unpaced.
  • Concurrent callers (added at the maintainer's request): 2, 4, and 8 callers sharing one serverlet as branches of a parallel block; each sample is one caller's round trip.
  • Output: run.py writes boundary_ladder.csv, boundary_ladder_samples.csv, boundary_ladder.json, and boundary_ladder.md under benchmarks/results/ (gitignored), with an environment header: CPU, OS, arch, orchestrate, rustc, cargo, Python, TypeScript toolchain and backend, wasmtime version, sample counts, commit SHA, dirty flag. The README's tables are pasted from the generated Markdown.
  • The TypeScript rung is stripped and reported as skipped when Bun or TypeScript 7 is missing (--no-typescript forces it).

What one run showed (Apple M2)

  • The sandbox sits with in-process at the median (8 vs 11 µs); the wasmtime call is small next to the channel hop.
  • Paced at 100 Hz, every rung pays a wake-up: in-process 37 µs, secret 70, Python 78, TypeScript 126 at p50, against 7–46 µs unpaced.
  • Under 8 callers the in-process and sandboxed rungs keep their per-call latency; secret (97 µs), Python (130), and TypeScript (264) queue.
  • shared let costs about 9 ns per statement; the plain let row reads 0 because LLVM folds the loop, which the notes say.

Caveats

Recorded in LIMITATIONS-notes.md: the plain let row is the method's floor, microsecond quantisation under every low p50, the first sweep pays for being first, TypeScript maxima, and that concurrent callers are runtime futures rather than OS threads.

Changelog entry under [Unreleased]. No version bump.

🤖 Generated with Claude Code

…callers sweep

The latency benchmark measured three serverlet kinds. The paper's claim
is about four boundaries and the ownership below them, so the ladder
now has every rung: in-process, sandboxed, secret, Python and TypeScript
serverlets, and below a serverlet call, `shared let` and a plain `let`,
timed per batch of a thousand statements because clock_micros has
microsecond resolution.

Two sweeps join the payload sweep. A call-rate sweep paces the int
payload at 100 Hz and 1 kHz with the caller asleep between calls, so
the actor and the child really go idle as they would under a host that
ticks, and at 10 kHz spinning. A concurrent-callers sweep puts 2, 4 and
8 callers on one serverlet as branches of a parallel block, so every
sample is one caller's round trip and the rows show what queueing
costs; the process-based rungs queue, the in-process and sandboxed ones
do not.

run.py writes CSV, JSON and Markdown under benchmarks/results with an
environment header, and the README's tables are pasted from that output
rather than typed. The loops in main.orch are unrolled on purpose: a
serverlet client has no type a task parameter can name, and a task
cannot reach a top-level binding, so every timed loop lives inline.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant