2025/09/23(火)64bit バイナリは footprint の大きさを実行効率で覆せるのか

CPU
近年 Windows では 64bit バイナリが普及してきたが、
基本的に64bit バイナリはプロセスイメージが大きい（必要メモリ容量が大きい）。

64bit版が不利な点

  • キャッシュに収まりにくい
    • CPUの並列化は進んでいるが周波数は伸び悩んでいる。プログラムの動作スピードに影響が大きいのがキャッシュにヒットするかどうかである。その点、プロセスイメージの大きいバイナリはキャッシュ的に不利である。

32bit版が不利な点

  • Windows API が WOW64
    • Windows x86_64 版では 32bit プログラムは WOW64 というエミュ層で動くらしいので、これがネイティブ64bit版APIを経由するような構成の場合は、APIコールの数がスピードに響いてくる。
  • 汎用レジスタが少ない
    • 64bitバイナリは 16個の汎用レジスタを使えるが、32bit版は4～6個くらい。関数コール等のABIでレジスタ渡しが難しいのも影響ありそう
私はキャッシュ信者なので、基本的にはキャッシュに収まりやすい方が速いのでは、と思っている。

32bit と 64bit 両方のバイナリがある場合に、大きいメモリを扱わないケースで 64bit 版のほうが速くなることがあるのだろうか。

思考実験としては
  • 大きいメモリを使わない→キャッシュにヒットしやすい→64bit版でもOK
  • 大きいメモリを使う→キャッシュにヒットしにくい→どちらの版でも遅いがポインタ的には64ビットのほうが良い
実際のプログラムごとのベンチマークが見てみたい所である。

メモリ使用量の例

図は例として Tera Term の 32bit 版と 64bit 版のメモリマップである。
どちらともプログラム起動直後の状態。
  • 32bit
    • teraterm-5-5-0-32bit-20250923.png
  • 64bit
    • teraterm-5-5-0-64bit-20250923.png
Image(Text) も Heap も64bit版がずっと大きい。
CPUのキャッシュ(L1/L2/L3)に収める必要がある領域が大きくなる。
コメント（0件）