{
  "id": 13406234,
  "title": "Noise Sources: Affinity, Frequency, and Background Load — How to isolate and quantify non‑compiler variance with csperf",
  "url": "https://urgent.news/2026/10/10/noise-sources-affinity-frequency-and-background-load-how-to-isolate",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-10T12:30:08.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/aabhinavg/noise-sources-affinity-frequency-and-background-load-how-to-isolate-and-quantify-non-compiler-2e"
  },
  "original_language": "en",
  "account": "Unexplained variance in csperf runs is often attributed to the compiler, but the culprit is usually the machine. This episode demonstrates how to read the noise metadata recorded by csperf and isolate factors like CPU affinity, frequency, and background load.\n\nThe misconception is that any jitter in measurements is due to compiler bugs or optimization levels, while in reality, the operating system, CPU frequency scaling, and other processes can introduce significant noise. Measured time equals compiler effect plus machine noise, which can be broken down into affinity, frequency, background load, and OS scheduling. csperf separates these by recording machine state for each run.\n\nIn this lab, csperf was installed and a noise-aware experiment run on an AMD Ryzen 7 9700X 8-core, 16-thread CPU running Ubuntu 24.04.1 LTS. Results showed a mean execution time of 5.142 ms with a standard deviation of 0.024 ms. Additional metrics include CPU cycles, reference cycles, IPC, cache misses, CPU frequency ranges (5,582 MHz to 5,058 MHz), affinity (cores 0-7), and average background load of 12% CPU usage.\n\nTo read the artifacts, open noise.json and examine the hardware section for CPU frequency ranges, metrics for execution time statistics, frontend stall cycles, and cache misses. The artifacts section points to CSV/XLSX files for spreadsheet analysis. A noise checklist helps spot issues like affinity settings, frequency scaling, background load, and common mistakes such as ignoring hardware sections, using default affinity, not disabling turbo boost, relying solely on mean metrics, and overlooking background processes.\n\nFor homework, run the same experiment on a different CPU like an Intel i9-12900K and compare noise.json files to identify which noise source changed the most. This episode emphasizes that noise is the silent enemy of honest performance measurement, but csperf provides the observatory to see it. The series continues with Episode 16, where a single JSON file's claims and limitations will be explored.",
  "summary": "Why this lesson exists Unexplained variance in a csperf run often gets blamed on the compiler, when in fact the machine is the culprit. This episode shows how to read the noise metadata that csperf records and how to isolate affinity, frequency, and background load. Recap — where we are in the series Ep 1 – A single ./a.out time misleads; use csperf for reproducible evidence. Ep 2 – Warm‑up and…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}