魔改 Exynos 9810:其實也不比驍龍 845 差

譯者的話：

之前 CITREA 同學已經翻譯了 AnandTech 的 Galaxy S9/S9+ 評測文章，著重探討 Exynos 9810 這顆 SoC 的性能表現，大家可以去看一看。她雖然沒有翻譯全文，不過其實基本可以看出 Exynos 9810 就 CPU 部分未能達到三星自己的預期——尤其是先前還誇下海口說其單線程性能翻番；其實際系統性能和能效比驍龍 845 差了一截。

不過其實我們從 Exynos M3 核心走的「胖核心」路子可知，三星的這番宣傳或許不能用「誇下海口」形容，而是在實際操作的時候遇到了一些問題。這個核心的「胖」大致是個什麼概念呢？6-wide decode 寬度和 50% IPC 提升咱就不提了，這個講法可能對很多普通愛好者而言不夠直觀。

Exynos 9810 內部 M3 大核及其周邊佔地面積有 20.23mm²；M3 僅核心的尺寸是 3.46mm²，加上配套的 L2 緩存，面積比驍龍 845 的 A75 大核 + L2 緩存大了超過一倍。M3 貓鼬核心基本上快要達到蘋果 A11 Monsoon 核心的規模（不過蘋果在製程方面是有一定優勢的）；大小核心兩簇加起來，面積是 22.1mm²，遠比蘋果的 14.48mm² 和高通的 11.39mm² 大多了，這個料還是堆足了，所以我覺得這會是個挺有趣的事情。雖然高通其實從 835 開始就放棄胖核心思路了。

但 Galaxy S9 在真實使用場景中實際表現出來的效率是比較低下的。AnandTech 未能在 S9/S9+ 評測中給出太多解釋，所以其後他們針對 Exynos 9810 的固件和驅動進行了改造，試圖真正找出 9810 表現不佳的原因，所以有了這篇文章。

本文是對 AnandTech 於今年 4 月發布兩篇挖掘 Exynos 9810 CPU 部分潛能的翻譯，面向愛好者，不存在太多晦澀的內容。個人水平有限，若有貽笑大方之處還請不吝賜教。

為此 AnandTech 將這篇文章分成了上下兩篇，其中上篇嘗試將 Exynos 9810 的最高頻率限制到 1794MHz，意外發現其底層性能（SPEC）表現居然已經達到了驍龍 845 的程度，而且 IPC 效率還更高；而在系統性能層面，1794MHz 頻率下某些項目的成績甚至比 2.7GHz（原生單核最高頻率）的成績更好（雖然系統性能仍比驍龍 845 差一些），這個「更好」不光是能效方面的優，連帶性能也變優了——這事兒是不是挺古怪的？想知道原因的話，就看文章吧。

在上篇研究發現 9810 低效的一大原因在於其 scheduler 和 governor 調度過慢之後，AnandTech 嘗試在下篇中修改其 scheduler 調度機制，實現了性能與能效的進一步提升，並在 2.3GHz 頻率下實現系統性能與驍龍 845 的基本同一水準。

而且實際上，AnandTech 認為其中仍有進一步的優化餘地，以榨取更多的性能與能效，這是個挺有意思的故事，各位千萬不要錯過了。

其實我覺得三星這次的嘗試還是有價值的，即便最終結果並不是特別好，升級固件依舊可以改善很多問題，只不過他們明顯沒有準備就緒，對下一代產品會有比較大的意義。

正文開始

上篇

上周我們發表了 Galaxy S9 與 S9+ 體驗文章，這次的三星旗艦在處理器方面依然有兩個版本，分別是驍龍 845 SoC 與 Exynos 9810 SoC 版。我們對 Exynos 9810 是寄予很大期望的，畢竟三星宣稱這是首顆「很大核心」（very large core）的 Android SoC。但我們在初步測試中發現了不少問題，Exynos 9810 的綜合跑分成績，並沒有很好地在實際使用場景中體現出來。而且我還在測試中發現，設備的 scheduler（調度器）與 DVFS（動態電壓頻率調節）配置也不盡人意。

全篇體驗文，我沒有對設備的配置進行修改，畢竟初步測試文章定位的還是普通消費用戶，我感覺對讀者而言價值並不大。先前我也說了，未來幾周我會做持續跟進。所以我想儘量榨取 Exynos 9810 的可能性，減少驅動對其影響。

