【轉】麒麟9000s大中核規(guī)格對比、初步性能測試

2023-09-02 00:16 作者:小林家的垃圾王R 0人讀過 | 我要投稿

【轉】

麒麟9000s大中核規(guī)格對比、初步性能測試

JamesAslan

喜歡畫畫和攝影的硅工碼農（滑稽）

收起

前言

大核中核規(guī)格對比

性能預覽

SPEC06

SPEC17

Coremark

Verilator

超線程（SMT）

測試平臺

前言

鑒于許多人的詢問和關心，我們提前放出了部分初步測試結果，用以詳細刻畫9000s使用的TSV new（？）微架構的技術細節(jié)。

大核中核規(guī)格對比

麒麟9000s的中核相較大核有一定程度的閹割降級。主要集中于最大頻率、L2 Cache容量、浮點流水線規(guī)模、亂序隊列規(guī)模方面。以下數(shù)據為初步probe結果，在手動細測后會有所變動，請注意。

從頻率上來看，中核最大頻率為～2GHz，大核最大頻率為～2.61GHz。

流水級寬度TSV110TSV new(middle)TSV new(big)Cortex A78Fetch(ICache)4664Fetch(mop Cache)N/AN/AN/A6Decode4664Rename4666

從主流水線寬度上來看，大核中核是一致的，他們大概率是同源微架構。整個海思微架構家族沒有使用mop cache的跡象,至少mop cache沒有被用于提升供指帶寬。

執(zhí)行部件數(shù)量TSV110TSV new(middle)TSV new(big)Cortex A78ALU3444BRU2222MUL1222AGU(ld+st)2443AGU(ld)2223AGU(st)1222FPU2242FADD2222FMUL2242FMA2222

從執(zhí)行單元規(guī)格上來看，中核閹割了浮點側規(guī)格，屬于意料之中。TSV new展現(xiàn)出了與前作TSV110完全不同的單元配置，整數(shù)側ALU、MUL單元有所增長；浮點側的寬度大幅增加，延遲大幅降低。TSV new也與A78完全不同，其AGU風格為intel式的load、store全分離，而非ARM慣用的組合式。

Cache容量TSV new(middle)TSV new(big)L1I64KB64KBL1D64KB64KBL2512KB1MBL3 (shared)4MB4MBSLC (shared)4MB4MB

從Cache規(guī)格上來看，中核縮小L2容量情理之中。9000s的L3容量過小是一大遺憾，會嚴重影響整數(shù)側的性能表現(xiàn)，限制了TSV new發(fā)揮其全部潛力。

TSV110TSV new
(middle)TSV new
(big)Cortex A78Cortex X1ROB~92*n(coalesced ROB)～224~240~160~216PRF(integer)~140~160~192~160~184PRF(float)~96~160~192~92~152DispatchQ+IssueQ(fix)~36~64~72~56~64DispatchQ+IssueQ(float)~28~56~56~48~56LDQ~48~78~128~64~80STQ~32~54~72~48~60

從亂序隊列規(guī)模上來看，中核有所縮減。不過TSV new相較前代有了大幅增長，規(guī)模更接近Cortex X系列。不過較為遺憾的是，TSV110上coalesced ROB的設計巧思似乎沒有延續(xù)。由于暫時沒有去探究TSV new是否真實啟用了SMT以及SMT的具體策略，此處容量存在誤差，僅供參考。LDQ與STQ容量均未減去相關發(fā)射隊列容量。ISQ容量測試時默認使用了非intel風格的probe模式。話說回來，TSV new的LDQ容量大得驚人，可能使用了什么特殊的優(yōu)化提升了等效容量。受限于本人精力，各種隊列的準確容量和分布方式我們就留到以后再去探究吧。

性能預覽

在這一部分我們使用SPEC06、SPEC17、Coremark以及Verilator對處理器進行測試。注意，我們并不執(zhí)著于fine-tune以獲得某一微架構的最高分數(shù)；而是以合理、統(tǒng)一的編譯參數(shù)帶來可比的分值數(shù)據。SPEC06、SPEC17等的分值受系統(tǒng)環(huán)境、編譯器版本、編譯參數(shù)、BIOS調教、頻率穩(wěn)定性、具體SKU的Cache配置、具體平臺的內存參數(shù)等因素影響巨大，且無法通過任何簡單線性縮放進行分數(shù)推演。

我們首先總覽TSV new在各種微架構中的位置：

SPEC06

SPEC06是已經退役的SPEC測試集但是仍然被廣泛使用；其負載特性與SPEC17并不相同，因此仍然具有相當?shù)臏y試價值。

編譯環(huán)境：GCC12.0 -Ofast -static ? ? ? ?GLIBC 23.5-0

