12

リアルタイムで実行する必要がある流体力学のナビエストークス ソルバーに取り組んでいます。したがって、パフォーマンスは重要です。

現在、実行時間のかなりの部分を占めている多数のタイト ループを調べています。ボトルネックは 1 つもありません。これらのループのほとんどは、いくつかの浮動小数点演算を実行しますが、間に多くの分岐があります。

浮動小数点演算は、ほとんどの場合、加算、減算、乗算、除算、および比較に限定されています。これはすべて 32 ビット浮動小数点数を使用して行われます。私のターゲット プラットフォームは、少なくとも SSE1 命令を備えた x86 です。(アセンブラー出力で、コンパイラーが実際に SSE 命令を生成することを確認しました。)

私が扱っているほとんどの浮動小数点値の上限はかなり小さく、ゼロに近い値の精度はそれほど重要ではありません。それで、固定小数点演算に切り替えると速度が上がるのではないかという考えが浮かびました。本当に確実な唯一の方法は測定することだとわかっていますが、それには数日かかるかもしれないので、事前に成功の確率を知りたいです.

Doom の時代には固定小数点が大流行していましたが、2010 年現在の状況がどうなっているのかはわかりません。現在、浮動小数点のパフォーマンスにどれだけのシリコンが投入されているかを考えると、固定小数点演算が引き続き使用される可能性はありますか?速度が大幅に向上しますか? 私の状況に当てはまる実世界の経験を持っている人はいますか?

4

3 に答える 3

6

浮動小数点に固執します。固定小数点が実際に役立つのは、8 ビットまたは 16 ビットで動作し、SIMD を使用できる場合のみです (画像処理とオーディオは、この典型的な使用例です)。

最新の CPU には通常 2 つの FPU があり、クロック サイクルごとに最大 2 つの FP 命令を発行できます。また、4 ウェイ FP SIMD (SSE) を使用して最適化することもできます。

それでも良いパフォーマンスが得られない場合は、Intel の ICC などのより優れたコンパイラを使用してみてください。また、64 ビットの Intel 実行可能ファイルは、64 ビット モデルのレジスタ数が増加しているため、対応する 32 ビット版よりも多少高速になる傾向があるため、可能であれば 64 ビット用にビルドしてください。

そしてもちろん、ホットスポットがどこにあるかを確実に把握できるように、コードのプロファイリングも行う必要があります。使用している OS はわかりませんが、Windows のVTune 、 LinuxのZoom 、Mac OS X のSharkはすべて、パフォーマンスのボトルネックをすばやく簡単に見つけるのに役立ちます。

于 2010-04-19T12:48:28.487 に答える
3

他の人が言ったように、すでに浮動小数点 SIMD を使用しているのであれば、固定小数点で多くの改善が得られるとは思えません。

コンパイラーが SSE 命令を発行していると言っていましたが、ベクトル化された SSE コードを作成しようとしたようには聞こえません。コンパイラが通常どれだけ優れているかはわかりませんが、調査する必要があります。

注目すべき他の 2 つの領域は次のとおりです。

  1. メモリ アクセス- すべての計算が SSE で行われている場合、キャッシュ ミスが実際の計算よりも多くの時間を占めている可能性があります。

    1. _mm_prefetch または __builtin_prefetch などを使用してデータをプリフェッチできます (コンパイラ/プラットフォームによって異なります)。
    2. 入力と出力の間のエイリアシングについて、高価な関数を確認してください。これらにより、余分なメモリの読み取り/書き込みが発生する可能性があります。
    3. 別の方法でデータを保存することを検討してください。x 座標の流体ソルバー ソルバーが y 座標とは独立している場合は、それらを別の配列に保存する方がキャッシュに適している可能性があります。それらが一緒に解決される場合は、インターリーブを検討してください (例: xyx y...)

  2. 展開- 内側のループを展開すると、パフォーマンスが向上するはずです。目標は (多くの人が考えるように) ループ終了チェックの数を減らすことではありません。主な利点は、独立した命令をインターリーブできるようにして、命令のレイテンシを隠すことです。VMX Optimization : Take it up a Levelこれは少し役立つかもしれません。Xbox360 での Altivec の指示に焦点を当てていますが、展開に関するアドバイスの一部は SSE でも役立つ可能性があります。

他の方もおっしゃっている通り、プロフィール、プロフィール、プロフィール。そして、まだ遅いものを教えてください:)

PS -ここにある他の投稿の 1 つで、マトリックス ソルバーで Gauss-Seidel の代わりに SOR を使用するように説得しました。そういえば三重対角ソルバーを使わない理由ってあるんですか？

于 2010-04-19T21:40:10.390 に答える
0

あなたのマシンは浮動小数点用にかなり最適化されているので、固定小数点の分数に行ってもあまり節約できないでしょう。

ボトルネックは 1 つではないとおっしゃっていますが、複数ある可能性があり、そのうちの 1 つを削ることができれば、残りの時間の多くの割合が残りの部分に費やされ、注意が向けられるので、それらも削ることができます。

おそらくこれを行ったことがあるでしょうが、時間のかかる関数ができるだけ高速であることだけでなく、それらが必要以上に呼び出されないようにすることもできます。

于 2010-04-19T17:01:08.837 に答える