OpenMP、TBB、および OpenCL で通常のループ アプリケーションをいくつか実装しました。これらすべてのアプリケーションで、カーネルで特定の最適化を行わずに CPU でのみ実行している場合、OpeCL は他のアプリケーションよりもはるかに優れたパフォーマンスを提供します。OpenMP と TBB も優れたパフォーマンスを提供しますが、OpenCL よりもはるかに劣ります。これらはどちらも CPU に特化したフレームワークであり、少なくとも OpenMP/TBB と同等のパフォーマンスを提供する必要があるためです。
私の 2 番目の懸念は、OpenMP と TBB に関して言えば、私はそれほど専門家ではないので、非常に優れた最適化のために調整していない私の実装では、OpenMP は常に TBB よりもパフォーマンスが優れているということです。通常、OpenMP が TBB よりもパフォーマンスが優れている理由はありますか? どちらも、または OpenCL でさえも、低レベルで同じ種類のスレッド プーリングを使用していると思うので、専門家の意見はありますか? ありがとう
TBB や OpenMP に対する OpenCL の利点の 1 つは、ハードウェアで SIMD 並列処理をより有効に活用できることです。一部の OpenCL 実装では、各作業項目がマシンの SIMD ベクトル レーンで実行されるだけでなく、個別のコアで実行されるように、コードを実行します。アルゴリズムによっては、これにより多くのパフォーマンスが向上する可能性があります。
C コンパイラは、自動ベクトル化を使用して SIMD 並列処理を利用することもできますが、C のメモリ エイリアシング規則により、場合によってはこれが機能しにくくなります。OpenCL では、プログラマーが作業項目を呼び出してメモリ アクセスを明示的にフェンスする必要があるため、OpenCL コンパイラはより積極的になる可能性があります。
結局、それはあなたのコードに依存します。OpenCL、OpenMP、または TBB のいずれかが最適なアルゴリズムを見つけることができます。
Intel が提供する CPU および MIC 用の OpenCL ランタイムは、内部で TBB を使用します。これは単なる「低レベルでのスレッド プーリング」ではありません。TBB が提供する洗練されたスケジューリング アルゴリズムとパーティショニング アルゴリズムを利用して負荷バランスを改善し、CPU の使用率を向上させるからです。
TBBとOpenMPについて。通常、それは誤った測定に帰着します。たとえば、TBB には OpenMP のような暗黙のバリアがないため、ウォームアップ ループでは不十分です。すべてのスレッドが作成され、このオーバーヘッドが測定に含まれていないことを確認する必要があります。別の例: コンパイラーは、OpenMP でベクトル化された同じコードを TBB でベクトル化できない場合があります。
OpenCL カーネルは、特定のハードウェア用にコンパイルされます。ベンダー/ハードウェア固有の最適化の可能性は非常に大きいです。