线程化的性能障碍：它们将给 OpenMP 代码带来什么影响？

1. 能更快的执行同一工作：
   如果应用程序负载固定（如，对静态照片应用某种效果），我们可以通过线程化更快地完成工作。评测此代码时，我们将记录执行时间和通过线程化实现的加速比。
2. 执行更多的工作：
   如果将应用程序扩展到执行更多个负载相同的工作（例如，更新较大的像素缓冲区），或将不同的工作添加到负载中（例如，对游戏管道添加粒子效果），则我们应 该进行线程化以通过应用程序完成更多的工作。通常我们将其作为吞吐量进行评测。要评测此代码，就要评测吞吐量，吞吐量是针对全部执行时间评测的工作量。
3. 抵销慢操作所花费的时间：
   如果应用程序需要进行长时间的操作（如加载文件），则通过线程化可事先执行这些操作，以便在需要结果时能够立刻提供。有多种方法可用于评测此代码，但主要 评测是用以定性的评测；用户能否从这些操作中察觉到延迟？能否轻松地进行评测，取决于负载情况。很多应用程序（尤其是游戏）已开始使用线程化（以及一些其 他技术，如异步磁盘 I/O）来抵消慢操作所花费的时间。

Amdahl 法则 Amdahl 法则描述了任意给定代码所能实现的加速比的理论可能性。 对于代码 F 的串行成分，理论上预期可以在 N 个处理器上实现加速比： 如果线程化 20% 的代码（80% 保持串行），则在 4 个处理器上可以实现最大加速比： 我们还可以使用 Amdahl 法则预测加速比的上限（将 N 设置为 ∞）。我们更多将该法则用于预测在拥有两个或四个处理器内核的典型情况下的加速比，在这些情况下我们希望线程化能带来较大的优势。

评测串行代码非常简单，因此我们主要介绍并行代码。

图 1：并行循环示例

在图 1 的代码中，评测所示块花费的（包括 OpenMP #pragma）的并行时间。同时记录线程计数，这样可以看出代码从单核计算机到双核计算机甚至多核计算机的加速情况。记录线程计数的简单方法是使用omp_get_max_threads() 调用。也请参阅下文对加速比的讨论。

很少有不经过一些大转换而向应用程序添加重要线程的情况。有时候，整个算法都会更改。循环通常包含数据依赖关系。要处理好依赖关系从而可以线程化，可能需要为每个线程缓冲额外的数据副本，然后添加同步代码以解决所有差异。

此类大幅度更改可能会使代码运行速度加快或减慢，具体取决于如何执行更改。使用此方法时请务必小心。

转换代码时可以尝试进行其他更改，例如重构代码。通常情况下，这是一个好方法，但是它将使评测性能更改的难度加大。一般的做法是尽量将这些活动彼此分开。在一次运行过程中进行重构，然后在另一次运行过程中进行线程化（反之亦然）。

评测此类转换的难度比较大。很难评测各个代码块，因为您在不断地对其进行更改。评测经转换的代码的最佳方法是具有一个可以在更改前、更改过程中和更改后都可以评测的应用程序级标准。

线程化将给代码带来何种开销？

在真正了解代码的性能之前，您要考虑其他几个因素。

首先，考虑开销。在进行线程化过程中，总是会增加一些开销；我们增加的是固定的启动开销和每线程开销。在某些情况下（通常是在小循环和低迭代计数中），这些开销数额太高，以至于使线程化代码变得没有意义。在这些情况下，我们最好将代码保留为其原始串行形式。

下面列出了线程化代码的一些开销因素。多数情况下，在 OpenMP 代码中我们可以忽略这些因素，但是在此表的后面，我们将探讨不能忽略这些因素的情况。

图 2：OpenMP 中的开销因素

这些是线程化代码中的开销因素。多数情况下，在 OpenMP 代码中我们可以忽略这些因素，我们将进一步探讨不能忽略这些因素的情况。

让我们看看这些不同的开销都是在何处发生的。

图 3：线程开销位置

评测图 3 中显示的这些开销。评测每线程和库启动开销很容易，但是评测线程启动开销则需要进行几种不同的测试。首先，评测恰好运行一次 OpenMP parallel for 指令所需的时间。然后，评测运行该指令两次所需的时间。由于 OpenMP 使用线程池，因此第一个循环应包含所有线程启动开销。最终，第二次迭代所花费的时间应远远少于第一次迭代所花费时间的 2 倍。第二次迭代所增加的时间是运行一次循环迭代的"本地"时间；将第一次循环迭代所花费的时间减去此时间，即可计算出线程启动开销。

