From acc928a20301eace11b6aa16be2b9e6fa9c6b4c2 Mon Sep 17 00:00:00 2001 From: Joseph Ferano Date: Sun, 13 Sep 2026 23:28:39 +0700 Subject: [PATCH] The b3 note belongs under the table, not inside it --- spike/x86/COST.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/spike/x86/COST.md b/spike/x86/COST.md index fd7c224..0e5835a 100644 --- a/spike/x86/COST.md +++ b/spike/x86/COST.md @@ -149,15 +149,16 @@ Times are best-of-seven, in milliseconds. | `b1-calls` | 20M calls of a one-instruction function | 2.1 | 36.8 | 104.3 | 2.8× | 200 → 807 | | `b2-bounds` | 20.5M bounds-checked array loads | 4.7 | 27.0 | 112.6 | 4.2× | 407 → 1390 | | `b3-spill` | 5M iterations of a six-deep arithmetic tree | 22.2 | 29.0 | 137.3 | 4.7× | 248 → 1117 | +| `b4-copy` | 2M copies of a 64-byte struct | 2.0 | 7.2 | 20.8 | 2.9× | 348 → 877 | + +`b2` with `--no-bounds-checks` on both sides: LLVM 4.5ms, x86 105.0ms — the 7.6ms the check costs over 20.5 +million of them, and the 241 bytes it costs in `flan.main`, are the whole of it. `b3`'s ratio is the one to distrust slightly: its expression ends in a `%`, which is an `idiv`, and an `idiv` is twenty-odd cycles on every side. That is most of LLVM's own 22.2ms and a good part of its 29.0ms, so the denominator is largely a hardware latency this backend cannot do anything about. The absolute gap — 108ms over 5 million iterations, about 21ns of extra work each — is the honest reading of that row. -| `b4-copy` | 2M copies of a 64-byte struct | 2.0 | 7.2 | 20.8 | 2.9× | 348 → 877 | -`b2` with `--no-bounds-checks` on both sides: LLVM 4.5ms, x86 105.0ms — the 7.6ms the check costs over 20.5 -million of them, and the 241 bytes it costs in `flan.main`, are the whole of it. `b1-calls` and `b3-spill` are the pair to read together, with the `idiv` caveat above in mind. `b1` is 20 million