有关并行化——你知道的可能是错的

2005 年，英特尔发布奔腾 D 处理器，由此开始多核台式机 CPU 的时代。而今天，即使我们的手机处理器也是多核处理器，完全利用这些核并不是那么容易做到的事情，现代的编程语言和库已经走过了漫长的道路，来帮助程序员利用多核来改善程序效率。为了让我们更简单方便地使用多核处理器，很多实用函数和并发抽象已经开发出来。然而有时，这些抽象的库有不小的开销，甚至，没有达成将并行放在首位目标。

不要尝试并行化已经并行的代码

假设你正在为一个高流量的网站运行一系列任务，你将会很快遭遇性能的瓶颈。你考虑并行化去解决，并且已经在你有 4 个内核的开发计算机上做了测试，结果是要比之前快很多。你预计在 24 核的生产服务器上会跑得更快。然而，一旦你部署到生产服务器上，你发现在生产环境中，性能比之前还略差！你忘了的是， Web 服务器已经处于较高的水平并行化的软件，它已经使用全部 24 个核同时处理多个请求。当你的并行化代码跑起来，其他所有的核心都忙于其他请求。因此，你可能承受了并行化的开销缺没有获取相应的收益。

另一方面，如果你的网站是一个低流量的内部网站，只有几十每天访问，这种情况并行可能会得到相应的收益，因为总是会有备用核心可以使程序运行的更快。你必须考虑你的 Web 服务器的整体 CPU 利用率以及你并行代码将如何与其他正在进行的任务交互。它会对 L1 缓存造成影响并且使其他任务慢下来吗？记住，需要进行测试并收集测试数据。

一种情况，假设你正在制作 3D 游戏，你有一些物理数学技巧，可以使用并行来加速出力，比如将现实建筑加入到 Minecraft 游戏中。但另外一些线程已经在忙着处理过程中产生的新块，渲染，网络数据和玩家输入。如果这些都得大多数系统的 CPU 核非常繁忙，那么你的并行代码不会对整体运行效率有所帮助。另一方面，如果其他线程都没有都在工作，多余的 CPU 确实可以加速你的程序。

所以，想想你的代码运行环境，如果程序已经在更高层次上得到并行化了，在较低的水平上再并行一次可能没有任何好处。相反，这时候重点应该放在在单核尽可能高效地运行的算法上。

考虑运行的硬件环境

许多开发人员都使用最少 8 核的机器。但考虑你的代码可能会运行的环境。它会在云中低开销的虚拟化 Web 应用程序运行环境中运行吗？这只能有 1 个或 2 个虚拟核为你工作。它会在旧的台式机或廉价的手机上运行吗？这也可能只有 2 个核可以使用。在你的 8 核上跑的很好的算法，在只有 2 核的机器上并不会得到同样的效果。我们来看几个简单并行化循环的案例。

简单并行化循环的案例

对一个特定的编程语言来说，在可行的时候，使用编译器提示或库函数来做简单的并行循环很常见。然而发生什么，却会根据每一种语言和库使用有很大的不同。

在某些情况下，在循坏块里可以创建多个线程执行任务，或线程池可用于减少创建线程的开销。对提供给您的并发抽象是如何工作，有一个粗略的了解是很重要，这样可以使你对何时使用、调整及衡量他们做到心中有数。至少应该考虑以下问题。

如果创建或管理线程的开销比你得到的好处更大，那你就可以结束对比，因为并发程序比单线程还要慢。我将比较如下语言的工作负载，在 C#， F#， C++ 和 Java 的一些常见的并行循环抽象。

C#

public double ImperativeSquareSum

{

var localArray = rawArray;

double result = 0.0;

for (int i = 0; i < localArray.Length; i++)

{

result += //Do Work

}

return result;

}

public double LinqParallelSquareSum

{

var localArray = rawArray;

return localArray.AsParallel.Sum(/* Do Work */);

}

public double ParallelForSquareSum

{

var localArray = rawArray;

object lockObject = new object;

double result = 0.0;

Parallel.For(0, localArray.Length, => 0.0,

(i, loopState, partialResult) => { /*Do Work*/ },

(localPartialSum) => { lock (lockObject) { result += localPartialSum }});

return result;

}