在對手機進行 root 操作，搞完定製內核之後，我最先做的事情就是搞定所謂的 hotplugging 機制——我在先前的體驗文章中曾經提到過，這在我看來應該是對性能影響最嚴重的癥結。

（譯者註：三星利用的就是這種 hot-plugging 機制實現線程在核心間的遷移，AnandTech 在針對 S9 的評測中提過他們認為這是一種低效的實施方案。在嘗試給出更多性能資源時，scheduler 也被調校得過於保守。）

搞定製內核是可以推高頻率的，所以在搗鼓一陣之後，我就把 M3 核心推至 4x 2496MHz，GeekBench 多核跑分也創了記錄。再進一步讓 M3 核心持續跑 2704MHz 頻率，就會導致設備崩潰，所以我還是決定從頭來，用我們的方法來讓性能最優化。

配置一覽與 SPEC

首輪測試，我判斷，徹底關閉 hotplugging 機制會比較好，因為這玩意兒沒能發揮應有的作用。M3 核心頻率設定在 1794MHz，和官方搭載內核原本給四核 M3 一起跑時分配的頻率一致。僅從頻率上來說，理論上其多線程性能表現應該會更高，只不過單核性能會更糟。

不過實際情況還挺有趣。Exynos M3 核心跑在 1794MHz 頻率下的表現相當好，綜合基準測試超出我的預期。首先是 SPEC：

（譯者註：按照慣例，還是解釋一下這張圖；這裡略微有點複雜。第一張圖的維度叫做 Efficency As Total Energy，左邊部分的柱狀條表示的是效率——這根柱狀條越短表示效率越高；柱狀條右邊有兩個數字，逗號前面那個數字表示的是功率-單位瓦特，也就是一般人常說的功耗；逗號右邊還有個數字，那是總共消耗的能量，單位焦耳——左邊柱狀條代表的也是能量，所以越短越好；

右邊部分的柱狀條表示的就是絕對性能，越長越好；另外需要注意，藍色柱狀條一共列了四項，第一條是原生 Exynos 9810 的成績，第二條是 cust.1 定製版 9810 的成績——也就是前文提到 CPU 部分去除 hotplugging，頻率限制到 1796MHz 以後的 9810；而第三條則是採用 CPU Limiter 模式，將頻率限制到 1469MHz 以後的跑分成績。）

（譯者註：這張圖的維度叫做 Performance Efficiency，下文也會解釋這是個啥東西。這張圖左邊部分柱狀條表示的是 performance efficiency，其計算方法是用性能跑分（SPECspeed）來除以耗費的能量（焦耳），得到的這個值表示的是耗費每 1 焦耳能量，跑了多少分，這根柱狀條越短越好——這玩意兒就叫 performance efficency，它或許並不能簡單解釋為「能效」，因為大部分人對於能效的理解其實不是這麼算的；提一句，功率表示的就是單位時間內所做的功，它是大部分人對於能耗的理解。許多人對能效的理解就處理器層面來看是 IPC，即跑分除以頻率，得到每 GHz 可以跑多少分；而在系統性能層面，考量能效更多是用跑分去除以功率，得到每 1 瓦特能跑多少分（或 GPU 的多少幀）；

左側柱狀條右邊有兩個數字，照例逗號前面的數字是功率，而逗號後面的數字就是 跑分/能量 的 performance efficiency 了；右邊部分的柱狀條仍表示絕對性能，越長越好。）

在 Galaxy S9 的體驗文章中，我已經做出過假設，Exynos 9810 若要達到驍龍 845 相同的峰值性能，則在效率方面會有不及。評測中我就推測說，用 CPU Limiter 模式把頻率限制在 1469MHz，可能這個頻率以後，能量會隨頻率的升高進一步變大。從那次測得的成績來看，我原本覺得 Exynos 9810 如果要在 SPEC 測試中達到驍龍 845 那樣的成績，可能需要 2.1-2.3GHz 這樣的頻率。

（譯者註：在針對 Galaxy S9 的評測文章中，AnandTech 使用 web 瀏覽來測試其電池續航（WiFi），發現其最終結果非常糟糕。AnandTech 嘗試去理解是否是由 M3 核心過高的功耗導致。所以他們選擇啟用所謂的 CPU Limiter 模式——這是三星自己在固件中提供的一個電池優化可選項，這個模式會將 M3 核心頻率限制在 1469MHz，並將內存控制器的速度限制一半，另外可能也更改了某些 scheduler 設定，令其更加保守。這麼做的確讓續航多了 3 個小時，但體驗也變得明顯更糟）

