您不能将TBB视为另一个线程库。他们有一个全新的模型,它真正位于线程之上,并将线程抽象出来。你学会了在任务中思考,并行类型操作和管道。如果我要建立一个新项目,我可能会尝试以这种方式对其进行建模。

我们在VisualStudio中工作,它工作得很好。它最初是为linux/pthreads编写的,因此在那里也可以正常运行。

便携性

build directory ,您可以看到构建系统支持的所有配置,包括各种操作系统(Linux、Windows、Android、MacOS、iOS、FreeBSD、AIX等)和编译器(GCC、Intel、Clang/LLVM、IBM XL等)。我没有用TGB尝试PGI C++编译器,并且知道它不能与CRAY C++编译器一起工作(如2017)。

big_iron.inc 构建系统助手。其他问题是支持相对古老的GCC版本(4.1和4.4),并确保PowerPC原子能正常工作。我希望在提供或兼容GCC和POSIX的平台上,移植到任何当前不受支持的体系结构都会相对简单。

社区守则的使用

我知道至少有两个HPC应用程序框架使用TBB:

• MOOSE
• MADNESS

与其他线程模型相比的性能

我个人曾在 Parallel Research Kernels C++ subdirectory 详情请参阅。

下图显示了上述型号在Intel Xeon Phi 7250处理器上的相对性能(详细信息并不重要-所有型号使用相同的设置)。正如您所看到的,TBB做得很好,除了较小的问题规模,其中自适应调度的开销更相关。TBB具有会影响这些结果的调谐旋钮。

充分披露:我在英特尔公司从事研究/寻路工作。

我还建议大家也看看openMP 3。

(这仅适用于创建自由软件。) 不是 现在是 这个案子。

Txs,Jihn指出了这次更新。。。

我在一个项目中使用TBB。它似乎比线程更容易使用。 有些任务可以并行运行。任务只是对并行子例程的调用。负载平衡是自动完成的。这就是为什么我接受它作为一个更高级别的并行化库。我在4核intel处理器上实现了2.5倍的速度,而无需做很多工作。 有一些例子,他们在论坛上回答问题,这是维护和免费的。

TBB(线程构建块)与其他替代方案(例如C++ 11x并发特性)相比,值得一提。TBB是一个可移植且可扩展的库(不是编译器扩展),允许您以轻量级任务的形式编写代码,TBB将安排这些任务在可用的CPU资源上尽可能快地运行。它的设计不支持用于其他目的的线程(例如,抢占)。

我已经使用TBB将图像扫描线上的for循环的现有图像处理加速为并行的_for循环(作为“粒度”大小,至少有2-4条扫描线)。这是非常成功的。它确实要求(重新)写入循环体以处理任意索引,而不是假设每个循环体都是按顺序处理的(例如,在每个循环迭代之间递增的指针)。

这是一个相当简单的案例,因为没有任何共享存储可更新。使用更强大的功能(如管道)将需要对现有代码进行重大的重新构思和/或重写,因此可能更适合新代码。

这是一个强大的优势,即这种基于TBB的代码保持可移植性,似乎不会同时使用其他线程策略干扰同一进程中其他地方的其他代码,并且以后可以在更高或更低的级别与多处理策略相结合(例如,代码的TBB并行_可以从TBB多处理管道中的过滤器调用)。

我研究过TBB,但从未在项目中使用过。我看不出(就我的目的而言)比 ZThread . 可以找到一个简短且有点过时的概述 here

它相当完整,有几个线程调度选项、所有常用的同步类和一个非常方便的基于异常的线程“中断”机制。它易于扩展、编写良好并有文档记录。我已经在20多个项目中使用过它。
它还可以与任何支持POSIX线程和Windows的*NIX配合使用。

值得一看。

中的线程构造块(TBB) 新商业版299美元,不要 了解差异)是GNU吗 通用公共许可证版本2,带有 特定于仅在上使用 创建自由软件。)我看到了 其他尝试 接近LGPL但启用 事实并非如此。

据此, question

你看过吗 boost 图书馆及其应用 thread API