Question

我尝试学习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。 OS环境是带有Xcode 4.5的Mac OS X 10.8。编译器是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，可以缩短执行时间。

Answer 1

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

Multi-Core Profiling Screenshot

如您所见，图表大部分为黄色。黄色表示线程无效，等待某个任务执行。绿色表示它执行任务。换句话说，你编写代码的方式，应用程序花费99％的时间来完成任务，每个任务执行几乎没有时间 - 太多的开销。那么为什么会这样呢？

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

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

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;
}

现在，探查器显示以下内容：

Not that bad

再次运行测试，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缓存，缓存遗忘算法等等。记住 - 总是使用分析器！

希望它有所帮助。祝你好运！

Answer 2

GCD不会神奇地减少总体执行时间，并且它的使用肯定会产生成本：例如，考虑像dispatch_apply_*这样的陈述以及它们所暗示的所有幕后管理这一事实，必须花费一些时间。（现在，在我看来，2.5秒这样的管理时间太长了，但我现在无法评估结果的有效性）。 最终结果是，如果您正确使用GCD（在正确的方案中）并且您的硬件允许，GCD可能会提高您的性能。

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

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

一旦澄清了这一点，进入有关您的示例的更多细节，您还可以注意到以下内容：

您正在同一个辅助线程上安排N个任务：即使在多核系统上，这些任务也会按顺序执行;
唯一正在运行的其他线程，运行main的线程，没有做任何冗长的事情，因此程序的总持续时间由第1点任务的持续时间唯一决定;
最后，如果你考虑到任务的性质，你会发现它只是你执行N次的任务。现在，在GCD的情况下，对于每个这样的赋值，您将对任务进行排队，然后在辅助线程上执行它;在非GCD的情况下，你只是迭代一个for循环来执行N个赋值，这给你最快的时间。在前一种情况下，对于每项任务，您还要为排队+任务安排付费。

这可能不是您可能想要衡量GCD优势的最重要方案，而在性能方面衡量GCD成本可能是一个很好的方案（看起来像是最糟糕的情况）我）。

为什么GCD会增加执行时间？

2 个答案: