Apple M1 Icestorm微架構(gòu)評(píng)測(cè)（上）:重鑄小核榮光

JamesAslan喜歡畫(huà)畫(huà)和攝影的硅工碼農(nóng)（滑稽）Luv Letter?等?

前言

M1的橫空出世可謂徹底改變了消費(fèi)級(jí)市場(chǎng)的格局，憑借極高的性能和極低的功耗，Apple sillion在手機(jī)之外的移動(dòng)端開(kāi)疆?dāng)U土。拋開(kāi)生態(tài)問(wèn)題，同期生AMD Zen3和Intel Sunnycove與之相比簡(jiǎn)直乏善可陳，Arm公版更是相形見(jiàn)絀；究其根本，M1這股新風(fēng)仿佛讓我們看到了海的彼岸，讓身陷x86頻率競(jìng)賽的世界看到另一種可能。 M1大核微架構(gòu)Firestorm堪稱(chēng)蘋(píng)果大核心寬發(fā)射路線(xiàn)的集大成之作，讓Arm架構(gòu)無(wú)法勝任高性能的說(shuō)法不攻自破，將體系結(jié)構(gòu)Brainiac與Speed Demon的世紀(jì)之爭(zhēng)帶入了嶄新的維度。在Firestorm的光芒下小核Icestorm往往為人所忽視，然而Icestorm對(duì)M1的成功不可或缺；與羸弱的A55、A510不同，其能夠很好地勝任系統(tǒng)任務(wù)、后臺(tái)任務(wù)，提供良好體驗(yàn)的同時(shí)保持極低的功耗。我們這次就來(lái)探究Icestorm的微架構(gòu)。

基準(zhǔn)測(cè)試

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

頻率

我們使用的平臺(tái)是Apple Mac mini M1；處理器為Apple M1。在Arch Linux下其小核icestorm穩(wěn)定運(yùn)行頻率為2.05GHz，以下的測(cè)試都基于2.05GHz的頻率進(jìn)行。

SPEC06

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

我們選取了A76、A78這兩款處理器作為參考對(duì)象，因?yàn)榛ヂ?lián)網(wǎng)上常有A76與Icestorm孰強(qiáng)孰弱的討論。在絕對(duì)性能上Icestorm全面落后于A76、A78，但是從IPC上來(lái)看Icestorm強(qiáng)于A76弱于A78。由于蘋(píng)果目前特殊的核心簇互聯(lián)設(shè)計(jì)，Icestrom先天受制于E核簇較小的可訪問(wèn)L2 Cache規(guī)模，在部分子項(xiàng)上無(wú)法發(fā)揮全部實(shí)力。但是從462、429子項(xiàng)來(lái)看，Icestorm配備了相當(dāng)強(qiáng)悍的數(shù)據(jù)預(yù)取器，一定程度上彌補(bǔ)了Cache子系統(tǒng)容量的不足。從400子項(xiàng)上來(lái)看，Icestorm的間接跳轉(zhuǎn)預(yù)測(cè)器還有較大的進(jìn)步空間，主預(yù)測(cè)器容量也遇到了瓶頸，0.91%的分支誤預(yù)測(cè)率高于當(dāng)代所有Arm、X86競(jìng)品。出于定位考量Icestorm相對(duì)不擅長(zhǎng)浮點(diǎn)，IPC與A76相近。當(dāng)然這里的對(duì)比有些越級(jí)的意味，從自身定位角度看Icestrom的成績(jī)可圈可點(diǎn)。

SPEC17

SPEC17是現(xiàn)役的SPEC測(cè)試集，被廣泛用于微結(jié)構(gòu)性能評(píng)估。

SPEC17測(cè)試中，三款處理器的相對(duì)結(jié)論并沒(méi)有變化，只是Icestorm相對(duì)A76不再具有綜合IPC優(yōu)勢(shì)。實(shí)際上SPEC17測(cè)試集相對(duì)SPEC06測(cè)試集對(duì)數(shù)據(jù)預(yù)取的敏感度更低，換言之Icestorm較小的L2 Cache容量會(huì)成為更加明顯的瓶頸。此處也不得不稱(chēng)贊ARM Cortex A系列的演進(jìn)，A78相較A76的提升十分全面，在幾乎所有子項(xiàng)上都有正向提升而非“取舍的藝術(shù)”。

Coremark

Coremark是一款嵌入式基準(zhǔn)測(cè)試程序，其受下級(jí)Cache子系統(tǒng)、內(nèi)存等的影響極小，主要考察核內(nèi)流水線(xiàn)以及L1 Cache的性能表現(xiàn)。

Icestorm受制于較弱的后端執(zhí)行單元規(guī)格，落后于其他兩款CPU。雖然Icestorm是一款4發(fā)射處理器，但是僅配備了3組ALU單元，這對(duì)coremark的影響是巨大的；其偏弱的前端取指能力更是雪上加霜。

Verilator

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

在這一項(xiàng)目中，盡管Icestrom頻率最低但仍然勝出。采用分離式前端的A78與Gracemont受制于較小的前端規(guī)模，發(fā)生了海量的BTB miss；采用傳統(tǒng)設(shè)計(jì)的Icestorm則將ICache視為下級(jí)BTB，因此取指效率更好。但是這樣的設(shè)計(jì)在線(xiàn)程數(shù)增加后上限較低(參看下圖，引入了Zen4作為對(duì)比)；不過(guò)受限于蘋(píng)果目前的核心簇互聯(lián)設(shè)計(jì)，即便有配備了8個(gè)Icestorm的型號(hào)也無(wú)法獲得可以參考的性能縮放數(shù)據(jù)。

前端

隨著現(xiàn)代程序體量的膨脹，處理器面臨越發(fā)巨大的前端壓力；為了應(yīng)對(duì)巨大的程序代碼段帶來(lái)的海量跳轉(zhuǎn)指令，大部分高性能處理器核心的BTB容量、分支預(yù)測(cè)器容量不斷擴(kuò)展，分支預(yù)測(cè)算法不斷演進(jìn)。

BTB

