ディスク入出力に頼らず、物理メモリー内で直接大量のデータを処理できるということは、おそらく、
64 ビット・マシンのパフォーマンス上最大の利点でしょう。しかし、いくつかのアプリケーションは、64 ビット・モードで再コンパイルしたときよりも、32 ビット・モードでコンパイルした方が良いパフォーマンスを示します。これには次のようないくつかの理由があります。
- 64 ビット・プログラムの方が大きい。プログラム・サイズの増加により、物理メモリーの負荷がより大きくなります。
- 64 ビットの long 型除法の方が、32 ビットの整数除法よりも時間がかかる。
- 64 ビット・プログラムで、配列指標に 32 ビットの符号付き整数を使用する場合は、配列を参照するたびに、符号拡張を行うための追加の命令が必要となる場合がある。
64 ビット・プログラムのパフォーマンス上のマイナス影響を補正するには、次のような方法があります。
- 32 ビットと 64 ビット混合の演算を行わないようにする。例えば、
32 ビットのデータ型と 64 ビットのデータ型を加算する場合は、32 ビット型の方を符号拡張し、レジスターの上位 32 ビットをクリアする必要があります。このため、計算が遅くなります。
- 可能な限り、long 型の除法を使用しない。乗算は、多くの場合、除法よりも高速です。同じ除数で多くの除法を実行する必要がある場合は、除数の逆数を一時変数に割り当て、すべての除法を一時変数に対する乗算に変更します。例えば、次の関数を考えてみます。
double preTax(double total)
{
return total * (1.0 / 1.0825);
}
この方が、次の直接除法よりも実行が速くなります。
double preTax(double total)
{
return total / 1.0825;
}
その理由は、除法 (1.0 / 1.0825) は、コンパイル時にのみ評価され、フォールディングされるためです。
- 頻繁に使用される変数 (ループ・カウンター、配列指標など) には、
signed、unsigned、および簡潔な int などの型ではなく、
long 型を使用する。このようにすると、コンパイラーが、配列参照、関数呼び出し中のパラメーター、および戻される関数結果を、切り捨てたり符号拡張したりする必要がなくなります。
