【问题标题】:performance difference of pthreadspthread的性能差异
【发布时间】:2015-10-28 05:54:07
【问题描述】:

我正在编写对性能敏感的代码。我实现了一个简单的调度程序来分配工作负载,主线程负责调度程序。

cpu_set_t cpus;
pthread_attr_t attr;
pthread_attr_init(&attr);
     for(int i_group =0; i_group<n_groups; i_group++){
        std::cout  << i_t<< "\t"<<i_group << "th group of cpu"  <<std::endl;
        for(int i =index ; i < index+group_size[i_group]; i++){
            struct timeval start, end;
            double spent_time;
            gettimeofday(&start, NULL);
            arguments[i].i_t=i_t;
            arguments[i].F_x=F_xs[i_t];
            arguments[i].F_y=F_ys[i_t];
            arguments[i].F_z=F_zs[i_t];
            CPU_ZERO(&cpus);
            CPU_SET(arguments[i].thread_id, &cpus);
            int err= pthread_attr_setaffinity_np(&attr, sizeof(cpu_set_t), &cpus);
            if(err!=0){
                std::cout << err <<std::endl;
                exit(-1);
            }
            arguments[i].i_t=i_t;
            pthread_create( &threads[i], &attr, &cpu_work, &arguments[i]);
            gettimeofday(&end, NULL);
            spent_time = ((end.tv_sec  - start.tv_sec) * 1000000u + end.tv_usec - start.tv_usec) / 1.e6;
            std::cout <<"create: " << spent_time << "s " << std::endl;
        }
        i_t++;
        cpu_count++;
        arr_finish[i_group]=false;
    }
} 

就像上面的主线程创建。为了简单的解释,我假设 i_group=1。子线程分而治之的是一堆矩阵-矩阵乘法。这里 rank 表示 thread_id。

int local_first = size[2]*( rank -1 )/n_compute_thread ;
int local_end = size[2] * rank/n_compute_thread-1;
//mkl_set_num_threads_local(10); 

gettimeofday(&start, NULL);
for(int i_z=local_first; i_z<=local_end; i_z++ ){
    cblas_dgemm( CblasColMajor, CblasNoTrans, CblasNoTrans,
                size[0], size[1], size[0], 1.0,  F_x, size[0],
                rho[i_z], size[1], 0.0, T_gamma[i_z], size[1] );
}
for(int i_z=local_first; i_z<=local_end; i_z++ ){
    cblas_dgemm( CblasColMajor, CblasNoTrans, CblasNoTrans,
                 size[0], size[1], size[1], 1.0, T_gamma[i_z], size[0],
                 F_y, size[1], 0.0, T_gamma2[i_z], size[0] );
}
gettimeofday(&end, NULL);
std::cout <<i_t <<"\t"<< arg->thread_id <<"\t"<< sched_getcpu()<<  "\t" << "compute: " <<spent_time << "s" <<std::endl;

尽管工作负载相当分散,但每个线程的性能差异太大。看看下面的结果

5 65 4 4 计算:0.270229s

5 64 1 1 计算:0.284958s

5 65 2 2 计算:0.741197s

5 65 3 3 计算:0.76302s

第二列显示了在特定线程中完成了多少矩阵-矩阵乘法。最后一列显示消耗的时间。 当我第一次看到这个结果时,我认为它与线程的亲和性有关。因此,我添加了几行来控制线程的绑定。但是,它并没有改变最后一栏的趋势。

我的电脑有 20 个物理核心和 20 个虚拟核心。我只做了 4 个子线程来测试。当然,它是在 Linux 机器上测试的。

为什么线程的性能差异如此之大?以及如何解决?

【问题讨论】:

  • 这不是问题。
  • 是的,......我忘记了这个问题......
  • gettimeofday 不是正确的工具。 man7.org/linux/man-pages/man3/pthread_getcpuclockid.3.html(这可能无法解决您的问题)。
  • benching 认为比一秒快的速度变化太大,你需要让他们做更多的工作。使用clock_gettimeCLOCK_MONOTONIC 进行测量。但你甚至没有告诉我们spent_time 是如何计算的。另外请避免混合语言,您的代码似乎是 C 但使用 C++ IO 功能。
  • 同意@Jens。性能测试的运行时间应超过亚秒级。比较线程池在生命的最初几毫秒内的性能,就像比较一匹赛马在比赛前两步后的性能。观察并不是一件完全坏事,但将有关性能的信息限制为仅开始性能。调度任务几乎没有时间进入静止状态。为了获得整体性能(在这种情况下工作负载分散),让它运行一分钟以上,看看情况如何。 (或不)

标签: c++ linux multithreading pthreads


【解决方案1】:

首先,您实际上是在创建调度程序吗?您的代码示例表明您正在使用 Linux 调度程序并设置线程属性对象和线程关联参数等。这种差异与选择如何解决问题有关。

在任何情况下,问题都很大,并且可以提出几个额外的问题/主题来帮助澄清条件,并更接近真正的答案。首先,需要考虑以下几点:

1 - 基准测试的长度。对线程池中线程性能的亚秒级评估似乎不够充分。延长评估时间以使调度程序有时间稳定下来。也许几分钟。
(有关现有基准测试实用程序中使用的典型持续时间示例,read this

2 - 线程优先级。你的线程不是唯一的。内核调度程序是否可能会定期将基准测试作为属于具有更高优先级的其他进程(您创建的进程除外)的线程? (因此正在取代你的,导致任务完成时间倾斜)

3 - 任务的大小。完成每个任务所需的操作数量是否足够小以适应调度程序分配的时间片?这可能有助于感知线程到线程的性能问题,尤其是在每个任务之间的操作数量存在差异的情况下。 (Processes that exceed the allotted CPU time slice are automatically moved down to a lower “tier,” while processes that make I/O requests or block will be moved to higher “tiers.”

4 - 任务平等 - 你提到分而治之的是一堆矩阵-矩阵乘法。但是矩阵的大小是否相同,内容是否相似。即,您确定每个任务中的操作数等于所有其他任务中的操作数吗?调度程序分配给每个同等优先级线程的时间片将确保随着时间的推移,操作计数大于单个时间片可以完成的任务将更容易受到更长完成时间的影响( context switching 因为其他操作系统进程的优先级更高)比那些操作少到足以适应一个时间片的那些。

5 - 其他进程。我在上面的其他项目中提到了这一点,但它应该有自己的编号。 In order to use multiple cores,同时需要多个线程。但反之则不成立。单核不限于单线程。操作系统可以随时以更高优先级的进程抢先中断 特定核心 上的一个进程(线程),(同时不中断任何其他核心)可能会扭曲您的时间测量。同样,更长的基准测试时间将有助于减少由这种特殊现象引起的线程间差异的影响。

【讨论】:

    猜你喜欢
    • 2013-03-28
    • 1970-01-01
    • 2016-02-02
    • 2018-02-08
    • 1970-01-01
    • 2023-04-09
    • 2013-07-08
    • 2013-07-12
    • 1970-01-01
    相关资源
    最近更新 更多