對(duì)于采用了分離式前端（用英文表述decoupled branch prediction更為準(zhǔn)確）的設(shè)計(jì)而言，BTB是前端的絕對(duì)核心組件；其負(fù)責(zé)在譯碼之前識(shí)別指令流中的跳轉(zhuǎn)指令，并提供相應(yīng)的跳轉(zhuǎn)地址。過(guò)于頻繁的BTB miss會(huì)造成嚴(yán)重的性能損失。但是Icestorm并沒(méi)有采用當(dāng)今更為普遍的分離式前端，其只有一級(jí)主BTB。

可見(jiàn)，Icestorm的L1 BTB容量為1024項(xiàng)，組相聯(lián)。對(duì)現(xiàn)今的分離式前端設(shè)計(jì)而言，這樣的BTB配置并不算大；不過(guò)對(duì)于傳統(tǒng)前端設(shè)計(jì)這樣的容量也算正常。決定BTB性能的遠(yuǎn)不止有效容量，其吞吐率、預(yù)測(cè)速度也十分重要。Icestorm并不支持每周期2 taken分支，不及A78和Intel的新產(chǎn)品12代、13代酷睿（GoldenCove等）；在面對(duì)密集taken跳轉(zhuǎn)代碼塊時(shí)Icestorm的表現(xiàn)會(huì)遠(yuǎn)遠(yuǎn)落后，但是這樣的場(chǎng)景并不那么常見(jiàn)。

當(dāng)分支數(shù)量超過(guò)1024后，圖像變得混亂，即延遲波動(dòng)十分巨大。此時(shí)Icestorm的L1 BTB已然失效，需要從ICache中取指并預(yù)譯碼才能獲得分支指令信息，進(jìn)而修正執(zhí)行流；這帶來(lái)了巨大的延遲損失，也是傳統(tǒng)非分離前端設(shè)計(jì)的弊端。但是這樣的設(shè)計(jì)也非沒(méi)有優(yōu)點(diǎn)，借助巨大的ICache，Icestorm無(wú)需配備獨(dú)立的巨大下級(jí)BTB，省下了寶貴的片上空間并減少了功耗。尤其是對(duì)于低定位的處理器，其BTB容量一般會(huì)受到削減，分離式前端的效果也會(huì)有所折扣（面對(duì)前端壓力大的負(fù)載時(shí)尤為明顯）；從verilator benchmark中我們也可以看到Icestorm在同定位處理器中的顯著性能優(yōu)勢(shì)。

RAS

指令流中的call、return調(diào)用是較為特殊的分支指令情況，其棧形式的特征催生了專(zhuān)門(mén)用于預(yù)測(cè)此類(lèi)場(chǎng)景的RAS（Return Address Stack）。簡(jiǎn)而言之，call指令壓棧，return指令彈棧；而硬件棧（RAS）結(jié)構(gòu)的深度就影響了處理器在復(fù)雜函數(shù)調(diào)用場(chǎng)景中的性能表現(xiàn)。

可見(jiàn)Icestorm的RAS容量為32項(xiàng)，對(duì)于小核而言這個(gè)深度極大，甚至比肩了X86桌面型號(hào)。可見(jiàn)蘋(píng)果對(duì)于RAS的理解與ARM公版有一定的差異。至于圖像的鋸齒與波浪則反映了RAS溢出后其自恢復(fù)機(jī)制，此中的細(xì)節(jié)不在本專(zhuān)欄討論；不過(guò)至少I(mǎi)cestorm配備了有效的自恢復(fù)機(jī)制，優(yōu)于公版A78。

RAS CapacityIcestorm32A7816Gracemont2？(甚至可能沒(méi)有傳統(tǒng)意義的RAS)Zen432

BP

分支預(yù)測(cè)器是當(dāng)代高性能處理器前端中的又一核心組件，負(fù)責(zé)在流水線(xiàn)早期給出分支指令跳轉(zhuǎn)與否的猜測(cè)，引導(dǎo)指令流的方向。在推測(cè)執(zhí)行的超標(biāo)量處理器中，分支預(yù)測(cè)器的準(zhǔn)確率會(huì)極大影響處理器的性能和能效表現(xiàn)。

本測(cè)試考察分支預(yù)測(cè)器在不同歷史pattern長(zhǎng)度、不同分支數(shù)量（需要預(yù)測(cè)）情況下的準(zhǔn)確性表現(xiàn)。Icestorm的分支預(yù)測(cè)器展現(xiàn)出了完全不同于A78的特性。

• Icstorm分支預(yù)測(cè)器的等效有效容量甚至超過(guò)了A78，無(wú)論是在分支較少還是分支較多時(shí)，Icestorm都能追蹤更長(zhǎng)的歷史。

• Icestorm的分支預(yù)測(cè)器有較明顯的Cascading特征。當(dāng)分支歷史超過(guò)一定長(zhǎng)度后上級(jí)預(yù)測(cè)器的準(zhǔn)確率下降，下級(jí)預(yù)測(cè)器開(kāi)始接管，導(dǎo)致延遲小幅增長(zhǎng)。下級(jí)預(yù)測(cè)器接管時(shí)取指流水線(xiàn)容易出現(xiàn)空泡，降低前端吞吐量；因此盡管Icestorm分支預(yù)測(cè)器的等效有效容量大于A78，實(shí)際表現(xiàn)可能反而不及。

總體而言Icestorm的分支預(yù)測(cè)器十分魯棒，考慮到其自身定位就更為驚艷了。

IJP

IJP（Indirect Jump Predictor）作為BP（Branch Predictor）的一部分，負(fù)責(zé)預(yù)測(cè)間接跳轉(zhuǎn)的地址。與預(yù)測(cè)跳轉(zhuǎn)與否的BP不同的是，IJP需要在多個(gè)可能的跳轉(zhuǎn)目標(biāo)中選擇本次的跳轉(zhuǎn)目標(biāo)，并引導(dǎo)指令流。

首先考察Icestorm IJP在不同歷史pattern長(zhǎng)度（但是可能目標(biāo)均只有2個(gè)）、不同間接跳轉(zhuǎn)數(shù)量（需要預(yù)測(cè)）情況下的準(zhǔn)確性表現(xiàn)。Icestorm的IJP表現(xiàn)出了與BP不一樣的特性，在間接跳轉(zhuǎn)預(yù)測(cè)方面能力弱了許多，甚至不及A78。

