今年的hotchip上marvell展示了其基于ARM架構的Thunder X3服務器芯片。Marvell在fabless廠商中應該算是鼎鼎大名，從硬盤控制芯片起家至今，已經發展成為包含豐富產品線的綜合性公司。其中ARM處理器產品線，除了這次展示的服務器芯片Thunder系列外，還包括面向無線通信基站的基帶及智能射頻的Octeon系列，以及低功耗的應用級Armada系列。不過Thunder并非Marvell自家研發，而是在2017年花費60億美元收購了Cavium獲得。并不為大多數人所知的是，這并不是Marvell第一次嘗試ARM服務器的設計。

　　早在2006年，Marvell通過收購intel的通信及應用處理器業務Xscale獲得了ARM指令集的授權，資料源碼和設計團隊。在2010年左右Marvell開始著手設計基于ARM v8的服務器芯片，當時的設計主要來自原Xscale的美國團隊，上海部門也有部分人員參與。

　　彼時是ARM服務器的第一波熱潮，都對ARM能夠替換X86報有很大的期待，研發也持續了幾年時間。不過最后的結果并不如人意，由于種種原因這款芯片沒有走到tape-out就夭折了，加之當時Marvell深陷和卡耐基梅隆的專利官司，股價一跌再跌，同時其他參與ARM服務器研究的公司也紛紛退出，最終這項充滿不確定和挑戰的項目遺憾的被砍掉，國外的設計團隊也整體轉給了ARM，之后ARM cortex A系列的幾款處理器就出自這個設計團隊。

　　不過Marvell也一直不死心，隨著thunder系列處理器收歸囊中，從thunder X2開始，ARM服務器似乎開始走運了。從新聞上發布的消息來看，這款處理器銷量不錯，比如美國能源部旗下桑迪亞國家實驗室的超級計算機“Stra”，就使用了145152個ThunderX2核心；洛斯阿莫斯國家實驗室和法國原子能機構CEA的超算系統也是基于Thunder X2打造。

　　在商用領域，微軟內部也正為Azure部署基于ThunderX2 的量產級服務器集群，主要針對Project Olympus平臺，據說有數十萬顆至多。如果都落實下來的話，這樣的規模對于初出茅廬的Thunder X2來說是非常好的成果了，也可以證明ARM服務器的在超算和商用的可行性。

　　雖然包括Amazon在內的幾家公司也在推出相應的ARM服務器芯片，不過其核心仍然是由ARM提供，大多是Neoverse N1內核，而Thunder的ARM核心是Marvell自研的，對于其他的競爭者來說還是有很大的差異性。下面就來看看新一代Thunder x3有哪些改進。

　　首先回顧下Thunder X2，這是2016年的產品，基于TSMC 16nm。32核心，單核4線程，頻率2.5GHz，可以boost到3.0GHz。每核心32KB數據和指令緩存、256KB二級緩存，共享32MB三級緩存。其他的如虛擬化，TrustZone的也基本都支持。

　　到Thunder X3，可以看到核心從32增加到了60個，同時還提供了一個dual die的增強版，可以增加到96個核心。每個核心仍然是4個線程，工藝升級到TSMC 7nm。可以看到Thunder X3相比X2在同頻下單線程有30%的性能提升，這個一個是比較高的數字。其中dual die的設計還是很有特點，并不是single die數目乘2，應該是考慮到單芯片的功耗。不過為什么不在單個die上直接堆疊96個核心呢，這樣還能避免2個die一起的互聯問題，這個暫時沒有答案。

　　Anandtech網站給了一個很好的數據對比，可以看到對比amazon和ampere的產品，Thunder X3在核心線程數和L3 cache容量上遙遙領先，其他的數據也都持平，不過PCIe的帶寬上小氣了一些。另外一個典型的區別是Thunder系列仍然采用了Ring的結構，和同類A型產品包括X86在內幾乎都是使用mesh總線的。由于核心數量較多時，Ring總線訪問的不對稱時延會比較明顯，同時拓撲結構不如mesh能提供更靈活的連接性和更高的帶寬，對于這個選擇還是持保留態度，雖然Thunder X3采用了一個增強版的swithed 3x Ring。這也許就是96個核心沒有選擇放在一個die上而是dual die的原因。

