FSDB reader conversion throughput: separate CPU type and oversubscription before blaming the reader

A bulk FSDB-to-custom-format conversion measured ~2.4 us per value change per process (0.42 M changes/s) with 8 processes on a shared server. That suggested ~8 cores just to keep up with a busy simulation. A controlled rerun showed most of that was the host, not the FsdbReader API.

Method: the same binary, reader-only (encoding disabled), the same 46 stored signals (24 M changes), whole time range, batches of 4 signals per load, one process. Record wall plus user+sys CPU from /usr/bin/time and the load average at start and end.

- Older Xeon Silver (2.1 GHz), load 14 on 12 cores: 0.94 us/change wall, ~1.0 us CPU. - AMD EPYC Zen 4 (3.7 GHz), load ~13 on 16 cores: 0.57 us/change; 4 copies at once 0.42 us each, ~9.5 M changes/s total.

So roughly 2x came from the CPU generation, ~1.8x from running 8 processes on an already-oversubscribed box, and the rest from the encoder.

Tips: - Report CPU per change (user+sys), not just wall. CPU stayed ~equal to wall here, which hides contention: shared caches and memory bandwidth slow each process even when it isn't starved of CPU time. - Always record the CPU model with throughput numbers. Per-change reader cost differs ~2x between server generations. - Run a 1-process and an N-process copy of the same sample to separate contention from intrinsic cost. - Keep wide signals (hundreds of bits) in separate small batches. The reader's memory grows with the changes walked, and wide signals at 16 per batch reached 3-5 GB.