• Icestorm的IJP無(wú)法追蹤較長(zhǎng)的歷史，在256后即丟失了預(yù)測(cè)能力。當(dāng)然此處不是指其能夠追蹤256bit長(zhǎng)的歷史，而是通過(guò)與BP的數(shù)據(jù)對(duì)比可以看出其要么單獨(dú)使用了較短的分支歷史；要么是每條間接跳轉(zhuǎn)指令需要在歷史中占據(jù)較多的bit數(shù)，進(jìn)而導(dǎo)致追蹤能力變?nèi)酢?/p>

• Icestorm的IJP同樣有一定的Cascading特征。當(dāng)分支歷史超過(guò)一定長(zhǎng)度后上級(jí)預(yù)測(cè)器的準(zhǔn)確率下降，下級(jí)預(yù)測(cè)器開(kāi)始接管，導(dǎo)致延遲小幅增長(zhǎng)。

• 由于測(cè)試代碼PC是2的冪次對(duì)齊，Icestorm的IJP在某些排布下似乎出現(xiàn)了hash沖突，導(dǎo)致行為不符合規(guī)律。

• 當(dāng)分支數(shù)量超出256后，Icestorm的IJP基本丟失了預(yù)測(cè)能力，其IJP表項(xiàng)的數(shù)量應(yīng)該是偏少的。

不過(guò)考慮到間接跳轉(zhuǎn)指令在一般程序指令流中占比較少，Icestorm這樣的取舍是也是可以理解的。

接下來(lái)，考察Icestorm IJP在不同可能跳轉(zhuǎn)目標(biāo)、不同間接跳轉(zhuǎn)數(shù)量（需要預(yù)測(cè)）情況下的準(zhǔn)確性表現(xiàn)。可見(jiàn)Icestorm IJP的表現(xiàn)十分糟糕，僅在最基本情況（2個(gè)可能的間接跳轉(zhuǎn)目標(biāo)）下能夠較快處理間接跳轉(zhuǎn)；一旦可能目標(biāo)增多延遲立即退化。在這樣的場(chǎng)景下Icestorm IJP使用的歷史似乎已經(jīng)短到不可思議，難以有效應(yīng)對(duì)哪怕是分支數(shù)量極少且pattern歷史也不長(zhǎng)的情形，這里有多種可能性：

1. IJP自身的表項(xiàng)容量被配置得極少，也許蘋(píng)果眼中corner case下的間接跳轉(zhuǎn)性能并不重要。

2. IJP使用的全局歷史十分短，或間接跳轉(zhuǎn)目標(biāo)地址占據(jù)了過(guò)多歷史bit，使得等效歷史長(zhǎng)度變短。

3. IJP使用的歷史中沒(méi)有混合間接跳轉(zhuǎn)目標(biāo)地址bit。

此中的細(xì)節(jié)留到之后在隔壁專(zhuān)欄深入探究。

ITLB

TLB是現(xiàn)代處理器中容易被忽視的一個(gè)部件，其負(fù)責(zé)虛擬地址至物理地址的翻譯。在一般情況下TLB并不會(huì)成為瓶頸，但是隨著現(xiàn)代程序體量的膨脹TLB承受的壓力也與日俱增，這一點(diǎn)在服務(wù)器負(fù)載中尤為明顯。蘋(píng)果本身并不將Apple sillion推向服務(wù)器市場(chǎng)，且MacOS原生使用16KB頁(yè)（對(duì)TLB的壓力天然減?。?，也許并未對(duì)TLB做過(guò)多優(yōu)化。

Icestorm的ITLB容量為32項(xiàng)，取指時(shí)可以訪問(wèn)的L2 TLB容量為256項(xiàng)。其ITLB容量、L2 TLB容量均小于A78；在一般用戶(hù)程序中這樣的TLB規(guī)模并不會(huì)成為瓶頸。不過(guò)需要注意的是訪問(wèn)延遲的上漲點(diǎn)較為靠前，也許預(yù)示著某種特殊的替換算法或初級(jí)的TLB預(yù)取。

取指

處理器對(duì)程序的執(zhí)行始于取指，前端的指令供給能力至關(guān)重要；一旦前端無(wú)法提供足夠的指令，縱使后端的亂序執(zhí)行能力再?gòu)?qiáng)也無(wú)力回天。對(duì)于Icestorm這樣的四發(fā)射處理器，我們期望其每周期能夠取指至少4條指令。

與主流（之前的ARM自研玩家為ARM公版、蘋(píng)果、三星）不同，Apple對(duì)mop cache并不感興趣，因此Icestorm也沒(méi)有配備mop cache。我們可以看到指令足跡在128KB以?xún)?nèi)時(shí)由ICache供指，取指帶寬為4條/周期；這樣的帶寬在分支較少時(shí)是完全夠用的，但是無(wú)法與配備了mop cache的處理器比肩（例如A78的mop cache供指帶寬為6條/周期）。出人意料的是，即便是小核心蘋(píng)果也為之配備了128K的ICache，實(shí)屬奢華。當(dāng)執(zhí)行流來(lái)到L2 Cache以后取指帶寬驟然下降至2條/周期，可能預(yù)示著ICache較小的Refill通路位寬；相對(duì)得，A78的L2 Cache取指帶寬相較ICache取指帶寬并未嚴(yán)重下滑，仍然保持著～3.4條/周期的良好表現(xiàn)。與A78類(lèi)似的是，Icestorm也似乎有意限制了代碼段可以占據(jù)到L2 Cache（對(duì)于Icestorm已經(jīng)是LLC）的容量，指令只能使用到一半左右的空間，而X86陣營(yíng)并沒(méi)有這類(lèi)限制。當(dāng)指令流進(jìn)入SLC與內(nèi)存段后取指帶寬徹底雪崩，僅剩0.5條/周期或更低。

A78的mop Cache對(duì)于nop指令進(jìn)行了壓縮優(yōu)化；倘若使用nop指令測(cè)試取指，mop cache每周期能夠供給超過(guò)10條指令；Icestorm沒(méi)有配備mop cache，自然也沒(méi)有此類(lèi)優(yōu)化。

后端

