Intel于当地时间6月18日在德国汉堡正式发布了Larrabee GPU架构的转世，基于MIC（集成众核）的计算加速协处理器Xeon Phi。目前的产品开发代号为"Knights Corner"，集成使用22nm 3-D Trigate/FinFET工艺制造的超50个Pentium P54C复刻版核心。

与此同时一些媒体如VR-Zone的专栏作者Theo Valich和3DCenter等也对其展开了分析，不过他们似乎忘记了重要一点——Intel所宣称的MIC架构优越性如x86兼容等没这么简单，其中的一些部分竞争对手NVIDIA早在今年4月就已撰文指出过。下面就让我们从一些公开资料透露的内容中分析一下到底在Intel MIC架构中存在“免费的午餐”与否。

MIC架构的x86兼容性

既然是为超级计算机以及高端工作站所设计，那么Intel自然会对Xeon Phi中的P54C核心进行改进。在Intel公开的说法中，Xeon Phi同样属于Intel 64（即AMD最早提出的x86-64架构）产品，那么实际是否如此呢？

回答是否定的，根据包括以下几点：在Intel为开发者提供的指南[1]中明确表示，Knight Corner架构只支持Intel 64位架构指令集中的一部分子集，包括MMX、XMM、YMM寄存器操作在内的指令不被支持。换句话说，Knights Corner抛弃了17年来Intel力推的MMX、SSE和AVX指令集的绝大部分。取而代之的是，资讯网站BSN透露Intel在Xeon Phi中加入了新的512bit宽度ZMM寄存器指令集，使得Xeon Phi的矢量单元（vector unit）和其他所有Intel处理器产品都不相同，这意味着Xeon Phi系列产品和其他Intel CPU在二进制代码上实际是不兼容的。

Intel在面向开发者的博客[2]中也总结了这一点，内部高速总线、高度并行数据处理所需的特殊矢量单元等特性综合导致了上面的结果——为Xeon Phi所编写、编译的代码不能在其余CPU上运行，反之亦然：为SIMD大量优化的代码对Xeon Phi同样没有意义。此外Intel还重申Xeon Phi是一款协处理器，需要CPU的辅助才能发挥应有的作用，从模式上来说已经和NVIDIA的Tesla加速卡类似，偏离了原有的设想。

而Xeon Phi在对于开发者的导向上也打破了此前和AMD的默契，此前Intel的开发文档中均表态鼓励程序员使用SSE2/AVX指令集并称所有的Intel64架构产品均支持SSE2——现在这一“潜规则”也已烟消云散。并且Intel是否会将Xeon Phi中的特有指令集导入其余产品如服务器/台式机/笔记本CPU中也暂且不得而知。

不存在能自动并行化代码的“魔法”编译器

有人可能会提出：那么去除掉不兼容部分的二进制代码呢？NVIDIA CTO Steve Scott早在今年四月份就撰文[3]告诉我们，这些代码经过简单的再编译是有可能运行在MIC架构上的，但存在两大问题：如果使用MPI API（one rank/core），MIC加速卡的50多个CPU核心将会分享8GB的内存，这远远小于目前HPC应用中1-2GB/每CPU核心的数量，而且50多个CPU核心同时通讯将会导致网络传输堵塞，OpenMP API的情况也只是好一点；另外根据阿姆达尔定律，代码中不能并行化的部分将成为极大的瓶颈——别忘了Xeon Phi的每个核心单线程能力实际上和十来年前的初代奔腾P54C没什么两样，并且目前多数x86 CPU上运行的代码并行度和线程数量都不高，简单编译自然无法发挥Xeon Phi的能力。

Scott表示，不管是现在还是未来，不会存在一个“魔法”编译器，使得原有的代码可以很好地自动并行化。在超级计算机领域甚至每个应用的代码更换系统后都需要重新编译一遍，目前还看不到哪个公司（包括Intel、NVIDIA或者其他任何人）能帮助程序员从这一工作中解脱出来。

此外，Scott引述的美国国家计算中心（NICS）的MIC架构性能演示[4]也侧面说明Xeon Phi仍未解决Larrabee架构的一些问题——随着线程数量的提高性能提升幅度越来越小，并且实际线程数量还远未达到HPC级别。

NICS的MIC架构初步试验结果

Intel在2008年进行的Larrabee模拟测试

总结

以上解释与说明只指向一个事实：在MIC架构上编写应用并不比走CUDA/OpenCL GPGPU的道路工作量小。即使是号称通用性最强的OpenCL，代码也必须根据硬件的架构特征做大量的优化与改动，否则得到的性能数据毫无实际意义。联系到目前的实际情况，毫无疑问NVIDIA的CUDA无论性能还是走在了市场的最先端，而OpenCL和Intel要稍微落后一些。

当然，NVIDIA CTO Steve Scott在鼓吹CPU+GPU混合系统的优势的同时，他在原文的评论里也表示Intel在软件开发环境上仍然具有一定优势：即使是需要大量修改代码并重新编译，具有x86或其他Intel SIMD ISA扩展开发经验的程序员面对MIC架构也能很快上手，而CUDA或者OpenCL的编程模式则完全不同；另外CUDA目前主要走C/C++的道路，在FORTRAN方面成绩远远不如Intel可提供成熟编译器的程度。Intel自己也声称，使用相对不受平台限制的高级语言则不会遇到二进制代码不兼容的问题。

总之，笔者仍然坚持自己的观点：在超级计算领域最后的赢家一定是软件开发环境以及Ecosystem打造情况最好的厂商，Intel的财力使其最容易来达到这一目标，但目前的Xeon Phi还有待于进一步的检验，与Tesla相比还为时过早。

参考资料：

[1]http://software.intel.com/file/45322

[2]http://software.intel.com/en-us/blogs/2012/06/05/knights-corner-micro-architecture-support/

[3]http://blogs.nvidia.com/2012/04/no-free-lunch-for-intel-mic-or-gpus/

[4]http://www.olcf.ornl.gov/wp-content/training/electronic-structure-2012/20120206-Brook-AACE-MICApps.pdf