我和 RapidMind 的人们进行了精彩的交流。该公司为 C/C++ 程序员提供了一个非常巧妙的工具，以帮助他们利用多核 CPU 的并行处理能力。其理念是使并行处理至少在某种程度上对程序员透明。程序员可以使用 RapidMind 来改进现有应用程序的多核性能，只需对代码进行最少的修改，并构建新的多核应用程序，而无需处理诸如线程同步等复杂问题。

RapidMind 和任何其他类似解决方案都非常宝贵，并且在很长一段时间内都将如此。C/C++ 是一个根深蒂固的遗留编程平台。然而，我不禁想知道，硬件中日益增长的并行处理趋势是否会缓慢但稳定地转向固有的多线程、托管编程平台，如 Java。

向 CPU 添加核心的内在权衡为任何编程平台提出了一个有趣的问题。随着您添加核心，您会增加功耗，从而产生更多的热量。减少热量的一种方法是降低单个核心的处理速度，或者至少，阻止它们像历史可能沿其当前路径继续发展那样快速地提高速度。

因此，任何单个执行线程在快速的单核 CPU 上运行速度都比在多核 CPU 的较慢核心上运行速度快。看似显而易见的答案是将任务分解为多个线程。Java 本质上是多线程的，对吧？因此，在所有其他条件相同的情况下，Java 应用程序应该是多核 CPU 平台的天然选择，对吧？

不一定。如果 Java 是利用并行处理的绝对优势方法，我就会将这种向 Java 的转变视为一种预测，而不是一个问题。事情没那么简单。例如，不要让任何人告诉你 Java 从一开始就是为了利用多个处理器和核心而构建的。事实并非如此。Java 著名的垃圾回收最初阻碍了并行编程。即使是 1.4 版本的 Java 也使用单线程垃圾回收器，当它运行时，无论您有多少个 CPU，都会暂停您的 Java 程序。

但是 Java 的多线程设计比许多其他语言更容易利用并行处理，并且最终使其能够改进垃圾回收。JDK 5.0 包括各种调优参数，可以最大限度地减少垃圾回收对多个核心或 CPU 的影响。它并不完美，您必须考虑应用程序的设计方式，但这是一个巨大的进步，而这一进步之所以成为可能，是因为 Java 从一开始就构思得很好。

显然，这些功能还不够。IBM 在其 WebSphere 应用服务器中构建了许多额外的并行性。此外，IBM 和其他研究人员正在开发一种与 Java 相关的语言 X10，该语言专门为利用并行处理而设计（请参阅 x10.sourceforge.net/x10home.shtml）。

同样有趣的是，当英特尔吹嘘其在 Java 上的四核性能时，其数字是基于使用 BEA jRockit JVM，而不是 Sun JVM。有关图表和更多信息，请参阅 www.intel.com/performance/server/xeon/java.htm。我怀疑英特尔使用此 JVM 是因为 BEA JVM 采用了更高效的垃圾回收算法，以便在多个核心上使用。

英特尔使用非 Sun JVM 这一事实使得关于 Java 在多核 CPU 上的未来的整个问题变得有趣。我不会排除英特尔可能已经调整其代码以使其与 BEA JVM 最佳配合的可能性。但对于 Java 来说，一个重要的优势是您可以选择最适合您拥有的硬件的 JVM。最大的优势是您仍然只需要学习一种语言 Java，并且这不会限制您对架构或平台的选择。如果您在多核平台上运行您的应用程序，您可以在 JVM 和 JVM 特定的调优参数之间进行选择，以从您的应用程序中挤出额外的性能。

现在，再往未来想一点。想象一下并行性出现在未来一代的手机或其他小型设备中。有什么比平台无关的语言更适合利用这种未来呢？

不过，一些免责声明是必要的。首先，我不认为任何工具或语言很快就能使多核或 CPU 的最佳编程完全透明。然而，Java 有潜力以比许多其他语言对程序员影响更小的方式利用多核，这就是为什么我认为随着这种新的硬件趋势，Java 的未来变得更加光明。其次，尽管我认为 Java 具有优势，但其他托管的多线程语言无疑也会搭上这股浪潮。Python、Ruby 和您在这种类型中喜欢的其他语言可能也拥有同样光明的未来。