處理器的后端負(fù)責(zé)指令的執(zhí)行，當(dāng)代高性能處理器普遍配備了亂序超標(biāo)量機(jī)制，后端的設(shè)計(jì)也是紛繁復(fù)雜。

流水線(xiàn)寬度

在超標(biāo)量處理器中我們著重關(guān)注前端與mid-core部分的寬度。

流水級(jí)寬度Fetch(ICache)4Fetch(mop Cache)no mop CacheDecode4Rename4

Icestorm能夠提供的最大取指帶寬為4條指令/周期，后續(xù)的重命名級(jí)與譯碼級(jí)和取指寬度一致，因此Icestorm是最大吞吐為4條指令/周期的典型4發(fā)射處理器核。

執(zhí)行單元

執(zhí)行部件數(shù)量延遲ALU31BRU2MUL13DIV119（支持提前退出）AGU(ld+st)2AGU(ld)24AGU(st)1FPU2FADD23FMUL24FDIV19FMA24

Icestorm只配備了3個(gè)ALU單元，不禁讓人聯(lián)想起A76，同樣是4發(fā)射的A76也只配備了3組ALU（在隨后的A77中補(bǔ)齊為4組）。簡(jiǎn)單ALU并不占據(jù)過(guò)多的面積，難度來(lái)自于物理寄存器堆讀寫(xiě)端口的設(shè)計(jì)，這在更寬的處理器上會(huì)更加棘手，也許蘋(píng)果出于控制寄存器堆復(fù)雜度的角度才縮減了ALU配置。Icestorm配備了2組BRU，在密集跳轉(zhuǎn)應(yīng)用中能夠保證吞吐量，符合現(xiàn)代應(yīng)用程序發(fā)展的趨勢(shì)；配備2組BRU已經(jīng)成為當(dāng)今處理器核設(shè)計(jì)的趨勢(shì)。乘除法單元上，Icestorm只配備了1組；其乘法器延遲較大，除法器算法也較為普通；除法器支持提前退出，當(dāng)被除數(shù)變?yōu)?時(shí)算法可以提前結(jié)束。

Icestorm擁有2個(gè)AGU（訪存地址生成單元），但是AGU load與AGU store并非分離式設(shè)計(jì)；2個(gè)AGU中1個(gè)支持load/store操作，1個(gè)只支持load操作。對(duì)于一款4發(fā)射處理器而言，這樣的訪存單元配置較為標(biāo)準(zhǔn)，但是與其他4發(fā)射處理器相比略微偏小，畢竟有一組AGU為load store共用。在memory wall越發(fā)明顯的趨勢(shì)下，重訪存也是我個(gè)人十分欣賞的設(shè)計(jì)哲學(xué)；但是我個(gè)人更喜歡Intel式的AGU load與AGU store分離的設(shè)計(jì)，不過(guò)這也會(huì)顯著增加發(fā)射隊(duì)列、物理寄存器堆設(shè)計(jì)的復(fù)雜度，恐怕這也是Arm與蘋(píng)果都未完全分離load與store AGU的原因?；氐絀cestorm上，沒(méi)有配備第二個(gè)AGU store屬實(shí)有些意外；客觀上鑒于Icestorm的定位是不需要第二個(gè)AGU store的，但是蘋(píng)果本可以使用相同的AGU單元減少重復(fù)設(shè)計(jì)。也許這樣的偏執(zhí)就是Icestorm能效比超高的秘密吧。

由于Icestorm的定位其只配備了兩組浮點(diǎn)流水線(xiàn)。其FMADD延遲較低僅需4周期，F(xiàn)ADD延遲表現(xiàn)一般需要3周期；考慮到Icestorm本身的目標(biāo)頻率也較低，這樣的成績(jī)較為平庸。與Arm公版（A78）不同的是，Icestorm的FMA單元不能支持較快的獨(dú)立FADD操作，F(xiàn)MUL也似乎直接使用了FMA的流水線(xiàn)，蘋(píng)果對(duì)于不重視的部分也拋棄得很徹底。FDIV的延遲較低。

總體而言Icestorm的后端執(zhí)行單元配置偏重整數(shù)和分支，弱浮點(diǎn)向量，訪存堪堪夠用。

幕間

在下篇中我們將對(duì)Mid-core、訪存子系統(tǒng)、核外系統(tǒng)進(jìn)行逆向探究。

分析與測(cè)試：lyz、lxy

編輯于 2023-03-04 16:28

幕間

在上篇中我們主要探究了Icestorm微架構(gòu)的取指前端和后端執(zhí)行單元配置，下篇我們繼續(xù)探究Mid Core、訪存子系統(tǒng)、核外系統(tǒng)。

JamesAslan：Apple M1 Icestorm微架構(gòu)評(píng)測(cè)（上）:重鑄小核榮光123 贊同 · 13 評(píng)論文章

Mid Core

重命名消除

在實(shí)際應(yīng)用程序中許多指令并不需要進(jìn)入處理器后端被真正執(zhí)行（如move指令）；現(xiàn)代處理器普遍配備了各式各樣的重命名消除機(jī)制，以減少處理器后端壓力并加速程序執(zhí)行。

Elimination typeThroughputmove imm zero3move imm one4move chain1.2move single4move self4move bounce1.2sub self1xor self1

Icestorm配備了基本的重命名消除機(jī)制，優(yōu)于A78之流，但是與X86競(jìng)品相比仍較為落后。X86處理器傾向于配備極強(qiáng)的重命名消除機(jī)制，可能源自于其寄存器數(shù)相對(duì)較少的歷史包袱。較為奇特的是，move置0似乎沒(méi)有被特別消除，但是move置較小的立即數(shù)卻被特別消除了，這是之后可以深入探究的一點(diǎn)。Icestorm的重命名可以消除不相關(guān)的move，但是不能在同一周期內(nèi)處理move相關(guān)鏈；這樣的取舍可以理解，一方面是在真實(shí)應(yīng)用中這樣的場(chǎng)景較少；另一方面是Icestorm流水線(xiàn)可能偏較短，支持相關(guān)鏈重命名會(huì)給重命名級(jí)帶來(lái)巨大的時(shí)序壓力。

