c++ - 多线程C++程序性能不佳

Question

我有一个在Linux上运行的C++程序，在其中创建了一个新线程来独立于主线程进行一些计算量大的工作(通过将结果写入文件来完成计算工作，最终结果非常大)。但是，我的性能相对较差。

如果我直接实现该程序(不引入其他线程)，它将在大约2个小时内完成任务。使用多线程程序需要大约12个小时才能完成相同的任务(仅在产生一个线程的情况下进行了测试)。

我尝试了几件事，包括pthread_setaffinity_np将线程设置为单个CPU(我正在使用的服务器上的24个可用线程)，以及pthread_setschedparam设置调度策略(我只尝试了SCHED_BATCH )。但是到目前为止，这些影响可以忽略不计。

是否有导致此类问题的一般原因？

编辑:我已经添加了一些我正在使用的示例代码，希望这是最相关的部分。函数process_job()实际上是计算工作，但是要在此处包含太多内容。基本上，它读取两个数据文件，并使用它们在内存中的图形数据库上执行查询，在该数据库中，结果在一个小时内被写入两个大文件中。

编辑第2部分:只是为了澄清，问题不是我想使用线程来提高我拥有的算法的性能。但是，我想同时运行我的算法的许多实例。因此，我希望算法在放入线程时的运行速度与完全不使用多线程时的运行速度相似。

编辑第3部分:感谢所有建议。我目前正在按照一些建议进行一些单元测试(看看哪些部分在变慢)。由于该程序需要花费一些时间来加载和执行，因此要花一些时间才能看到测试的任何结果，因此，对于较晚的响应，我深表歉意。我认为我想澄清的要点是线程可能导致程序运行缓慢的可能原因。根据我从评论中收集到的信息，根本不应该如此。我会在找到合理的分辨率时发布信息，再次感谢。

(最后)编辑第4部分:事实证明，该问题毕竟与线程无关。在这一点上描述它太麻烦了(包括使用编译器优化级别)，但是此处发布的想法非常有用并且受到赞赏。

struct sched_param sched_param = {
    sched_get_priority_min(SCHED_BATCH)
};

int set_thread_to_core(const long tid, const int &core_id) {
   cpu_set_t mask;
   CPU_ZERO(&mask);
   CPU_SET(core_id, &mask);
   return pthread_setaffinity_np(tid, sizeof(mask), &mask);
}

void *worker_thread(void *arg) {
   job_data *temp = (job_data *)arg;  // get the information for the task passed in
   ...
   long tid = pthread_self();
   int set_thread = set_thread_to_core(tid, slot_id);  // assume slot_id is 1 (it is in the test case I run)
   sched_get_priority_min(SCHED_BATCH);
   pthread_setschedparam(tid, SCHED_BATCH, &sched_param);
   int success = process_job(...);  // this is where all the work actually happens
   pthread_exit(NULL);
}

int main(int argc, char* argv[]) {
   ...
   pthread_t temp;
   pthread_create(&temp, NULL, worker_thread, (void *) &jobs[i]);  // jobs is a vector of a class type containing information for the task
   ...
   return 0;
}

Answer 1

如果您有大量的CPU内核并且有大量的工作要做，那么在多线程中运行的时间应该不会比单线程模式花费的时间长-实际的CPU时间可能要长一点，但是“挂钟时间”应该是较短。我很确定您的代码存在某种瓶颈，其中一个线程阻塞了另一个线程。

这是因为其中一项或多项-我将首先列出它们，然后在下面进行详细说明:

线程中的某些锁正在阻止第二个线程运行。

线程之间的数据共享(true或“false”共享)

缓存崩溃。

对某些外部资源的竞争，导致崩溃和/或阻塞。

一般而言，设计不良的代码...

线程中的某些锁正在阻止第二个线程运行。

如果有一个线程需要锁，而另一个线程要使用该线程锁定的资源，则它必须等待。显然，这意味着线程没有做任何有用的事情。只能通过短时间锁来将锁保持在最低限度。使用一些代码来识别锁是否持有您的代码，例如:

while (!tryLock(some_some_lock))
{
    tried_locking_failed[lock_id][thread_id]++;
}
total_locks[some_lock]++;

打印一些锁的统计信息将有助于确定锁的争用位置-或者您可以尝试“在调试器中按Break并查看您的位置”这一老技巧-如果线程一直在等待某个锁，那就是阻碍进步...

线程之间的数据共享(true或“false”共享)

如果两个线程使用[并经常更新其值]相同的变量，则两个线程将必须交换“我已更新此”消息，并且CPU必须先从另一个CPU获取数据，然后才能继续使用它的变量。由于“数据”是在“每个缓存行”级别共享的，并且缓存行通常为32字节，因此类似:

int var[NUM_THREADS]; 
...
var[thread_id]++; 

将被归类为“虚假共享”-每个CPU更新的ACTUAL数据是唯一的，但是由于数据位于相同的32字节区域内，因此内核仍将更新相同的内存。

缓存颠簸。

如果两个线程进行大量的内存读和写操作，则CPU的缓存可能会不断丢弃好数据，以将其他线程的数据填充到该数据中。有一些可用的技术可以确保两个线程不会在“锁步”中运行，CPU使用缓存的那一部分。如果数据为2 ^ n(2的幂)且相当大(为高速缓存大小的倍数)，则为每个线程“添加偏移量”(例如1KB或2KB)是一个好主意。这样，当第二个线程将相同的距离读入数据区域时，它将不会覆盖第一个线程当前正在使用的完全相同的缓存区域。

对某些外部资源的竞争导致颠簸和/或阻塞。

如果有两个线程正在对硬盘，网卡或某些其他共享资源进行读写，则可能导致一个线程阻塞另一个线程，从而降低性能。该代码也有可能检测到不同的线程并进行一些额外的刷新操作，以确保在开始与另一个线程一起工作之前以正确的顺序或类似的顺序写入数据。

当一个以上的线程正在使用同一资源时，在代码中内部也可能存在锁定资源的锁(用户模式库或内核模式驱动程序)，这些锁会阻塞。

一般不好的设计

这是“很多其他可能出错的东西”的“杂物间”。显然，如果需要一个线程中一个计算的结果来进行另一线程的计算，那么显然，在那个线程中不能做很多工作。

工作单元太小，因此所有时间都花在启动和停止线程上，并且工作量不足。举例来说，您将少量数字分配给每个线程“计算是否为质数”，一次分配一个数字，那么将数字分配给线程可能要比计算“是这个时间”花费更长的时间。实际上是质数”-解决方案是为每个线程提供一组数字(也许是10、20、32、64等)，然后一次性报告整个批次的结果。

还有很多其他的“不良设计”。如果不了解您的代码，很难确定。

您的问题很可能不是我在这里提到的问题，而是最可能的问题之一。希望此解决方案有助于查明原因。