64ビットプログラムは32ビットバージョンよりも大きくて高速ですか？

私はx86に焦点を合わせていると思いますが、一般的に32ビットから64ビットへの移行に興味があります。

論理的には、定数とポインタが大きくなる場合があるため、プログラムが大きくなる可能性が高いことがわかります。また、効率を上げるために単語の境界にメモリを割り当てたいという要望は、割り当て間の空白を増やすことを意味します。

また、x86の32ビットモードでは、4Gアドレス空間が重複している可能性があるため、コンテキスト切り替え時にキャッシュをフラッシュする必要があると聞いています。

では、64ビットの本当の利点は何ですか？

そして補足的な質問として、128ビットはさらに良いでしょうか？

編集：

最初の32/64ビットプログラムを作成しました。それは16バイト（32bバージョン）または32バイト（64bバージョン）オブジェクトのリンクリスト/ツリーを作成し、stderrに多くの印刷を行います-本当に便利なプログラムではなく、典型的なものではありませんが、それは私の最初のものです。

サイズ：81128（32b）v 83672（64b）-それほど大きな違いはありません

速度：17s（32b）v 24s（64b）-32ビットOS（OS-X 10.5.8）で実行

更新：

64bであるが32bポインターを使用する新しいハイブリッドx32ABI（アプリケーションバイナリインターフェイス）が開発されていることに注意してください。一部のテストでは、32bまたは64bよりもコードが小さく、実行が高速になります。

https://sites.google.com/site/x32abi/

32bアドレス指定で許可されるより多くのメモリにアクセスする必要がない限り、メリットはほとんどありません。

64b CPUで実行している場合、32bコードと64bコードのどちらを実行していても（同じキャッシュと同じバスを使用している）、同じメモリインターフェイスを使用できます。

x64アーキテクチャには、より簡単な最適化を可能にするレジスタがいくつかありますが、これは多くの場合、ポインタが大きくなり、ポインタを含む構造を使用するとメモリトラフィックが増えるという事実によって打ち消されます。32bアプリケーションと比較した64bアプリケーションの全体的なメモリ使用量の増加は約15〜30％であると推定します。

通常、x86と比較してx86-64の計算集約型コードの速度は30％向上しています。これは、8 x32ビットの汎用レジスタと8x SSEレジスタの代わりに、16 x64ビットの汎用レジスタと16xSSEレジスタがあるためと考えられます。これは、x86-64Linux上のIntelICCコンパイラ（11.1）の場合です。もちろん、他のコンパイラ（gccなど）または他のオペレーティングシステム（Windowsなど）での結果は異なる場合があります。

利点に関係なく、ライブラリを32ビットバイナリとしてコンパイルして64ビットで提供する場合は、常にシステムのデフォルトのワードサイズ（32ビットまたは64ビット）でプログラムをコンパイルすることをお勧めします。システムでは、64ビットバージョンがデフォルトで使用可能な場合、ライブラリとリンクしたい人は誰でも、ライブラリ（およびその他のライブラリの依存関係）を32ビットバイナリとして提供するように強制します。これは、誰にとっても非常に厄介なことです。疑わしい場合は、ライブラリの両方のバージョンを提供してください。

64ビットの実用的な利点に関して...最も明白なのは、より大きなアドレススペースが得られることです。したがって、ファイルをmmapすると、一度により多くのアドレスをアドレス指定できます（そしてより大きなファイルをメモリにロードできます）。もう1つの利点は、コンパイラが最適化を適切に実行すると仮定すると、算術演算の多くを並列化でき（たとえば、32ビット数の2つのペアを2つのレジスタに配置し、1回の加算演算で2つの加算を実行する）、大きな利点です。数値の計算はより高速に実行されます。とは言うものの、64ビットと32ビットの違いは、漸近的な複雑さにはまったく役立ちません。したがって、コードを最適化する場合は、このような一定の要素ではなく、アルゴリズムを検討する必要があります。