• move imm zero(mov x10, #0)吞吐為3說(shuō)明重命名并未對(duì)置立即數(shù)0進(jìn)行消除。

• move imm one(mov x10, #1)吞吐為4說(shuō)明重命名時(shí)對(duì)置立即數(shù)1進(jìn)行了消除，因?yàn)槠鋬H有3個(gè)ALU。

• sub與xor均未對(duì)置0情況進(jìn)行特別優(yōu)化，可能是ARM ISA的編譯器極少進(jìn)行此類(lèi)操作；X86處理器普遍配備此類(lèi)優(yōu)化。

• move single（非相關(guān)的move消除）等的吞吐為4，超過(guò)了ALU數(shù)量（因此move并未由后端真正執(zhí)行），說(shuō)明其具備基本的重命名消除機(jī)制。

• move bounce與move chain等的吞吐為1.2，說(shuō)明后端出現(xiàn)了數(shù)據(jù)相關(guān)或前端重命名吞吐量下降，無(wú)論如何均表明未被重命名消除。

亂序資源

亂序推測(cè)執(zhí)行的處理器需要海量的隊(duì)列空間來(lái)跟蹤指令，確保指令最終的提交順序正確。

IcestormA78ROB~108~160PRF(integer)~108~160PRF(float)~112~92PRF(conditional bit/flag)~36~44

如果說(shuō)ARM的A78貫徹了中核的定位采用了小而美的設(shè)計(jì)，那么Apple的Icestorm則將“節(jié)儉”推向了極致。不過(guò)Icestorm的數(shù)據(jù)不能與A78進(jìn)行直接橫向?qū)Ρ?，因?yàn)镮cestorm使用了與其他處理器核有較大差異的基礎(chǔ)結(jié)構(gòu)。

• Icestorm的ROB表項(xiàng)可以存儲(chǔ)多條指令但是存在一定的限制，如：只能有一條指令發(fā)生回滾，具體機(jī)制仍需精細(xì)試驗(yàn)刻畫(huà)。

• 由于上述ROB設(shè)計(jì)，Icestorm的PRF相對(duì)ROB并非簡(jiǎn)單的超額或足額，只能說(shuō)較為均衡。

• Icestorm的重命名信息有單獨(dú)表項(xiàng)存儲(chǔ)，并非存儲(chǔ)在ROB中，該表項(xiàng)的大小為約108項(xiàng)；從這一角度來(lái)看Icestorm的PRF是足額的。

雖然提供了足額的浮點(diǎn)物理寄存器堆，但受制于浮點(diǎn)執(zhí)行單元的性能限制，Icestorm的浮點(diǎn)性能表現(xiàn)并不優(yōu)秀。由于ARM ISA定義了Conditional Bits，該結(jié)構(gòu)也支持重命名操作，其容量在36項(xiàng)左右。本專(zhuān)欄提及A78的Mop Cache和ROB對(duì)Nop指令進(jìn)行了特殊優(yōu)化（每個(gè)mop cache項(xiàng)和ROB項(xiàng)可以存儲(chǔ)多條Nop指令）；Icestorm的ROB也對(duì)Nop指令進(jìn)行了優(yōu)化：

使用精心配比的非Nop指令占滿(mǎn)ROB時(shí)得到下圖：

亂序推測(cè)執(zhí)行的處理器最為直接的調(diào)度窗口由各級(jí)發(fā)射隊(duì)列的容量決定：

IcestormA78IssueQ+DispatchQ (Simple fix)～36~56IssueQ+DispatchQ (Complex fix)～14~32IssueQ+DispatchQ (Float)～32~48IssueQ+DispatchQ (Load)～20~32LDQ～54~64STQ～40~48

蘋(píng)果的發(fā)射隊(duì)列采用了2級(jí)設(shè)計(jì)，在傳統(tǒng)IssueQ之前放置有DispatchQ；DispatchQ為近FIFO結(jié)構(gòu)，其中的指令不接受亂序調(diào)度。我們此處沒(méi)有分離DispatchQ與IssueQ的容量，其實(shí)Icestorm的DispatchQ容量為～6項(xiàng)。DispatchQ的容量并不是在任何微結(jié)構(gòu)中都可以探測(cè)的；蘋(píng)果的DispatchQ容量可知是因?yàn)槠淙肟趲捙c出口帶寬不等。每周期每個(gè)IssueQ只能接受1條來(lái)自DispatchQ的指令。

• 整數(shù)發(fā)射隊(duì)列為36項(xiàng)左右，相較firestorm大幅縮減。整數(shù)發(fā)射隊(duì)列與ROB表項(xiàng)的比值為36/108=0.33，是相當(dāng)高的；這是較為平衡的設(shè)計(jì)，可以認(rèn)為代表了一般場(chǎng)景下較好的亂序調(diào)度能力。

• 復(fù)雜整數(shù)指令如乘法指令所享受到的發(fā)射隊(duì)列項(xiàng)數(shù)只有約14項(xiàng)；這是分布式發(fā)射隊(duì)列的特征，每個(gè)執(zhí)行單元前有一個(gè)獨(dú)立的發(fā)射隊(duì)列，且只有一個(gè)乘法執(zhí)行單元。分布式發(fā)射隊(duì)列的有效容量在極端情況下不及集中式發(fā)射隊(duì)列，因此盡管icestorm整數(shù)發(fā)射隊(duì)列與ROB表項(xiàng)的比值為36/108=0.33，與A78相仿，但是實(shí)際調(diào)度效果上是不及的。

• 浮點(diǎn)發(fā)射隊(duì)列為36項(xiàng)左右，相較firestorm大幅縮減。對(duì)于Icestorm這樣的設(shè)計(jì)而言是富足的，尤其是考慮到Icestorm的浮點(diǎn)執(zhí)行單元本身規(guī)格一般。

• 訪存發(fā)射隊(duì)列為20項(xiàng)左右，相較firestorm大幅縮減。對(duì)于Icestorm這樣的設(shè)計(jì)而言是合理的，但對(duì)訪存能力的追求永無(wú)盡頭。

總體而言，Icestorm的亂序調(diào)度窗口（去除DispatchQ容量以后）并不算很大，發(fā)射隊(duì)列的配置甚至讓人回想起上古AMD K10。

