1

我尝试学习 Grand Central Dispatch (GCD) 并使用以下代码进行测试：

使用 GCD：

#include <dispatch/dispatch.h>
#include <vector>
#include <cstdlib>
#include <iostream>

int main(int argc, char *argv[])  
{
   const int N = atoi(argv[1]);
   __block std::vector<int> a(N, 0);
   dispatch_apply(N, 
     dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), 
     ^(size_t i) 
     { 
       a[i] = i;
#ifdef DEBUG           
       if ( i % atoi(argv[2]) == 0)
         std::cout << a[i] <<  std::endl;
#endif
     });
  return 0;
}

没有 GCD：

#include <vector>
#include <cstdlib>
#include <iostream> 

int main(int argc, char *argv[]) 
{
  const int N = atoi(argv[1]);
  std::vector<int> a(N, 0);
  for (int i = 0; i < N; i++)   
    {
      a[i] = i;
#ifdef DEBUG
      if ( i % atoi(argv[2]) == 0)
    std::cout << a[i] <<  std::endl;
#endif
    }
 return 0;
}

GCD的测试结果：

$ time ./testgcd 100000000 10000000
4.254 secs

没有 GCD 的测试：

$ time ./nogcd 100000000 10000000
1.462 secs

我认为 GCD 应该减少执行时间，但结果却相反。我不确定我是否滥用了 GCD。操作系统环境是 Mac OS X 10.8 和 Xcode 4.5。编译器是 Clang++ 3.1。硬件是带有 i5 CPU 的 Macbook Pro，它有两个内核。

为了比较，我使用 OpenMP（在同一台笔记本电脑上也使用 Xcode 4.5 附带的 GCC）：

#include <vector> 
#include <cstdlib>

int main(int argc, char *argv[])  
{
  const int N = atoi(argv[1]);
  std::vector <int> a(N, 0);
  #pragma omp parallel for
  for (int i = 0; i < N; i++)
    a[i] = i;
  return 0;
}

和 w/wo (-fopenmp)，我有两个可执行文件要测试，

编译时带有-fopenmp标志：

$ time ./testopenmp 100000000
1.280 secs

编译时没有-fopenmp标志：

$ time ./testnoopenmp 100000000
1.626 secs

使用 OpenMP，可以减少执行时间。

4

2 回答 2

7

GCD 不一定要增加执行时间。在您的情况下这样做的原因是您做错了。重要的是你首先要知道为什么你的应用程序很慢。所以我去多核分析器（Instruments.app）下运行你的代码，它显示的是：

多核分析截图

如您所见，该图大多是黄色的。黄色表示线程什么都不做，等待某个任务执行。绿色表示它执行任务。换句话说，按照您编写代码的方式，应用程序将 99% 的时间用于传递任务，并且每个任务执行几乎不需要时间——开销太大。那么为什么会这样呢？

因为您已经安排了大约 100000000 个任务来运行。运行每个任务都有一些开销，这远远大于将整数分配给数组。经验法则是如果任务的复杂性低于线程间通信的复杂性，则不安排任务。

那么你如何解决这个问题？安排更少的任务，在每个任务中做更多的事情。例如：

int main(int argc, char *argv[])
{
   const int N = atoi(argv[1]);
   __block std::vector<int> a(N, 0);
   dispatch_apply(4,
     dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0),
     ^(size_t iN)
     {
         size_t s = a.size()/4;
         size_t i = (s*iN);
         size_t n = i + s;
         //printf("Iteration #%lu [%lu, %lu]\n", iN, i, n);
         while (i < n) {
             a[i] = i++;
         }
     });
  return 0;
}

现在，分析器显示以下内容：

没那么糟

再次运行测试，GCD 会快一点：

$ time ./test_nogcd 100000000 10000000

real    0m0.516s
user    0m0.378s
sys 0m0.138s
$ time ./test_gcd 100000000 10000000

real    0m0.507s
user    0m0.556s
sys 0m0.138s

也许运行更少的任务会使它变得更好？试试看。通过这样一个简单的工作流程，您可能会更好地使用单线程 SIMD 实现。或者可能不是 ：）

请注意，在某些情况下您必须格外小心，例如，当总大小不能分成 N 等份时等。为简单起见，我省略了所有错误检查。

此外，在当今的商品硬件上并行任务时存在大量细微差别。我建议您熟悉 MESI、错误共享、内存屏障、CPU 缓存、缓存遗忘算法等。记住 - 始终使用分析器！

希望能帮助到你。祝你好运！

于 2013-01-13T22:03:34.533 回答
2

GCD 不会神奇地减少整体执行时间，而且它的使用肯定是有代价的：例如，考虑一下这样一个事实，例如dispatch_apply_*，以及它们所暗示的所有幕后管理必须花费一些时间。（现在，在我看来，2.5 秒对于这种管理来说太长了，但我现在无法评估你的结果的有效性）。最终结果是 GCD 可能会提高你的性能，如果你正确使用它（在正确的场景中）并且你的硬件允许它。

可能是 GCD 的特性让您相信 GCD 能够在单独的线程中以异步方式执行任务。这本身以及在这两种情况下都不一定会缩短整体执行时间，但它可以帮助提高应用程序的响应能力，例如，不允许 UI 冻结。

除此之外，如果一个 CPU 有更多的内核，或者你有一个多 CPU 系统，并且线程被调度在不同的内核/CPU 上，那么 GCD 可能会提高整体执行时间，因为两个（实际上，最多内核数）不同任务将并行执行。在这种情况下，两个任务的总持续时间将等于较长的任务持续时间（+ 管理成本）。

一旦澄清这一点，更详细地了解您的示例，您还可以注意到以下内容：

  1. 您在同一个辅助线程上调度 N 个任务：即使在多核系统上，这些任务也将按顺序执行；

  2. 唯一在做事情的线程，即运行 main 的线程，没有做任何冗长的事情，因此程序的整体持续时间由第 1 点的任务持续时间唯一确定；

  3. 最后，如果你考虑到任务的性质，你会发现它只是一个你执行 N 次的任务。现在，在 GCD 的情况下，对于每个这样的分配，你排队一个任务，然后在辅助线程上执行它；在非 GCD 的情况下，您只需迭代一个 for 循环来执行 N 个分配，这为您提供了最快的时间。在前一种情况下，对于每个任务，您还需要为任务的排队+调度付费。

可能这不是您可能想要衡量 GCD 收益的最重要的场景，而从性能方面衡量 GCD 的成本可能是一个很好的场景（在我看来，这似乎是最坏的情况）。

于 2013-01-13T21:23:42.933 回答