鐵之狂傲

 取回密碼
 註冊
搜尋

切換到指定樓層
1#
相關閲讀:

ABI Research:Intel[url=https://www.gamez.com.tw/forum.php?mod=forumdisplay&fid=509&filter=typeid&typeid=3606]移動處理器已經比高通、三星更好[/url]
Intel處理器真的勝過ARM了?安兔兔什麼的才不可靠呢

  第三方調查公司ABI Research以安兔兔成績盛讚Intel Atom處理器性能超過高通、三星一事其實是5月中發生的,今天EETimes上篇博文又談到了這件事,認為ABI只用安兔兔成績說事有些武斷,他又列舉了其他評測項目的成績來反駁,並認為安兔兔從2.9.3版到3.x的評分機制變化導致Intel處理器得分大幅上升,所以才占到了優勢。
  沒想到這件事並沒有結束,既然雙方爭論的焦點是安兔兔軟體,Anandtech論壇上就有一位愛較真的網友(應該是個程序員或者開發者)分析了安兔兔軟體,結果卻讓人很震驚,他認為安兔兔有故意為Intel處理器最佳化甚至使用對ARM不公平的方式了評分。
  如果此事成真,那麼安兔兔的節操就要灑滿一地了。
  下面來看一下他的分析。
安兔兔是怎樣的一個程序
  首先是解包安兔兔程序,APK程序實際上就是一個標準的ZIP壓縮檔案,這一步沒什麼難度。解包後在lib庫中發現了X86和ARM-v7a目錄,分別對應Intel和ARM處理器。然後再解包libabenchmark.so檔案,他用的是objump軟體。
  下面就來理解一下安兔兔軟體的根基了,原文作者從解包出來的檔案中發現安兔兔實際上就是nbench,因為二者的功能及函數之類的東西都是一樣的,我們可以說安兔兔的CPU整數和浮點測試都是基於nbench的,後者的源碼地址在http://www.tux.org/~mayer/linux/bmark.html。(原來安兔兔的測試部分不是自己開發的,也開源程序DIY的啊)
  現在繼續我們的目的,揭開為啥安兔兔3.x測試中Intel處理器跑分這麼高的原因。之前EETimes一文質疑的原因就是在於從2.9.3版升級到3.0之後,Atom處理器總分及記憶體測試分別提升了122%、292%,而三星Galaxy S4隻提升了53%、59%,這其中的區別耐人尋味。
Atom超高跑分第一個疑兇:編譯器
  找出的第一個“疑兇”是編譯器,安兔兔針對X86使用的是ICC編譯器,這是一種公認的高品質矢量化編譯器,而矢量化恰恰是ARM處理器不擅長的,因為後者缺少整數NEON指令。
  安兔兔針對ARM處理器使用的是GCC編譯器,而且也不支援ARM的NEON指令,因為存在着Tegra 2這樣早起的處理器不支援NEON指令的情況,但是現在來看這些不是理由,NDK中使用獨立代碼支援NEON指令不是難事,這也是Google的文檔中標準的開發範例。
  令人奇怪的就是安兔兔不按照Google的開發範例支援原本應該支援的功能,卻對不屬於NDK標準支援之內的ICC編譯器青睞有加。
  編譯器的問題只是一個開始,下面還有更精彩的,它們的作用甚至比編譯器更“出色”。
第二疑兇:代碼最佳化
  Nbench測試時會檢查CPU是怎樣執行簡單的按位操作的,包括shift位移、and加、or或等,為了執行這些,它會在記憶體載入一系列bit,每次載入一個,實際的代碼如下:

  再來看ARM和X86是如何實際執行的。
arm01.jpg
ARM處理器執行的代碼

arm05.jpg
X86執行的代碼

  X86上的代碼在做的是講整個32bit運行到0或者1,其中的f64c3和f64c6是關鍵。它用這兩個指令取代了ARM循環中的32次迭代。這個的作用就不需多說了,X86用這種方式獲得了十多倍的運行速度提升。
  這種做法打破了整個測試過程。當編譯器本來打算用一些被測試程序認定為正確的操作來提升測試程序的性能時,它實際上並沒有執行真正的測試程序功能。典型的例子就是如果結果沒有被讀取,它就省去了代碼,或者是在輸入數據被認為是常量時,它可以將原本需要的運行時間縮減到只需編譯時間即可。
  在這種情況下Intel肯定會宣稱這是他們正當的最佳化而已,但是原文作者不讚同,認為這種最佳化很難被當做正常的代碼,用處也很有限,因為沒誰會用這樣的代碼來執行。這種伎倆更應該被認為是一種作弊,因為當運行長度不是非常大的時候它甚至會更慢。
  更重要的是,這種最佳化是在最近的一次版本升級中才出現在ICC中的,作者不認為他們是最近才發現了這種最佳化的價值,更可能的情況是他們發現這種最佳化可以數倍提升安兔兔分數,或者這也可以解釋為什麼最近曝光的下一代Atom處理器在1.1GHz頻率下都能以4萬的高分秒了2.3GHz的驍龍800了。
  我們簡單歸納一下作者的觀點和論據:Atom處理器跑分高有兩個原因,一個是編譯器的原因,X86使用的ICC編譯器最佳化很好,而針對ARM所用的GCC編譯器甚至都不能支援ARM的NEON指令。第二個就是安兔兔代碼中,將X86運行測試程序的代碼“最佳化了”,只需2個指令就能完成ARM處理器需要進行的32次迭代,但是這種最佳化對實際性能沒有好處,這種反常的設計頗有尋味之處。
  原文最後把矛盾的焦點轉向了安兔兔,因為他們預設了這樣的性能提升,還認為安兔兔有可能是收錢了(probably for a price),不然這些反常的現象是沒法解釋的。
Intel、ARM出面掀起新高潮
  原文的翻譯差不多完了,因為是技術文章,個別語句可能把握的不夠準,不過大體意思我們是知曉了的。我能這麼早看到這篇文章其實是微博所賜,發這個連結的正是ARM移動市場經理王駿超EW,微博發出之後很快就有人回覆,其中一個人則是Intel中國研究院首席工程師吳甘沙,看完Intel對ARM還是很注意的嘛,這讓人想起了錢鍾書說過的一句話:情敵之間的掛念有時候要比情人之間的牽掛還要多。

  王先生雖然發了連結,不過自己並沒有說太多,但他顯然是站在揭黑幕、維護ARM的立場上的,而吳先生也客氣地解釋了這個問題,他認為編譯器也是架構競爭力的一部分,用ICC無可厚非,而且ARM的NEON指令是比不過Intel的SSE 4.x指令集的。他還認為原文的分析並不能解釋Atom在安兔兔多數程序上的優勢。
  總之,現在這件事已經多多少少地從媒體牽扯到了ARM、Intel兩家公司出面了,而涉及最深的應該是安兔兔,目前還沒有他們的表態,只是從這篇文章的分析來看,安兔兔不管有沒有收錢,在這件事上都是有不光彩行為的。
  去年華為發布Q1四核之後,安兔兔突然在其英文版網站(選擇的還不是中文官網)上義正言辭斥責華為K3V2處理器作弊,因為在相關代碼中發現K3V2會針對測試程序全速或者超頻運行,而在日常應用中卻降頻使用,安兔兔好一副公正無私的表現。
  當然,華為是大公司,大風大浪見多,安兔兔的指責也沒改變他們把K3V2當成萬年寶貝用在旗下多款高級甚至旗艦手機上。
<strike>  看來不論是什麼人或者什麼公司,節操都不會第一位的,哪怕碎了一地也可以撿起來繼續。</strike>
 
轉播0 分享0 收藏0

回覆 使用道具 檢舉

你需要登入後才可以回覆 登入 | 註冊

存檔|手機版|聯絡我們|新聞提供|鐵之狂傲

GMT+8, 24-11-3 04:31 , Processed in 0.018914 second(s), 18 queries , Gzip On.

回頂部