Icestorm的Load Queue容量為54項(xiàng)，Store Queue容量為40項(xiàng)。需要注意的是，本專(zhuān)欄對(duì)LDQ與STQ的計(jì)數(shù)并沒(méi)有減去IssueQ部分的容量；作為參考，C&C的相關(guān)數(shù)值也沒(méi)有減去IssueQ部分的容量而dougallj的相關(guān)數(shù)值減去了IssueQ部分的容量。這樣的規(guī)格甚至相距A78不遠(yuǎn)，從其他亂序資源的規(guī)模上來(lái)看，Icestorm的LDQ與STQ容量綽綽有余；從執(zhí)行單元的規(guī)格上來(lái)看（2 load AGU、1 store AGU），Icestorm的LDQ與STQ容量也十分大?？傮w而言，Icestorm仍然是一款相當(dāng)注重訪存的微架構(gòu)；較強(qiáng)的訪存能力會(huì)讓處理器在實(shí)際負(fù)載中獲得較好的表現(xiàn)，而非僅僅是理論跑分戰(zhàn)神。

訪存

訪存是體系結(jié)構(gòu)永恒的話(huà)題與難題，訪存性能直接決定了處理器性能的上限（甚至取指也受制于訪存），訪存子系統(tǒng)的表現(xiàn)體現(xiàn)了設(shè)計(jì)團(tuán)隊(duì)的綜合實(shí)力（前端、后端）。為了緩解越發(fā)明顯的緩存墻（memory wall）問(wèn)題，現(xiàn)代處理器的訪存子系統(tǒng)十分復(fù)雜；流水線(xiàn)內(nèi)的LDQ、STQ，Dcache、DTLB，下級(jí)Cache、下級(jí)TLB，各級(jí)預(yù)取器等組件交織配合；嘗試在延遲、帶寬等多個(gè)維度提高訪存性能。

load-store前遞

當(dāng)load指令命中STQ中還未來(lái)得及寫(xiě)回DCache的store指令（訪問(wèn)了相同的物理地址）時(shí)，配備了load-store forwarding的處理器無(wú)需等待store指令寫(xiě)回DCache后再執(zhí)行l(wèi)oad指令，而是可以直接將STQ中存儲(chǔ)的相應(yīng)數(shù)據(jù)發(fā)送至LSU，完成load指令的執(zhí)行。

Icestorm的Store-to-load forwarding圖像并不傳統(tǒng)，對(duì)角線(xiàn)區(qū)域延遲高度統(tǒng)一，我們需要計(jì)算實(shí)際的執(zhí)行周期數(shù)才能確定其是否存在store-to-load forwarding機(jī)制。Icestorm的運(yùn)行頻率為2GHz，因此4ns代表8個(gè)時(shí)鐘周期，這一數(shù)字較為曖昧。相較其他配備了forwarding機(jī)制的處理器核，倘若此處發(fā)生了forwarding，那么8個(gè)時(shí)鐘周期的延遲略大了一點(diǎn)，但又顯著小于其他處理器核store-to-load forwarding失效的情況。那么此處可以有兩種解釋?zhuān)?/p>

1. （個(gè)人傾向的高概率解釋?zhuān)㊣cestorm配備了store-to-load forwarding機(jī)制。與其他處理器核不同的是，前遞粒度為8bit即1 Byte（STQ的查詢(xún)和存儲(chǔ)粒度為8bit）；也就是說(shuō)Icestorm可以從任何非對(duì)齊位置對(duì)partial overlay的load指令進(jìn)行store數(shù)據(jù)前遞，而無(wú)需等待store指令的數(shù)據(jù)寫(xiě)入DCache再重新執(zhí)行l(wèi)oad指令。這一設(shè)計(jì)十分激進(jìn)。

2. Icestorm沒(méi)有配備store-to-load forwarding機(jī)制。與其他處理器核不同的是，Icestorm的load指令回滾開(kāi)銷(xiāo)極小或根本沒(méi)有發(fā)生load指令回滾，load指令在store指令寫(xiě)入Dcache后迅速訪問(wèn)Dcache并取得數(shù)據(jù)。這一設(shè)計(jì)十分巧妙（借助store order violation predictor或棧操作消除機(jī)制）。

當(dāng)store和load操作地址跨行時(shí)，都不會(huì)帶來(lái)額外的延遲損失，且forwarding（如果解釋1成立）完美工作。這一驚人的特性是蘋(píng)果特殊的DCache設(shè)計(jì)帶來(lái)的。

Dcache端口

load-store forwarding圖還包含了更多的信息，蘋(píng)果與眾不同的DCache設(shè)計(jì)展現(xiàn)出了驚人的特性。

load、store均不跨行時(shí)，每周期能夠執(zhí)行1組store-load指令對(duì)，符合Icestorm只有1個(gè)AGU store（共兩個(gè)AGU）的設(shè)計(jì)。

load不跨行store跨行時(shí)，store寫(xiě)入Dcache的帶寬沒(méi)有降低，這一點(diǎn)十分不同尋常；此時(shí)每周期仍然能夠執(zhí)行1組store-load指令對(duì)。蘋(píng)果的DCache除了8 Byte的分bank外還按照地址（cacheline）進(jìn)行了interleave。大核firestorm擁有4個(gè)block共128KB容量；小核icestorm則削減至2個(gè)block共64KB容量。

按照cacheline interleaved（相鄰2個(gè)cacheline會(huì)分布于2個(gè)不同的block）的2個(gè)block分別提供了1個(gè)寫(xiě)端口（共2個(gè)寫(xiě)端口），因此跨行store僅需同時(shí)調(diào)用不同block的寫(xiě)端口即可，不會(huì)影響帶寬。那么可以預(yù)見(jiàn)得：

load跨行store不跨行時(shí)，load讀取Dcache的帶寬沒(méi)有降低；此時(shí)每周期能夠執(zhí)行1組store-load指令對(duì)。

