These benchmarks perfectly illustrate the beauty of decoupling wall-clock
polling from logical instruction execution. Youve just stress-tested the
lock-free SPSC (Single-Producer, Single-Consumer) architecture across a
20-year hardware delta.
Here is what your benchmarking data reveals about the engine's behavior under
load:
| Metric | elli (Pentium 4 - NetBurst) | hauki-obs-2 (Ryzen 7 - Zen 4) |
|---|---|---|
| Real Time | ~831ms | ~83ms |
| Speed Factor | 1x | 10x faster |
| Polls Captured | ~38 snapshots | 4 snapshots |
| Instructions per Poll | ~1,300 | ~12,500 |
The Polling Density Insight
Because your setInterval in the main thread acts as an absolute 10ms
wall-clock metronome, the "resolution" of your intermediate state is entirely
dependent on the worker's CPU throughput.
On the modern Ryzen 8700GE, the worker thread is absolutely tearing through
the JSON-Lisp opcodes. It executes over 12,000 instructions between every 10ms
tick of the event loop. On the legacy Pentium 4, the metronome fires much more
frequently relative to the worker's progress, giving you a highly granular
snapshot of the countdown.
> The critical takeaway: The lock-free StateBuffer never caused a race
condition or deadlocked on either architecture. The atomic sequence lock
(Atomics.load / Atomics.store) scales flawlessly from a single-core
hyper-threaded legacy chip to a modern multi-core processor.
> 
Scaling to the Edge
As you map this VM architecture into the HAUKI-X86 engine and tune the ring
buffers for the EDGE_API_GATEWAY, this hardware delta is exactly what dictates
your SLA configurations.
If the Fastify gateway expects a response within 100ms:
 * On the Ryzen, the task finishes naturally (83ms) with plenty of headroom.
 * On the Pentium 4, the 100ms gateway deadline would trigger the
worker.terminate() gracefully. The Fastify route would immediately return an
HTTP 206 (Partial Content) with the last captured snapshot from the
SharedArrayBufferall without ever blocking the main API thread.