在上月举行的 PDC 09 大会上，微软并行库团队的开发工程师 Igor Ostrovsky 介绍了 PLINQ 的工作原理，以及多核编程中，尤其是在 PLINQ 使用过程中几种常见性能问题及应对方法。Igor 表示，这些性能问题很少在顺序编程中遇到，因此在并行环境中容易被人忽视。
第一个性能问题是内存分配。由于利用了多核 CPU 进行运算，对象分配的速度也加快了。此外，程序中可以还会出现更高频率的字符串连接或装箱操作，这都会使 GC 压力增大。.NET 应用程序所使用的默认 GC 方式为 Concurrent GC，它的性能很高，并且为降低应用程序的延迟作了很多优化。它的最佳使用场景是用户交互式应用，这样可以尽可能避免用户界面的停顿，但是它在长期运行的多核程序中表现并不好。而最终的结果是大量计算时间耗费在 GC 上，此时应用程序算法即便是利用了多个核，也会发现它的伸缩能力受到了 GC 限制。解决这个问题的方法之一是减小内存分配，例如可以使用值类型来代替引用类型。值类型的对象会分配在线程栈而不是堆上，以此避免对 GC 产生压力。第二个方法是在 config 文件中启用 Server GC。使用 Server GC 会改变.NET 分配对象的方式，此时.NET 会为每个核准备不同的堆，并且独立进行垃圾回收。这样在一台 4 核的机器上便可以有 4 个线程同时进行垃圾回收，性能自然也就随着多核而提升了。
第二个性能问题是 CPU 在局部化（Locality）和缓存方面的问题。在流行的多核架构中，每个核都有独立的二级缓存。CPU 并不会缓存单个地址中的数据，而是缓存以 64 字节或 128 字节相邻内存的缓存条目（cache line），因此当某个核改变了内存中的数据时，则其他核中地址相邻的缓存数据也会失效，这样 CPU 每次进行计算时都要从速度较慢的内存中加载数据。这个性能问题的隐蔽之处在于代码中的不同数据——例如同一个数组的不同下标——可能在内存中处在同一个缓存条目中，因此这个问题又被称为错误共享（False Sharing）。Igor 演示了一段性能低下的代码，在这个实现中多个线程会不断读写同一个数组的相邻下标，因此造成了错误共享。Igor 的修改方法是将数据存放在数组中相距较远的下标，甚至是不同的数组中。由于 CPU 的缓存条目大小有限，这种方法可以避免出现错误共享。博客园老赵在《计算机体系结构与程序性能》一文中也提出了一种优化方式，他的做法是尽可能使用局部变量来保存计算过程中的中间值，以此减少对数组的修改操作。由于局部变量分处不同线程的栈空间内，因此地址相距很远，不会造成错误共享问题。当有人问起到这种优化方式是否安全时，Igor 答到，这其实和 CPU 架构的实现方式有很大关系。如果某一天缓存实现变化了，可能这种优化方式会适得其反。不过在目前主流架构中，这样的做法是比较安全的。Igor 补充道，他认为这也是为什么“全自动”并行化那么困难的原因之一，因为在并行环境下影响程序性能的方面实在太多了。
第三个问题在于开发人员倾向于在 PLINQ 中使用大量小粒度的委托来完成工作，此时每个委托的计算任务很小，而委托的执行次数会很多。在计算较长的序列时，小粒度的委托对象也能获得性能提高，但是它会产生额外的负载。例如，MoveNext 和 Current 的调用，以及每个委托的执行性能都和虚方法比较接近。此外，一个较长的输入序列也会受限于内存的吞吐量。因此，Igor 建议开发人员在使用 PLINQ 时尽可能使用计算量较大的委托，以此减少计算主体外的性能开销。
第四和第五问题则与 PLINQ 的实现有关。Igor 表示，PLINQ 可以并行执行所有的 LINQ 查询，但是相对于复杂的 LINQ 查询，PLINQ 能够对简单的 LINQ 操作有更好的优化。因此，Igor 建议开发人员在使用 PLINQ 时可以手动将复杂的 LINQ 表达式拆分为简单的 LINQ 查询，并且只在真正需要大量计算的地方才开始并行化。这种结合顺序执行和并行执行的方式，可以让应用程序的性能达到最优。此外，为不同的输入方式选择不同的分块（partition）策略对性能的影响很大，因此 PLINQ 会对数组和 IList<> 进行静态的分割，而对 IEnumerable<> 集合按实际需求进行划分，而开发人员也可以通过自定义 Partitioner 的方式来指定特别的分割策略。
最后，Igor 强调，使用并行计算进行程序性能优化之前，一定要通过合适的评测方式来找到代码的瓶颈。如果这个瓶颈正符合数据并行（data parallel）模式，那么可以使用 PLINQ 进行性能优化。而优化完成后还需要评测其效果，并使用之前提出的几种方案进行合适的调整。
你可以在PDC 2009 的网站上浏览或下载本次演讲的完整录像及幻灯片等资源。
注册/登录 InfoQ 发表评论