【发布时间】：2020-11-04 02:14:46
【问题描述】：
考虑这段代码：
#include <algorithm>
#include <chrono>
#include <cstdio>
#include <execution>
#include <functional>
#include <random>
#include <vector>
using namespace std;
using namespace std::chrono;
constexpr size_t NUM_OF_ELEMENTS = 30000000;
// execute lambda and print the execution time
void measure(function<void()> lambda)
{
auto start = high_resolution_clock::now();
lambda();
auto end = high_resolution_clock::now();
printf("%ld\n", duration_cast<microseconds>(end - start).count());
}
int main()
{
random_device rd;
mt19937_64 gen(rd());
// range from INT_MIN to INT_MAX
uniform_int_distribution<> distr(-2147483648, 2147483647);
vector<int> original;
original.reserve(NUM_OF_ELEMENTS);
for(size_t i = 0; i < NUM_OF_ELEMENTS; i++)
original.push_back(distr(gen));
vector<int> the_copy(original.begin(), original.end());
// sort with single thread
measure([&]{ sort(original.begin(), original.end()); });
// sort with execution::par
measure([&]{ sort(execution::par, the_copy.begin(), the_copy.end()); });
return 0;
}
代码可以总结为几点：
- 创建随机数生成器
- 创建随机整数向量
- 创建该向量的副本
- 用一个线程对原始向量进行排序并测量执行时间
- 使用
std::execution::par对副本进行排序并测量执行时间 - 打印执行时间
execution::par 版本总是需要更长的时间。不管NUM_OF_ELEMENTS 有什么价值。我尝试了从 100 000 到 30 000 000 以 100 000 递增的值。上面的代码会产生类似的结果（以微秒为单位的值）：
9729406 // single thread
10834613 // execution::par
我使用 VS Code 在 Windows 10 上使用 gcc 编译了代码：
g++ -std=c++17 -g ${workspaceFolder}/main.cpp -o ${workspaceFolder}/main.exe
对于 C++ 标准库，我使用 here 的 mingw 发行版。
程序版本：GCC 10.1.0 + LLVM/Clang/LLD/LLDB 10.0.0 + MinGW-w64 7.0.0
我的处理器有 6 个内核，在执行时我没有运行任何主要程序或后台进程。
首先，我认为这与向量的大小有关，但 30 000 000 个元素肯定足够了。在完成单次测试之前，它已经运行了 10 秒。
- 这是怎么回事？
-
execution::par是不是应该这样使用？ - 是否必须启用某些编译标志或其他技巧才能使其按预期工作？
【问题讨论】：
-
您不应该对未优化的代码进行性能比较。使用
-O2，您的性能结果可能会发生巨大变化。 -
如果交换 sort 和 par sort 调用的行会产生什么结果？
-
@JorgeBellon 遗憾的是，事实并非如此。使用
-O2，它为两者提供了更好的时间：2111474 and 2172487但execution::par仍然较慢。 -
在一个问题上投入更多线程并不能保证更快的代码。尤其是你使用的线程越多，任务切换和操作系统必须执行的任务就越多，如果你不小心，这实际上会减慢代码。
-
@Taekahn 我同意。但这是基本的排序。多线程应该会更快。
标签： c++ multithreading sorting c++17 mingw-w64