早期的研究²发 现线程启动开销平均为 170-190 毫秒（在双核计算机上创建两个线程时）。值得高兴的是多数 OpenMP 实现（包括最新的英特尔和 Microsoft 编译器的 OpenMP 实现）都使用了线程池。您的代码只需支出线程开销一次，即在第一次使用线程时。这样，对于多数线程和调用模式来说，线程启动开销非常低。

这 是 OpenMP 与典型的 Windows 线程化相比所具有的独特优势之一；只要有可能，OpenMP 运行时即会自动使用线程池。由于典型的 Windows 线程化不使用线程池，因此每个线程都有线程启动开销。可能很多应用程序都禁止这种行为。如果选择 Windows 线程化而非 OpenMP，可以将 Windows 线程与线程池结合使用以避免此开销，但是操作更为复杂。

OpenMP 库可以检测代码在任意给定计算机上的最佳线程数。这是 OpenMP 与典型的 Windows 线程化相比的另一个优势。

有 很多迹象表明在管理锁定方面与 Windows 本地线程相比，在英特尔 C++ 编译器中实现的 OpenMP 更有效。这是一个好消息，但可能不会对您的代码产生大的影响。但是最好确保锁定代码不在代码的热点列表中（使用类似 VTune 性能分析器的工具），这很容易实现。这是因为经常在出现资源争用的位置使用锁定，因此等候资源时，代码一定会阻塞。在这些情况下，阻塞是一个更为重要的考 虑因素，因此基本上无需评测锁定管理开销。

在典型的循环代码中（迭代计数大小适中、计算集长度适中），这些开销都没有什么影响。继续阅读有关阻塞问题（通常是更为重要的考虑因素）的讨论。

何为阻塞？
阻塞问题通常是阻碍线程化应用程序实现最佳性能的最大因素。解决阻塞问题需从设计和实现两个方面入手。在进行设计时，我们应使实际阻塞量降至最低。我们还应测试和调整实现，以确保代码仅在预期的时间和地点阻塞。

理想情况下，代码阻塞应不花费任何时间，但实际上很难做到这一点。

可以粗略估计阻塞会多大程度地减慢代码速度：注意关键部分相对于其余代码的比率。关键部分较大或关键部分相对于其余代码的比率较高，都表明可能会有麻烦。

要查看和评测代码阻塞的位置、程度和原因，使用可以隔离阻塞的工具至关重要，例如英特尔线程性能分析器。

有时候，在很少争用的资源周围也会有锁定（例如，参考计数）。如果发现锁定花费的时间较多，且代码并没有阻塞，则请考虑进行优化，例如双重检测锁定优化⁶。此技术使您在多数时间可以使用锁无关算法，且不用支出大量的锁定管理开销。

代码如何加速？

 
  

   
#pragma omp parallel for 
   
for(int i = 0; i < middleLoopCount; i++) { 
   
 Work(innerLoopCount); 
   
} 
  

 
  

   
#pragma omp parallel sections 
   
{ 
   
 #pragma omp section 
   
 for (int i = 0; i < chunkSize; i++) { 
   
 Work(innerLoopCount); 
   
 } 
   
 #pragma omp section 
   
 for (int i = chunkSize; i < middleLoopCount; i++) { 
   
 Work(innerLoopCount); 
   
 } 
   
} 
  

 
  

   
#pragma omp parallel for schedule (static, chunkSize) 
   
for(int i = 0; i < middleLoopCount; i++) { 
   
 Work(innerLoopCount); 
   
} 
  

 
  

   
#pragma omp parallel for schedule (dynamic, chunkSize) 
   
for(int i = 0; i < middleLoopCount; i++) { 
   
 Work(innerLoopCount); 
   
} 
  

 
  

   
#pragma omp parallel for schedule (guided, chunkSize) 
   
for(int i = 0; i < middleLoopCount; i++) { 
   
 Work(innerLoopCount); 
   
} 
  

• InterlockedIncrement()
• InterlockedDecrement()
• InterlockedExchange()
• InterlockedExchangeAdd()
• InterlockedCompareExchange()