編集：
並列化された加算についての私の声明は無視してください。これは通常のaddステートメントでは実行されません...ベクトル化/ SSE命令のいくつかと混同していました。アドレス空間が大きいことを除けば、より正確な利点は、より多くの汎用レジスタがあることです。つまり、変数をに配置する場合よりも、より多くのローカル変数をCPUレジスタファイルに保持でき、アクセスがはるかに高速になります。プログラムスタック（通常、L1キャッシュに出力することを意味します）。

より多くのレジスタを持つことに加えて、64ビットにはデフォルトでSSE2があります。これは、実際にいくつかの計算を並行して実行できることを意味します。SSE拡張命令には他にも利点がありました。しかし、主な利点は、拡張機能の存在を確認する必要がないことだと思います。x64の場合は、SSE2を使用できます。...私の記憶が正しく私に役立つ場合。

私はfoolsmateという名前のチェスエンジンをコーディングしています。ミニマックスベースのツリー検索を使用した深さ9（特定の位置から）への最良の移動抽出には、次のものがあります。

上のWin32設定：〜17.0s;

x64構成に切り替えた後：〜10.3s;

これは加速度の41％です！

アプリケーションを64ビットに移動する理由は、大規模なデータベースや、アプリケーションがパフォーマンスを向上させるためにキャッシュするときに2GBの制限をすぐに超える数百人の同時ユーザーがいるERPアプリケーションなどのアプリケーションでより多くのメモリが必要になることだけです。これは特に、整数と長さが32ビットのままであるWindows OSの場合です（新しい変数_int64があります。ポインターのみが64ビットです。実際、WOW64はWindows x64で高度に最適化されているため、32ビットアプリケーションは64ビットWindowsで低いペナルティで実行されます。 OS。Windowsx64での私の経験では、32ビットアプリケーションバージョンは64ビットよりも10〜15％高速に実行されます。以前の場合、少なくとも独自のメモリデータベースでは、bツリー（データベースシステムの最もプロセッサを集中的に使用する部分）を維持するために整数のポインタを使用できるためです。 。32-64ビットオペレーティングシステムではdoubleでは得られない最高の精度を得るために大きな小数を必要とする計算集約型アプリケーション。これらのアプリケーションは、ソフトウェアエミュレーションの代わりにネイティブで_int64を使用できます。もちろん、大容量ディスクベースのデータベースでも、クエリプランのキャッシュなどに大容量メモリを使用できるため、32ビットを超える改善が見られます。

メモリフェッチごとにCPUとRAMの間でより多くのデータが転送されるため（32ビットではなく64ビット）、64ビットプログラムは、これを適切に利用するように記述されていれば、より高速になります。

x68からx68_64の特定のケースでは、64ビットプログラムは、わずかに小さくはないにしても、ほぼ同じサイズになり、少し多くのメモリを使用し、より高速に実行されます。これは主に、x86_64に64ビットレジスタがあるだけでなく、2倍の数があるためです。x86には、コンパイルされた言語を可能な限り効率的にするのに十分なレジスタがないため、x86コードは、レジスタとメモリ間でデータを前後にシフトする多くの命令とメモリ帯域幅を消費します。x86_64はそれがはるかに少ないため、必要なスペースが少し少なくなり、実行速度が速くなります。x86_64では、浮動小数点およびビットをいじるベクトル命令もはるかに効率的です。

ただし、一般的に、64ビットコードは必ずしも高速であるとは限らず、実行時のコードとメモリの使用量の両方で通常は大きくなります。

トランスコーディング、ディスプレイパフォーマンス、メディアレンダリングなど、CPU使用率を必要とするアプリケーションは、オーディオであろうとビジュアルであろうと、確かに（この時点で）必要であり、CPUが完全に処理できるため、64ビットと32ビットを使用することでメリットが得られます。そこにスローされるデータの量。データが処理される方法であるため、アドレス空間の問題ではありません。64ビットコードが与えられた64ビットプロセッサは、特にトランスコーディングやVoIPデータなどの数学的に難しいもので、パフォーマンスが向上します。実際、あらゆる種類の「数学」アプリケーションは、64ビットCPUとオペレーティングシステムの使用によって恩恵を受けるはずです。私が間違っていることを証明してください。