但讓我意外的是，1794MHz 頻率下的峰值成績居然和驍龍 845 差不多，僅有幾個百分點的差別。而且不僅是性能方面很接近，從效率來看也出乎我的意料。在 SPECint 測試項中，這顆 Exynos 晶片的能量消耗情況和驍龍差不多。而在 SPECfp 測試中，Exynos 甚至還在能效方面領先了 15%。

這次我針對 SPEC 還做了第二張圖。其實我對呈現這份數據也還是挺矛盾的，這張圖考量的維度是「單位能量、單位時間內的工作量（work per time per energy）」，或者「單位能量內的性能表現」（performance per energy）（譯者註：也就是每消耗 1 焦耳能量，SPECSpeed 跑了多少分）。可能我也很難回答，這展示的究竟算是個什麼，我將之稱作「性能效率（Performance Efficency）」——這可能是最合適的叫法了。讀者此處需要注意區分「效率（efficiency）」一詞，總的能量消耗（譯者註：即上圖中 Total Energy），和「性能效率（Performance Efficiency）」兩種呈現方式裡，都出現了「效率」這個詞，後者在其含義方面可能更難以理解。

這些差異的產生，我覺得主要是由以下三個因素導致的：禁用「hotplugging」機制以後，也就從其他線程中排除了所有單線程性能噪聲。M3 核心在更低頻率下有著更好的優化，在某些溫度限制負載測試中，諸如 libquantum，我們也看到了一些部分提升。

第二個原因，也是在我看來最重要的，即在這樣的設定下，相對保守的存儲控制器 DVFS 才能更好地為 M3 核心服務。這在 SPECfp 測試成績中表現得很明顯，1794MHz 頻率下，每 GHz 的 SPECSpeed 成績是 12.37（能效的其中一個衡量維度）；而如果跑原生內核，這個比值則為 9.94。也就是說，在 IPC 效率方面，1794MHz 頻率獲得了 24% 的提升。SPECint 的測試結果也是類似的，每 GHz 的跑分性能也從原生的 8.05 提升到了 9.53，有 18% 的提升。

在 SPECspeed/焦耳（也就是 performance efficiency）那張圖中，我們就已經看到將頻率調整到 1794MHz，其成績表現是優於原生與 CPU Limiter 模式的。這部分提升若以 perf/W 和總能耗圖表來呈現，則是看不出來的，所以這裡加入了所謂的性能效率考量維度。

總的來說，在這樣的最佳配置狀態下，M3 核心相較高通驍龍的 Kryo 385 Gold 核心有著 51% 的 IPC 領先優勢。從早前三星的公告和微架構調整來看，這和我們預期的情況就差不多了。

系統性能

在 Galaxy S9 評測中我就提到過，Exynos 晶片版本的實際性能表現其實受到了軟體的影響，那些負載實際上並沒有真正充分利用其實際性能。那我們就先來快速看看，如果以 1794MHz 頻率跑分，測試成績表現會是怎樣。

相較原生配置，在 PCMark 的 Web Browsing 2.0 測試中，其性能提升多達 22%。這裡我還想再強調一次，hotplugging 機制的確對實際使用中的性能表現有很大影響，這項機制沒有在諸多負載任務中做到對線程行為的細粒度高效控制。結果自然是可想而知的，即便我們的定製內核較大程度限制了單線程 CPU 性能，web 測試仍然表現出了更好的成績。

視頻編輯（Video Editing）測試項目似乎有小幅性能滑坡，未來我還會對此做進一步的研究。

照片編輯（Photo Editing）測試也有性能方面的提升。

Writing 2.0（寫入 2.0）和 Data Manipulation（數據操作）測試則出現性能下滑，畢竟我們對其進行了頻率較大幅度的限制。不過我相信再做進一步調整，是可以找回這部分性能損失的，畢竟到此我還沒有去調整 scheduler 和 DVFS 行為。

在最後的 web 測試中，我們的定製版配置再次在測試成績上優於原生配置，這一點還是頗為諷刺的，因為 web 負載原本應該是單核性能理應充分發揮的一個場景。幾年前我寫過一篇文章，《移動 CPU 核心數之爭：分析真實使用場景》，不過現如今的情況已經不大一樣的，現在的瀏覽器也已經更偏向多線程。

