THE FOLD / GRIND / THE HOT LOOP / THE WRITE COMBINING
THE WRITE COMBINING
the saving and the ordering bug are one mechanism
1 WHAT IT IS · WHAT IT DOES · FACT OR FICTION
A store buffer holds writes back briefly so that several to the same cache line can leave as one transaction. Write the line in order and you pay once for sixty-four stores. Scatter them and you pay every time.
LIT verified live. 100,000 stores over 64-byte lines. Written in order they combine into 1,563 bus transactions — 64.0 stores per transaction, and exactly the number of distinct lines the data occupies. Scattered, the same 100,000 stores produce 98,125 transactions: 62.8× the traffic for the identical bytes.
LIT verified live. 100,000 stores over 64-byte lines. Written in order they combine into 1,563 bus transactions — 64.0 stores per transaction, and exactly the number of distinct lines the data occupies. Scattered, the same 100,000 stores produce 98,125 transactions: 62.8× the traffic for the identical bytes.
2 HOW IT WAS WEAVED · AI + HUMAN
Write-combining buffers are why
AVAN (AI) gated on the wrong arithmetic first: I asserted that combined transactions should equal
memcpy and framebuffer writes are fast, and why non-temporal stores exist at all.AVAN (AI) gated on the wrong arithmetic first: I asserted that combined transactions should equal
100000/64, which is 1562.5 — a value the counter can never take. The measurement of 1,563 was right all along and the assertion was impossible. The gate now compares against ceil, which is the number of distinct lines and the thing the claim is actually about.3 ONE DIMENSION
Sixty-four stores, one line. Ordered and scattered.
4 TWO DIMENSIONS · INTERACTIVE
Break the ordering and watch the bus traffic climb.
5 THREE DIMENSIONS + AVAN’S INVERSE
The green forward object: sixty-four writes leaving as one.
AVAN’s addition (the inverse-companion): the forward reading is that write combining saves bus traffic. The inverse is that it saves it by delaying your writes and telling nobody. The buffer holds data that your program believes has been stored, and every fence instruction in existence is there to drain it — so the optimisation is invisible until it is a correctness problem, at which point it is the whole problem. Read backwards, the 64× saving and the memory-ordering bug are the same mechanism, billed to different departments.
LIT 100,000 stores over 64-byte lines combine into 1,563 bus transactions when written in order - 64.0 stores each, and exactly the number of distinct lines the data occupies - against 98,125 transactions when scattered, which is 62.8 times the traffic for the identical bytes
FIG Write-combining buffers are why memcpy and framebuffer writes are fast, and why non-temporal stores exist. AVAN gated on the wrong arithmetic first: I asserted that combined transactions should equal 100000/64, which is 1562.5 - a value the counter can never take. The measurement of 1,563 was right all along and the assertion was impossible. The gate now compares against ceil, which is the number of distinct lines and the thing the claim is actually about.
FIG Write-combining buffers are why memcpy and framebuffer writes are fast, and why non-temporal stores exist. AVAN gated on the wrong arithmetic first: I asserted that combined transactions should equal 100000/64, which is 1562.5 - a value the counter can never take. The measurement of 1,563 was right all along and the assertion was impossible. The gate now compares against ceil, which is the number of distinct lines and the thing the claim is actually about.
◆ sealed .dlw.fold → folded to ROOT_0 · a sphere of THE HOT LOOP · David Lee Wise (ROOT0), with AVAN