それは正確なCPUと操作に依存します。たとえば、64 ビットの Pentium IV では、64 ビット レジスタの乗算はかなり遅くなりました。 Core 2 以降の CPU は、最初から 64 ビット操作用に設計されています。
一般に、64 ビット プラットフォーム用に記述されたコードでさえ、値が収まる 32 ビット変数を使用します。これは主に算術演算が高速だからではなく (最新の CPU では一般的にそうではありません)、使用するメモリとメモリ帯域幅が少ないためです。
1ダースの整数を含む構造体は、それらの整数が32ビットの場合、64ビットの場合よりもサイズが半分になります。これは、保存に半分のバイト数、キャッシュ内の半分のスペースなどを必要とすることを意味します。
値が 32 ビットに収まらない場合は、64 ビットのネイティブ レジスタと演算が使用されます。ただし、主なパフォーマンス上の利点は、x86_64 命令セットで使用できる追加の汎用レジスタから得られます。そしてもちろん、64 ビット ポインターから得られるすべての利点があります。
だから本当の答えは、それは問題ではないということです。 x86_64 モードを使用する場合でも、32 ビット演算を使用することができ (通常は使用します)、より大きなポインターとより汎用的なレジスターの利点が得られます。 64 ビット ネイティブ操作を使用するのは、64 ビット操作が必要であり、複数の 32 ビット操作でそれを偽造するよりも高速であることを知っているからです。そのため、32 ビット レジスタと 64 ビット レジスタの相対的なパフォーマンスは、実装を決定する際の決定要因にはなりません。
この質問に出くわしましたが、ここで 1 つの非常に重要な側面が欠けていると思います:インデックスに型 'int' を使用してアセンブリ コードを実際に調べると、コンパイラが生成するコードが遅くなる可能性があります。これは 'int' が原因です。多くの 64 ビット コンパイラとプラットフォーム (Visual Studio、GCC) ではデフォルトで 32 ビット型になり、ポインタ (64 ビット OS では必ず 64 ビットになります) と 'int' を使用してアドレス計算を行うと、コンパイラは 32 ビットと 64 ビットのレジスタ間で不要な変換を発生させます。 .コードの非常にパフォーマンスが重要な内部ループでこれを経験しました。ループ インデックスとして 'int' から 'long long' に切り替えると、アルゴリズムの実行時間が約 10% 改善されました。これは、その時点で既に使用していた広範な SSE/AVX2 ベクトル化を考慮すると、非常に大きな利益でした。