memory - 64ビットマシンに32ビットオペレーティングシステムをインストールすることで帯域幅が改善されますか？

Question

Knuthは最近、64ビットシステムに反対し、4ギガのメモリに収まるプログラムの場合、ポインタが32ビットシステムの2倍の大きさであるため、「キャッシュの半分を効果的に破棄する」と述べました。

私の質問は、64ビットマシンに32ビットオペレーティングシステムをインストールすることでこの問題を回避できるかどうかです。そして、この場合の利点を示す帯域幅を大量に消費するベンチマークはありますか？

Answer 1

帯域幅は、ここでは実際には正しい用語ではありません。Knuth が実際に話していたのは、キャッシュのフットプリントに関連するデータ密度です。16KB の L1 データ キャッシュがあるとします。純粋にポインターを格納する場合、2^14/2^2 = 2^12 = 4096 個の 32 ビット ポインターを格納できますが、64 ビット ポインターは 2048 個しか格納できません。アプリケーションのパフォーマンスが 2K を超えるさまざまなバッファーを追跡できるかどうかに依存している場合は、32 ビットのアドレス空間から実際のパフォーマンスが向上する可能性があります。ただし、ほとんどの実際のコードはこの方法ではなく、キャッシュ システムによる実際のパフォーマンスの利点は、多くの場合、大量のポインターではなく、共通の整数および浮動小数点データ構造をキャッシュできることから得られます。あなたのワーキング セットがポインタを多用しない場合、64 ビットのマイナス面は無視できるほどになり、プラス面ははるかに明白になります。

Answer 2

答えは次のとおりです。パフォーマンスの違いが大きくなる可能性は低いですが、ある程度は可能です。

これをテストするためのベンチマークは、多くのポインタ解決を行う必要があり、ノイズから分離するのは困難です。最適化されないベンチマークを設計することは困難です。 欠陥のあるJavaベンチマークに関するこの記事は、別​​の質問に答えて誰かが投稿したものですが、そこに記載されている原則の多くはこれに当てはまります。

Answer 3

Knuth が 64 ビット システムに反対したとは思いません。彼は、RAM が 4GB 未満のシステムで 64 ビット ポインターを使用するのはばかげていると言いました (少なくとも、二重リンク リストのようなポインターがたくさんある場合)。私は彼に同意するとは言えません.3つの異なる方法があります. 一部の Intel Core Duo のように、32 ビット モードでも実行できる 64 ビット対応の CPU があるとします。

1 - OS、APPZ、それらすべてが 32 ビットです。したがって、32 ビット ポインターがありますが、64 ビット モードで使用できる追加のレジスター/命令を使用することはできません。

2 - すべてが 64 ビット、OS、APPZ、それらすべてです。したがって、64 ビット ポインターがあり、64 ビット モードで使用できる追加のレジスター/命令を使用できます。しかし、RAM が 4GB 未満であるため、64 ビット ポインターを使用するのはばかげているように思えます。でも、そうですか？

3 - OS は 64 ビットであり、OS は興味深いことに、すべてのコード/データ ポインターが 0x00000000 - 0xFFFFFFFF の範囲内にあることを確認します (仮想メモリ !!!)。ABI は、メモリ/ファイルに保持されるすべてのコード/データ ポインタが 32 ビット幅であるにもかかわらず、ゼロ拡張として 64 ビット レジスタにロードされるという非常に奇妙な方法で実行されます。ジャンプするコードの場所がある場合、コンパイラ/ABI は必要な修正を行い、実際の 64 ビット ジャンプを行います。このように、ポインターは 32 ビットですが、APPZ は 64 ビットにすることができます。つまり、64 ビットのレジスターと命令を利用できます。このプロセスは、サンクのようなものだと思います;-P

私の結論は::

3 番目のオプションは実行可能に思えましたが、簡単な問題ではありません。理論的には機能しますが、実現可能ではないと思います。そして、彼の引用「そのようなポインタ値が構造体の中に現れると、メモリの半分を浪費するだけでなく、事実上キャッシュの半分を捨ててしまう」とも思います。誇張されています...

Answer 4

(x86 CPU 上で) 最良の組み合わせは、64 ビット OS と 32 ビット アプリケーションを使用することだとどこかで見たことがあります。

64 ビット OS では、次のようになります。

• 4GB を超えるアドレス空間を処理する機能
• データコピー操作に役立つ、より多くのより大きなレジスタ

32 ビット アプリを使用すると、次のようになります。

• 小さいポインタ
• コンテキストスイッチを節約するためのより少ない、より小さなレジスタ

短所：

• すべてのライブラリを複製する必要があります。HD スペース標準では小さい。
• 読み込まれたライブラリはすべて RAM 上に複製されます。そんなに小さくない…

驚くべきことに、モードを切り替える際のオーバーヘッドはないようです。ユーザー空間のビット数に関係なく、ユーザー空間からカーネルへの移行のコストは同じだと思います。

もちろん、大きなアドレス空間の恩恵を受けるアプリケーションもいくつかあります。ただし、それ以外の場合は、32 ビットにとどめることでさらに 5% のパフォーマンスを得ることができます。

いいえ、この小さなスピードアップは気にしません。しかし、64 ビットの KUbuntu マシンで 32 ビットの FireFox を実行することで「気分を害する」ことはありません (いくつかのフォーラムで見たように)。