1 million doubles - (result += x*x)

在 C# 中使用并行，最简单的方法是使用 PLINQ。输入您的集合名称，然后 .AsParallel和就可以开始 LINQ 查询。不幸的是在上述情况下是没有收益。Parallel.For 也同样如此。对并行代码来说，乘方然后加和的工作负载是不足以获得足够的好处。您需要使用线程池或者线程，这样可以更直接的加速代码执行。

1 million doubles - (result += Math.sin(x))

对更大的工作负载并行化，可以得到一个非常大的改善。它需要 2 个数量级以上的 CPU 周期来执 sin 操作。正因为如此，每个元素开销占总运行时间的比例要小得多，我们期望得到 4 倍加速，因为有 4 个核。相比之下，更复杂的 Parallel.For 比 LINQ 降低了更多开销。考虑工作量有多大，可以帮助决定采用简单的 LINQ 的做法是否值得。

F#

F# 有许多易于使用的第三方库可以用于并行。所有这些库也都可以再 C# 里使用。代码如下：

(* Nessos Streams ParStream *)

array

|> ParStream.ofArray

|> ParStream.fold (fun acc x -> acc + x*x) (+) (fun -> 0.0)

(* FSharp.Collections.ParallelSeq *)

array

|> PSeq.reduce (fun acc x -> acc+x*x)

(* SIMDArray (uses AVX2 SIMD as well) *)

array

|> Array.SIMDParallel.fold (fun acc x -> acc + x*x)

(fun acc x -> acc + x*x)

(+) (+) 0.0

1 million doubles (result += x*x)

SIMD 在这里欺骗了大家，因为它也做 SIMD 操作，但是因为是我写的库，所以我还是把它引入进来。 - 所有这些出执行上述核心库函数。 -

1 million doubles (result += Math.Sin(x))

Sin 操作不能被 SIMD 化，因此 SIMDArray 出局。 Nessos streams 再一次证明了它比 ParallelSeq 更高效。

C++

现在，使用 C++ 做同样的实验。大多数 C++ 编译器可以自动并行化循环，你可以通过在你的代码编译器标志或内联提示控制。例如使用 Visual Studio 的 C ++ 编译器你可以把一个循环的顶部（（ 8） hint_parallel）的 #pragma 循环，如果情况允许，就会并行化。不幸的是我们的例子是（有意而为）有一点点过于复杂。因为我们要求和，这将创建一个数据的依赖。幸运的是，我们可以使用 OpenMP，它是在 Microsoft Visual C++ 的， GCC， clang，和其他流行的 C ++ 编译器上使用：

double result = 0;

#pragma omp parallel for reduction(+ : result)

for(int i = 0; i < COUNT; i++)

{

result += /*Do Work*/;

}

这相当于在 C ＃上面使用的循环的 Parallel.For， - 在那里你确定将汇总数据 -。实际上代码更少，更易于阅读，即使语法古怪。它执行的结果如何呢？

1 million doubles - (result += x*x) No SIMD

我们可以看到， OpenMP 在此情况下比 .NET 更高效，差不多快 3 倍。在其他编译可用较新的 OpenMP 实现也使用 SIMD 矢量化来得到更快的执行速度。然而在微软的 Visual C ++ 并不能使用，并且自动矢量化似乎没有在 OMP 循环内起作用。自动矢量可以在循环单线程上完成，但是在测试时我们已经关闭了自动矢量化的功能。在 C ++ 编译器使用旧的 SSE 指令，如同 .NET 和 Java，但后两者只使单通道。在你指定/ FP 的情况下， MSVC ++ 将使用所有通道。

1 million doubles - (result += sin(x)) No SIMD

这一次提速 3 倍多一点，整体速度还是比 .NET 为好。

Java

Java 流式 api 可以用在这里。只需告诉它你想要一个并行流：

//Regular stream

sum = Arrays.stream(array).reduce(0,(acc,x) -> /*Do Work*/);

//ParallelStream

