为什么包含rand()的c++ 11代码在多个线程中比在一个线程中慢?

Why is this C++11 code containing rand() slower with multiple threads than with one?

本文关键字：线程 一个 包含 rand 代码 为什么 c++      更新时间：2023-10-16

我正在尝试新的c++ 11线程，但是我的简单测试有糟糕的多核性能。作为一个简单的例子，这个程序将一些随机数的平方相加。

#include <iostream>
#include <thread>
#include <vector>
#include <cstdlib>
#include <chrono>
#include <cmath>
double add_single(int N) {
    double sum=0;
    for (int i = 0; i < N; ++i){
        sum+= sqrt(1.0*rand()/RAND_MAX);
    }
    return sum/N;
}
void add_multi(int N, double& result) {
    double sum=0;
    for (int i = 0; i < N; ++i){
        sum+= sqrt(1.0*rand()/RAND_MAX);
    }
    result = sum/N;
}
int main() {
    srand (time(NULL));
    int N = 1000000;
    // single-threaded
    auto t1 = std::chrono::high_resolution_clock::now();
    double result1 = add_single(N);
    auto t2 = std::chrono::high_resolution_clock::now();
    auto time_elapsed = std::chrono::duration_cast<std::chrono::milliseconds>(t2-t1).count();
    std::cout << "time single: " << time_elapsed << std::endl;
    // multi-threaded
    std::vector<std::thread> th;
    int nr_threads = 3;
    double partual_results[] = {0,0,0};
    t1 = std::chrono::high_resolution_clock::now();
    for (int i = 0; i < nr_threads; ++i) 
        th.push_back(std::thread(add_multi, N/nr_threads, std::ref(partual_results[i]) ));
    for(auto &a : th)
        a.join();
    double result_multicore = 0;
    for(double result:partual_results)
        result_multicore += result;
    result_multicore /= nr_threads;
    t2 = std::chrono::high_resolution_clock::now();
    time_elapsed = std::chrono::duration_cast<std::chrono::milliseconds>(t2-t1).count();
    std::cout << "time multi: " << time_elapsed << std::endl;
    return 0;
}

在Linux和3核机器上使用'g++ -std=c++11 -pthread test.cpp'编译，典型的结果是

time single: 33
time multi: 565

所以多线程版本要慢一个数量级以上。我使用了随机数和平方根，使示例不那么琐碎，易于编译器优化，所以我没有想法。

编辑:

  1. 这个问题适用于更大的N，所以问题不是短运行时间
    2. 创建线程的时间不是问题。排除它不会显著改变结果

哇，我找到问题了。确实是rand()。我用c++ 11替换了它，现在运行时可以完美伸缩。谢谢大家!

在我的系统上的行为是相同的，但正如Maxim提到的，rand不是线程安全的。当我将rand改为rand_r时，那么多线程代码就像预期的那样快了。

void add_multi(int N, double& result) {
double sum=0;
unsigned int seed = time(NULL);
for (int i = 0; i < N; ++i){
    sum+= sqrt(1.0*rand_r(&seed)/RAND_MAX);
}
result = sum/N;
}

正如你所发现的，rand是罪魁祸首。

对于那些好奇的人来说，这种行为可能来自您使用互斥锁来实现rand的线程安全。

例如，eglibc用__random定义rand，其定义为:

long int
__random ()
{
  int32_t retval;
  __libc_lock_lock (lock);
  (void) __random_r (&unsafe_state, &retval);
  __libc_lock_unlock (lock);
  return retval;
}

这种锁会迫使多个线程串行运行，导致性能降低。

执行程序所需的时间非常小(33msec)。这意味着创建和处理多个线程的开销可能会超过实际收益。尝试使用需要更长的执行时间的程序(例如，10秒)。

为了更快，可以使用线程池模式。

这将允许您在其他线程中排队任务，而不会在每次想要使用多个线程时创建std::thread的开销。

不要在性能指标中计算设置队列的开销，只计算排队和提取结果的时间。

创建一组线程和一个任务队列(一个包含std::function<void()>的结构)来提供它们。线程在队列中等待新任务，完成它们，然后等待新任务。

任务负责将它们的"完成程度"传达给调用上下文，例如通过std::future<>。让您将函数加入任务队列的代码可能会为您完成这种包装，即签名:

template<typename R=void>
std::future<R> enqueue( std::function<R()> f ) {
  std::packaged_task<R()> task(f);
  std::future<R> retval = task.get_future();
  this->add_to_queue( std::move( task ) ); // if we had move semantics, could be easier
  return retval;
}

将返回R的裸std::function变为虚packaged_task，然后将其添加到任务队列中。注意，任务队列需要是移动感知的，因为packaged_task是仅移动的。

注1:我不是很熟悉std::future，所以上面可能是错误的。

注2:如果放入上述队列的任务在中间结果上相互依赖，则队列可能会死锁，因为没有提供"回收"被阻塞的线程并执行新代码的规定。然而，"裸计算"非阻塞任务应该可以很好地使用上述模型。

相关文章：