体验 VS2010 并行开发 - Visual Studio 2010_.NET_编程开发_程序员俱乐部

若干年前我在学校里进行图形图像处理方面的实验项目。当时我们面临的一大挑战，是项目的实时性要求。同学们聚集在一起讨论可行的解决办法，其中最简单直接的，则是向导师申请经费，购买更高端的硬件系统。的确，对于若干年前的程序员来说，即使程序的运行速度不够快，那也是暂时的，随着客户使用的计算机更新换代，性能方面的问题就自行解决了，这不啻为免费的午餐。

?

免费的午餐已经结束

????CPU的计算能力仍旧在不断提升中，与其说要感谢摩尔定律，不如说要感谢一代代CPU设计师们不懈的努力。那为什么说免费的午餐已经结束了呢？简单来说就是，由于散热和功耗等物理条件的限制，处理器主频的提升遭遇了瓶颈。业界已经不能提供指数级增长的更快的处理器，而只能选择提供指数级增长的更多的处理器。更加详尽的论述可以参考《程序员》2006年11月号的译文《免费午餐已经结束——软件历史性地向并发靠拢》（http://blog.csdn.net/hsutter/archive/2006/08/29/1136281.aspx），在此不再赘述。最近笔者在国内某家在线电脑商城查询主流笔记本电脑的CPU配置，配置单核CPU的笔记本只有6台在售，而双核笔记本的数量是245台。这进一步证明了多核已经成为毋庸置疑的主流。

????在这样的发展趋势下，如果把今天在单核下实现的应用程序拿到一台64核的机器上运行，你会看到任务管理器显示如下的画面——只有1/64的计算能力得到了利用：

图表 1 任务管理器显示64核机器上运行单线程应用程序，只有一个核在计算

????既然传统的应用程序再也无法顺其自然地在更高端的硬件设备上获得更高的性能回报，我们要问的是，程序员们面临的选择是什么？Herb Sutter在他的原文中非常明确地给出了答案：并行计算。如果在四年前说“并发将是软件开发史上的又一个重大变革”是一个预测，那么今天，并行计算已经成为软件开发的核心趋势之一（援引自Soma的博客中文版http://blog.joycode.com/soma/archive/2010/03/04/115899.joy）。

是到了亲自下厨的时候了。

?

自己烹饪并不容易

????我们都知道，应用程序的开发并不仅仅是写代码这么简单。从需求分析，程序的设计编写，到调试和性能优化，以及测试、发布和后期维护，这一系列的行为都有其复杂性。而并行计算在程序原有的复杂性上，更平添了一个维度。在这个过程中，程序员会遇到各种各样的问题：

1. 我的性能目标是什么？应用程序性能瓶颈在哪里？

2. 这个任务可以并发执行么？哪种形式的并行最适合我，任务并行，数据并行，还是管道（Pipeline）并行？

3. 如果可以利用并行，性能究竟能提升多少？

4. 该怎么测试？如何确保一定的覆盖率？

在实际编程过程中，更加细节的问题也会涌现：

5. 并发执行的线程之间如何同步？共享的内存应该如何保护？怎样避免死锁？

6. 为什么我并发执行的任务反倒使得性能下降了？或者为什么性能提升不如我预想的那么多？

7. 资源分配是否合理？任务可以在处理器之间平均地分配么？

8. 代码可读性和可维护性如何？我的程序扩展性怎么样？如果在更多核的机算计上运行会如何？

9. 为什么同样一段程序运行多次的结果不一样？如何重现执行程序中的错误？用什么方法调试我的应用程序？

????毋庸置疑，开发并行应用程序要比开发传统的串行应用程序难。那么一些准备好的食材，一套可供参考的菜谱，和一系列顺手的厨具，是不是能让自己烹饪的过程稍微容易一点呢？

?

食材，菜谱和厨具很重要

????2007年，微软宣布成立并行计算平台组，致力于简化并行应用程序的开发。随着Visual Studio 2010和.NET Framework 4的发布在即，我们看到这一努力的初步结果。