没有免费的午餐 浅析Xeon Phi的x86兼容性--作者ChrisR应该是在论坛里，致敬

gzpony

没有免费的午餐 浅析Xeon Phi的x86兼容性

2012-08-08 13:35:13 520 人阅读 作者：ChrisR 编辑：ChrisR [复制链接] [我要爆料]

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处理器上运行的代码并行度和线程数量都不高。 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

mooncocoon

其实以Intel的编译器体系来看，ZMM的优化和过渡本身问题应该并不大，但关键是ZMM本身与前面的SSE和AVX都不相同，不可能指望它们交叉兼容的。所以从512bit Vector Unit、register以及ZMM定案的一瞬间，这玩意是个协处理器的基调就已经定了。
抛弃对传统指令的支持有很多重原因，其中最重要的一点就是目前阶段Xeon Phi协处理器的定位。未来的MIC依旧会向更全面的指令集支持以及独当一面的方向去发展，但在现在这个阶段上，系统复杂度要求MIC只能选择协处理器异构计算的方式来分摊系统复杂度带来的挑战和压力。
某帖中我一直在说请千万明白MIC究竟是啥，到底是在干什么然后再来讨论它与HSA和Maxwell的关系，其实目的无非是让讨论进行在应该被进行的轨迹上而已。如果连这个最基本的点都抓不住，那讨论自然也就无法进行下去了

nom8393

Intel的Fortran编译器是强的离谱，可惜我从来不会用到。

bcyj

其实按我的理解,intel选择了最合理的
1.使用了mmx,sse2优化的软件或闭源库,都不会是长久没更新的
2.长久没更新,使用了几十年的闭源库,最多只会使用x87浮点,phi可以兼容这部分
3.对于紧跟硬件发展,有进行各种新指令优化的软件,再去为zmm优化不是难事

然后,最重要的一环其实是操作系统的支持程度了,操作系统支持得好,利用处理器异常,其实可以把一切都隐藏,当执行到不支持的指令集时,调度到支持的cpu上执行,内存管理更是小问题了..地址映射罢了...把专用内存理解成缓存好了..

asdfjkl

bcyj 发表于 2012-8-8 19:37
其实按我的理解,intel选择了最合理的
1.使用了mmx,sse2优化的软件或闭源库,都不会是长久没更新的
2.长久没 ...

有一个问题请教，Intel的Xeon Phi实现了与CPU统一寻址么？ 有提到到么？

bcyj

asdfjkl 发表于 2012-8-8 19:42
有一个问题请教，Intel的Xeon Phi实现了与CPU统一寻址么？ 有提到到么？

地址是都映射到了dma上了,通过总线都可以访问

bcyj

asdfjkl 发表于 2012-8-8 19:42
有一个问题请教，Intel的Xeon Phi实现了与CPU统一寻址么？ 有提到到么？

给你找了一下来源,原来第一页就有
http://software.intel.com/file/45322

Coherent memory model
The Knights Corner instructions operates in a memory address space that follows
the standard defined by the Intel® 64 achitecture. This feature eases the process of developing vector code.

bcyj

所以我觉得这个文章的作者,不是进行底层开发的,其实只要指令编码方式一样,没有指令重码和冲突,兼容性就没有什么大问题...
在开发时,遇到不支持的指令,用异常处理来软件模拟不支持的指令,应该是开发中常见手段了...加上现在是多处理架构,直接调度去给支持的cpu执行也很简单