sum = Arrays.stream(array).parallel.reduce(0,(acc,x) -> /*Do Work*/);

1 million doubles (result += x*x)

1 million doubles (result += Math.sin(x))

Java 在第一例时性能向 C++ 看起，但使用 Math.sin 时落后。这不是由于并行数据流导致的问题，那是因为 Java 的使用更准确的 sin 实现，而不是直接调用 x86 指令。因为在其他硬件平台不一定有 sin 指令的实现。我不喜欢不能碰硬件的程序语言。提供一个 Math.NativeSin 将是很好的解决方案。 Java 整体的流 API 库被证明是优秀的，在性能级别和并行种类上都可以向 C++ 看齐。

Rust

Rust 提供并不太容易使用的并行抽象，你必须撸一个自己的。 OpenMP 风格的特性可能正在开发中，第三方库有些是可用的。因此，让我们来看看一个不错的一个叫 Royan 的库，它增加了一个“ par_iter”函数提供了类似的功能。代码仍然非常简单：

// The regular iter

vector.iter.map(|&x| /* do work */).sum

// Parallel iter

vector.par_iter.map(|&x| /* do work */).sum

1 million doubles (result += x*x)

1 million doubles (result += Math.sin(x))

这是非常出色的结果，跟 C++ 同一个量级，并且只需要改一行代码。

总结

这里研究的循环抽象只是一种并行或并发编程抽象。还有大量的并发抽象， Actor 模型， Async / Await，任务，线程池等。一定要了解你使用的是什么，衡量它是否真的有用，或者是否应把重点放在快速单线程算法或寻找第三方工具以拥有更好的性能。

测试结果聚合

1 million doubles ( result += x*x) No SIMD ( Except SIMDArray)

1 million doubles ( result += sin(x)) No SIMD

基准测试细节

我运行所有的基准测试都选择每一种语言（ C ++ 有待商榷）可用于 Windows 的最新和最好的编译器。 - JIT 预热时间是占时适用 -。如果你找出代码或编译器/环境的选择是次优的情况下，请给原作者发电子邮件。

环境

Host Process Environment Information:

BenchmarkDotNet=v0.9.8.0

OS=Microsoft Windows NT 6.2.9200.0

Processor=Intel(R) Core(TM) i7-4712HQ CPU 2.30GHz, ProcessorCount=8

Frequency=2240907 ticks, Resolution=446.2479 ns, Timer=TSC

F# / C# 运行时

CLR=MS.NET 4.0.30319.42000, Arch=64-bit RELEASE [RyuJIT]

GC=Concurrent Workstation

JitModules=clrjit-v4.6.1590.0

Type=SIMDBenchmark Mode=Throughput Platform=X64

Jit=RyuJit GarbageCollection=Concurrent Workstation

C++

Visual Studio 2015 Update 3, Optimizations set for maximum speed, SIMD off

Java

Oracle Java 64bit version 8 update 102

Rust

rustc 1.13.0-nightly build with cargo rustc --release -- -C lto -C target-CPU=native

网友评论

本文原文发表后，引起了大量网友热议，部分讨论如下。如果对本文观点有疑问，也欢迎留言。

wyldfire：

不要尝试并行化已经并行的代码

在并行化之前，为什么不先做下 profile 了解下系统的瓶颈在哪里才开始并行化？当你 profiler 之后，你可以更清楚的了解，这是计算资源密集型（ CPU / bus / mem / Cache），还是在等待一些异步任务返回。后者的情况比你想象的要多得多。

vvanders：

一般来讲，游戏引擎已经迁移到基于 work-stealing 任务的架构。使用一个宏系统（所有物理对象，渲染工作，玩游戏都由这个线程来负责）对于从单线程游戏迁移来说是非常有利的，即使这种做法经常会导致空闲线程。

在 PS3 的时代，这种情况也很严重，你仅有 SPU 和 256K 内存。整体而言，这会引出能够任意扩展的好架构，毕竟各种平台的 CPU / 计算能力可能会差异非常大。

英文原文：

https://jackmott.github.io/programming/2016/08/30/think-before-you-parallelize.html