問題タブ [tbb]

私は OpenMP を使用して自分のプログラムを並列化しようとしていますが、行き止まりになっていると感じることがあります。

クラスで定義（および初期化）した関数メンバーで変数を共有したいと思います。私の理解が正しければ、クラス#pragma omp parallel shared(foo)のデータ メンバー ( int、boost::multi_arrayおよび など) を実行することはできません。std::vector例: クラスのベクター データ メンバーで push_back() を使用します。a の値を更新しますboost::multi_array。

私の質問は、OpenMP が適切なツールであるかどうか、または boost::thread または tbb を使用する必要があるかどうかです。または何か... C++ APIをサポートするもの

よろしく

Intel のスレッディング ライブラリとその使用方法に関する良い本を誰か推薦してもらえますか?

私はTBBconcurrent_bounded_queueを使用しています。このクラスでは、使用可能な要素がない場合にブロックされるpopを使用できるためです。キューのデフォルトのサイズはどれくらいですか？また、concurrent_bounded_queueを使用する代わりに本を読みました。parallel_whileまたはpipelineを使用します。これらは、concurrent_boundedキューの代わりにどのように役立ちますか？同期を使用して2つのスレッド間でデータを共有するためにparalle_whileまたはパイプラインを使用する方法の例を1つのplsで示すことができますか？

ありがとう！

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 はロックフリーのデータ構造を同期に利用していませんか?

yadifフィルターの並列実行を可能にする小さなffmpeg「ハック」を作成しようとしています。

私は解決策を見つけたと思いますが、それの同時インスタンスは1つしかありません。これは、「scalable_yadif_context」が元のyadif「filter_line」関数を置き換える関数「scalable_yadif_filter_line1」に対してローカルであるためです。「scalable_yadif_context」スレッドをローカルにすることもできますが、この関数は頻繁に呼び出されるため、オーバーヘッドが非常に高くなります。

この問題を解決する方法として何かアイデアはありますか？

最大18の同時インスタンスで機能する非常に醜いソリューションを作成しました。

次の場所で条件変数の記事を読んでいます

http://software.intel.com/en-us/blogs/2010/10/01/condition-variable-support-in-intel-threading-building-blocks/

私の理解では、条件変数を使用してイベントを待機しています。次の質問があります

1. 条件変数を使用しているのに、なぜここでミューテックスを使用しているのですか？
2. whileループのconsumer（）関数で、ミューテックスを取得して条件を待機しています。コンシューマーがすでにミューテックスを取得している場合、プロデューサー関数はどのようにミューテックスをロックでき、デッドロックではないことを通知できますか？
3. unique_lockはscoped_lockとどのように異なりますか？

私の質問を明確にするためにあなたの助けをありがとう。

C ++でTBBスレッドを使用し、「tbb_thread」APIを使用したい。

たとえば、私は以下のようにクラスに静的関数を持っています

tbb_thread APIを使用して、クラスの上で定義された「ThreadRoutineFunction」でスレッドを生成したいと思います。tbb_threadAPIを使用してこれを実現するにはどうすればよいですか。スレッドルーチン関数へのポインタを渡さなければならないことに注意してください。誰かが私にこれを行う方法の簡単な例を教えてもらえますか？

OpenMP、TBB、および OpenCL で通常のループ アプリケーションをいくつか実装しました。これらすべてのアプリケーションで、カーネルで特定の最適化を行わずに CPU でのみ実行している場合、OpeCL は他のアプリケーションよりもはるかに優れたパフォーマンスを提供します。OpenMP と TBB も優れたパフォーマンスを提供しますが、OpenCL よりもはるかに劣ります。これらはどちらも CPU に特化したフレームワークであり、少なくとも OpenMP/TBB と同等のパフォーマンスを提供する必要があるためです。

私の 2 番目の懸念は、OpenMP と TBB に関して言えば、私はそれほど専門家ではないので、非常に優れた最適化のために調整していない私の実装では、OpenMP は常に TBB よりもパフォーマンスが優れているということです。通常、OpenMP が TBB よりもパフォーマンスが優れている理由はありますか? どちらも、または OpenCL でさえも、低レベルで同じ種類のスレッド プーリングを使用していると思うので、専門家の意見はありますか? ありがとう

私の新しいアプリケーションでは、マルチスレッド用のライブラリの使用を柔軟に決定できます。これまでは pthread を使用していました。次に、クロス プラットフォーム ライブラリを探索します。私はTBBとBoostに焦点を当てています。Boost に対する TBB の利点が何であるかがわかりませんでした。ブーストに対する TBB の利点を見つけようとしています: TBB Excerpts for wiki "代わりに、ライブラリは、操作を「タスク」として処理できるようにすることで、複数のプロセッサへのアクセスを抽象化します。これは、ライブラリの実行によって個々のコアに動的に割り当てられます。タイム エンジン、およびキャッシュの効率的な使用を自動化することによって。TBB プログラムは、アルゴリズムに従って依存タスクのグラフを作成、同期、および破棄します。"

ただし、スレッド化ライブラリは、コアへのスレッドの割り当てについて心配する必要さえあります。これはオペレーティング システムの仕事ではないでしょうか。それでは、Boost よりも TBB を使用することの本当の利点は何でしょうか?

私はopenCVを初めて使用し、いくつかのチュートリアルに従ってみました。opencv2/imgproc/imgproc.hpp を含めて filter2D 関数を使用するまで、すべてがうまくいきました。プログラムを起動すると、次のエラーが発生しました。

「コンピューターに tbb_debug.dll が見つからないため、プログラムを開始できません。」

インターネットで、このエラーは 32 ビット バージョンと 64 ビット バージョンの dll に関係があることがわかりました。

私は 64 ビット バージョンの Windows を使用しており、VS2010 で 32 ビット コンソール アプリケーションを作成しました。アプリケーションは 32 ビット バージョンの openCV dll を使用しています。プログラム "dependency walker" を開始すると、プログラムがすべてのシステム dll の 64 ビット バージョンを使用していることがわかります (C:\windows\system32....)。opencv の dll のみが 32 ビットです。

依存ウォーカーのスクリーンショット:

ありがとう