コーディングによる（マイクロ最適化以外の）パフォーマンスの向上はありますか
float f1 = 200f / 2
と比較して
float f2 = 200f * 0.5
私の教授は数年前に、浮動小数点の除算は浮動小数点の乗算よりも遅いと言いましたが、その理由は詳しく説明されていませんでした。
この声明は、最新の PC アーキテクチャにも当てはまりますか?
アップデート1
コメントに関しては、次のケースも考慮してください。
float f1;
float f2 = 2
float f3 = 3;
for( i =0 ; i < 1e8; i++)
{
f1 = (i * f2 + i / f3) * 0.5; //or divide by 2.0f, respectively
}
更新 2 コメントからの引用:
[私が知りたい] > 除算が乗算よりもハードウェアではるかに複雑になるアルゴリズム/アーキテクチャ要件は何かを知りたい
はい、多くのCPUは1または2クロックサイクルで乗算を実行できますが、除算には常に時間がかかります（ただし、FP除算は整数除算よりも高速な場合があります）。
この答えを見ると、分割が24サイクルを超える可能性があることがわかります。
なぜ除算は乗算よりもはるかに長い時間がかかるのですか？小学校に戻ったことを思い出すと、乗算は基本的に多くの同時加算で実行できることを思い出すかもしれません。除算には、同時に実行できない反復減算が必要なため、時間がかかります。実際、一部のFPユニットは、逆数近似を実行してそれを乗算することにより、除算を高速化します。それほど正確ではありませんが、多少高速です。
除算は、本質的に乗算よりもはるかに遅い演算です。
そして、これは実際には、浮動小数点の不正確さのために多くの場合、コンパイラが最適化できない(そして、最適化したくない) ものである可能性があります。これらの 2 つのステートメント:
double d1 = 7 / 10.;
double d2 = 7 * 0.1;
意味的に同一ではありません -として正確0.1に表すことができないdoubleため、わずかに異なる値が使用されることになります - この場合、除算を乗算に置き換えると、異なる結果が得られます!
はい。私が認識しているすべての FPU は、除算よりもはるかに高速に乗算を実行します。
ただし、最近の PC は非常に高速です。また、多くの状況下で違いを無視できるパイプライン アーキテクチャも含まれています。それに加えて、適切なコンパイラーは、最適化をオンにしてコンパイル時に示した除算演算を実行します。更新された例では、まともなコンパイラはその変換自体を実行します。
したがって、一般的には、コードを読みやすくすることを心配し、コンパイラーに高速化を心配させる必要があります。その行で測定された速度の問題がある場合にのみ、速度のためにコードを改変することを心配する必要があります。コンパイラは、CPU の速度よりも高速なものをよく認識しており、一般に、期待以上に優れたオプティマイザです。
2つのnビット数の乗算に何が必要かを考えてください。最も簡単な方法では、1つの数値xを繰り返しシフトし、条件付きでそれをアキュムレータに追加します（他の数値yのビットに基づく）。n個の追加が完了すると完了です。結果は2nビットに収まります。
除算では、xを2nビット、yをnビットから始め、x/yを計算します。最も簡単な方法は筆算ですが、2進数です。各段階で、比較と減算を実行して、商のもう1ビットを取得します。これにはnステップかかります。
いくつかの違い：乗算の各ステップは1ビットだけを見る必要があります。分割の各段階では、比較中にnビットを確認する必要があります。乗算の各段階は、他のすべての段階から独立しています（部分積を追加する順序は関係ありません）。除算の場合、各ステップは前のステップによって異なります。これはハードウェアにとって大きな問題です。物事が独立して実行できる場合、それらはクロックサイクル内で同時に発生する可能性があります。
答えは、プログラミングしているプラットフォームによって異なります。
たとえば、コンパイラはSIMD命令を使用するアセンブラコードを作成する必要があるため、x86の配列で多くの乗算を実行すると、除算よりもはるかに高速になります。SIMD命令には除算がないため、乗算を使用してから除算を使用すると、大幅な改善が見られます。