Die Speicherlatenz ist schuld, nicht die CPU
It's the Memory Latency, Stupid
Wenn die Datenbank-CPU bei 100 % steht, wartet sie oft nur auf den Arbeitsspeicher. Ein moderner Prozessor schafft 400 bis 800 Instruktionen pro RAM-Zugriff, doch bei einem naiven GROUP BY mit Millionen Gruppen geht fast jeder HashTable-Zugriff an den Caches vorbei. Pivot zeigt an ClickBench (99 Mio. Zeilen): 50 % der CPU-Zeit sind Speicher-Stalls. Mit Radix-Partitionierung sinkt das auf 23,5 %, die Laufzeit fällt von 3,9 auf 2,7 Sekunden und der DRAM-Verkehr von 4,5 auf 1,5 GB.
Das zeigt uns, dass die CPU 50,1 % der Zeit nichts tun konnte, weil sie auf den Speicher wartete!
- boricj
Ich arbeite mit einem anderen Team zusammen, das viele Message-Passing, virtuelle C++-Methoden in tief verschachtelten Klassenhierarchien, große DOMs und Standard-C++-STL-Container verwendet ... auf einem STM32MP1, der einen In-Order-Cortex-A7 und einen armseligen Cache hat.
Andererseits habe ich in meinem Team meine eigenen C++-STL-Container geschrieben, die inline allokieren, SAX-artige Verarbeitungsbibliotheken und einen Objektpool mit Links, die Index+Generationen wie in Videospielen der 2000er verwenden ... auf einem STM32H5 mit weniger als einem Megabyte RAM.
Mechanisches Einfühlungsvermögen wirkt auf die Leute, denen ich es demonstriere, wie eine verlorene Kunst ... und ich musste dem ersten Team mit Benchmark-Zahlen beweisen, dass ich nicht um Größenordnungen der Flaschenhals zwischen uns sein würde.
- happyPersonR
Hut ab vor dem Autor, es scheint kohärent zu sein.
Ich mag Flamegraphs
Ich weiß, dass Leute perf verwenden, um sie zu erzeugen
Aber in Zukunft, jetzt wo LLM da ist, lass einen Agenten den Assembly-Code, die PMUs prüfen und auch sehen, was du in Assembly machst.
Meine 2 Cent und fröhliches Coden an alle :)
- drivebyhooting
Ich habe das Gefühl, die vorgestellte Lösung ist einfach eine geclusterte Hashmap oder „locality sensitive“, wenn man so will.
Immer noch nicht um Größenordnungen besser.
- brcmthrowaway
https://people.freebsd.org/~lstewart/articles/cpumemory.pdf
Hat das jemand für 2026 neu geschrieben?