TSV new的fp成績遠高于int成績。由于浮點程序訪存行為較為容易預取，SPEC06int相較fp對L3容量更敏感，倘若能夠增大L3 Cache（如16MB），個人估計同頻下SPECint成績能夠提升15+%，其中受L3容量影響較大的子項應該是401、403、429、471、473、483。浮點側受到的影響相對小，預計436、450、470、482受到了可觀的負面影響。

TSV new在部分重訪存代寬的子項中表現(xiàn)優(yōu)秀，如462、410、433、434、437、447、450、459、470、481，表明了其配備了精細調節(jié)過的訪存子系統(tǒng)（包括內存控制器和數(shù)據預取器等）。462.libquantum與470.lbm分數(shù)較高表明TSV new配備了較好的stream/stride預取器；而462.libquantum想要更進一步則需要更大的L3 Cache容量（如>20MB）。433.milc成績離當前的第一梯隊有一定距離，表明delta模式預取可能仍然存在進步空間。由于Cache容量過小，這些分析的噪聲較大；如429.mcf受L3容量影響極大，我們無從剝離分析預取表現(xiàn)。483.xalancbmk相較TSV110提升寥寥，很可能是L3 Cache過小的緣故，但同樣不能排除面對短流時預取器的無效操作過多。471.omnetpp的表現(xiàn)似乎表明TSV new沒能克服激進預取帶來的污染和擁塞問題。

總體而言TSV new取得了長足的進步。在本節(jié)我們同時列出了手機、PC平臺的A78的表現(xiàn)，可見平臺對微架構的性能的影響；因此TSV new在可能的鯤鵬930上才能發(fā)揮出其全部實力。

SPEC17

SPEC17是現(xiàn)役的SPEC測試集，被廣泛用于微結構性能評估。

編譯環(huán)境：GCC12.0 -O3 -static ? ? ? ?GLIBC 23.5-0

總體而言中核相較大核性能衰減較大，但是這主要來自于頻率的大幅下降，倘若我們計算IPC性能會發(fā)現(xiàn)中核的縮水較為有限。盡管頻率處于劣勢，但是中核仍然在總性能中超越了前代產品TSV110；如果有更好的下級memory system支持，中核恐怕也能夠超越全規(guī)格的TSV110。盡管受限于有限的memory system規(guī)格，TSV new仍然保持著對A78的性能優(yōu)勢，這讓我更為期待可能的滿血版本了。

Coremark

由于其他測試耗時較長，我們首先放出coremark的成績。Coremark是一款嵌入式基準測試程序，其受下級Cache子系統(tǒng)、內存等的影響極小，主要考察核內流水線以及L1 Cache的性能表現(xiàn)。

可見TSV new成功邁入了9分大關，符合我們對一款現(xiàn)代6發(fā)射處理器的基本期待，但是時至2023年，這樣的成績算不上優(yōu)秀，6發(fā)射的上限遠不止于此，期待后續(xù)產品的迭代。

Verilator

以上三款測試集對處理器的前端壓力較小，仿真大規(guī)模設計的verilator則恰恰相反，海量的分支與數(shù)MB的代碼足跡能夠輕松壓垮ICache、BTB等組件，導致巨大的性能下降。

由于手機環(huán)境的限制，我們完整仿真環(huán)境中的部分組件無法運行，裁切部分組件并削減仿真規(guī)模后得到了Verilator_lite測試。注意：

Verilator_lite測試的成績與Verilator測試的結果不能直接比較。
我們也會在桌面平臺上運行Verilator_lite測試以提供參照，請留意圖表標題是Verilator_lite還是Verilator。
在同一圖表中僅會出現(xiàn)Verilator_lite或Verilator成績中的一種，不會有數(shù)據混雜。

TSV110表現(xiàn)過差不予展示（各位自行腦補一個突破天際的柱子）。TSV new在前端供指方面取得了長足的進步，這是部分服務器負載十分看重的性能指標，因此對于可能的鯤鵬930十分重要。盡管頻率極低，TSV new仍然能保持與ARM公版最新的產品接近的成績。可以預計倘若配備了2顆2.8GHz的TSV new，在verilator中它們的表現(xiàn)將超過A715。不過本人還在糾結TSV new到底有沒有使用decoupled frontend設計，有沒有大神知道其中的真相呢23333。

超線程（SMT）

在ubuntu中雖然我們可以調用額外的線程號，但是從core-to-core latency的測試來看并沒有超線程跡象。這里有兩種可能：

我們使用的ubuntu中的API沒有真正成功綁定8-11號核，導致我們仍然在0-7號核上執(zhí)行，致使沒有觀測到sibbling核間超低的臟數(shù)據交換延遲。那么我們只能等待其他大佬真正適配SMT了。
TSV new使用了特殊的設計，保證了sibbling線程間更強的數(shù)據一致性，使得所有數(shù)據交換都下探到了L3層級。