64 ビット CPU で、int
が 32 ビットでlong
が 64 ビットの場合、は ?long
よりも効率的int
でしょうか?
4 に答える
あなたの質問の主な問題は、あなたが「効率的」を定義しなかったことです。効率に関連するいくつかの違いが考えられます。
もちろん、64ビットを使用する必要がある場合は、問題はありません。ただし、32ビットを使用できる場合があり、代わりに64ビットを使用する方がよいかどうか疑問に思います。
データサイズの効率32ビットを使用すると、使用するメモリが少なくなります。これは、特にそれらをたくさん使用する場合に、より効率的です。スワップアウトできないという意味でより効率的であるだけでなく、キャッシュミスが少なくなるという意味でも効率的です。ほんの少ししか使用しない場合、効率の違いは関係ありません。
コードサイズの効率これはアーキテクチャに大きく依存します。32ビット値を操作するために長い命令が必要なアーキテクチャもあれば、64ビット値を操作するために長い命令が必要なアーキテクチャもあり、違いがないアーキテクチャもあります。たとえば、Intelプロセッサでは、64ビットコードの場合でも32ビットがデフォルトのオペランドサイズです。コードが小さいほど、キャッシュの動作とパイプラインの使用の両方で少し利点があります。ただし、どのオペランドサイズがより小さなコードを使用するかはアーキテクチャに依存します。
実行速度の効率一般に、コードサイズによって示されるもの以外に違いはありません。命令がデコードされると、単なる実行のタイミングは一般的に同じです。ただし、これも実際にはアーキテクチャ固有です。たとえば、ネイティブの32ビット演算を持たないアーキテクチャがあります。
私のおすすめ:
大量に割り当てないのが小さな構造体の一部のローカル変数またはデータである場合は、サイズを想定しないint
方法で使用および実行して、新しいバージョンのコンパイラまたは別のバージョンのコンパイラを使用するようにします。のサイズは引き続き機能します。int
ただし、巨大な配列または行列がある場合は、使用できる最小の型を使用し、そのサイズが明示的であることを確認してください。
一般的な x86-64 アーキテクチャでは、32 ビット演算が 64 ビット演算より遅くなることはありません。Soint
は常に と同じか、より高速ですlong
。MMIX など、実際には 32 ビット演算が組み込まれていない他のアーキテクチャでは、これが当てはまらない場合があります。
基本的な知恵は次のとおりです。このようなマイクロ最適化を考慮せずに記述し、必要に応じてプロファイリングと最適化を行います。
64 ビットのデータを格納しようとしている場合は、long を使用します。64 ビットが必要ない場合は、通常の 32 ビット int を使用してください。
はい、64 ビットの数値は 32 ビットの数値よりも効率的です。
ただし、64ビットCPUでは、long intを要求すると、ほとんどのコンパイラが64ビットを提供します。
現在のコンパイラでサイズを確認するには:
#include <stdio.h>
int main(int argc, char **argv){
long int foo;
printf("The size of an int is: %ld bytes\n", sizeof(foo));
printf("The size of an int is: %ld bits\n", sizeof(foo) * 8);
return 0;
}
CPU が 64 ビット モードで実行されている場合、何を求めても、CPU はそれを使用することが期待できます。すべてのレジスターは 64 ビットであり、操作は 64 ビットであるため、32 ビットの結果を取得したい場合は、通常、64 ビットの結果を 32 ビットに変換します。
limits.h
私のシステムでは、次のように定義さlong int
れています。
/* Minimum and maximum values a `signed long int' can hold. */
# if __WORDSIZE == 64
# define LONG_MAX 9223372036854775807L
# else
# define LONG_MAX 2147483647L
# endif
# define LONG_MIN (-LONG_MAX - 1L)