Intel在面向開發(fā)者的博客中也總結(jié)了這一點，內(nèi)部高速總線、高度并行數(shù)據(jù)處理所需的特殊矢量單元等特性綜合導(dǎo)致了上面的結(jié)果——為Xeon Phi所編寫、編譯的代碼不能在其余CPU上運(yùn)行，反之亦然：為SIMD大量優(yōu)化的代碼對Xeon Phi同樣沒有意義。此外Intel還重申Xeon Phi是一款協(xié)處理器，需要CPU的輔助才能發(fā)揮應(yīng)有的作用，從模式上來說已經(jīng)和NVIDIA的Tesla加速卡類似，偏離了原有的設(shè)想。

而Xeon Phi在對于開發(fā)者的導(dǎo)向上也打破了此前和AMD的默契，此前Intel的開發(fā)文檔中均表態(tài)鼓勵程序員使用SSE2/AVX指令集并稱所有的 Intel64架構(gòu)產(chǎn)品均支持SSE2——現(xiàn)在這一“潛規(guī)則”也已煙消云散。并且Intel是否會將Xeon Phi中的特有指令集導(dǎo)入其余產(chǎn)品如服務(wù)器/臺式機(jī)/筆記本CPU中也暫且不得而知。

不存在能自動并行化代碼的“魔法”編譯器

有人可能會提出：那么去除掉不兼容部分的二進(jìn)制代碼呢?NVIDIA CTO Steve Scott早在今年四月份就撰文[3]告訴我們，這些代碼經(jīng)過簡單的再編譯是有可能運(yùn)行在MIC架構(gòu)上的，但存在兩大問題：如果使用MPI API(one rank/core)，MIC加速卡的50多個CPU核心將會分享8GB的內(nèi)存，這遠(yuǎn)遠(yuǎn)小于目前HPC應(yīng)用中1-2GB/每CPU核心的數(shù)量，而且50多個CPU核心同時通訊將會導(dǎo)致網(wǎng)絡(luò)傳輸堵塞，OpenMP API的情況也只是好一點;另外根據(jù)阿姆達(dá)爾定律，代碼中不能并行化的部分將成為極大的瓶頸——別忘了Xeon Phi的每個核心單線程能力實際上和十來年前的初代奔騰P54C沒什么兩樣，并且目前多數(shù)x86 CPU上運(yùn)行的代碼并行度和線程數(shù)量都不高，簡單編譯自然無法發(fā)揮Xeon Phi的能力。

Scott表示，不管是現(xiàn)在還是未來，不會存在一個“魔法”編譯器，使得原有的代碼可以很好地自動并行化。在超級計算機(jī)領(lǐng)域甚至每個應(yīng)用的代碼更換系統(tǒng)后都需要重新編譯一遍，目前還看不到哪個公司(包括Intel、NVIDIA或者其他任何人)能幫助程序員從這一工作中解脫出來。

此外，Scott引述的美國國家計算中心(NICS)的MIC架構(gòu)性能演示[4]也側(cè)面說明Xeon Phi仍未解決Larrabee架構(gòu)的一些問題——隨著線程數(shù)量的提高性能提升幅度越來越小，并且實際線程數(shù)量還遠(yuǎn)未達(dá)到HPC級別。

NICS的MIC架構(gòu)初步試驗結(jié)果

Intel在2008年進(jìn)行的Larrabee模擬測試

總結(jié)

以上解釋與說明只指向一個事實：在MIC架構(gòu)上編寫應(yīng)用并不比走CUDA/OpenCL GPGPU的道路工作量小。即使是號稱通用性最強(qiáng)的OpenCL，代碼也必須根據(jù)硬件的架構(gòu)特征做大量的優(yōu)化與改動，否則得到的性能數(shù)據(jù)毫無實際意義。聯(lián)系到目前的實際情況，毫無疑問NVIDIA的CUDA無論性能還是走在了市場的最先端，而OpenCL和Intel要稍微落后一些。

當(dāng)然，NVIDIA CTO Steve Scott在鼓吹CPU+GPU混合系統(tǒng)的優(yōu)勢的同時，他在原文的評論里也表示Intel在軟件開發(fā)環(huán)境上仍然具有一定優(yōu)勢：即使是需要大量修改代碼并重新編譯，具有x86或其他Intel SIMD ISA擴(kuò)展開發(fā)經(jīng)驗的程序員面對MIC架構(gòu)也能很快上手，而CUDA或者OpenCL的編程模式則完全不同;另外CUDA目前主要走C/C++的道路，在 FORTRAN方面成績遠(yuǎn)遠(yuǎn)不如Intel可提供成熟編譯器的程度。Intel自己也聲稱，使用相對不受平臺限制的高級語言則不會遇到二進(jìn)制代碼不兼容的問題。

總之，筆者仍然堅持自己的觀點：在超級計算領(lǐng)域最后的贏家一定是軟件開發(fā)環(huán)境以及Ecosystem打造情況最好的廠商，Intel的財力使其最容易來達(dá)到這一目標(biāo)，但目前的Xeon Phi還有待于進(jìn)一步的檢驗，與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

zhaohang