不能实施并行处理的情况

提交新文章

2009年03月24日 11:00


 

作为一名软件开发人员，您在决定是否以及如何针对并行架构修改您的应用时会面临众多选择。应采用哪种方法？对应用的修改程度如何？何时应“拒绝”实施并行处理？要回答这些问题，不仅需要深厚的技术专业知识，还需要从战略角度评估业务优势和成本。在权衡选择时，请考虑以下建议，这些建议源于我们在英特尔与软件开发人员合作优化代码时总结出的经验。

不要对非优化的串行代码进行并行处理
毋庸置疑，并行化是为当前和未来的各代硬件升级应用性能的一个重要方法。此外，优化应用的第一步不应是线程化，而应是确定您能否借助串行和矢量优化来实现性能目标。在某些情况下，通过优化串行代码所能实现的性能提升要比创建并行代码高。

如果串行代码的运行速度足够快，则不要进行并行处理
尽管您能够并且应当使您的代码支持未来架构，然而现在竭力满足尚未成形的需求也许时机尚未成熟，从而不会为您带来可观的成本效益。使用当前架构无法支持的高水平并行处理能力开发代码，这是少有的充分利用资源的方法。当然，如果您的代码受 I/O 或内存限制，那么对代码进行并行处理便无济于事了。

不要花费时间试图即刻对您以前的所有工作进行并行处理。仅当构建新代码或重建部分现有代码时再考虑使用并行处理。与其按顺序解决问题，不如考虑如何将这些问题分解为可以同时执行的单独片断。

在考虑需要长期执行的并行处理工作量时，请先确定应用工作负载的扩充速度，以及该扩充速度将如何影响计算需求。计算量可能会随数据集的增大呈线性增长，或者以较快或较慢的速度呈几何倍数增长。（如果工作负载随数据增长呈线性扩充，请注意代码会在某一点遇到 I/O 瓶颈。）

例如，由于一个音频处理应用已经能够以适当的取样率处理足够数量的信道，这个应用就不太适合并行处理。而另一方面，物理建模应用可能是理想的备选应用，因为借助更强大的计算能力，建模应用可以实现更精细的建模和更精确的算法。

总之，应确保并行处理应用所得收益超出延迟发运下一代产品所造成的损失。

不要通过从头重写代码进行并行处理
不要因噎废食。不要放弃整个正在使用的代码库，因为这是拙劣、绕弯而老套的做法。Netscape 的经历就是一个警示。软件开发人员 Joel Spolsky 在其博客中谈道，1997 年至 2000 年间，Netscape 重新编写了其浏览器的整个代码库，但未推出任何新的浏览器版本，于是微软趁机接收了浏览器市场，而 Netscape 再也未能翻身。

正如 Spolsky 所述，大多数程序员都致力于编写更完善的代码。通过开发流程，大量代码被添加和修改，因此最后得到的代码可能不太好看。然而如果重写代码，您就失去了上述代码块所代表的知识。而且在任何情况下，人们的眼中总会看到不好的一面。就像计算机代码，人们读起来可能很费力，但它却能够正常工作。

总会有一些需要重新开始的情况。然而，通过分解类或子例程来引入并行处理可能远比从头开始更加有效。

如果已有人为您完成了工作，则不要进行无谓的并行处理
在处理您的代码或尝试亲自对其进行并行处理之前，请查看商业或开放源代码解决方案能否提供您所需的内容。例如，如果您正在使用科学或技术应用，那么您也许会发现常用数学库中的标准例程可以帮您节省宝贵的时间。

请考虑使用英特尔® 软件工具（http://www3.intel.com/cd/software/products/asmo-na/eng/index.htm）。例如，借助英特尔® 线程构建模块，一种基于 C++ 模板的并行结构与算法运行时库来显著简化您的工作。借助这些结构，您的代码能够随执行内核数量的增加而自动扩充。此外，这些结构的设计还能够与其它线程技术（包括其它并行库）相兼容，如英特尔® IPP 高效多媒体函数库和英特尔® 数学核心函数库。借助编译器或 OpenMP*，提供更多方法来轻松增添并行能力。

不要冲动行事
多核架构的出现掀起了计算机技术领域的一场革命，但是利用多核技术的优势这一工作需要循序渐进地执行。多线程和其它并行化软件方法是复杂的任务，可能需要大量资源。应将并行化作为一种投资——在需要时进行部署，但首先要考虑成本和收益。