Same code, different cache layout, 10× performance gap. This video runs three benchmarks back-to-back to show how cache misses, TLB misses, and false sharing each show up in perf counters — and why none of them are visible in a flame graph.
Part of the CoreTracer project: the kind of bottleneck that you can only debug after you know to look for it.
The measured numbers
From the CoreTracer runs written up in the blog post, same work in every run:
| Layout | Wall time |
|---|---|
| Padded (two counters on separate cache lines) | 841 ms |
| False sharing (two counters on one cache line) | 4,284 ms |
| True ping-pong (both threads on one shared int) | 8,118 ms |
Layout
Padded (two counters on separate cache lines)
Wall time
841 ms
Layout
False sharing (two counters on one cache line)
Wall time
4,284 ms
Layout
True ping-pong (both threads on one shared int)
Wall time
8,118 ms
- Random access over the same bytes ran 4.5x slower than sequential access.
- A TLB-bound sweep ran 1.7x faster on 2 MB pages than on 4 KB pages, with nothing else changed.
- Both cores show 100% busy in every case, which is why
topand flame graphs miss all three.
Comments
This space is waiting for your voice.
Comments will be supported shortly. Stay connected for updates!
This section will display user comments from various platforms like X, Reddit, YouTube, and more. Comments will be curated for quality and relevance.
Have questions? Reach out through:
Want to see your comment featured? Mention us on X or tag us on Reddit.