當(dāng)兩條load指令訪問(wèn)同一block的同一set的不同bank時(shí)，Icestorm的多端口實(shí)現(xiàn)沒(méi)有采用體復(fù)制設(shè)計(jì)，而是采用了行內(nèi)廣播；同一行的數(shù)據(jù)會(huì)被廣播至所有l(wèi)oad。也就是說(shuō)，倘若兩條load指令訪問(wèn)同一block的不同set就會(huì)產(chǎn)生端口沖突。這一設(shè)計(jì)較為巧妙，規(guī)避了體復(fù)制造成的SRAM冗余；不過(guò)也可能造成某些極端情況下的帶寬降低。

Cache延遲

我們使用多種訪存模式訪問(wèn)逐漸變大的數(shù)據(jù)集（直至內(nèi)存），以探究Icestorm的Cache層級(jí)設(shè)計(jì)、預(yù)取器效果、內(nèi)存控制器效果。

Apple采用了2級(jí)Cache的特殊設(shè)計(jì)（舍棄了private L2），且小核心簇并不能高速訪問(wèn)所有L2（同時(shí)也是LLC）。在LLC之下還有內(nèi)存控制器側(cè)的SLC負(fù)責(zé)SoC數(shù)據(jù)互聯(lián)。

• DCache有效容量為64KB。

• Icestorm小核心簇的有效L2Cache有效容量為3MB-4MB。

• Linear Chain能做到無(wú)損預(yù)取。

• 存在開(kāi)頁(yè)預(yù)取器或類(lèi)Region預(yù)取器。

• 內(nèi)存延遲偏高，無(wú)法與高頻調(diào)參后的DDR4內(nèi)存相比。

可以看到在12MB左右的位置存在一次延遲跳變，與有效L2容量的差值正好約為8MB。這一數(shù)據(jù)也較為曖昧，無(wú)法確認(rèn)是來(lái)自遠(yuǎn)端大核側(cè)L2 Cache的影響還是下側(cè)SLC的影響（因?yàn)榇蠛藗?cè)的有效L2容量正好為8MB）。相對(duì)合理的解釋是影響來(lái)自后者，即SLC的容量為8MB，這樣的片上系統(tǒng)工作邏輯較為合理。

訪存序

亂序推測(cè)執(zhí)行的處理器中，store指令無(wú)法被推測(cè)執(zhí)行但是load指令允許被推測(cè)執(zhí)行，這就造成了訪存的RAW和WAR問(wèn)題。為了避免錯(cuò)誤推測(cè)執(zhí)行的load指令帶來(lái)頻繁的回滾或流水線(xiàn)清空，處理器內(nèi)部普遍配備了訪存違例預(yù)測(cè)器，預(yù)測(cè)可能會(huì)導(dǎo)致回滾和流水線(xiàn)清空的load指令，并強(qiáng)制這樣的load指令不再完全推測(cè)執(zhí)行。

Icestorm的訪存違例預(yù)測(cè)器有12項(xiàng)容量，采用了較為傳統(tǒng)的設(shè)計(jì)?，F(xiàn)今處理器仍然廣泛使用這樣的傳統(tǒng)設(shè)計(jì)而非store-set等機(jī)制（只有Intel的大核采用了類(lèi)store-set設(shè)計(jì)），但是傳統(tǒng)機(jī)制也有海量的設(shè)計(jì)細(xì)節(jié)，我們不在此展開(kāi)。相較大核firestorm，Icestorm的表項(xiàng)容量經(jīng)歷了大幅縮減；作為參考，業(yè)內(nèi)其余設(shè)計(jì)的容量普遍在32項(xiàng)左右。12項(xiàng)的容量對(duì)于SPEC06之類(lèi)的benchmark已然足夠，但是在實(shí)際應(yīng)用中是否足夠我個(gè)人還要給其打上一個(gè)問(wèn)號(hào)。

訪存并行度

在該測(cè)試項(xiàng)目中，我們考察處理器同時(shí)面對(duì)多個(gè)訪存流時(shí)的表現(xiàn)。每個(gè)訪存流均是隨機(jī)且獨(dú)立的，因此可以規(guī)避大部分預(yù)取器的影響，最大限度壓榨核內(nèi)流水線(xiàn)亂序結(jié)構(gòu)、各級(jí)Cache亂序結(jié)構(gòu)。

可見(jiàn)Icestorm的圖像與A78明顯不同，A78的圖像相互交織、混亂難辨；Icestorm的圖像清晰整潔。Icestorm較好地隔離了預(yù)取器等結(jié)構(gòu)的行為，使它們不會(huì)相互干擾?？梢?jiàn)對(duì)于Icestorm而言雙流訪存能夠獲得接近線(xiàn)性的帶寬提升；8個(gè)流以?xún)?nèi)時(shí)吞吐量有明顯的收益。在遠(yuǎn)端的內(nèi)存段，最大的有收益流數(shù)量為16個(gè)，在現(xiàn)如今處理器中不算很多；隨著訪存流數(shù)量繼續(xù)增長(zhǎng)，內(nèi)存帶寬受到干擾略微下降。對(duì)于小核心而言這樣的表現(xiàn)是極其優(yōu)秀的，體現(xiàn)了處理器內(nèi)部設(shè)計(jì)的扎實(shí)功底。

Pointer Chasing

Pointer chasing是現(xiàn)代高性能處理器中常見(jiàn)的訪存優(yōu)化，當(dāng)一條load指令的結(jié)果用于下一條load指令的地址計(jì)算時(shí)，該結(jié)果會(huì)從快速通路進(jìn)入AGU流水線(xiàn)，縮短這兩條load指令的執(zhí)行間隔。在配備了pointer chasing優(yōu)化的處理器中，觸發(fā)pointer chasing后load-to-use延遲會(huì)比正常情況減少1周期。

Load-to-use latencyPointer-chasing Case3No-pointer-chasing Case4

Icestorm的核內(nèi)訪存系統(tǒng)繼承了firestorm的特性，配備了pointer chasing優(yōu)化。Icestorm4周期的訪存延遲本身就較低，pointer chasing優(yōu)化后的load-to-use延遲僅為3個(gè)時(shí)鐘周期，更為驚艷。這不僅僅需要強(qiáng)大的邏輯設(shè)計(jì)能力（從蘋(píng)果的專(zhuān)利來(lái)看，其中有很多細(xì)節(jié)），還需要強(qiáng)悍的物理設(shè)計(jì)能力。

