问题标签 [tbb]

我尝试使用 Intel TBB 使用文件读取、排序、文件写入阶段编写双音排序的流水线版本，如下所示。代码在 while(!outQueue.try_pop(line)); 处冻结在自旋锁处；在 FileWriter 过滤器中。有人可以解释为什么会这样吗？

更新：我做了一些进一步的测试，发现头文件 _concurrent_queue_internal.h 中 try_pop 调用的 internal_try_pop 有一个 compare_and_swap 操作，对于这个特定的 try_pop，它永远失败。以下是我从 internal_try_pop 中提取的值

我认为尾部计数器值是垃圾。对于这种情况，我能想到的唯一原因是排序器添加到队列的值可能会被它隐式修改，从而使其不可用。

有任何想法吗？

谢谢 ：）

我正在使用英特尔 TBB 实现双音排序。使用parallel_invoke方法时一切顺利。但是当使用task_group（不调用wait方法）时，输出没有排序。如下使用 task_group 时，程序不会终止。

有人能看出什么问题吗？parallel_invoke 和使用 task_group 有什么区别？还有在这种情况下使用什么更好？parallel_invoke或task_group？_ 还是我应该使用其他方法？

提前致谢

有人可以指出我在 Visual Studio 2008 上开始使用 TBB 的快速方法吗？我确实完成了本教程，但它似乎有点旧（链接）

我正在使用 Intel Threading Building Blocks 库中的可扩展分配器进行一些 HPC 工作。在我的用例中，scalable_allocator 似乎过于频繁地调用 mmap。如何更改分配器使用的块的大小？

tbbmalloc_internal.h 有一个 blockSize 常量，但是改变它对我的系统产生了一些奇怪的影响，让我认为它可能不像切换一个变量那么简单。

我是线程构建块的新手，并试图在 TBB 中编码 FFT 算法以获得一些实践经验。在这种算法的情况下，我只能并行化最里面的循环。但是通过这样做，性能已经下降到无法接受的程度（超过一千次）。我尝试过最大为 2^20 的数组大小，但结果相同。我的代码如下

parallel_loop 的主体是

如果我用正常循环替换它，那么事情是正确的。

我正在尝试使用 TBB 并行化一些用 OpenCV 编写的图像匹配代码。问题是根据我的匹配（在左图像中创建一个 5x5 窗口并在右像素中逐个像素地寻找匹配）本质上是一个只读操作，目前我正在尝试并行化内部循环（即在给定的高度。我分配不同的像素到不同的线程）。令我惊讶的是，cvSetImageROI命令在并行完成时会中断。这是代码。

现在所有这些对我来说都是线程安全的，因为它们只读取图像。但是代码崩溃了。如果我在一开始就放了一个锁，虽然它可以工作。有人可以帮忙吗？

我正在尝试为线程构建块构建一些测试。不幸的是，我无法配置 tbb 库。链接器找不到库 tbb。我试过在 bin 目录中运行脚本，但没有帮助。我什至尝试将库文件移动到 /usr/local/lib/ ，这又是一个失败。任何的意见都将会有帮助。

我有一些串行代码已经开始使用英特尔的 TBB 进行并行化。我的第一个目标是并行化代码中几乎所有的 for 循环（我什至在 for 循环内并行化了 for 循环）并且现在已经完成了一些加速。我正在寻找更多的地方/想法/选项来并行化......我知道这可能听起来有点模糊，没有太多参考问题，但我在这里寻找可以在我的代码中探索的通用想法。

算法概述（以下算法在图像的所有级别上运行，从最短开始，每次将宽度和高度增加 2，直到达到实际高度和宽度）。

我在一台有 4 个英特尔处理器和 8 个内核的机器上运行一些并行代码。我正在使用 TBB。假设一个给定的循环（我并行化）有 X 次迭代我应该如何选择我的粒度以确保负载平均分配?

我有一些使用 Intel TBB 的代码，我在 32 核机器上运行。在代码中，我使用

parallel_for(blocked_range (2,left_image_width-2, left_image_width /32) ...

为执行并发工作的线程生成 32 个线程，没有竞争条件，并且希望每个线程都获得相同数量的工作。我正在使用 clock_t 来测量我的程序需要多长时间。对于某个图像，大约需要 19 秒才能完成。

然后我通过 Intel Parallel Studio 运行我的代码，它在 2 秒内运行了代码。这是我所期待的结果，但我无法弄清楚为什么两者之间存在如此大的差异。time_t 是否对所有内核的时钟周期求和？即使那样也没有意义。下面是有问题的片段。

任何意见，将不胜感激。