parallel_for ppl.h 不比顺序 C++ 快答案

【问题标题】：parallel_for ppl.h not faster than sequential c++parallel_for ppl.h 不比顺序 C++ 快
【发布时间】：2016-10-03 14:42:12
【问题描述】：

我有这样的代码（伪代码，因为我无法显示我的程序）：

concurrent_vector a, b, c;
concurrent_unordered_map mapForResult;

for(i=0; i<sequenceCount; i++){
  variables temp_a, temp_b, temp_c;
  database->read(&a, &b, &c);
}

parallel_for(0, sequenceCount, [](int i){
  var aa = a[i];
  var bb = b[i];
  var cc = c[i];

  resultOfFunction = MakeFunction(aa, bb, cc);

  mapForResults.insert(resultOfFunction);
}, static_partitioner());

它正在工作，但它比顺序版本慢得多。任何想法为什么？这是我第一次使用 ppl.h，所以我不知道所有提示和技巧。

【问题讨论】：

两个循环之间的缓存表现如何？并行版本中是否有很多缓存未命中？
如何验证？我是 C++ 和并行的初学者。
如果你在 Linux 上，你可以使用perf。
不幸的是 Windows。
This 可能会有所帮助。

标签： c++ parallel-processing ppl

【解决方案1】：

程序的每个并行版本都比单线程版本需要更多的指令。设置线程和管理对共享数据的访问只是不可避免的开销。这通常是有限的开销，当您有足够的可用内核时，额外的指令不会转化为额外的时间。简单地说，如果您有 300% 的额外内核，那么 10% 的开销并不是什么大问题。

在这种情况下，MakeFunction 可能非常小。这意味着您确实有很多开销，并且您的额外核心花费所有时间来争夺mapForResults。

【讨论】：

不幸的是 MakeFunction 很大。当我在小型数据库（大约 30 个序列）上使用它时，它比顺序快两倍。但是，当我尝试在大约 10000 个序列的数据库上使用它时，它就慢了。
还有一个问题：如果我使用 concurrent_vector 或 concurrent_unordered_map 战斗也会有问题吗？我选择了它而不是 Critical_Section，因为我认为它当时没有战斗。
"MakeFunction is big" 有点令人困惑 - 但随后您会跟进“数据库”。在添加单词数据库时，您更改了问题。也许你可以添加更多关于这个“MakeFunction”是什么以及做什么的信息。
@Queen：为什么选择无序映射（又名哈希表）作为输出结构？每次插入都必须维护其 O(1) 查找，这不是免费的。使用大小为sequenceCount 的普通向量可能更容易。它不需要并发，因为容器不需要改变大小，每个元素都由单个线程访问一次。
当然：std::vector<std::pair<int, std::string>> example(sequenceCount);