The b3 note belongs under the table, not inside it
This commit is contained in:
parent
35c33c7b8b
commit
acc928a203
@ -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
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user