相關閲讀：
ABI Research：Intel移動處理器已經比高通、三星更好
Intel處理器真的勝過ARM了？安兔兔什麼的才不可靠呢
安兔兔節操碎了一地？Intel Atom跑分高的”真相“謎團
安兔兔回應Intel處理器跑分偏高，V4版將強化使用者體驗
由安兔兔測試程序引發的Intel Atom處理器作弊與最佳化之爭剛剛停息了一段時間，現在又出現了新的主角了——三星Galaxy S4使用的Exynos 5 Octa處理器同樣陷入了這樣的困境，不同的是Exynos是根據不同測試程序來“最佳化”，而安兔兔是為特定處理器最佳化，Exynos 5 Octa的情況跟之前安兔兔指責華為K3V2針對安兔兔benchmark作弊有些類似。
先來看一下Exynos 5 Octa的基本參數：Octa使用了ARM的big.LITTLE架構，使用了四個1.6GHz頻率的Cortex-A15和四個1.2GHz頻率的Cortex-A7組成，GPU是PowerVR 544MP3，核心頻率為533MHz。
事情最早是Beyond3D論壇的一個玩家AndreiF要求Anandtech網站去掉國際版的GS4成績，他認為Octa的GPU只在個別程序中才能達到533MHz頻率，其他測試中大部分運行在480MHz下。在這樣的情況下，Anandtech網站就重新研究了一下。
GPU頻率研究結果
三星有一點做的不錯，在無需root的情況下就可以即時查看GPU的頻率，可以在ADB調用如下命令實現：adb shell cat /sys/module/pvrsrvkm/parameters/sgx_gpu_clk，希望三星不要砍掉這個功能。
實測顯示，運行大多數遊戲的情況下GPU頻率確實是480MHz，不過三星官方從未通告過Exynos 5 Octa處理器的的GPU頻率，所以這一點也不算什麼。
再運行別的程序看看。GLBenchmark 2.5.1中的GPU頻率是532MHz，Quadrant、安兔兔中同樣如此。
現在開始變得有趣了，再運行GFXBench 2.7.0(以前叫做GLBench 2.7.0)看看。Anaandtech與GFXBench的作者確認過，2.5.1和2.7.0的底層測試都是一樣的，理論上二者的成績應該是一樣的。
兩版GLBench測試的結果
測試重複了5次之後，2.5.1和2.7.0兩版程序之間有11%的性能差距(原文如此，實際上應該是13.9%吧)，為什麼呢？似乎是GLBench 2.5.1中可以運行在更高頻率/電壓下吧。
CPU頻率也受影響了
AndreiF糾結的地方主要是GPU頻率，Anandtech同樣也注意了一下CPU頻率。
左邊是1.2GHz的GLBech 2.5.1，右邊是500MHz的GLBench 2.7.0
通過系統監視器可以看到，GLBench 2.5.1中Octa將運行負載轉移到了A15核心上，預設頻率1.2GHz，而且頻率不會降低。如果運行2.7.0，那麼CPU負載會轉移到A7核心上，頻率為500MHz(有效頻率為250MHz)。
之後又驗證了安兔兔、Linpack、Benchmark Pi以及Quadrant等測試程序，結果也是類似，一旦上述程序載入，CPU調度器會固定在某個點上。
另外，現在測試的是國際版GS4，實際上驍龍600處理器的GS4的CPU測試也出現了同樣的情況，一旦特定的程序啟動之後，CPU就會以最高頻率運行，整個測試過程中都是如此，所有核心也會全速工作。
當然，還要注意到CPU和GPU全速運行時的不同，CPU是所有程序都可用的，只是在這些測試程序中才強制運行在最高頻率，而GPU的533MHz頻率只在某些特定的程序中才會出現。
深入挖掘：特定程序的最佳化？
根據上面的訊息下結論還有點武斷，現在再打開控制這些頻率變化的檔案了看一下。用十六進制編輯器打開TwDVFSApp.apk，搜索“PerformanceBooster”字元串。
從這個檔案中可以看到玄機了。Quadrant標準版、高級版以及專業版、linpack (免費版，不是付費版)、Benchmark Pi、AnTuTu等程序都是特別列出的，而GLBench 2.5.1不是。
當TwDVFSapp檔案運行時我們可以看到如下檔案執行：
//sys/class/devfreq/exynos5-busfreq-int/min_freq
//sys/class/devfreq/exynos5-busfreq-mif/min_freq
+/sys/class/thermal/thermal_zone0/boost_mode
2/sys/devices/platform/pvrsrvkm.0/sgx_dvfs_min_lock
當TwDVFSApp程序允許對特定程序進行特殊的DVFS行為時，boost_mode檔案值就會從0變成1，這樣很容易就能檢測到受影響的程序是否啟動了。以Benchmark Pi程序的啟動和關閉為例：
shell@android:/sys/class/thermal/thermal_zone0 $ cat boost_mode
1
shell@android:/sys/class/thermal/thermal_zone0 $ cat boost_mode
0
還有針對Fusion3(驍龍600+MDM9x15基頻的代號)及Adonis(Exynos 5 Octa的代號)的字元串：
doBoostAll
doBoostForAdonis
oBoostForAdonis::
doBoostForFusion3
doBoostForFusion3::
有趣的是，因為這個程序還是一個廣播接收器(broadcast receiver)，TwDVFSApp似乎還可以向處於白名單內的非特定程序發出BenchmarkBoost模式請求以達成某種目的。
6Lcom/sec/android/app/twdvfs/TwDVFSBroadcastReceiver$1;
6Lcom/sec/android/app/twdvfs/TwDVFSBroadcastReceiver$2;
?Lcom/sec/android/app/twdvfs/TwDVFSBroadcastReceiver$IntentInfo;
4Lcom/sec/android/app/twdvfs/TwDVFSBroadcastReceiver;
boostIntent
5com.sec.android.intent.action.DVFS_FG_PROCESS_CHANGED
*com.sec.android.intent.action.SSRM_REQUEST
現在我們不僅看到了這種最佳化行為及部分測試程序是如何受影響的，我們也知道了白名單及TwDVFSApp程序是如何對特定程序作出特殊的DVFS行為的。
總結：
Anandtech的標題還算比較保守，說這是“最佳化”，當然很多人可能有不同的理解。三星對Exynos 5 Octa的“最佳化”其實也不新鮮了，針對特定程序火力全開，CPU和GPU都能高速運行，除了測試程序之外的應用則降頻使用，反正三星不是第一個這麼幹的，也不會是最後一個，去年安兔兔就以此指責過華為K3V2跑分作弊。
我們常說目前的移動處理器發展越來越像PC，而PC業的所謂最佳化也是司空見慣的事了，但是不能因為我們在PC上見過了這樣的事，廠商就覺得移動處理器有這樣的事也是正常的。
廠商跟測試程序玩躲貓貓也早有例子了，典型的就是GPU廠商對Furmark的態度，他們認為Furmark跑出的溫度和功耗遠超正常範圍，所以千方百計地限制這個程序，驅動程式、BIOS甚至硬體保護電路的手段都用過。
三星需要做的是要麼針對所有程序開放這樣的設置，要麼就是去掉這樣所謂的最佳化，否則的話任由廠商這麼做下去，他們就會把精力放在提高某些測試程序的成績而非使用者體驗上。
提升使用者體驗的最佳化是必須的，而好的測試程序會從中受益。 | 
傳送訊息
發表於 13-8-8 04:00:30