当我使用并行代码时，为什么我的计算机没有显示加速？

Question

所以我意识到这个问题听起来很愚蠢（是的，我使用的是双核），但我尝试了两个不同的库（Grand Central Dispatch 和 OpenMP），并且当使用 Clock() 对带有和不带有使代码行进行计时的代码时平行的话，速度是一样的。 （根据记录，他们都使用自己的并行形式）。他们报告在不同的线程上运行，但也许他们在同一个核心上运行？有什么办法可以检查吗？ （这两个库都是针对 C 的，我在较低层感到不舒服。）这太奇怪了。有什么想法吗？

Answer 1

编辑：添加了 Grand Central Dispatch 的详细信息以响应 OP 评论。

虽然这里的其他答案通常很有用，但您问题的具体答案是您不应该使用 clock() 来比较计时。 clock() 测量跨线程累加的 CPU 时间。当您在核心之间拆分作业时，它至少会使用同样多的 CPU 时间（由于线程开销，通常会多一点）。在此页面上搜索clock()，找到“如果进程是多线程的，CPU时间添加进程的所有单独线程消耗的内容。”

只是该作业是在线程之间分割的，因此您需要等待的总时间会更少。您应该使用挂钟时间（挂钟上的时间）。 OpenMP 提供了一个例程 omp_get_wtime() 来执行此操作。以下面的例程为例：

#include <omp.h>
#include <time.h>
#include <math.h>
#include <stdio.h>

int main(int argc, char *argv[]) {
    int i, nthreads;
    clock_t clock_timer;
    double wall_timer;
    for (nthreads = 1; nthreads <=8; nthreads++) {
        clock_timer = clock();
        wall_timer = omp_get_wtime();
        #pragma omp parallel for private(i) num_threads(nthreads)
        for (i = 0; i < 100000000; i++) cos(i);
        printf("%d threads: time on clock() = %.3f, on wall = %.3f\n", \
            nthreads, \
            (double) (clock() - clock_timer) / CLOCKS_PER_SEC, \
            omp_get_wtime() - wall_timer);
    }
}

结果是：

1 threads: time on clock() = 0.258, on wall = 0.258
2 threads: time on clock() = 0.256, on wall = 0.129
3 threads: time on clock() = 0.255, on wall = 0.086
4 threads: time on clock() = 0.257, on wall = 0.065
5 threads: time on clock() = 0.255, on wall = 0.051
6 threads: time on clock() = 0.257, on wall = 0.044
7 threads: time on clock() = 0.255, on wall = 0.037
8 threads: time on clock() = 0.256, on wall = 0.033

您可以看到 clock() 时间没有太大变化。在没有 pragma 的情况下，我得到 0.254，因此在一个线程中使用 openMP 比根本不使用 openMP 慢一点，但每个线程的挂起时间都会减少。

改进并不总是那么好，例如，由于部分计算不并行（请参阅 Amdahl's_law) 或不同线程争夺同一内存。

编辑：对于 Grand Central Dispatch，GCD 参考< /a> 指出，GCD 使用 gettimeofday 作为挂机时间。因此，我创建了一个新的 Cocoa 应用程序，并在 applicationDidFinishLaunching 中输入：

struct timeval t1,t2;
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
for (int iterations = 1; iterations <= 8; iterations++) {
    int stride = 1e8/iterations;
    gettimeofday(&t1,0);
    dispatch_apply(iterations, queue, ^(size_t i) { 
        for (int j = 0; j < stride; j++) cos(j); 
    });
    gettimeofday(&t2,0);
    NSLog(@"%d iterations: on wall = %.3f\n",iterations, \
                t2.tv_sec+t2.tv_usec/1e6-(t1.tv_sec+t1.tv_usec/1e6));
}

并在控制台上得到以下结果：