Galaxy S9 的 Exynos 9810 現有運行機制的一大問題就是用力太過，犧牲了太多多線程性能，換取單線程性能表現。所以我們最終的測試結果自然也並不好看，整體譁啦啦崩塌的節奏。

續航表現提升

最後還得來看看，在我們的設定下，Galaxy S9 的續航表現是否會有提升。

在我們的 web 瀏覽測試中，Exynos 版的 Galaxy S9 續航提升達到 20%，多出 1 小時 23 分鐘，這還是個很不錯的提升。我們對內核做的這次小手術，在較多場景中，尤其是 web 瀏覽，都讓 Exynos 9810 表現出了更好的成績，這更讓我感覺三星本身的機制就有問題。原生內核讓 M3 核心達到更高的頻率，並沒有讓它在真實使用場景中表現出什麼優勢，因為軟體並沒有（而且很可能是不能）合理利用這部分資源。

上面的結果只是 Galaxy S9 內部 Exynos 9810 晶片行為的一個快覽，而且還修改了三星的一些設定。最終的結果還是不錯的，我們最終獲得了現實使用場景的性能表現提升，而且能效和續航也都有提升。

實際上還有很多工作可以做，畢竟我還沒有動過 scheduler 或 DVFS 調節邏輯，不過我相信還可以做得更好。雖然在電池續航方面可能是無法做到驍龍 845 版 Galaxy S9 的程度了，畢竟還是需要考慮到較低性能點的能效曲線，這是無法簡單修改的。不過儘可能彌合其中的差距，還是可行的。

我們尚未得到三星方面的官方評論，不過我覺得未來的固件更新應該會帶來較大程度的提升。但就目前看來，上面的這些結果對普通消費用戶是沒有什麼價值的，也不應作為購買這款手機的參考依據，有這方面需求的同學請參閱 Galaxy S9 和 S9+ 評測文章。

下篇

我們的 Galaxy S9 評測之後，出現了不少有關 Exynos 9810 版 Galaxy S9 性能和電池續航的討論。在最初的評測文章中，我就已經發現了影響性能的一些關鍵因素。在上篇中，我對內核做了一些小改動，在我們的 web 瀏覽電池續航測試中，成績是有好轉的，而且性能方面也有些許提升。

在前篇中，我就發現要提升性能、優化電池續航，其實還有更多的工作可以去做。尤其性能方面在我看來要提升也並不難，這對用戶體驗是有好處的。

專注性能

針對下篇，我嘗試儘可能提升其性能，讓 Exynos 9810 版 Galaxy S9 在性能方面做到與驍龍 845 版相近，同時也還是需要照顧到電池續航問題。

首先，我們繼續上篇中沒有去做的事情，其實也很直接，就是針對 M3 核心移除所有超過 1.8GHz 的頻率，另外禁用在線核心/hotplugging 驅動。

要了解修改方法，可以參考 AnandTech 原文給出的一些連結

在最初的評測中，我就發現，影響手機性能最大的問題，就是設備頻率切換以及線程遷移到大核心的速度非常慢。起先我就提到了，從穩定狀態持續工作負荷，到達到大核心最大頻率，需要大約 410ms。這就和驍龍 845 的 65ms 形成了強烈對比。這其實就是導致 Exynos 9810 交互表現不佳的最重要因素，這自然也成為我們最想修復的問題。

有關 EAS 調度的歷史

這裡值得一提的是，幾年前 ARM 引進 big.LITTLE 架構的最大目標，其實是期望 SoC 供應商以智能的 scheduler 來調度不同架構多核處理器，這種調度器理應會考慮到 CPU 性能和能耗方面的問題。這個目標當然是很好的，但實現這一目標的過程卻充滿崎嶇。ARM 的方案是嘗試在上遊 Linux 內核，或在 Linaro 內核中去實現。悲慘的是，這麼多年對 EAS（能量感知調度，energy aware scheduling）的宣傳，表現在最終的商業設備上都是失敗的。遙想 2015 年驍龍 810，高通在這部分的改動就很不錯，我們先前也撰文提過高通嘗試解決 EAS 相關問題做了哪些事，參見：

歐陽洋蔥：揭開高通驍龍 810 的舊傷疤，你的 Nexus 6P 現在還好嗎？zhuanlan.zhihu.com

