Intel のThreading Building Blocks (TBB)オープン ソース ライブラリは非常に興味深いものです。このテーマに関するO'Reilly Bookさえありますが、多くの人がそれを使用しているとは聞いていません。Unix (Mac、Linux など) 環境でマルチレベルの並列アプリケーション (MPI + スレッド) に使用することに興味があります。なんといっても、私はハイ パフォーマンス コンピューティングや数値計算の種類のアプリケーションに興味があります。
TBBの経験がある人はいますか？うまくいきますか？かなり移植性がありますか (GCC やその他のコンパイラを含む)? このパラダイムは、あなたが作成したプログラムでうまく機能しますか? 調べる必要がある他のライブラリはありますか?
16コアのマシンに移行したときに使用するbettermallocが必要だったため、コードベースに導入しました。8以下では、それは重要な問題ではありませんでした。それは私たちにとってうまくいきました。次に、きめの細かい並行コンテナを使用する予定です。理想的には、製品の本質を利用できますが、そのためには、コードの作成方法を再考する必要があります。TBBのアイデアは本当に気に入っていますが、コードベースに後付けするのは簡単ではありません。
TBBを別のスレッドライブラリと考えることはできません。それらには、スレッドの上に実際に配置され、スレッドを抽象化するまったく新しいモデルがあります。タスク、parallel_forタイプの操作とパイプラインで考えることを学びます。新しいプロジェクトを構築する場合は、おそらくこの方法でモデル化しようとします。
Visual Studioで動作し、問題なく動作します。もともとはlinux/pthreads用に書かれていたので、あちらでも問題なく動作します。
私は数値計算を行っていませんが、データマイニング（クラスタリングと分類を考えてください）を使用しています。ワークロードはおそらく似ています。すべてのデータは静的であり、プログラムの最初にあります。私はIntelのTBBを簡単に調査しましたが、私のニーズに対してそれらがやり過ぎであることがわかりました。生のpthreadベースのコードから始めた後、OPENMPに切り替えて、読みやすさとパフォーマンスを適切に組み合わせました。
あるプロジェクトで TBB を使用しています。スレッドより使いやすそうでした。並行して実行できるタスクがあります。タスクは、並列化されたサブルーチンへの単なる呼び出しです。負荷分散は自動的に行われます。そのため、私はそれをより高いレベルの並列化ライブラリとして受け入れています。4 コアの Intel プロセッサで、あまり手を加えずに 2.5 倍の速度アップを達成しました。例があり、フォーラムで質問に答えており、維持されており、無料です。
ZThread は LGPL です。オープン ソース プロジェクトで作業していない場合、動的リンケージでのライブラリの使用に制限されます。
オープン ソース バージョンの Threading Building Blocks (TBB) (299 ドルの新しい商用バージョンがありますが、違いはまだわかりません) は、GNU General Public License バージョン 2 であり、いわゆる「ランタイム例外」(つまり、
LGPL に近づこうとする他のランタイム例外を見たことがありますが、商用利用と静的リンクを有効にすると、現在はそうではありません 。
私がこれを書いているのは、ライブラリのライセンスを調査する機会を得たからであり、それらは、ライブラリに与える意図に基づいた選択の考慮事項でもあるはずです。
Txs、このアップデートを指摘してくれたジン...
私は TBB を簡単に使用しましたが、将来的にはもっと使用することになるでしょう。最も重要なことは、C++ のマクロ/拡張機能を扱う必要がなく、言語内にとどまるからです。また、かなりポータブルです。WindowsとLinuxの両方で使用しました。ただし、TBB を使用してスレッドを操作するのは難しく、タスクの観点から考える必要があります (これは実際には良いことです)。Intel TBB は裸のロックの使用をサポートしません (面倒です)。しかし、全体として、これは私の予備的な経験です。
また、openMP 3 も参照することをお勧めします。
他の代替手段 (例: C++ 11x 同時実行機能) と比較するために、TBB (Threading Building Blocks) の目的を明確にすることは価値があります。TBB は移植可能でスケーラブルなライブラリ (コンパイラ拡張ではありません) であり、TBB が利用可能な CPU リソースで可能な限り高速に実行するようにスケジュールする軽量タスクの形式でコードを記述できます。他の目的 (プリエンプションなど) のスレッド化をサポートするようには設計されていません。
TBB を使用して、画像スキャン ライン上の for ループの既存の画像処理を parallel_for ループ (「粒度」サイズとして最低 2 ～ 4 スキャン ライン) に高速化しました。これは非常に成功しています。各ループ本体が順次処理されると仮定するのではなく、任意のインデックスを処理するようにループ本体を (再) 書き込む必要があります (たとえば、各ループ反復間でインクリメントされるポインター)。
更新する共有ストレージがなかったので、これはかなり些細なケースでした。より強力な機能 (パイプラインなど) を使用するには、既存のコードを大幅に再考したり書き直したりする必要があるため、おそらく新しいコードに適しています。
この TBB ベースのコードが移植性を維持し、他のスレッド戦略を同時に使用している同じプロセス内の他の場所にある他のコードに干渉しないように思われ、後で上位または下位レベルでマルチプロセッシング戦略と組み合わせることができることは強力な利点です (例: TBB parallel_forコードは、TBB マルチプロセッシング パイプラインのフィルターから呼び出すことができます)。
私は TBB を調べましたが、プロジェクトで使用したことはありません。ZThreadよりも（私の目的のために）利点はありませんでした。簡潔でやや時代遅れの概要については、こちらを参照してください。
いくつかのスレッド ディスパッチ オプション、すべての通常の同期クラス、および非常に便利な例外ベースのスレッド "割り込み" メカニズムでかなり完全です。簡単に拡張でき、適切に記述され、文書化されています。20以上のプロジェクトで使用しました。
また、Windows だけでなく、POSIX スレッドをサポートする *NIX でもうまく機能します。
一見の価値あり。
オープン ソース バージョンの Threading Building Blocks (TBB) (299 ドルの新しい商用バージョンがあり、違いはまだわかりません) は、GNU General Public License バージョン 2 であり、いわゆる「ランタイム例外」(つまり、 LGPL に近づこうとする他のランタイム例外を見たことがありますが、商用利用と静的リンクを可能にするのはそうではありません。
この質問によると、ビルディングブロックのスレッド化は、商用利用でコピーレフトの制限なしで使用できます。
スレッド APIを使用してブーストライブラリを見たことがありますか?