2010-03-10 17:33:43.022 GCDClock[39741:a0f] 1 iterations: on wall = 0.254
2010-03-10 17:33:43.151 GCDClock[39741:a0f] 2 iterations: on wall = 0.127
2010-03-10 17:33:43.236 GCDClock[39741:a0f] 3 iterations: on wall = 0.085
2010-03-10 17:33:43.301 GCDClock[39741:a0f] 4 iterations: on wall = 0.064
2010-03-10 17:33:43.352 GCDClock[39741:a0f] 5 iterations: on wall = 0.051
2010-03-10 17:33:43.395 GCDClock[39741:a0f] 6 iterations: on wall = 0.043
2010-03-10 17:33:43.433 GCDClock[39741:a0f] 7 iterations: on wall = 0.038
2010-03-10 17:33:43.468 GCDClock[39741:a0f] 8 iterations: on wall = 0.034

这与我上面得到的结果大致相同。

这是一个非常人为的例子。事实上，您需要确保将优化保持在 -O0，否则编译器将意识到我们没有保留任何计算并且根本不执行循环。另外，我在两个示例中采用的 cos 整数是不同的，但这不会对结果产生太大影响。请参阅 dispatch_apply 联机帮助页上的 STRIDE，了解如何正确执行此操作以及为什么 iterations 与 num_threads 大致相当。 > 在这种情况下。

编辑：我注意到雅各布的回答包括

我使用 omp_get_thread_num()
我的并行循环中的函数
打印出正在工作的核心
上...这样您就可以确定
它在两个核心上运行。

这是不正确的（已通过编辑部分修复）。使用 omp_get_thread_num() 确实是确保代码是多线程的好方法，但它不会显示“它正在哪个核心上工作”，而只是显示哪个线程。例如，以下代码：

#include <omp.h>
#include <stdio.h>

int main() {
    int i;
    #pragma omp parallel for private(i) num_threads(50)
    for (i = 0; i < 50; i++) printf("%d\n", omp_get_thread_num());
}

打印出它正在使用线程 0 到 49，但这并没有显示它正在处理哪个核心，因为我只有八个核心。通过查看活动监视器（OP 提到了 GCD，因此必须在 Mac 上 - 转到窗口/CPU 使用情况），您可以看到作业在核心之间切换，因此核心！=线程。

Answer 2

您的执行时间很可能不受您并行化的那些循环的限制。

我的建议是您分析一下您的代码，看看哪些内容占用了大部分时间。大多数工程师会告诉您，在采取任何重大优化措施之前，您应该先执行此操作。

Answer 3

没有任何细节很难猜测。也许您的应用程序甚至不受 CPU 限制。您在代码运行时观察过 CPU 负载吗？是否至少在一个核心上达到了 100%？

Answer 4

您的问题缺少一些非常关键的细节，例如您的应用程序的性质是什么，您试图改进其中的哪一部分，分析结果（如果有）等......

话虽如此，您在接近时应该记住几个关键点性能改进工作：

• 工作应始终集中在已通过分析证明效率低下的代码区域
• 并行化 CPU 绑定代码将几乎永远 不会提高性能（在单核机器）。您将在不必要的上下文切换上浪费宝贵的时间，并且什么也得不到。通过这样做，您可以很容易降低性能。
• 即使您在多核机器上并行化 CPU 密集型代码，您也必须记住，您永远无法保证并行执行。

确保您不会违背这些观点，因为有根据的猜测（除非有任何其他细节）会说这正是您正在做的事情。

Answer 5

如果您在循环内使用大量内存，则可能会妨碍其更快。您还可以查看 pthread 库来手动处理线程。

Answer 6

如果您不指定 num_threads，我会在并行循环中使用 omp_get_thread_num() 函数来打印它正在处理的核心。例如，

printf("Computing bla %d on core %d/%d ...\n",i+1,omp_get_thread_num()+1,omp_get_max_threads());

上面的内容适用于此编译指示
#pragma ompparallel for default(none)shared(a,b,c)

这样您就可以确保它在两个内核上运行，因为只会创建 2 个线程。

顺便问一下，编译时是否启用了 OpenMP？在 Visual Studio 中，您必须在属性页中启用它，C++ ->语言并将OpenMP支持设置为是