0

私の教授は、SSE と OpenMP を使用した 3D 線形分離可能なカーネル畳み込みのこの興味深い実験を発見し、私たちのシステムの統計をベンチマークするタスクを私に与えました。著者は、シリアル アプローチから 18 倍のスピードアップを達成したと主張しています。常にではないかもしれませんが、これをデュアル コア Intel で実行すると、少なくとも 2 ～ 4 倍のスピードアップが期待されていました。

http://software.intel.com/en-us/articles/16bit-3d-convolution-sse4openmp-implementation-on-penryn-cpu/#comment-41994

残念ながら、スピードアップはまったく見つかりませんでした。OpenMP の有無にかかわらず、シリアル コードのパフォーマンスは常に向上します。

私は Linux を使用していますが、特定の傾向を観察しました...システムで他のプロセスが実行されていない場合、しばらくすると loadavg が増加し始め、%CPU 使用率が低下します。

私が誤って遭遇した別の誤検知の可能性...私はプログラムを開始し、すぐに一時停止しました。次に、bg を使用してバックグラウンドで実行したところ、2 倍以上のスピードアップが見られました。これは常に発生します。

どんなアドバイスも素晴らしいでしょう。

ありがとう、サヤン

4

2 に答える 2

2

ボトルネックを特定するには、プログラムのプロファイルを作成する必要があります。また、より「全体的な」方法で最適化を検討する必要があります。パフォーマンスの問題は、貧弱な設計、貧弱なコーディング、メモリ帯域幅の制限、およびその他の多くの問題に関連している可能性があります。これらの問題は、スカラー コードの代わりに SIMD を使用するなどのマイクロ最適化では解決されません。

プロファイルから始めて (これにはZoomなどのツールを使用します)、そこから作業を進めます。

于 2010-04-12T16:44:32.623 に答える
0

-O0 オプション (最適化なし) を使用してプログラムをコンパイルしたところ、ほとんどすべての XYZ 値でほぼ 2 倍のスピードアップが得られました。また、デュアル コアで 2 つのスレッドが使用されていることも確認できました (以前は 1 つしか使用していませんでした)。しかし今、OpenMP プラグマを削除しても、スピードアップは見られませんでした。SSE は物事をかなりスピードアップできるはずなので、これは私を悩ませます。したがって、この高速化は完全に OpenMP に起因する可能性があり、SSE が失敗する理由を突き止める必要があります。操作が些細な場合 (おそらく、この言葉が発する重みは人によって異なるため、議論の余地があります)、SSE を使用しても高速化は得られない、と誰かが私に言いました。しかし、i_max_size = 64000 の sqrt(i)/i を計算する小さなプログラムを書きました。SSE バージョンでは 3.5 ~ 4.0 の高速化が得られました。

于 2010-04-14T17:19:11.847 に答える