<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>False-Sharing on Jasper</title><link>https://jasper-aa64.github.io/tags/false-sharing/</link><description>Recent content in False-Sharing on Jasper</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sun, 04 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://jasper-aa64.github.io/tags/false-sharing/index.xml" rel="self" type="application/rss+xml"/><item><title>Low-Latency Trading — MESI Cache Coherence</title><link>https://jasper-aa64.github.io/posts/low-latency-mesi-cache-coherence/</link><pubDate>Sun, 04 Oct 2026 00:00:00 +0000</pubDate><guid>https://jasper-aa64.github.io/posts/low-latency-mesi-cache-coherence/</guid><description>MESI enforces one rule: a cache line has either one core that may write it or any number of cores that may only read it, never both. The four states are the answers to two questions — does anyone else hold this line, and have I changed it? — and every cost in the protocol comes from moving data between layers or waiting for another core to confirm. False sharing, a cached queue cursor and a producer that slows down as readers join are all the same state machine. Coherence still doesn&amp;rsquo;t make a multi-word read atomic, and it says nothing about the order of writes to different addresses; that is what fences are for.</description></item><item><title>Trading System Notes #6: Alignment, Layout, and Cache and DRAM Geometry</title><link>https://jasper-aa64.github.io/posts/alignment-layout-cache-dram-geometry/</link><pubDate>Sun, 04 Oct 2026 00:00:00 +0000</pubDate><guid>https://jasper-aa64.github.io/posts/alignment-layout-cache-dram-geometry/</guid><description>An access never pays for bytes; it pays for cache lines, and the address decides which lines, which cache set they compete for, and which DRAM channel and bank they live on. Part 1 is alignment: why a double aligned to 8 never straddles a line, why padding exists for arrays, alignas on a type versus a member, and how to get 64-byte and 2 MiB alignment on the heap. Part 2 is layout: lines per access, AoS versus SoA, and denormalization as a way to cut a dependency chain. Part 3 goes into the hardware: L1 picks a set from address bits 6–11, so data 4 KiB apart competes for 8 slots however empty the cache is (measured on an M1); a DRAM bank has one row buffer, 14 ns on a hit and 41 ns on a conflict; a column walk loses at five layers; refresh adds a P99 tail software can&amp;rsquo;t remove; and channels balance only when the hot stride is coprime with the channel count.</description></item><item><title>Trading System Notes #2: Memory Ordering and Cache Lines</title><link>https://jasper-aa64.github.io/posts/memory-ordering-false-sharing-dependency-chains/</link><pubDate>Tue, 15 Sep 2026 00:00:00 +0000</pubDate><guid>https://jasper-aa64.github.io/posts/memory-ordering-false-sharing-dependency-chains/</guid><description>The store buffer and the cache-coherence protocol are one piece of hardware, but they create two unrelated engineering problems. One is correctness: does a thread see the right value, in the right order — solved by memory_order and release/acquire pairing. The other is performance: how many cycles does touching shared or dependent data cost, even when every value read is already correct — solved by cache-line layout and instruction scheduling. Conflating the two is the single most common confusion in this part of systems programming.</description></item></channel></rss>