It's the Memory Latency, Stupid
Comments on “It's the Memory Latency, Stupid”
Claim-checked. Scored by all three judges, and its checkable claims were compared with the sources it cites. How far stories are checked
A technical essay titled "It's the Memory Latency, Stupid" explains why a database CPU showing 100% utilization may be mostly stalled waiting on RAM rather than doing useful work.
Why it ranked
No. 25 of 127 with a score of 0.62. The panel rated it highest on technical depth (0.90) and new information (0.88), lowest on significance (0.48). Placed No. 25, No. 57 by score alone: the placement terms moved other stories past it.
- AI judgeJudge 2claude-haiku-5-5
- Solid, well-measured engineering writeup on CPU memory latency and cache-aware group-by with perf data; useful to builders, though narrow and partly promotional for its own engine.
- AI judgeJudge 3gpt-5.6-luna
- A technically detailed database performance write-up demonstrates radix partitioning with reproducible code, perf counters, timings, and memory measurements. It is highly actionable for systems and data engineers, though its broader significance is mainly within performance-sensitive database work.
Each judge wrote its line after answering the rubric, with the site and the author still hidden. Every answer behind this is in the table under Score.
Score
0.62total under rubric v2.3
- Significance0.48
- Reader interest0.74
- Audience breadth0.57
- Practical relevance0.72
- Substantiated0.86
- Technical depth0.90
- New information0.88
- Counts against: Promotional0.16
- Counts against: Overclaim0.20
Each judge’s answer per question (0–1), their mean and spread, and what the question adds to the score (weight × mean).
| Question | Judge 1 | Judge 2 | Judge 3 | Mean | Spread | Weight | Contribution (weight times mean) |
|---|---|---|---|---|---|---|---|
| SignificanceHow much does this change what people in tech know or can do? | 0.51 | 0.30 | 0.62 | 0.48 | 0.32 | +0.24 | +0.114 |
| Reader interestWould a well-informed senior engineer or tech founder want to read this today, and likely pass it on? | 0.64 | 0.70 | 0.88 | 0.74 | 0.24 | +0.26 | +0.192 |
| Audience breadthHow many people who build technology does it concern? | 0.64 | 0.50 | 0.58 | 0.57 | 0.14 | +0.13 | +0.075 |
| Practical relevanceHow useful is it to someone who builds software or tech products? | 0.75 | 0.60 | 0.82 | 0.72 | 0.22 | +0.22 | +0.159 |
| SubstantiatedHow well is it backed? Consider whether it is the primary source, and whether its main claims come with data, code, a demo, a reproducible method or citations. | 0.97 | 0.70 | 0.91 | 0.86 | 0.27 | +0.05 | +0.043 |
| Technical depthHow technically substantive is it? | 1.00 | 0.85 | 0.86 | 0.90 | 0.15 | +0.05 | +0.045 |
| New informationDoes it contain information absent from the stories covered in the last 7 days (list provided)? | 0.81 | 0.90 | 0.94 | 0.88 | 0.13 | +0.05 | +0.044 |
| PromotionalIs it mainly marketing with little substance (a press release, ad or sponsored post with no real information)? A launch post that carries real news is not promotional. | 0.10 | 0.25 | 0.12 | 0.16 | 0.15 | −0.19 | −0.030 |
| OverclaimDo the headline or conclusions claim more than the body supports? | 0.29 | 0.20 | 0.10 | 0.20 | 0.19 | −0.11 | −0.022 |
| Sum of contributions | +0.621 | ||||||
| Claim-check penalty | 0.000 | ||||||
| Total, as published | 0.622 | ||||||
Spread is the highest minus the lowest judge answer. marks a spread above 0.40: the judges disagree, and the story is marked contested.
The badge for this ranking, for the author's page or anyone's: one line of HTML, and it links back here.
<a href="https://rubric.hrih.si/editions/2026-10-30/25/"><img src="https://rubric.hrih.si/badge/2026-10-30/25.svg" alt="Ranked #25 on Rubric, 30 Oct 2026" width="245" height="28"></a>Claim check
Claim check: 8 no source given. Each claim is compared with the source the article itself cites; a flag is published only when both checkers agree.
No source givenNumber
A modern CPU can process roughly 4-8 instructions per nanosecond, while a memory access to RAM takes roughly 50-100ns, so a CPU can do around 400-800 instructions per RAM access.
The article gives no link or citation for it.
The article says “a modern CPU might be able to process somewhere in the realm of 4-8 instructions per nanosecond. A memory access to RAM can take somewhere in the realm of 50-100ns”
The source says No source to compare with.
No source givenNumber
The naive HashMap GROUP BY on ClickBench hits (99m rows, ~17m unique UserIDs) took 3.9 seconds on the first run and 3.6 seconds on the second run.
The article gives no link or citation for it.
The article says “This takes... a whopping 3.9 seconds”
The source says No source to compare with.
No source givenNumber
For the naive GROUP BY, perf showed 50.1% of CPU slots backend-bound on memory and only 16.1% retiring.
The article gives no link or citation for it.
The article says “This tells us that 50.1% of the time, the CPU couldn't do anything because it was stalling on memory! And only 16.1% of the time the CPU was actually retiring…”
The source says No source to compare with.
No source givenNumber
The naive GROUP BY pulled about 4.5GB from DRAM on CPU loads, versus 1.5GB for the radix-partitioned version.
The article gives no link or citation for it.
The article says “on demand we pulled 1.5GB from DRAM, instead of 4.5GB in the naive version”
The source says No source to compare with.
No source givenNumber
The radix-partitioned GROUP BY ran in 3.3 seconds on the first run and 2.7 seconds on the second.
The article gives no link or citation for it.
The article says “3.3 seconds, and then on second run 2.7 seconds”
The source says No source to compare with.
No source givenBenchmark result
With radix partitioning, memory-bound stalls fell to 23.5% of slots and retiring rose to 32.2%, despite more operations executed (19.35 billion versus 11.43 billion).
The article gives no link or citation for it.
The article says “23.5% of the time is spent on waiting for memory (as opposed to 50% before), 32% for actually retiring operations”
The source says No source to compare with.
No source givenCausal conclusion
Splitting the GROUP BY into 4096 partitions makes the aggregating HashMaps small enough to likely fit in CPU caches, which saves time.
The article gives no link or citation for it.
The article says “By dividing our group by into 4096 pieces, we've made our working HashMaps much likelier to fit into our CPU caches”
The source says No source to compare with.
No source givenNumber
Pivot's full implementation runs the query in 1848 ms on a single core (954 MB from DRAM) and 171.773 ms on 16 cores.
The article gives no link or citation for it.
The article says “Time: 1848.353 ms (00:01.848”
The source says No source to compare with.
Also covered by
No other coverage was clustered with this story.
Elsewhere
Elsewhere: HN 2 pts, not on front page
Recorded for context only, checked 30 Oct 2026, 05:47 UTC. It played no part in the ranking.