核外

隨著摩爾定律的放緩，即便是消費(fèi)級(jí)處理器也被迫向多核方向發(fā)展，核外組件發(fā)揮著重要的作用。核外系統(tǒng)是個(gè)紛繁復(fù)雜的世界，無(wú)論是總線(xiàn)結(jié)構(gòu)、一致性協(xié)議、LLC設(shè)計(jì)還是內(nèi)存控制器調(diào)度，每項(xiàng)都復(fù)雜到讀完1本書(shū)都無(wú)法入門(mén)。因此，我們只關(guān)注其中較為淺顯、直觀的部分。

核間延遲

我們通過(guò)CAS測(cè)量Soc中兩兩核間的延遲，其反映了處理器的一致性協(xié)議效率、LLC設(shè)計(jì)、總線(xiàn)設(shè)計(jì)等多個(gè)維度特性的交疊。

M1的核間延遲表現(xiàn)較為奇怪。大小核簇內(nèi)部均能夠有效地共享信息（傳遞臟數(shù)據(jù)），但是大小核簇之間并不能有效得共享信息。因此M1并沒(méi)有采用Dynam IQ式的扁平crossbar類(lèi)互聯(lián)，大小核簇間很可能只能通過(guò)SLC及以下的結(jié)構(gòu)傳遞臟數(shù)據(jù)。核心簇內(nèi)40ns左右的延遲在如今是較慢的水平，不過(guò)對(duì)于消費(fèi)級(jí)而言綽綽有余；核心簇間160ns的延遲簡(jiǎn)直匪夷所思，超過(guò)跨socket互聯(lián)延遲，表現(xiàn)極其糟糕。我們甚至有理由懷疑此處數(shù)據(jù)被寫(xiě)回了內(nèi)存再被讀出；不過(guò)考慮到firestorm與icestorm調(diào)度的單向遷移特性，這一點(diǎn)也似乎可以強(qiáng)行解釋。

當(dāng)然，這里的數(shù)據(jù)異常也可能是測(cè)試方法導(dǎo)致（雖然不同渠道的不同結(jié)果能夠相互映證，但是還是不能徹底排除這一可能），需要日后進(jìn)一步排查。

訪存帶寬

我們通過(guò)Stream程序測(cè)試Soc中CPU單核的訪存帶寬，其反映了處理器核內(nèi)的流水線(xiàn)設(shè)計(jì)、各級(jí)Cache設(shè)計(jì)、總線(xiàn)設(shè)計(jì)、內(nèi)存控制器設(shè)計(jì)等多個(gè)維度特性的交疊。

Icestorm:

FunctionBest Rate (MB/s)Copy27731Scale27698Add29834Triad29557

配備了大位寬LPDDR的M1的內(nèi)存帶寬理應(yīng)極高，但是小核實(shí)測(cè)數(shù)值卻十分低，我們不禁懷疑是小核簇的某些結(jié)構(gòu)位寬限制了訪存帶寬，或是QoS機(jī)制不允許小核使用全部?jī)?nèi)存帶寬。測(cè)試大核訪存帶寬如下：

Firestorm:

FunctionBest Rate (MB/s)Copy58026Scale58192Add55090Triad54843

果然大核的帶寬極高。icestorm在SPEC06中浮點(diǎn)性能偏弱，內(nèi)存帶寬限制難脫其責(zé)。

總結(jié)

自從2011年Arm v8橫空出世，Arm公版就執(zhí)著于順序流水線(xiàn)小核心，A53、A55無(wú)不是這樣的產(chǎn)品；但是隨著十?dāng)?shù)年間移動(dòng)端對(duì)性能的不斷渴求，順序雙發(fā)射微架構(gòu)逐漸力不從心。讓人意想不到的是，伴隨Arm v9而來(lái)的A510仍然是一款順序流水線(xiàn)產(chǎn)品，牛津團(tuán)隊(duì)甚至將其擴(kuò)展到了三發(fā)射規(guī)格。安卓小核在人們心目中的印象也逐漸固化為性能孱弱、功耗平庸、難堪大用。但是蘋(píng)果自研架構(gòu)的攀登之旅讓我們有機(jī)會(huì)看到了山另一邊的故事。原來(lái)小核心也可以性能喜人的同時(shí)功耗極低，完美承接后臺(tái)任務(wù)與系統(tǒng)任務(wù)，與大核心配合無(wú)間，一起締造了M1的能耗比傳奇。已然站在高峰的蘋(píng)果并沒(méi)有停滯步伐，次年的迭代產(chǎn)品Blizzard將讓我們看到山巔更高更遠(yuǎn)的青空，不過(guò)這已是后話(huà)。高通Nuvia似乎已跟進(jìn)蘋(píng)果的步伐，采用亂序微架構(gòu)的能效核心；Arm公版也將于今年更新A510為A520，這恐怕是史上最短的公版小核更新周期，讓人不禁期待其將采用怎樣的微架構(gòu)。后M1時(shí)代群雄并起，逐鹿中原；盛宴難再，幸甚快哉。

分析與測(cè)試：lyz、lxy

測(cè)試平臺(tái)

本文的測(cè)試是在Mac mini M1上進(jìn)行的，其使用了Apple M1（配備了4顆firestorm大核心和4顆icestorm小核心），環(huán)境為Arch Linux。

由于擔(dān)心過(guò)熱降頻，因此沒(méi)有使用Macbook Air。Mac mini對(duì)于想體驗(yàn)蘋(píng)果產(chǎn)品的人來(lái)說(shuō)性?xún)r(jià)比極佳，更新M2款后更是如此；搭配學(xué)生優(yōu)惠僅需3699，整體漲價(jià)環(huán)境中的一股降價(jià)清流。不過(guò)目前Arch Linux還未適配M2款Mac mini，我們的基準(zhǔn)跑分?jǐn)?shù)據(jù)庫(kù)無(wú)法錄用MacOS下的分值（由于無(wú)法控制調(diào)用庫(kù)，我們?cè)贛acOS下的跑分相較Linux都有一定的提升，故不能直接比較相對(duì)差異），因此Blizzard與Avalanche的評(píng)測(cè)仍需等待。

發(fā)布于 2023-03-11 10:33