Intel Threading Building Blocks (TBB)parallel_forのオーバーヘッドが大きいのはなぜですか? セクション 3.2.2 によると、その約 0.5 ミリ秒の自動チャンク。Tutorial.pdfこれはチュートリアルからの特技です:
注意: 通常、ループのパフォーマンスを向上させるには、parallel_for に少なくとも 100 万クロック サイクルかかる必要があります。たとえば、2 GHz プロセッサで少なくとも 500 マイクロ秒かかるループは、parallel_for の恩恵を受ける可能性があります。
私がこれまでに読んだことによると、TBB はスレッドプール (ワーカー スレッドのプール) パターンを内部で使用し、ワーカー スレッドを最初に 1 回だけ生成することで、このような悪いオーバーヘッドを防ぎます (数百マイクロ秒のコストがかかります)。
では、何が時間を取っているのでしょうか。ミューテックスを使ったデータ同期ってそんなに遅くないですか？また、TBB はロックフリーのデータ構造を同期に利用していませんか?
私がこれまでに読んだことによると、TBB はスレッドプール (ワーカー スレッドのプール) パターンを内部で使用し、ワーカー スレッドを最初に 1 回だけ生成することで (数百マイクロ秒かかります)、このような悪いオーバーヘッドを防ぎます。
はい、TBB はスレッドを事前に割り当てます。が表示されるたびにワーカー スレッドを物理的に作成して結合するわけではありませんparallel_for。OpenMP およびその他の並列ライブラリはすべて事前割り当てを行います。
ただし、プールからスレッドを起動し、論理タスクをスレッドにディスパッチするためのオーバーヘッドはまだあります。はい、TBB はロックのないデータ構造を利用してオーバーヘッドを最小限に抑えますが、それでもある程度の並列オーバーヘッド (シリアル部分) が必要です。そのため、TBB マニュアルでは、非常に短いループを避けるようにアドバイスしています。
一般に、並列処理を高速化するには、十分なジョブが必要です。1 ミリ秒 (=1,000 マイクロ秒) でも小さすぎると思います。私の経験から、意味のある高速化を確認するには、実行時間を約 100 ミリ秒増やす必要がありました。
TBB の並列オーバーヘッドparallel_forが本当に気になる場合は、単純な静的スケジューリングを試す価値があるかもしれません。私は、TBB の静的スケジューリングの実装についてよく知りません。ただし、OpenMP のものは簡単に試すことができますomp parallel for schedule(static)。このオーバーヘッドは、並列処理の最小コストになると思います。ただし、静的スケジューリングを使用しているため、動的スケジューリングの利点 (特に作業負荷が均一でない場合) が失われます。