M1 · frozen before collection
Repeated cold and warm Chrome launches
Corpus status: not collected. This preregistration fixes the schedule, stopping rule, Chrome build, cache strata, source hashes, failure accounting, and permit envelope. The published envelope grants no browser authorization.
Pinned M1 artifacts, sources, and binaries
The controlled sum-u32 experiment pins exact source implementations, build recipes, and binary hashes:
- Machine-readable experiment: m1-chrome-sum-u32-v1.json
- Build manifest: build-manifest.json
- JavaScript baseline source: workload.js
- Raw WAT source (Track A): sum_u32.wat
- Raw WAT SIMD source (Track B): sum_u32_simd.wat
- Compiled WebAssembly binary: sum-u32.wasm (96 B)
- Interactive runner: sum-u32 benchmark page
Fixed denominator
- Cache strata
- Cold and warm, never pooled
- Minimum
- 20 committed pairs before analysis
- Fixed cap
- 60 attempted launches per stratum
- Maximum envelope
- 120 owned Chrome launches
Each fresh launch measures both exact variants in a balanced order. A pair enters timing summaries only when both records pass output, fixed-work, source/artifact, cache, provenance, and cleanup checks. Partial pairs, failed launches, and blocked launches stay in the denominator; they supply no timing pair and receive no substitute or automatic retry.
Stopping and uncertainty
Precision is checked after 20, 30, 40, 50, and 60 attempts in each stratum, provided at least 20 pairs have committed. Every checkpoint uses a two-sided exact distribution-free sign/order-statistic interval for the median paired log ratio at alpha 0.01. Bonferroni assigns the family-wise alpha of 0.05 across the five checks. For an even sample count, the point estimate averages the two central values.
The stratum stops once the finite interval has multiplicative half-width at most 3%. At 60 attempts, its state becomes precision-met or cap-inconclusive; the latter also applies when failures leave fewer than 20 committed pairs. A deterministic 10,000-resample bootstrap of per-launch paired log ratios supplies descriptive sensitivity. It does not control confidence or stopping, and it rejects absolute differences and target medians as inputs.
Exact scope
- Google Chrome for Testing 150.0.7871.24 with exact binary SHA-256 and ordinary cache enabled.
- Exact local origin, source commit, benchmark, build manifest, input, oracle, JavaScript, and Wasm hashes.
- Cold profiles have no priming, Service Worker, or origin storage; warm profiles prime only the three exact assets.
- Headline launches are uninstrumented: no profiler, trace, heap snapshot, forced GC, or memory polling.
- CDP, process-memory, tiering, and heap diagnostics require separate launches and a separate permit; they cannot enter headline cells.
- Unavailable evidence remains typed with a reason and is never changed to numeric zero.
Authorization boundary
The JSON contains a template-only-not-consumed envelope bound to the experiment, origin, Chrome version and hash, deadline, operation, and 60-launch cap per stratum. Collection requires a separate permit tied to Paul’s explicit request, and the collector consumes that permit atomically. Publishing this page consumes nothing and starts no browser.
Suite-wide experimental architecture (49 demos across 38 workloads)
In addition to the frozen M1 single-workload preregistration, the benchmark suite evaluates 49 runnable in-browser demos across 38 catalog workloads under three controlled progression stages and three strictly isolated measurement scopes (see methodology):
- Group 1 — Core Baseline (JavaScript vs Raw WAT): First-principles comparison between handwritten JavaScript and handwritten WebAssembly bytecode text before compiler transformations.
- Group 2 — Multi-Language Comparison (Track A Controlled): Identical algorithms implemented across compiled language toolchains (C, C++, Rust, AssemblyScript, and Dart with WasmGC or typed memory).
- Group 3 — Idiomatic & Hardware Optimizations (Track B): Specialized optimizations including 128-bit SIMD vectorization and cache blocking, evaluated against each target's own baseline alongside local exploratory experiments.
Each workload separates measurements into Kernel compute (bare in-memory loop on pre-instantiated engines), Task pipeline (worker dispatch, serialization, and oracle verification), and Real-DOM journey (driving real DOM nodes in an inspectable iframe stage).