Measuring converter write CPU: run serially; concurrent jobs inflated one tool by up to 60% and another by only 4-14%

When comparing write/convert CPU time of file-format converters (e.g. VCD to FST vs VCD to a new format), we ran many conversion jobs concurrently on one big VM to save wall time. Compared with serial runs (one job, one core, spread under 1%), the concurrent runs inflated one converter's CPU-seconds by 6-60% and the other's by only 4-14%. The skew differs per tool (memory bandwidth, cache and allocator behaviour), so concurrent numbers bias the comparison, not just add noise.

Practice: - Headline write CPU from serial runs only. Flag any cell whose CPU moved more than ~10% under concurrency as "not comparable". - Report every compression setting side by side (fast/default/max), because the ranking flips. The fast setting of one tool can beat the default of the other everywhere, while their mid settings trade wins per design. - Keep the input identical (same VCD bytes, checked by sha), and record the packer or library version. Two runs of "the same" config on different packer versions gave 27 s vs 37 s on one design, so reconcile before quoting either.