CPU使用率100%でも処理は止まっている——ボトルネックはメモリレイテンシだった
It's the Memory Latency, Stupid
データベースのCPUが100%でも、実際に命令を実行しているのは16%だけ。残りの大半はメモリ待ちで停止している。PivotのエンジニアがClickBenchの9900万行データでGROUP BYを計測したところ、素朴なHashMap実装ではCPU時間の50%がメモリ待ちに費やされ、DRAMから4.5GBを読み込んでいた。キーを4096個のパーティションに分割するradix partitioningを導入すると、メモリ待ちは23.5%に減り、DRAM読み込みも1.5GBまで下がった。処理命令数はむしろ増えているのに高速化した、という逆説が面白い。
この場合、メモリ起因で停止したCPUスロットは8364109137から3790955223へと減少しました。先に述べた通り、冷たいDRAMアクセスをCPU命令に置き換えられるなら、それはほぼ常に良いトレードなのです。
HNでの議論
54- boricj
職場の別チームは、メッセージパッシングを多用し、深くネストしたクラス階層でC++の仮想メソッドを使い、巨大なDOMと既製のC++ STLコンテナを使っている…それをSTM32MP1上でやっていて、これはインオーダーのCortex-A7でキャッシュはほんのわずかだ。
一方、私のチームでは、インラインでアロケートする独自のC++ STLコンテナ、SAXスタイルの処理ライブラリ、そして2000年代のビデオゲームのようにインデックス+世代を使うリンク付きオブジェクトプールを書いた…それをRAMが1メガバイト未満のSTM32H5上で動かしている。
メカニカル・シンパシーは、私が実演して見せる人々にとっては失われた芸術のように感じられる…そして最初のチームには、私が彼らの間のボトルネックには桁違いにならないことをベンチマークの数字で示さなければならなかった。
- happyPersonR
著者に敬意を表します、一貫性があるように見えます。
私はフレイムグラフが好きです。
人々がフレイムグラフの生成にperfを使うのを知っています。
しかし将来、LLMが登場した今、エージェントにアセンブリやPMUをチェックさせ、アセンブリで何をしているかも見させることができるでしょう。
私の2セント、そして皆さん楽しいコーディングを :)
- drivebyhooting
提示された解決策は、クラスタ化ハッシュマップ、あるいは「局所性に敏感」と言いたければそういうものに過ぎない気がする。
それでも桁違いに良くはならない。
- brcmthrowaway
https://people.freebsd.org/~lstewart/articles/cpumemory.pdf
これを2026年向けに書き直した人はいるのだろうか？