使用 OpenMP 进行并行加速

Posted 2023-02-16

技术标签:

【中文标题】使用 OpenMP 进行并行加速【英文标题】：Parallel speedup with OpenMP 【发布时间】：2011-10-28 05:30:08 【问题描述】：

我有两种测量指标的场景，例如计算时间和并行加速（sequential_time/parallel_time）。

场景 1：

顺序时间测量：

startTime=omp_get_wtime();  
for loop computation  
endTime=omp_get_wtime();  
seq_time = endTime-startTime;

并行时间测量：

startTime = omp_get_wtime();  
for loop computation (#pragma omp parallel for reduction (+:pi) private (i)  
for (blah blah)    
    computation;   
  
endTime=omp_get_wtime();  
paralleltime = endTime-startTime; 

speedup = seq_time/paralleltime;

场景 2：

顺序时间测量：

for loop  
startTime=omp_get_wtime();  
   computation;  
endTime=omp_get_wtime();  
seq_time += endTime-startTime;

并行时间测量：

for loop computation (#pragma omp parallel for reduction (+:pi, paralleltime) private (i,startTime,endTime)  
for (blah blah)   
    startTime=omp_get_wtime();  
    computation;  
    endTime=omp_get_wtime();  
    paralleltime = endTime-startTime;  
  

speedup = seq_time/paralleltime;

我知道场景 2 不是最好的生产代码，但我认为它通过忽略 openmp 生成和管理（线程上下文切换）多个线程所涉及的开销来衡量实际的理论性能。所以它会给我们一个线性加速。但是场景 1 考虑了产生和管理线程所涉及的开销。

我的疑问是：在场景 1 中，我得到了一个从线性开始的加速，但随着我们转向更多的迭代次数而逐渐减少。在场景 2 中，无论迭代次数如何，我都能获得完全的线性加速。有人告诉我，实际上，场景 1 将给我一个线性加速，而不管迭代次数如何。但我认为这不会因为线程管理导致的高过载。有人可以向我解释为什么我错了吗？

谢谢！对于这篇相当长的帖子感到抱歉。

【问题讨论】：

方案 2 中的并行时间测量不正确，因为在每次迭代中，您都会在同一线程上重新编写上一次迭代获得的结果。如果你把它改成paralleltime += endTime-startTime;（注意+=），你将总结所有迭代的时间，这将与seq_time基本相同。这就是为什么我在 pi 和 paralleltime 上执行 reduce 操作 #pragma omp parallel for reduction (+:pi, paralleltime) private (i,startTime,endTime) 减少paralleltime 不会使您的程序正确。您可以查看 OpenMP 规范，特别是第 2.9.3.6 节以了解详细信息。简而言之，归约变量的每个私有副本都会累积由同一线程执行的几次循环迭代的结果。为了说明，让我们假设第 1 次和第 2 次循环迭代由同一个线程执行；然后第 2 次迭代将其时间写入第 1 次迭代的时间，而第 1 次迭代将丢失。谢谢阿列克谢！我不知道减少是以这种方式起作用的.. 【参考方案1】：

在很多情况下，场景 2 也不会给您带来线性加速——线程之间的错误共享（或者，就此而言，共享变量的真实共享会被修改）、内存带宽争用等。加速通常是真实的，而不是测量工件。

更一般地说，一旦您将计时器放入 for 循环中，您就会考虑比使用此类计时器真正适合测量的更细粒度的计时信息。出于各种原因，您可能很希望能够将线程管理开销与正在完成的实际工作分离开来，但在这里您试图通过向omp_get_wtime() 插入 N 个额外的函数调用以及算术来做到这一点和归约操作，所有这些都将产生不可忽略的开销。

如果您真的想准确计时在computation; 行中花费了多少时间，您真的想使用采样之类的东西而不是手动检测（我们稍微讨论一下here 的区别）。使用gprof 或scalasca 或openspeedshop（所有免费软件）或英特尔的VTune 或其他东西（商业包）将为您提供关于在该行上花费了多少时间的信息 - 通常甚至是线程 -低得多的开销。

【讨论】：

【参考方案2】：

首先，根据加速比的定义，你应该使用场景1，其中包括并行开销。

在场景 2 中，您在paralleltime 的测量中输入了错误的代码。为了满足您在场景2中的目标，您需要通过分配int paralleltime[NUM_THREADS]并通过omp_get_thread_num()访问它们来拥有每个线程paralleltime（注意此代码将具有错误共享，因此您最好分配64 -byte 结构与填充）。然后，测量每个线程的计算时间，最后取最长的一个来计算不同类型的加速（我会说一种并行性）。

不，即使场景 2，您也可能会看到亚线性加速，甚至可以获得超线性加速。潜在的原因（即不包括并行开销）是：

compuation

computation

在场景一中，会包含并行库的开销：

逻辑

我不认为您的代码（1 级静态调度并行循环）由于线程管理而具有很高的并行开销，除非此代码每秒调用数百万次。所以，可能是我在上面提到的其他原因。

请记住，决定加速的因素有很多；从固有的并行性（=负载不平衡和同步）到并行库的开销（例如调度开销）。

【讨论】：

你好敏江。注册。并行时间计算，我也在场景 2 中减少并行时间。所以我得到的并行时间是正确的，对吧？顺便说一句，我喜欢你的回答。给出了很好的详细解释。但不知何故，我觉得我必须选择另一个。 :)【参考方案3】：

您要准确测量什么？由于并行性导致的开销是实际执行时间的一部分，因此恕我直言，场景 1 更好。

此外，根据您的 OpenMP 指令，您正在对某些数组进行缩减。在方案 1 中，您正在考虑这一点。在场景 2 中，您不是。所以基本上，你测量的东西比场景 1 中的要少。这可能也会对你的测量产生一些影响。

否则，Jonathan Dursi 的答案非常好。