From JetStream to Silicon: Bridging Browser Benchmarks and CPU Design
JetStream 3 deliberately moved away from microbenchmarks, and for browser engineers that was the right call. Small, tight loops once let engines win benchmarks without making real web apps faster.
Pre-silicon CPU teams face the opposite problem. They need to know how a chip that doesn't exist yet will run browser workloads, and a full JavaScript suite is nearly impossible to run on a simulator. The answer is not to abandon microbenchmarks, but to build ones that are correlated with workloads like JetStream.
Why JetStream breaks down before silicon
Simulation is too slow. A JetStream run in V8's d8 shell takes tens of seconds on real hardware, which means hundreds of billions of instructions. Cycle-accurate simulators typically run well under a million instructions per second, so one data point can take days. Design exploration needs hundreds.
The JIT changes the program. V8 decides when to tier code up from its interpreter to optimizing compilers based on timing and background compiler threads. On a simulator, timing differs, so the engine generates different machine code and triggers garbage collection at different moments. You end up simulating a different workload from the one you profiled on hardware.
Sampling breaks. Techniques like SimPoint rely on stable code addresses to pick representative regions. JIT code is generated at runtime and lands at different addresses every run.
It needs a full system. Even the lightweight shell needs an OS, libraries, file I/O and threads, forcing slower full-system simulation.
One score hides the cause. A composite score can't tell an architect what happens if the branch target buffer doubles in size.
Correlated microbenchmarks, driven by Python
The fix is small, deterministic native kernels, each isolating one mechanism: branch predictor pressure, instruction-cache footprint, cache-line contention or prefetch accuracy. They run in millions of instructions, generate identical code every time, and map directly to design knobs.
What makes them trustworthy is correlation. A weighted suite is tuned to reproduce JetStream's hardware counter fingerprint, including IPC, cache misses per thousand instructions and branch mispredictions. You validate that correlation on today's silicon, where JetStream can run, then rely on the suite where it can't.
Python is the engine around the kernels, not the kernels themselves. It generates parametric variants, drives identical runs across silicon, emulators and simulators, and handles counter analysis and correlation fitting. Pure Python loops would just swap V8's runtime for CPython's.
How Whileone approaches it
At Whileone Techsoft, we follow a four-step path from browser workload to pre-silicon proxy:
Characterize on silicon. We profile JetStream in both Chrome and the d8 shell on current Arm and x86 hardware, using top-down analysis and hardware counters to build each workload's bottleneck fingerprint.
Map to a micro library. Our microbenchmarks target the mechanisms browser workloads stress most: cache-line bouncing, atomic operations, branch predictor pressure and prefetch accuracy, across both architectures.
Validate the correlation. We weight the suite to match each fingerprint, then test it across multiple platforms with rank correlation and predictions on changes the suite hasn't seen.
Deliver pre-silicon ready. The same kernels and Python harness run on simulators, emulators and FPGA prototypes, giving architects fast, deterministic answers during design.
This work is taking shape in ArcadeBench, our benchmarking framework, currently under development.
The takeaway
JetStream is the right benchmark for browsers on real hardware. Before silicon exists, the right tool is a small, validated suite of native microbenchmarks that predicts how JetStream would respond, with Python making the whole methodology fast to build, run and trust.
Comments