tbb 确定不正确的并发答案

【问题标题】：tbb determines incorrect concurrencytbb 确定不正确的并发
【发布时间】：2018-07-20 14:03:07
【问题描述】：

我正在使用 tbb 进行并行化，但遇到了一个烦人的问题。

我使用 tbb::parallel_for 并且算法在单个线程上运行。

如果我打印

std::cout << tbb::task_scheduler_init::default_num_threads() << std::endl;

它报告1。

如果我通过以下方式手动覆盖并发：

 tbb::task_scheduler_init guard(std::thread::hardware_concurrency());

tbb 创建适当数量的线程，但 parallel_for 仍将所有工作安排在单个线程上（甚至不在内核之间切换）。这一切都发生在 16+ 线程的机器上。

此外top 报告100% cpu 使用情况（而不是正确的1600%）和 16 平均负载。图片上可以看到蓝色的核心已经饱和，而其余的核心有时会闲置（截图是我的桌面不是16+核心服务器，但效果差不多）。

我正在使用 tbb-2018_U5 opensuse 15 和 dlib

这是一个错误吗？

【问题讨论】：

我设法发现进程的亲和掩码是1：taskset -p 15299 pid 15299的当前亲和掩码：1

标签： multithreading tbb dlib parallel-for

【解决方案1】：

我已经设法通过强制进程的亲和性来解决这个问题。在Linux 你写：

cpu_set_t mask;
int       status;
CPU_ZERO(&mask);
const auto NUMCORES = sysconf(_SC_NPROCESSORS_ONLN);
for (int64_t core = 0; core < NUMCORES; core++) CPU_SET(core, &mask);
sched_setaffinity(0, sizeof(cpu_set_t), &mask);

在 main 函数的开头，线程按预期扩展。

【讨论】：

能否分享一下最小的复制器，或者你如何使用dlib 和tbb 的伪代码？

【解决方案2】：

也许，调用线程被dlib绑定到一个核心。考虑一下answer。

更新：根据#1422 dlib 不影响亲和力掩码。

【讨论】：

您好，我找到了这个帖子，但我不知道它是什么意思。我已经从源代码编译了dlib，但它没有（在源代码中）对 tbb 的引用。我应该寻找一些 linux API 调用吗？
看起来dlib 使用 OS API 更改了进程/线程掩码（TBB 没有更改关联性的 API）。但是，TBB 尊重 OS 对亲和掩码的设置，并根据掩码绑定自己的线程池。
Dlib 不会发送任何线程掩码用于关联或类似的东西。
我可以添加到讨论中的是 dlib::parallel_for 的行为方式类似，即它在单个核心上执行所有块。