1.4 KiB
Where a game frame goes on the sim thread — method
The record lives in the operator's infra repo (
services/flybrain/simloop-profile.md), verbatim and dated. This file keeps only the method and what it found.
The question came from a release-box finding: flysim's main thread at 100% CPU with the pool workers at about 70% and the realtime factor oscillating below 1, against a much higher figure for the brain-only soak at the same thread count. Which of the sim thread's serial phases is the difference in?
Answer: two of them. plasticity.observe is a large fixed slice of every frame and
does not move with the thread count, and the hot checkpoint's envelope encoding lands
entirely in whichever frame carries it — one frame in a few hundred blowing through the
16.74 ms budget, twice a stream-minute. Everything else on the sim thread is small: the
emulator frame, the retina, the decoder, the rewards and the whole snapshot publish
together are a fraction of one of those two.
The premise that spike propagation is serial is wrong — it has been sharded by target
range since feat/flysim-perf.
Method: instrument each serial phase of the sim loop with its own timer, run at several thread counts, and compare per-phase means and the worst frame. A phase that does not move with the thread count is serial work; a phase that only appears in some frames needs its worst case reported, not its mean.