Question

第二个原则是，代码将在多个可用核心中自给自足。你的代码不能等待很长时间，否则将抵消并行处理的优势。不过幸运的是，在我们的例子中，一直遵循着这个规则。

你可能已经看到，我们有几个地方用 Parallel.For 替换了经典的循环以此来并行处理。

第一个例子是 DrawTriangle 方法中。我们将用并行处理用几条线画三角形。在此，你可以很容易的将 2 个正常循环替换为 Parallel.For 循环：

if (dP1P2 > dP1P3)
{
  Parallel.For((int)p1.Y, (int)p3.Y + 1, y =>
    {
      if (y < p2.Y)
      {
        ProcessScanLine(y, p1, p3, p1, p2, color);
      }
      else
      {
        ProcessScanLine(y, p1, p3, p2, p3, color);
      }
    });
}
else
{
  Parallel.For((int)p1.Y, (int)p3.Y + 1, y =>
    {
      if (y < p2.Y)
      {
        ProcessScanLine(y, p1, p2, p1, p3, color);
      }
      else
      {
        ProcessScanLine(y, p2, p3, p1, p3, color);
      }
    });
}

但是，在我的情况下，输出的结果有一点点出乎意料。我的性能被降低了，竟然从 45 FPS 跌到了 40 FPS！那么，是什么原因导致了这个问题呢？

那么，出现这样的情况，显然不是使用并行处理就够了。我们需要花更多的时间用于上下文切换，也就是从一个核心移动到另一个核心而不是真正并行处理。你可以使用 Visual Studio 2012 的嵌入式分析工具： Visual Studio 2012 并行可视化 来查看。

下面是第一种并行方式的核心利用图：

各种颜色都与工作线程有关，这真的没有效率可言。下面再看看 非并行版本 的核心利用图：

我们只有一个线程在工作（绿色的），所显示的是由操作系统派出的一些核心。即使我们不明确使用并行，CPU 也会自动使用多核心处理。显然我们的第一种并行方案上下文切换太频繁了。