今年的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的具体结构了。可以看出其基本结构是一个双向双工的环路，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更精彩的对决。