64ビットプログラムは32ビットバージョンよりも大きくて高速ですか？
私はx86に焦点を当てていると思いますが、一般的に32ビットから64ビットへの移行に興味があります。
論理的には、定数とポインターが大きくなる場合があり、プログラムが大きくなる可能性が高いことがわかります。また、効率のためにWordの境界にメモリを割り当てたいという願望は、割り当て間の空白を増やすことを意味します。
また、4Gアドレス空間が重複している可能性があるため、コンテキストの切り替え時にx86の32ビットモードでキャッシュをフラッシュする必要があると聞きました。
それで、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ポインターを使用する新しいハイブリッドx32 ABI（アプリケーションバイナリインターフェイス）が開発されていることに注意してください。一部のテストでは、32bまたは64bよりもコードが小さく、実行速度が速くなります。
32bのアドレス指定で許可されるより多くのメモリにアクセスする必要がない限り、その利点はわずかです。
64b CPUで実行している場合、32bコードと64bコードのどちらを実行していても同じメモリインターフェイスを使用できます（同じキャッシュと同じBUSを使用しています）。
X64アーキテクチャには最適化を容易にするレジスタがいくつかありますが、これは多くの場合、ポインターが大きくなり、ポインターを持つ構造を使用するとメモリトラフィックが増加するという事実によって相殺されます。 32bのアプリケーションと比較した64bのアプリケーションの全体的なメモリ使用量の増加は、約15〜30％と見積もられます。
通常、x86と比較してx86-64での計算集中型コードの速度は30％向上します。これは、8 x 32ビットの汎用レジスタと8 x SSEレジスタの代わりに、16 x 64ビットの汎用レジスタと16 x SSEレジスタがあるためです。これは、x86-64 Linux上のIntel ICCコンパイラ（11.1）を使用した場合です-他のコンパイラ（gccなど）または他のオペレーティングシステム（Windowsなど）の結果は、当然異なる場合があります。
ライブラリを32ビットバイナリとしてコンパイルし、64ビットで提供する場合、利点に関係なく、常にシステムのデフォルトのWordサイズ（32ビットまたは64ビット）に合わせてプログラムをコンパイルすることをお勧めします。システムでは、64ビットバージョンがデフォルトで使用可能な場合、ライブラリとリンクしたい人はだれでも自分のライブラリ（およびその他のライブラリの依存関係）を32ビットバイナリとして提供するように強制されます。これは誰にとっても非常に迷惑なことです。疑わしい場合は、ライブラリの両方のバージョンを提供してください。
64ビットの実際的な利点については...最も明らかなのは、より大きなアドレス空間を取得することです。そのため、ファイルをmmapすると、一度により多くのアドレスを指定できます（そして、より大きなファイルをメモリにロードできます）。別の利点は、コンパイラーが最適化の良い仕事をすると仮定して、算術演算の多くを並列化できることです（たとえば、2つのレジスターに2組の32ビット数を配置し、単一の加算演算で2つの加算を実行する）。数値計算がより速く実行されます。とはいえ、64ビット対32ビットの全体は漸近的な複雑さではまったく役に立ちません。そのため、コードを最適化しようとしている場合は、おそらくこのような一定の要因ではなくアルゴリズムを検討する必要があります。
編集：
並列化された追加に関する私の声明を無視してください。これは通常のaddステートメントでは実行されません...私はそれをベクトル化/ SSE命令のいくつかと混同していました。アドレス空間が大きいことに加えて、より正確な利点は、より汎用レジスタがあることです。これは、CPUレジスタファイルに保持できるローカル変数が多いことを意味します。プログラムスタック（通常、L1キャッシュに行くことを意味します）。
64ビットには、より多くのレジスタがあることに加えて、デフォルトでSSE2があります。これは、実際にいくつかの計算を並行して実行できることを意味します。 SSE拡張機能には他の利点もありました。しかし、主な利点は拡張機能の存在を確認する必要がないことです。x64の場合、SSE2が利用可能です。正しく私に役立ちます。
アプリケーションを64ビットに移行する正当な理由は、大規模データベースやERPアプリケーションキャッシュ時に2 GBの制限をかなり早く超える100人以上の同時ユーザーを持つアプリケーションなど）これは、整数とlongがまだ32ビットであるWindows OSの場合です（新しい変数_int64があります。ポインターのみが64ビットです。実際、WOW64はWindows x64で高度に最適化されているため、32ビットアプリケーションは低ペナルティで実行されます） Windows x64での私の経験は、32ビットアプリケーションバージョンは64ビットより10〜15％高速です。以前のケースでは、少なくとも独自のメモリデータベースでは、bツリーを維持するためにポインタ演算を使用できます32〜64ビットのオペレーティングシステムでは、倍精度では得られない最高の精度を得るために大きな小数を必要とする計算集中型のアプリケーション。これらのアプリケーションは、ソフトウォーの代わりにネイティブで_int64を使用できます。エミュレーション。もちろん、大規模なディスクベースのデータベースも、クエリプランのキャッシングに大容量のメモリを使用できるなどの理由で、32ビット以上の改善が見られます。
CPUとRAM各メモリフェッチ（32ではなく64ビット）の間でより多くのデータが転送されます。 。
X68からx68_64の特定のケースでは、64ビットプログラムはほぼ同じサイズになりますが、わずかに小さくはなりませんが、メモリを少し使用し、実行速度を上げます。これは主に、x86_64には64ビットのレジスターがあるだけでなく、2倍の数があるためです。 x86には、コンパイルされた言語を可能な限り効率的にするための十分なレジスタがないため、x86コードは、レジスタとメモリ間でデータをシフトする多くの命令とメモリ帯域幅を消費します。 x86_64の方がはるかに少ないため、必要なスペースが少なくなり、実行速度が速くなります。 x86_64では、浮動小数点およびビット調整ベクトル命令もはるかに効率的です。
ただし、一般に、64ビットコードは必ずしも高速ではなく、通常は実行時のコードとメモリ使用量の両方でより大きくなります。
チェスエンジンをコーディングしています。深さ9（特定の位置から）へのミニマックスベースのツリー検索を使用した最適な移動抽出には、Win32構成で約17.0秒かかり、x64に切り替えた後、約10.3秒かかります。これは加速の41％です！
トランスコーディング、ディスプレイパフォーマンス、メディアレンダリングなどのCPU使用を必要とするアプリケーションは、オーディオでもビジュアルでも、（この時点で）確実に（この時点で）CPUの能力により、64ビット対32ビットを使用する必要がありますスローされるデータの量。データの処理方法であるため、アドレス空間の問題ではありません。 64ビットコードが与えられた64ビットプロセッサは、特にトランスコーディングやVoIPデータなどの数学的に困難なものでパフォーマンスが向上します-実際、あらゆる種類の「数学」アプリケーションは、64ビットCPUとオペレーティングシステムの使用によって恩恵を受けるはずです。間違っていることを証明してください。