multithreading - 英特尔 TBB 流程图开销

Question

这是我对英特尔 TBB 流图性能进行基准测试的尝试。这是设置:

• 一个广播节点发送continue_msg到 N 后继节点
  (一broadcast_node<continue_msg>)
• 每个后继节点执行一次计算，该计算需要 t 秒。
• 串行执行时的总计算时间为 Tserial = N * t
• 如果使用所有内核，理想的计算时间是 Tpar(ideal) = N * t / C ，其中 C 是核心数。
• 加速比定义为 Tpar(actual) / Tserial
• 我在 16 核 PC 上使用 gcc5 测试了代码。

以下结果显示了加速作为单个任务(即主体)处理时间的函数:

t = 100 microsecond  ,   speed-up =  14
t  = 10 microsecond  ,   speed-up =   7
t  =  1 microsecond  ,   speed-up =   1

对于轻量级任务(其计算时间少于 1 微秒)，并行代码实际上比串行代码慢。

这是我的问题:

1 ) 这些结果是否符合英特尔 TBB 基准？
2 ) 当有数千个任务每个花费不到 1 微秒的时间时，是否有比流程图更好的范例？

Answer 1

并行的开销

你的成本模型是错误的。

理想的并行计算时间是:

Tpar(ideal) = N * t / C + Pstart + Pend

其中 Pstart 是开始并行处理所需的时间，而 Pend 是完成并行处理所需的时间。 Pstart 大约为几十毫秒并不罕见。

我不确定您是否熟悉 OpenMP(尽管了解它是件好事)，但是，就我们的目的而言，它是一种在线程团队之间划分工作的线程模型。下图显示了与线程组大小相关的一些命令的开销:

要点是让您的并行性(parallel for 行)可能很昂贵，并且会随着线程数量的增加而增长。结束并行性(barrier 行)具有相似的成本。

事实上，如果你看一下 TBB 的教程，第 3.2.2 节(“自动分 block ”)说:

CAUTION: Typically a loop needs to take at least a million clock cycles for parallel_for to improve its performance. For example, a loop that takes at least 500 microseconds on a 2 GHz processor might benefit from parallel_for.

实现更快的速度

加速此类代码的最佳方法是仅在有大量操作的情况下并行执行操作和/或调整执行工作的线程数，以便每个线程都有很多事情要做。在 TBB 中，您可以实现类似的行为，如下所示:

#include <tbb/parallel_for.h>

// . . .
if(work_size>1000)
  tbb::serial::parallel_for( . . . );
else
  tbb::parallel_for( . . . );
// . . . 

您希望将 1000 调整为足够高的数字，以便您开始看到并行性带来的好处。

您还可以减少线程数，因为这会在一定程度上减少开销:

tbb::task_scheduler_init init(nthread);

TBB 还执行动态负载平衡(参见 here)。如果您希望循环迭代/任务具有广泛的运行时间分布，这很好，但如果预期的运行时间相同，则表示不必要的开销。我不确定 TBB 是否有静态调度，但可能值得研究。

如果人们最终没有对 TBB 做出坚定的 promise ，那么在 OpenMP 中，您会执行以下操作:

#pragma omp parallel for if(work_size>1000) num_threads(4) schedule(static)