跨不同架構 CPU 實現調度的關鍵問題，就在 scheduler 理解某些任務活躍性與負載的能力上，而不是僅僅了解大致的 CPU 使用情況。如果能夠了解個體任務的負載，對於將其放在哪些核心運行，也就有了更好的調度決策。這原本是通過在 Linux 內核中 PELT 機制（Per-entity load tracking）來實現的，用於 HMP 和 EAS 調度的線程遷移決策。

圖片來源：TechInsights

ARM 和 Linux 社區的另一個長期目標是在 scheduler 中集成 CPU 頻率選擇邏輯，而不是將其作為一個單獨的機制。最早這個項目叫 schedfrep，現在完全集成到了一個名為 schedutil 的 governor 裡面。但其具體實現的時間跨度仍需以年來計，我們現在看到的不同代的設備本身也有各種各樣的解決方案。

S.LSI 的 Exynos 晶片在這方面還是比較保守的，Exynos 9810 僅選擇採用 HMP scheduler，以及獨立的交互 CPU 頻率 governor。華為的 Kirin 晶片採用 EAS，華為也轉而採用傳統的交互方案（得到了很不錯的結果）。與此同時，高通進一步拔高了其定製版實施方案，採用另一種名為 WALT（Window-assisted load tracking）的方案，在響應方面比 PELT 要好得多。在驍龍 835 和 845 身上，這都是在調度和 CPU 頻率選擇方面確保最佳性能的核心機制。

調度機制：WALT & PELT

這些年，ARM 其實也意識到了與谷歌方面的配合進度緩慢，所以日趨針對 Android 內核配合更多開發工作，利用內核外（out-of-tree）的修改來促成行動裝置性能和續航方面的提升。高通在這方面也做出了很重要的貢獻，WALT 現如今就已經集成到了 Android 通用內核中。但這方面還有很多工作要開展，其他 SoC 製造商也需要對其平臺做出改進，讓終端設備的表現更出色。

三星 LSI 的現狀似乎有點奇怪。Exynos 9810 是真正採用 EAS 機制的首顆旗艦 SoC，原本是基於 Android 通用內核的 BSP（Board support package）的。問題就在於，三星沒有選擇通過 WALT 來優化 SoC，而轉而完全採用 PELT 任務利用。其實從核心遷移來看，問題也不大，但三星的 schedutil CPU 頻率驅動卻又相當一般。這也就意味著 Exynos 9810 的 CPU 在頻率大幅調節方面，會和 PELT 的某些特性類似，比如集成 PELT 的一大缺陷：相當慢的調節速度。

圖片來源：BKK16-208: EAS圖片來源：WALT vs PELT : Redux – SFO17-307

有關這個問題，做得比較好的一個例子是高通，畢竟他們在這個問題上下了好些年功夫。上面這張圖是在曼谷舉辦的 Linaro Connect 2016 大會上展示的，我們可以從中看到 PLET 和 WinLT（當時叫 WALT）行為方面的可視化差異呈現。具體到 Exynos 9810，可對比的是 util_avg（Galaxy S9 的默認行為），和 WALT 的 ravg.demand，以及其真實的任務執行情況。從 BSP 配置的角度來看，在所有可行的選擇中，三星似乎選擇了對性能而言最差的選項。我覺得三星似乎是故意為之，因為他們針對 scheduler（eHMP）和 schedutil（freqvar）都增加了額外的機制，以期抵消 PELT 所致的低效行為。

為了解決這些，我嘗試從源頭來修復問題，而不是在現有這套系統的基礎上去增加一套邏輯。

我最初用的方案是嘗試啟用 WALT，看看情況如何。針對 Galaxy S9 的 Exynos 9810 啟用 WALT，的確能夠得到很顯著的性能提升，但如此一來電池續航也會變得很糟糕。我之前研究了一下驍龍 845（驍龍版 Galaxy S9）的 scheduler，只是高通針對谷歌的通用內核似乎進行了較大程度的修改，所以如果要移植過來的話，要解決的問題就太多了。我又去研究了一下 Pixel 2 的內核，所幸和三星所用的還比較接近。隨後我就移植了所有 Pixel 2 設備上相關的部分，此外還將 EAS 置於 4.9-eas-dev 分支的 January 版本狀態。這麼做在提升性能的同時還加強了 WALT 的行為方式，但相較原生配置，電池續航問題仍然比較大。於是我又去嘗試其他方法。

