Intel的「霸道」:深究編譯器對CPU性能的影響-Intel,AMD,編譯器...

Intel的「霸道」：深究編譯器對CPU性能的影響

2012-09-28 21:00:46  

   編輯：上方文Q[

爆料

]

收藏文章

編譯器：CPU性能對比的另一秘訣

當前的CPU市場格局大家都有個了解，Intel從Core架構特別是進入Core i7/i5/i3之後以Tick-Tock戰略連連得勝，而且在CPU架構和製造工藝上一騎絕塵，AMD這幾年時間只更新了K10及Bulldozer推土機兩代，後者獨特的模塊化設計也一言難盡，並沒有達到預期目標，已經落於下風了。

如今的對比就是這樣，Intel在CPU性能上大幅領先AMD，AMD只能用性價比以及APU的劍走偏鋒來應對。雖然豪言CPU速度競爭已經不再重要，但是箇中滋味也自在心頭。

除了架構設計，CPU性能高低是不是還存在別的影響因素？一個由來已久的爭論就是編譯器(compiler)優化。江湖人人皆知，Intel不僅有自己的編譯器，而且在針對性的優化中區分Intel系及非Intel系，並針對自家的處理器做重點優化。

2008年開始美國聯邦貿易委員會在調查Intel壟斷案件中就以編譯器優化作為Intel不公平競爭的證據。2010年，FTC與Intel達成和解，Intel承諾編譯器不再區分Intel和非Intel處理器，優化時一視同仁。

Intel的編譯器優化注意事項中就提到在Intel處理器上會有額外的性能提高

這是前因後果，但是具體到測試上不同的編譯器又對CPU性能有多少影響呢？很少有媒體做這樣的測試，不過Behardware網站出手了，他們以Core i7-2600K、AMD FX-8150以及上一代的Phenom II X4 975處理器為例對比了不同的編譯器下的性能。

全文內容非常多，基礎原理、SSE/AVX指令集特點、編譯器優化歷史等等都有涉及，這部分內容就不再翻譯了，因為內容過於專業，大部分人都不是專業人士，讀起來晦澀難懂，同行超能網為我們選取了其中的重點內容。

編譯器有各種各樣的，Behardwar的測試以使用最多的C/C++編譯器作為測試對象，編譯環境是微軟的VS 2010 SP1、Intel的C++ Compiler XE 12.0u5以及TDM-GCC (MinGW/GCC 4.6.1)三種，

VS 2010 SP1

C++ Compiler XE 12.0u5

TDM-GCC (MinGW/GCC 4.6.1)

重要問題：AMD為什麼沒有自己的編譯器

這個要著重寫一下，Intel在CPU上有優勢主要是因為他們有自己的編譯器，為什麼AMD沒有？這倒不是說AMD不關注這個問題，因為他們主要選擇了跟其他廠商或者開發組織合作。首先，AMD也參與了GCC編譯器工程，而微軟開發VS時也會跟AMD及Intel保持合作以便對他們的CPU作出公正(微軟語)而又統一的優化支持。

另外，AMD贊助並推廣了Open64編譯器，它脫胎於一個編譯器研究計劃，後者最早是Intel贊助的、針對安騰架構所優化的編譯器項目。安騰架構或多或少地應用了VLIW指令，每條指令其實包含三條指令，可以由三個超標量單元執行。它實際上超越了編譯器，在安騰架構上可以選擇混合哪條指令以獲得最大性能，這是一個非常困難的任務。

後來，Intel不再繼續這個項目了，AMD還在選擇性支持部分Open64編譯器，Intel只在Linux平臺下才支持Open64，這就與本文無關了。

測試平臺及軟體說明

測試的CPU前面已經提過了，是Core i7-2600K、AMD FX-8150以及上一代的Phenom II X4 975這三顆，他們支持的指令集也不一樣，適合對比，具體如下：

·Intel Core i7 2600k：Sandy Bridge架構，支持所有的SSE、AVX指令集，除了SSE4a

·AMD Phenom II X4 975：Deneb架構，支持最高SSE4a