　　ThunderX3面向服務器級別，肯定是和intel，AMD一樣選擇全亂序多發射的架構。其中有幾個設計的特點值得討論。

　　第一，ThunderX3給出的decode寬度高達8個，這個數字遠遠超過其他競爭對手，而issue寬度卻只有4，前寬后窄的比例達到了2:1。這個是很奇怪的比例，取值譯碼的高帶寬會在相當程度上被issue的瓶頸所堵住，因此浪費了一定的硬件面積。不清楚ThunderX3這樣的設計是否有其他原因。

　　第二，經過dispatch，指令會統一發送到一個多大70個entry的unified Scheduer，也就是通常說的Issue Queue。之前曾經分析過ARM和ZEN的issue Queue設計，都是采用分離式的queue，這樣可以比較好的解決timing問題，同時能夠保證ALU的single cycle forwarding。ThunderX3這么大的unified Queue，一個cycle要發射8條指令到不同的執行單元，雖然調度策略上更優一些，但復雜程度可想而知。

　　另外應該是舍棄了single cycle forwarding的支持，通常來說這個對性能的影響是比較大的。希望Marvell之后能夠提供更詳細的性能對比。

　　這個是我從網站信息上總結的Thunder X3和Neoverse N1的參數對比總結。可以看到除了上邊的2個主要區別，其他的參數差距并不大，也都選擇了比較強的load-store單元，較大的L1和L2 cache size。當然這個對比不是很公平，畢竟N1是2年前的產品，其下一代應該也會有比較大的提升。之后的幾頁 slides是Thunder X3在各級流水線上的一些設計參數和細節，就不仔細分析，有興趣可以在文末的anandtech網站上查看細節。

　　這里介紹了thunderX3的單核4線程的仲裁方式，主要是在fetch，dispatch，scheduler和retire階段根據各線程指令的多少和新舊程度進行資源的平衡。

　　這里就是thunderX3所說的switch ring的具體結構了?？梢钥闯銎浠窘Y構是一個雙向雙工的環路，shared L3 cache被分成若干個tile和core綁定在一起。有幾個地方值得注意。

　　第一，這不是一個典型的ring，可以看到環的中間還有個上下貫通的通路，這個應該是在核心比較多的情況下給在ring上本來比較遠的節點提供一個更快的旁路通路。不過既然已經搞的這么復雜了，為什么不一步到位直接用更合適的mesh？

　　第二，在60個核心的規模上，還在使用snoop協議，而不是通常效率更高的directory協議，多核snoop造成的總線擁堵和核內干擾應該會很大程度制約其性能發揮，這個選擇很值得商榷。

　　第三，使用exclusive L3，這樣當然會剩一些存儲面積，但卻增加了不必要的L2-L3數據訪問，在以性能至上的服務器芯片，這似乎不是一個合適的選擇。

　　總體來看，ThunderX3在眾多采用arm公版設計的廠商中，還是努力走出了自己定制化的特點。這個和華為鯤鵬的策略應該是殊途同歸。然而在核心設計和互聯上的一些疑問，可能會對其真實性能發揮造成阻礙。這個希望能在后續詳細的性能評測中得到解釋。

　　另外服務器領域的具體應用非常龐雜，benchmark并不能提供較真實的數據，還是要靠大規模應用后得到實際的反饋。這一點arm服務器相比已經深耕十幾年的X86來說還有很長的路要走。不管怎樣，從amazon到marvell，arm服務器的定制化設計總算開了個頭，期待后邊能出現和x86更精彩的對決。