來源：LKML Estimate_Utilization (With UtilEst)

從 ARM 的資料來看，他們應該也意識到了其中的性能問題，而且還在很積極地加強 PELT 行為，以期在表現方面令其更接近 WALT。其中一個比較大的變化是名為 util_est（Utilisation estimation）的機制，這是加在 WALT 之上的一個東西，用於 CPU 頻率調整。所以我把這部分做了移植，結果由於更出色的 CPU 頻率狀態利用，其響應能力得到了極大提升。還有一個提升 PELT 機制的簡單方法，就是減少切換遷移的時間（ramp/decay timings），實際上有關這一點，碰巧近期也有了個上遊補丁。所以我也把這玩意兒移植到了內核中，測試設定 8ms 的「半衰期」，發現這麼做對續航也不是很好，又更新為 16ms 設定——相較原生內核為 32ms——這麼設定過後能夠得到最佳性能和相對更小的續航損失。

這種針對 scheduler 的改動幅度非常大，三星方面肯定還不會有類似的調整。我需要儘可能做好適配工作，包括禁用大部分機制，因為絕大部分是沒必要的。另外我還大幅修改了 EAS 性能和 cost table（成本表），我覺得三星填充 table 的方法是不正確的，或者說不能代表真實的功耗使用情況——這其實是個挺悲劇的問題。這個問題其實是我在上篇僅僅通過限制 CPU 頻率，性能就發生優化的原因之一，因為這麼做讓整個性能結構（capacity table）發生了變化，也改變了 scheduler 行為。

當然了，大部分同學想知道的應該並不是上面的這些操作方式，而是最終的結果如何，那我們就來看下結果吧。

性能與續航結果

實際上，Exynos 9810 版 Galaxy S9 的系統性能是個大問題。我們解決 scheduler 和 DVFS 調整的問題之後，就可以來看看基準測試成績了。這裡還是需要說一句，下面這些數據並非設備可獲得的最佳成績，但至少在我看來是平衡性能與續航之後，一個比較合理的配置——畢竟我們能夠為之投入的時間沒有那麼多。

再重申一次：下表中，原版固件 S9（E9810）的得分展示的是原有行為；而 cust.1 則是很單純地把 M3 核心限制到 1794MHz 頻率，並禁用更高的頻率 boost 模式。 Cust.2 則包含我們前文提到的配置方法，對內核進行了更大規模的改動，最高頻率也是 1794MHz。

Cust.3 配置則維持上述所有配置修改方案，但頻率維持在 2314MHz——之所以選擇這個頻率，是因為某些針對內核代碼的研究發現，這可能是這顆 SoC 原本設計時最高的頻率，而且從電壓變化來看，恰巧還是性能/功耗比發生衰變的臨界值。

PCMark 的網頁瀏覽測試 2.0 中，所有定製配置（custom configurations）都得到了成績方面較大的提升。cust.1 的性能飆升是由於切換時，線程傾向大核，更多的工作負載會遷往 M3 核心。而 cust.2 和 cust.3 的成績也比較類似，這兩者的性能提升其實是來自加強的 scheduler 和 DVFS 響應。而將時鐘頻率推高到 2.3GHz 並不會帶來太大的收益，性能提升已經越過效能臨界點，只會讓核心工作更激進，功耗變得更大，續航變差。

我在上篇文章裡就提過，如果針對 cust.1 內核做進一步修改，可以獲得性能的進一步提升。在視頻和寫入測試中，PELT 的改變，外加部分調整，的確相較原版內核有了提升。值得一提的是，2.3GHz 頻率帶來的效益（cust.3），其餘部分是差不多的，但寫入測試在得分方面有較大的領先。我懷疑這是因為 PDF 渲染測試部分對於計算會更敏感，受到 CPU 吞吐較大影響。

Data Manpulation（數據操作）測試未能反應 cust.1 和 cust.2 版本的大差異——這項測試似乎並沒有受到 scheduler 調整的較大影響，得分並沒有發生多大變化。而將頻率推回 2.3GHz（cust.3）則有了比較出色的提升，這和更長時間執行任務和 CPU 性能本身的限制是有關的。