·AMD FX-8150：(Bulldozer架構，支持所有的SSE、AVX指令集，包括SSE4a

需要說明的是SSE4a指令是AMD支持的指令，而Intel從沒支持這個指令。它實際上使用的也非常少，後面的測試中只有一個例子用到了這個指令，而X4 975也不支持任何SSE 4.1或者SSE 4.2指令。

另外，SSE 4.1與SSE4a之間只有很少部分是重疊的，大部分應用都不支持，這也為Intel的編譯器帶來了一些問題。

測試平臺配置

主板：華碩P8Z68-V Pro (Intel)、華碩M5A97-Evo (AMD)
內存：2×2GB DDR3 1600MHz
顯卡：Radeon HD 5450
硬碟：海盜船F120
作業系統：Windows 7 SP1

測試程序

測試使用的主要是SPEC 2006 v1.2，2011年9月的新版本，具體內容不表。

SPEC性能測試之bzip2、mfc

401.bzip2測試

語言：C
負載類型：整數
多線程：支持

bzip2是Linux平臺下很流行的壓縮軟體，測試用的程序經過改進，只能在內存中壓縮和解壓數據，這樣就避免了磁碟性能不足帶來的負面影響。

第一個測試就讓人有些吃驚，微軟的VS編譯器在Core i7以及FX處理器上都有著最好的性能。更諷刺的是Intel的編譯器在Phenom II X4 975上速度最快。

微軟的編譯器在Core i7上甚至要比AVX版還要快12%，後者本來應該是有最佳性能的。

結果有些出乎意料，SSE 4.1/4.2/AVX指令在i7/FX處理器上都是最慢的，但是Phenom X4上並非如此。

429.mcf測試

語言：C
負載類型：整數
多線程：不支持

在這部分測試中，微軟編譯器在SSE2及AVX指令上並沒有獲益，獲益的主要是Intel編譯器。

先看一下dispatcher builds，SSE3版的性能提升了30%，其他三種就只有輕微性能提升。這裡有什麼問題嗎？如果是使用「arch」 builds，那麼SSE3的性能優勢就沒有了。

在這裡，SSE3性能更快，但對其他模型來說就不一樣。

這裡要為Intel說一句話，如果沒有dispatcher，那麼它的編譯器在AMD處理器和Intel自家處理器上表現是一樣的，Phenom II X4處理器在arch:SSE3模式下性能比Intel還好。

調度器(Dispatcher)在AMD FX和Phenom II處理器上表現是一致的，這正是我們期待的結果。

◆ SPEC性能測試之gombk、hmmer及sjeng

445.gombk性能測試

語言：C
負載類型：整數
多線程：支持

gombk是遊戲中常用的人工智慧AI算法，主要在開源遊戲中GPNU Go中使用。

這個測試中不同的優化差異相對比較小，不過在i7處理器上微軟和GCC編譯器要比Intel自家的更快，不過Intel編譯器在Phenom II依然是最快的。毫無疑問，Intel編譯器在這個CPU上表現的很好。

456.hmmer測試

語言：C
負載類型：整數
多線程：不支持

hmmer是基因資料庫中常用的算法，同時在蛋白質序列分析中也很常用。

結果讓人很吃驚。不同的Intel編譯器調度器版本在Intel i7處理器上有明顯性能提升，同樣在AMD FX處理器上也有明顯提升。

458.sjeng測試

語言：C
負載類型：整數
多線程：不支持

sjeng是西洋棋軟體中使用的算法，來源於同名軟體。

SSE 4.1/4.2/AVX在i7處理器上有輕微性能提升，不過同樣的調度器下在AMD處理器上有一點下降。一旦去掉調度器，AVX在FX處理器確實有一點性能提升。

SPEC性能測試之h264ref、astar及milc

464.h264ref

語言：C
負載類型：整數
多線程：支持

h264ref是H264/AVC視頻編碼中使用的壓縮標準，這個測試包括baseline和main兩個視頻配置。

微軟的編譯器在i7處理器上要比Intel編譯器要快，而Intel編譯器不僅在Phenom II處理器要更快，在FX處理器上也是如此。有調度器的Intel編譯器是最有效率的。

GCC編譯器在Phenom II上優化的很好，但是在FX甚至起到反作用了。corei7avx在i7處理器還有一點性能優勢。

473.astar

語言：C++
負載類型：整數
多線程：不支持

astar是一種RTS遊戲中常用的尋路算法。

這是本文第一個C++編譯器測試，不過表現並不怎麼好，它的優化甚至有反作用。微軟編譯器是最優效率的，不過i7處理器除外。

需要的注意的是，在沒有調度器的情況下，只有SSE3版才能在Intel編譯器優化中受益，而其他版本不會。當然，這與指令集支持無關。

433.milc

語言：C
負載類型：浮點
多線程：支持

milc是量子色動力學中QCD中常用的物理模擬算法。

跟之前的測試一樣，有調度器的情況下，Intel編譯器在i7處理器商用SSE3模式會有性能增益，性能幾乎翻倍。在FX處理器上性能沒有變化，在Phenom II處理器上提升提升了9%。

SPEC性能測試之namd、lbm及sphinx3

444.namd

語言：C++
負載類型：浮點
多線程：支持

namd是分子運動動態模擬測試。

Intel編譯器的AVX調度器模式有輕微性能提升，在FX處理器上也是如此。微軟編譯器的AVX模式獲得了最多的性能提升，特別是在AMD平臺上。

在這裡，AMD和GCC的優化在i7處理器上要比Core i7的優化還要好。

470.lbm測試

語言：C
負載類型：浮點
多線程：支持

lbm是一個模擬流動行為的科學計算程序。

在這裡，Intel編譯器發威了，表現比其他編譯器要好。另外，AVX以及有調度器下的SSE 4.1模式有些小問題，在AMD處理器上明顯要慢，這也不是第一次遇到這個問題了。

482.sphinx3

語言：C
負載類型：浮點
多線程：支持

sphinx3是SPEC測試軟體中一個聲音識別算法。

首先來看微軟編譯器的表現，雖然SSE2模式明顯影響了三套平臺的性能，但是在i7處理器上AVX模式跟SSE2一樣慢，但是在FX處理器上它又突然變成最快的。

Intel編譯器的AVX模式在i7處理器上有一些性能提升，不過在其他平臺的非調度模式下就有性能下降。

性能測試之C-Ray、TSCP及7-Zip

除了SPEC，他們還測試了其他幾個軟體。

微軟編譯器在從X87到SSE2中性能翻倍還多，在三套平臺下都是如此，AVX模式在i7處理上甚至比Intel編譯器還要快。

與之前的情況一樣，Intel編譯器在AMD平臺上效率最好，Intel編譯器的不同調度器對此也沒什麼影響，甚至關掉也一樣，不過FX處理器在SSE 4.2和AVX模式下有一些性能下降。

另外，GCC編譯器對i7處理器甚至有反作用，但是在AMD處理器上就不一樣。

TSCP

語言：C
負載類型：整數
多線程：不支持

TSCP是源於Tom Kerrigan軟體中的西洋棋AI算法。

在這裡，Intel編譯器無論是否有調度器都沒有影響，有的話AVX模式下有一點優勢。GCC編譯器在三套平臺下表現都是最好的。

7-Zip

語言：C
負載類型：整數
多線程：支持

7-zip就無需過多介紹了，他們使用的是9.20版本，用LZMA2算法來評估性能。

7-zip是唯一一個用性能而非時間為基準的測試，數字越大越好。

測試結果中，微軟的編譯器在i7和FX處理器上是最快的，Intel編譯器只在Phenom II處理器上領先。

彙編語言的影響：X264測試

X264視頻壓縮軟體在這篇測試中非常特殊，因為它使用了大量彙編語言。而且作者也並非單獨針對X86優化，它還支持ARM架構中的NEON指令。如果禁用彙編優化，那麼它還可以作為編譯軟體使用，這樣就可以檢查出優化的影響。

首先要指出的是，X264一旦檢測到GCC編譯的帶有SSE4a優化的build就會停止執行，只有同時支持AVX和SSE4a指令的FX處理器才能完成整個編譯過程。

第二，用彙編語言寫成的代碼是獲得最高性能的最佳方式，雖然彙編語言從2600K的corei7/corei7avx配置及AMD處理器的bdver1及barcelona配置中受益很小。更讓人吃驚的是在無彙編語言的代碼上並不受歡迎。

最後，強制使用AVX 128bit指令確實會有影響，不過影響非常小。

當然這裡的測試結果並不能與我們之前測過的結果直接比較，但是我們還是要說，雖然編譯器現在扮演著重要角色，但是開發者總是可以大幅優化C/C++代碼的。

性能綜述：Intel編譯器佔優

前面一大堆的結果看的大家都累了，來看看綜合性的性能評述吧，這些表格平均了前面的測試結果，更方便對比。

cl base性能

cl SSE2平均性能

icc base性能

如果看完了前面的介紹，那麼這裡的結論並不讓人吃驚。Intel編譯器的是性能最好的，GCC也不錯，但是部分測試中市場有相反的作用。

VS 2010的標準版明顯最慢，主要是因為默認的浮點操作默認使用的還是X87代碼，吐過改用SSE2性能就會大幅提升，特別是在AMD處理器上。

如果對比默認的Intel模式(同樣為SSE2編譯)，那麼Intel編譯器就會領先，而FX-8150受益最為明顯，可提升24%的性能，i7才提升了20%。

總結：編譯器的抉擇困境

Behardware在最後表示希望他們的文章可以闡明有關編譯器的問題，讓大家了解到編譯器在處理器性能中扮演的角色。他們在文中問了幾個問題，現在我們可以自己找到答案了。(看過之後還是覺得一頭霧水的路過)

首先，編譯器的不同選擇會影響性能。之前一直在說Intel編譯器性能最好的說法得到證實，雖然有一些反例，但是Intel編譯器還是要比默認設置的微軟VS要好，就算後者強制使用SSE2數學操作，微軟的編譯器依然要比Intel編譯器慢上15-20%。

如果Intel投資開發了一款編譯器，那麼它當然可以作為性能戰爭中的一項優勢。Intel可以為自己的處理器自動優化，甚至可以通過命名的方式把這些優化當作指令集，比如為AVX優化的qaxAVX就是一例。Intel總是把最新的優化留給最新的處理器，這樣一來在測試中就會獲得性能優勢，然後加深大家對Intel處理器的性能優勢的印象。看看Phenom II在那些無AVX調度的應用中的性能就非常明顯了。

一個無指令調用功能的例子

如果禁用了調度器，就會因為一些優化層面的問題變得更複雜，這已經跟處理器是否支持某種指令集無關了。更差的情況就是，部分型號的表現反而要比其他型號更有效率，比如SSE3模式就是平均最快的了。

總之，Intel的編譯器給開發者帶來了複雜的選擇，要麼選擇沒有優化，要麼就是使用Intel制定的指令集以便在Intel處理器上獲得額外的15%性能提升，而在AMD處理器上沒有或者是降低了性能。

這個問題能怪開發者嗎？這是一個兩難的問題，如果你給開發者一個公平的編譯器，它在AMD處理器上能獲得35%的性能提升，但是Intel處理器上能獲得54%的性能提升，你會責怪開發者選擇了能給消費者最佳體驗的那條路嗎？

那麼AMD處理器用戶呢？他們是會接受一個公平但是性能更慢的情況,還是更願意接受一個自己有性能提升但是競爭對手性能提升更多的方案呢？真實世界中，用戶的觀點並不重要，軟體程序用戶沒得選擇，好與壞的決定權是在開發者手中。

實際上我們的處理器測試就已經受到了開發者的選擇的影響，儘管我們的原則是儘可能避免盲目推崇測試。一旦哪個非常流行的程序選擇了某個處理器而不是另一個，那麼測試性能不同反映的其實只是軟體的用戶體驗。

給出一個公正客觀的選擇也非常難，實際上也沒有多少解決方案。開發向LLVM那樣的編譯器以及編寫可管理的代碼是一個可行的方案，這就像.NET的普通應用一樣，要記住不論是誰控制了虛擬機，終端才是控制每個架構性能的關鍵。

閱讀更多：英特爾

相關閱讀：

輕薄+零噪音！AMD銳龍迷你機也能如此極品

華為全新筆記本預售：十代U 價格香

NV 7nm顯卡發布時間曝光：低功耗性能怪獸

20年來首次：AMD翻身 Intel越來越不淡定

史上第一次 AMD重要性超過蘋果、華為

Intel、高通居然走到了一起！