圖片編輯測試項，受到 scheduler 和 DVFS 改造的影響最大。這項測試也終於能夠表現 Exynos 9810 性能糟糕的原因：針對任務量繁重，但持續時間較短的任務，其頻率調節不夠快。在 WALT 機制下，以最激進的設定來測試，跑分至多可以達到 13000，當然了這也會造成功耗的極大提升。

高通似乎也意識到了這個問題，所以他們採用 PCMark 作為其定製版 scheduler 的參考。我很清楚，PCMark 並不能完全代表真實場景的使用情況，而且這個行業對於 PCMark 的關注可能有點太多了。但以我的經驗來看，這應該不是個問題，而且總體而言，我仍覺得 PCMark 是衡量設備表現一個最佳量度。

實際上，cust.2 和 cust.3 對 scheduler 的調整，的確讓 Galaxy S9 在表現上有了很大程度的提升，即便它可能仍然不是市面上響應最出色的設備，但也是其中之一了。針對真實使用場景，其實還有一個可考量的問題——我並沒有對手機的觸控 booster 做出調整。這是針對 SoC 較慢原生行為的一種調整。。。總的來說，WALT 和 PELT 修改的終極目標是徹底避免這類輸入突發機制的需求，並且做到節能。因此，從我的主觀經驗來看，經過調整以後手機變快可能只是暫時的，而且移除輸入（input）booster 也會影響電池優化。這些問題對我們而言，其實也很難進行客觀測試。

補充：我後來仍然嘗試了徹底關閉 input booster，手機依舊錶現不錯。

另外我還想澄清一點，有關設備響應表現的問題，我在使用手機的時候是把過渡動畫關掉的——這能夠提供更快的 UI 體驗。這麼做，其實也能很明顯表現出不同設備間的性能差異，畢竟默認的過渡動畫是可以掩蓋設備響應的真實水平的。

針對 web 跑分，我們採用 SpeedoMeter 2.0。採用我自己的 scheduler 設定之後，這項測試成績提升約為 7%，所以這項測試的重點應該仍在於更直觀的 CPU 表現。將時鐘頻率推回到 2.3GHz，則其成績基本上能夠達到驍龍 845 的水平。

WebXPRT 測試項對於 scheduler 配置也是比較敏感的，所以 cust.2 配置下的成績提升有 10%。這個測試場景下，新版的 PELT 行為則相較 WALT 更出色，前者只能達到 76 分。Cust.2 配置下的成績表現可能已經是其可達到的最理想成績了，畢竟頻率是 1794MHz，追求更高的得分顯然是受到 CPU 確切性能影響的。2.3GHz 下的成績表現也達到了驍龍 845 的水平。

另外我還想說一句，web 測試中的性能水平對 Exynos 而言已經是最高成績了，我不認為更多 scheduler 或軟體優化還會帶來更優的成績。尤其把核心鎖至最高頻率，帶來的收益也不大。

續航

性能和續航的平衡在經過我們的修改過後，自然也成為一個關鍵問題。我嘗試了大量配置方法，但絕大部分的續航表現都是堪憂的。各種軟體優化畢竟還是拗不過物理定律，各種性能提升其實都意味著讓 SoC 以更高的性能狀態執行計算，每個單元需要耗費的能量也越多。

Cust.2 配置帶來了性能的提升，但這是一定程度犧牲續航換來的。在我看來，這種犧牲仍在合理範圍內，對 Exynos 9810 版的 Galaxy S9 也是比較好的配置方案。但把頻率推高到 2.3GHz（cust.3）雖然能令其跑分成績接近驍龍 845，但對續航的影響就明顯比較大了。

原生版本和 cust.3 的對比結果比較有趣：這兩者的續航差不多，都低於 7 小時。但我們前面的測試就提到了 cust.3 配置能夠帶來 25-40% 的性能提升。就看你選擇性能還是續航了。

在上篇中，我沒有測試 PCMark 續航成績，這篇我希望能講得更全面一些。PCMark 的續航測試中，cust.2 和 cust.3 相較原生版本的續航更差，不過如果把前兩者更出色的性能表現考慮進去，實際是差不多的。而且這項測試在 2.3GHz 頻率下的續航犧牲，相比 web 測試更小——PCMark 對於持續工作負載更看重。這項測試沒有類似加載網頁這樣非常重型的任務，所以也不需要 M3 核心持續運作在高頻率下。

總結

寫這篇文章，我是期望去挖掘 Exynos 9810 的潛能的。可以肯定的是，挖掘空間是有的。而且我覺得如果能夠合理配置出 WALT，像驍龍 845 版的 Galaxy S9 或者 Pixel 2 那樣，則其性能和續航方面的提升還會更出色。這部分我自己就不搞了，我們這次嘗試的改造版 PELT 其實成績也已經不錯了。

我發現 M3 與 Kryo 385 核心性能差異，在綜合跑分測試，和部分 web 跑分測試上是不一樣的。在 GeekBench 或 SPEC 測試中，M3 核心只需要 1794MHz 就能達到驍龍之上基於 A75 大核的成績了，但某些 web 跑分測試卻沒能達到理想的成績，除非把頻率推高到 2.3GHz。我覺得主要問題可能不在軟體身上，更多的可能還是 M3 微架構本身的問題。這個問題還是比較大的，畢竟 Android 手機使用場景仍然是有偏向性的。

上面這張表，其實是我對於 性能/功耗 曲線的合理猜測，基於 scheduler 成本表（cost table）、電壓曲線，也基於真實測量的功耗數據統計。最大的問題是，從性能的角度來說，兩個架構的確切位置在那兒。如我們在上篇提到的，M3 核心在和驍龍 845 達到相同性能點的情況下，在諸如 SPEC 這樣的任務負載下，平均是能夠勝出的。但在 web 任務負載中，要達到驍龍 845 的水平，就需要推高頻率了，這樣一來能效曲線就會產生較大偏離。平均應該差不多，ARM 和三星在工作負載偏向性上可能都有自己相對完整的看法。

但毋庸置疑的是，M3 核心在更低頻率狀態下是落後的。在 1170MHz 以後，M3 核心才在電壓方面有所控制——在這個頻率之後，驍龍和 ARM 核心的功耗曲線變得更為陡峭。根據負載任務的差異，兩者的差別也比較大，25% 或 100%。這部分差異幾乎是不可克服，無法通過軟體優化來完成的。

總的來說，Exynos 9810 版 Galaxy S9 面臨兩大阻礙：其一是三星幾乎負優化的 BSP（Board supoort package；內核, 驅動等）（不僅是 S.LSI，三星移動部門可能也是造成這種阻礙的重要原因），尤其盲目追求諸如 GeekBench 這類綜合基準測試成績，造成真實場景使用情況非常糟糕。高通為 S9 準備的驍龍 845 之上的 BSP 就有著很不錯的表現——而 S.LSI 沒能達到同等水平的確是很悲劇的。另外一個阻礙在於，M3 核心本身尺寸似乎有些過大，對功耗要求很大，對於日常工作負載而言無法做到高效運作。最終導致了續航崩塌。對於效率及其性能問題的解決，仍然還有很多工作要做。

參考來源：

Improving The Exynos 9810 Galaxy S9: Part 1

Improving The Exynos 9810 Galaxy S9: Part 2 - Catching Up With The Snapdragon

手機技術資訊(mobile-info)是一個分享手機產品技術的微信公眾號，成立2年以來，每年會發布手機行業技術發展趨勢，同時會聯合志同道合的朋友，分享一些手機及VR/AR/智能穿戴/元器件/材料等方面的相關技術。歡迎大家關注手機技術資訊微信公眾號；

  從2017年2月開始，為了更好的和手機技術資訊的粉絲和讀者交流，我們逐步建立了一系列的粉絲群。

   目前1群為手機產品技術群， 歡迎手機產業鏈產品技術人士加入手機技術圈1群；

3/6/7為手機技術群（前期掃碼後滿100）,8群為銷售群，5群為智能家居群，9群為VR群，10群為IC群。 後續會將3/6/7整合到1群或者重新開闢一個手機技術群。

2群為結構及材料工藝群，如要加群，請向管理員：t806060279申請； 其他西安/上海/深圳/北京/西安/南昌/成都群請聯繫各大管理員加入。

    請注意，入群申請，請提供行業+崗位+地點給管理員（如手機+結構+深圳）。請同時分享一篇公眾號文章到朋友圈，謝謝！

    後續，手機技術資訊會開出更多的微信群，如CAM群，結構群或者其他專業群， 也歡迎在各個領域比較突出的人才願意作為者群助手（或群主，需要一定時間的考驗），共同開闢新的交流群。

註： 文章來源於周三科技，作者歐陽洋蔥，如有侵權，請聯繫lianjie0706刪除，謝謝！