防守与反击英特尔版帝国反击战序章二

　　时空背景
　　自打AMDZen3发布后，Intel感受到的压力是与日俱增，桌面、服务器以及笔记本市场都受到来自AMD产品矩阵的冲击。不仅于此，相对于上市的产品而言，Intel面临的另一个困境是制造工艺上已经不再占优，性能耗电比竞争力不再，这使得Intel或者说x86阵营得以在主流PC不败的地位遭受前所未有的冲击。例如Apple正逐渐切换到采用台积电生产的AppleSilicon处理器，这对Intel来说是一个非常危险的警号。
　　我们都知道，Intel本质上是一家工厂，同时也是美国目前为数不多的垂直大型芯片制造业龙头，是高端制造业中的重中之重，当自己生产的产品也被本国长期合作的企业放弃时，那就是到了非改不行的地步了。
　　Intel当前最大的问题是制程，由于制造工艺方面出现了落后于竞争对手代工厂的情况，因此摆在Intel面前的最大挑战首先是如何尽快采用更先进的制程，以及如何从架构着手让性能耗电比指标实现逆转胜。
　　相比三年前的了无生趣，PC正迎来一场史诗级的重新提速，这是一场旷世的防守与反击博弈，如今，这场史诗级的博弈正徐徐展开其第二篇揭幕战的序章。
　　Intel历史上也出现过产品部分竞争力不敌对手，那是在AMDK7K8vsIntelPentium4的时代，距今差不多20年，幸运的是，Intel赶上了笔记本崛起的浪潮，凭借WiFi和Core架构成功卡位并在随后的桌面大战中凭借Conroe收复失地。这说起来好像化解得挺轻松的，但是当年的动静可是非常大，以至于出现了IntelCEO当众下跪的局面。
　　来自Intel以色列海法团队的Yonah和Conroe是扮演救主的重要角色，前者让Intel把笔记本市场牢牢掌握在直接手里，后者则是一洗Netburst架构在桌面市场的性能耗电颓势。
　　如今，这支1974年就成立的团队再次出击，它们这次祭出的是代号为AlderLake的第十二代酷睿处理器。10纳米制程的全力出击AlderLake架构概况
　　对于研发阶段的产品或者技术冠以各种架构代号是司空见惯的，曾经在Intel任职20年的FrancoisPiednoel将将取架构代号的原因归结为两个：保密以及让媒体大惊小怪，当年Intel曾经于IDF密室内在媒体不知情的情况下演示过Conroe，由于屏蔽了其中的运算单元，以至于媒体以为跑的是更好的Yonah，后来Intel还把这个更好的Yonah发给OEM和ODM，大家浑然不知手头测试的是Intel全新的下一代处理器。
　　相对于多年前名称差别较大的代号名称，Intel现在的架构代号大都以Lake或者Cove结尾，要区分这么多cove和lake对读者来说是相当困惑和考验记忆力的事情。
　　AlderLake架构是Intel历史上第一个实际上市的混合核心架构，在这之前该公司曾经有一个代号Lakefield的x86混合内核项目。Lakefield是一个移动CPU，大小核分别是一个SunnyCove（在TigerLake或者说十一代移动酷睿处理器中采用）和四个Tremont，包括微软的SurfaceGo和三星的GalaxyBookS都曾经被表示会采用该处理器。
　　Lakefield采用堆叠芯片封装，其中的ComputeDie或者说计算芯片采用IntelP1274（10纳米）制程，里面的大核SunnyCove内核面积大约是4。5平方毫米，而小核Tremont只有0。88平方毫米，两者面积存在巨大差异，按照Intel的说法，每枚小核的性能相当于SunnyCove的七成。由于面向的是Intel一向竞争力最弱的移动设备，因此Lakefield在Intel的产品线中并不起眼，乃至它被取消了也没有引起什么波澜，存在感很低。
　　名字取自美国西部华盛顿州一处湖泊的AlderLake满血版具备8816个内核，其中8个高性能内核（PCore，内核编号07）的代号是GoldenCove，另外8个高效内核（ECore，内核编号815）的代号是Gracemont。
　　Intel将这种大小核混编的技术命名为IntelHybrid（英特尔混合）或者HybridComputingArchitectures（HCA），以便和ARM的big。LITTLE区分。
　　在Intel提交的perf（linux下的性能特征分析工具）补丁里，PCore属于Core类型，ECore属于Atom类型，很多性能计数器事件是分立的。例如，想要采集IPC数据的话，采集的指令性能事件需要单独列明，例如cpucoreinstructions和cpuatominstructions，当然如果是LLC（第三级缓存）、能源这类事件则是统一的。
　　从处理器的整体架构来看，AlderLake相当于传统Core系列处理器加挂了两个四核Atom内核簇，每个Atom内核簇共享一块L2Cache，然后分别挂在Ringbus上，与PCore一起共享L3Cache。
　　在内核拓扑关系工具lstopo中Corei912900K呈现的层次关系如下：
　　和扮演救火队员角色的RocketLake相比，除了GPU基本保持不变（都是XeLP架构，型号名称从UHD750变为UHD770，GPU频率有大约400MHz提升）外，AlderLake在CPU内核微架构（PCore、ECore）、PCIE总线、DMI总线、内存子系统上都有很大的变化。更重要的是，RKL使用的是Intel祖传14nm制程，而AlderLake则是Intel7或者更准确的说法10nmEnhancedSuperFin（10ESF）制程，这是AlderLake得以实现的基础。
　　GoldenCove和Gracemont虽然都是x86指令集处理器，但是在微架构层面上存在巨大差别，前者具有更深、更宽的流水线，频率设定较高，强调高性能；后者的角色按照设计理念是做一些轻体力活为主，强调低能耗，Intel为此还专门加入了一个名为ThreadDirector（线程导向器）的硬件线程导向器，这个导向器的目的就是把各种线程按照其负荷递交给不同类型的内核。
　　GoldenCove虽然属于十一代笔记本酷睿（TigerLake）里WillowCove的升级，但是它在某些方面都有巨大的变化，例如乱序指令窗口方面，ROB（重排序缓存）的大小可能是x86史上最大的增幅，充分利用了新制程晶体管密度提升带来的好处。按照Intel的说法，GoldenCove的IPC（每周期指令）性能相较上一代（WillowCove）提升了19。
　　Gracemont主打低能耗，但是本身的性能还是可以的，它属于Atom阵营里的第四代乱序执行架构，性能并不亚于三年前的主流桌面处理器。
　　更多的内核以及更宽的指令执行能力带来的问题是内存带宽需求增加，Intel为AlderLake配备了同时支持DDR4和DDR5的内存控制器，前者的价格相对较低，而后者具备更高的内存带宽。
　　在周边互联能力上AlderLake提供了PCIE5。0x16和PCIE4。0x4，前者可以提供合计64GBs的带宽，后者可以提供合计8GBs的带宽；与北桥或者说PCH的连接总线也从之前RKL的DMI3。0x8提升到了DMI4。0x8，，每条DMI4。0信道可以提供16GTs的传输速率，因此AlderLakeS和Z690芯片组之间的带宽可以达到64GBs。
　　桌面版或者说AlderLakeS搭配的GPU依然是RocketLake里的XeLP，拥有32个EU。每个EU是一个FPINTSIMD8（相当于NVIDIA的CUDAsubcore）的运算单元，每个周期可以执行8个FP32FMA指令或者说16个浮点操作，合计就是每个周期可以跑512个FP32浮点操作。像XeLP这样的核显性能可以满足很多应用场合，特别是在现在显卡溢价让人难以接受的情况下，XeLP表现出来的性能还是让我感到很满意的。
　　值得一提是，现在AdobePremierePro2022已经提供了IntelXe架构系列GPU的HEVC4：2：210bit硬件解码支持。
　　这个支持是用OpenCL接口调用Intel的视频解码器实现的，只要你使用上包含XeGPU的IntelCPU（台式酷睿十一代以上、笔记本酷睿十代以上）来跑，都能获得丝滑般的时间线流畅拖动效果，对于PC视频编辑用户来说，这意味着不用再羡慕苹果M1电脑了。
　　不过比较遗憾的是，这个特性目前尚未有DXVA接口解码器软件提供，这类视频目前在播放器里依然无法实现硬件解码回放。当然，也许某天例如明天，LAVfilter就把Intel的HEVC4：2：210bit调出来了。
　　AlderLake提供了DDR5和PCIE5。0这两个5系新技术，前者对于改善多核性能并且对核显性能会有一定助益，而PCIE5。0主要用武之地是显卡和NVMESSD，但是目前对大部分普通用户来说，这两个5系技术带来的性能提升在现实中不是那么容易察觉。
　　由于集成了多达16个内核以及大量高带宽部件，Intel为AlderLake的内部互联提供了TigerLake同款的1000GBs的双环路互连总线，理论上满载的时候每个内核可分配到的带宽是62。5GBs，当然这只是理论值，因为全核跑向量计算的时候内存带宽更容易成为瓶颈。
　　我用MicrobenchX的C2C测试了内核时延：
　　从C2C时延测试来看，AlderLake的核心间时延要比Zen3高不少，其中ecore的4核簇内部之间似乎存在较高的时延，这有点出乎意料，要知道它们是有一个L2cache共享数据。
　　Intel为12代酷睿提供了全新的LGA1700插座，这似乎不是什么大的问题，过去这么多年里，Intel更换插座基本上就和换件衣服一样说换就换，大家早有心理准备，很多散热器厂商都表示可以为用户提供相应的底板升级售后服务。按照目前的消息，这个LGA1700除了AlderLake外还会在之后的至少两代产品继续沿用。
　　接下来让我们看看AlderLake混合架构里两种内核的细节。微架构Gracemont
　　如果不考虑Larrabee这个物种的话，Intel的x86产品线可以分为两大品牌系列，也就是Core和Atom，分别对应高性能和低耗电。第一个Atom诞生于2008年，比Core晚了两年。当时正值移动设备迅速崛起，Intel全副身家都押宝x86，Atom则是其中被寄予厚望的品牌之一。
　　由于缺乏良好的生态以及配套服务，Atom最终在手机市场败下阵来，不过这个品牌并未消亡，由于x86在工业领域具备非常好生态，因此Atom都被做成工控机、路由器、NAS等不需要高性能内核的应用场合。
　　最初的Atom微架构代号是Bonnell，之后有名为Saltwell的衍生微架构，这两代都是属于顺序执行流水线，虽然省电，当时性能真的一般。
　　第三代Atom微架构名为Silvermont，引入了乱序执行，衍生微架构有为Airmont。
　　自此开始，所有的新Atom微架构代号都带有mont的后缀。
　　我们把Sivermont视作第一代乱序执行Atom微架构，之后分别有Goldenmont（衍生微架构为GoldenmontPlus）、Tremont以及现在AlderLake里的Gracemont，因此Gracemont已经是第四代乱序执行Atom微架构。
　　AlderLake是第一个采用Gracemont内核的芯片架构，满血的Corei912900K包含有8个Gracemont内核，每4个Gracemont构成一个内核模块共享2MBL2Cache。
　　图源：wikipedia
　　在AlderLake中，每四个Gracemont组成一个Atom簇，共享一块2048KiB大小的L2Cache，每个Gracemont拥有64KiBL1指令高速缓存（两倍于Tremont）和32KiBL1数据高速缓存。
　　比较特别的是，Gracemont引入了名为ODILD的按需指令长度预解码器设计。众所周知，x86属于CISC或者说复杂指令集计算机，其指令长度可以是1个字节到15个字节，进入解码器之前需要确定指令的边界或者说长度。Gracemont在L1指令缓存里存放了指令长度数据，可以在指令第二次拾取时绕过预解码阶段，直达指令解码器前的指令队列上，这样的设计可以节省部分周期和耗电。
　　Gracemont采用了双解码器簇的设计，每个解码器簇各有三个简单x86指令解码器。虽然看起来一共有六路解码，但是两个解码器簇合计只能向下游输出5个RISC风格的微操作。与之相比，Gracemont的直系上代微架构Tremont也具备一样的双3路解码器，但是只能做到输出4个RISC风格微操作。
　　按照之前Tremont微架构发布时候的说法，这种双解码器簇对于Atom来说效果比Core里使用位操作高速缓存（microopscache）的做法更好，既能做到6路指令解码又能降低芯片面积。
　　从较大的L1指令Cache到双解码器簇设计来看，Intel是下了大功夫来改善Gracemont的前端瓶颈，原因是它的后端微架构实在有点炸裂。
　　在后端方面，Gracemont的重排序缓存可以容纳256条目，可以向执行单元同时派发5个微操作，相比之下上一代的Tremont指令窗口是208条目，可以向执行单元同时派发4个微操作。在执行单元端口数方面，Gracemont和Tremont分别是17个（12个整数5个浮点）和10个（7个整数3个浮点），指令并行能力有所提升，事实上如此众多的执行端口也是Gracemont微架构中最让人惊讶的地方。
　　ecore和pcore同时开启的时候，指令集支持能力是完全一样的，可以支持AVX2或者说相当于Haswell的级别。
　　但是pcore或者说GoldenCove其实是内建了AVX512指令支持，当我们把ecore关闭后，现在的BIOS能够让pcore那边的AVX512开启。
　　关闭ecore后，uncore时钟频率（原为3。6GHz）也会得到提升，例如在Windows下会uncore提升到4。7GHz，而在Linux下uncore提升幅度会低许多，只有3。8GHz。
　　既然谈到了pcore，那么我们直接转到pcore的架构讨论吧。微架构GoldenCove
　　正如我们前面所说的那样，GoldenCove物理上具备AVX512指令集的硬件支持，但是其启用条件是要在BIOS（新版）里关闭所有ecore，这意味着目前的pcoreecore组合对于希望能实现AVX512的用户来说未必是最佳选择，英特尔倒是提供了6P0E的物理纯pcore版本，例如Corei512400。
　　让我们从流水线的前端（取指和解码）说起。
　　GolderCove的L1指令高速缓存和上一代的WillowCove相比未有变化，都是32KiB，但是与之关联的指令页表缓存（ITLB）是做了升级的，其中4K页表的条目数从128增加到256，2M4M页表的条目数从16提升到32。
　　在分支预测器方面，GoldenCove的目标分支缓存（BTB）条目数增加了一倍多，从5K增加至12K，相比较之下，AMD的Zen3不过是6。5K、WillowCove是5K。
　　更大的BTB原因很简单，GoldenCove的x86指令解码器达到了x86史上之最多达61个，而它的主要对手Zen3只有4个，更是两倍于WillowCove的两倍。
　　为了降低更多指令解码器带来的耗电和时延问题，Intel将微操作缓存（microopscache）的大小从WillowCove的2。25K条增加到4K。按照Intel的说法，由于具备微操作缓存设计，GoldenCove的解码器有80的时间都是处于时钟门控（clockgating，单元时钟被关闭，相当于熄火）状态，有效降低了这部分电路的动态功率。
　　为了喂饱6个解码器，Intel把指令拾取带宽从每周期16字节提升了一倍达到32字节，与Zen3持平。
　　在微操作高速缓存方面，现在可以每周期发送8个微操作，同样达到了对手Zen3的水准，相比之下WillowCove只做到了6个微操作。
　　位于解码器和微操作高速缓存下游的微操作队列（uopDQ，或者说分配队列AllocationQueue）如今也被加大了：
　　对于单线程应用，微操作队列可以存放144个（WillowCove是70个）；
　　对于支持SMT的应用微操作队列则只是增加了多了两个（7072）。
　　GoldenCove的调度器具备6个分配端口以及12个执行端口，相比之下上一代的WillowCove是5个分配端口和10个执行端口。
　　AMD的Zen的调度器采用了类似AppleM1那样的整数、浮点分离式设计，可同时调度8条整数指令和6条浮点指令。某种程度上，Zen系列和AppleM1这方面长得有点很像，都采用了分离式调度器的设计。
　　在ROB重排序缓存方面，GoldenCove达到了512条目，AMDZen3是256，WillowCove（TigerLake，10nm）和CypressCove（RocketLake，14nm）都是352。
　　AppleM1的ROB有媒体说高达600个，但是也有人（DougallJohnson）认为其ROB采用的是一种合并式的新设计大约有330条目，但是每个条目里可能有多达7个回退的微操作，这使得AppleM1在使用不同的测试条件下能达到的大小可以是623、853甚至2295个。
　　在后端执行单元方面GoldenCove的变化相对较少，主要是浮点单元方面，首次在x86处理器上实现了两个快速浮点加法单元，相比之下AMD的Zen3和Intel的WillowCove都缺少快速加法器。
　　此外，我们前面提到过AlderLake是支持AV512指令集的，但是需要关闭了ecore后才能开启AVX512，我们有理由相信Intel是经过深思熟虑后才决定把这个耗费了大量晶体管的单元给屏蔽掉的。
　　在整数流水线方面，GoldenCove引入了新的端口（Port10），使得GoldenCove一共有5个算法逻辑单元（ALU），这五个ALU都可以实现单周期执行LEA（返回有效地址）指令，这样的设计让GoldenCove和Zen3在整数后端方面达到接近的水平。
　　在内存子系统方面，GoldenCove增加了一个Load（加载）端口，合计可以每个周期跑3个256位Load操作（或者两个512bitLoad操作），以及可以跑两个Store操作。和AMDZen3是每个周期三个Load操作或者两个Store操作相比，GoldenCove要强上一些。
　　在LoadStore的乱序执行潜力方面，GoldenCove的LoadStore队列分别是128和72（AMDZen3从测试结果来看是112和64，但是AMD方面表示实际的大小是44和64，也许和内部的一些优化有关）。
　　上面就是Intel方面提供的Gracemont和GoldenCove微架构的资料，接下来，我们会进行一些底层测试，更进一步了解微架构的一些细节。测试平台
　　CPU：Inteli912900K、Inteli711700K、AMDRyzen75800X、
　　主板：
　　LGA1700：
　　DDR4：ASUSTUFGAMINGZ690PLUSWIFID4
　　DDR5：ASUSROGMAXIMUSZ690HERO
　　LGA1200：ASUSTUFGAMINGZ590PLUSWIFI
　　AM4：ASUSROGSTRIXX570E
　　内存：
　　DDR4：3600MTs，16GiBx4或8GiBx4；
　　DDR5：5200MTs，16GiBx4
　　显卡：NVIDIA独显（在微架构测试中不重要）
　　硬盘：256GBSSD
　　操作系统：
　　Linux：Ubuntu21。10Kernel5。15RC7
　　Windows：Windos1021H2底层测试指令吞吐测试
　　我们在这里使用的都是网上现成的底层测试软件，它们都有源代码提供，如果没特别提及的，大家也都可以循名称在网上搜索到。
　　为了便于对比和观察，如果不加说明，底层测试的频率都是锁定在4GHz，关闭超线程，彻底禁止WindowsDefender，Windows电源管理设置为性能模式，Linux电源管理设置为performance模式。MicrobenchX。IPC
　　这是MicrobenchX。IPC1。03版的测试结果，这里的Pcore测试结果我加入了AVX512的数据供大家参考。
　　测试结果扼要：
　　1、GoldenCove的第五个加法器提供了23的提升；
　　2、和Zen3相比，GoldenCove的128bit向量整数加法、64bit整数除法、256bit向量整数乘法、128bit向量整数乘法存在一定的差距；
　　3、虽然Gracemont具备超多的执行单元端口，但是和pcoreGoldenCove实际的底层IPC差距还是相当明显的。
　　4、从微架构角度来看，GoldenCove属于TigerLake中WillowCove的升级，但是它在桌面领域对应的前代产品则是采用CyperssCove微架构的RocketLake。和CypessCove相比，GoldenCove的AVX512浮点加法和减法性能快了一倍，整数浮点混合指令快了32，不少指令都有相对显著的提升。底层测试流水线深度探测
　　流水线深度和处理器频率延伸能力、分支预测失败惩罚有密切关系，不过目前的处理器厂商一般都不公布相关的信息，这是有原因的。
　　现在的内核流水线设计异常复杂，不同指令流向经过的流水线工位数可能是不一样的。
　　为了探测GoldenCove的流水线深度，我使用了多种代码来测试。
　　下表中的左侧是以伪代码方式提供分支程序测试片段，以第7个测试（Test6）为例：Test6，N1，8br，MOVZXXOR；if（cmask）｛REPN（cv〔c256〕）｝REP2（cv〔c260〕）
　　这段伪代码包含了一个MOVZX内存载入操作指令，根据处理器的不同，它可能需要额外的5到6个周期（可能更少）来执行，在支持乱序执行、乱序LS的处理器中，这个动作占用的流水线工位通常会被掩盖掉。
　　关于一些表格中的指令时延，例如MOVZX，我们做了另行的测试。
　　在GoldenCove上录得的数据为0。8个周期，Zen3Zen2Zen都是1个周期，CypessCove是0。9个周期。XORr64，r64指令方面，Zen3是0。2周期，Zen2ZenZen1是0。3周期。Test指令方面，除了当年Pentium4时代涉及访存的时候会有两周期时延外，这里测试的处理器都是1个周期时延。
　　从测试结果来看，在分支预测失败的情况下，GoldenCove的惩罚周期大约是13到26个周期，其中最普遍的是在18周期左右，Gracemont惩罚周期大约是15到23个周期，其中最普遍的是在16周期左右。据此我们估计GoldenCove的等效流水线深度大约是18级工位，而Gracemont是16级工位，由于GoldenCove具备可节省取值、解码阶段的微操作缓存，实际的流水线深度可能要接近22级甚至更深，Gracemont由于采用了可以绕过预解码阶段的按需指令长度解码器设计，因此其实际流水线可能是17级。底层测试取值、解码能力测试
　　取指、解码能力测试
　　处理器的流水线可以分为取指、解码、执行、写回四个工位，其中前端（frontend）是指取指和解码，执行和写回被称为后端（backend）。
　　对于现在的超标量流水线处理器说，每个周期可以执行多条指令，前端需要为后端提供匹配的取指、解码能力，同时为了保证流水线闲置执行单元不浪费，人们还引入了分支预测单元，根据预测结果决定是否将下一条指令先派发给后端闲置的单元执行，待分支确定是否选中后再决定是否保留计算结果或者重置流水线。
　　opcache也被称作microopcache或者L0ICache，它里面存放的是若干段处理器认为会被近期重复使用的微操作（microops），所谓的微操作是x86处理器为了简化后端设计引入的处理器本机指令，是已经经过解码器解码的长度固定的本机指令。
　　在循环语句里的指令在很多情况下都是不断重复的，这些指令以微操作的方式放在uopcache后，后面重复执行这些操作的话，就无须经过解码器这个工位，直接发往后端的队列里等待发射执行。
　　uopcache在x86上的原型是当年Pentium4引入的TraceCache，TracheCache需要消耗大量的芯片面积，但是这是提高超长流水线架构处理器性能重要的一环。在Pentium4终止后，TraceCache的瘦身版就以uopcache的形式引入。
　　要想了解处理器的能力，取指、解码是我们首先想要了解的，在这里我们使用nop、sub、prefixcmp8等三种指令来做测试，其中nop指令是看空操作指令，x86的nop长度是1个字节，sub是减法指令，和加法指令add一样在x86中指令长度都是两个字节，prefixcmp是8字节或者说64位长的指令。
　　我们图表中给出的prefixcmp测试结果基于这样的指令：
　　〔rep〕〔addrovr〕cmpeax，0x7fffffff）
　　图表横坐标标注使用的是十进制数据格式，66KB对应的是64KiB，34MB对应的是32MiB，如此类推。大家要是有办法在Excel里实现二进制数据格式的话不妨告知一下。
　　GoldenCove的测试结果实在有点让人感到惊艳。
　　首先，单字节的NOP指令看来是已经在很大程度上被Intel优化了，解码带宽数据显示此时达到了每个周期7字节或者说7IPC，并且能一直维持到L3Cache边界，我相信Intel对NOP这种什么都不干的指令做了一些特别的处理。
　　Gracemonmt的NOP表现也是不错，其6。xIPC性能可以维持到8KiB的水平，并且在128KiB边界处也能维持到接近6IPC的水平。
　　相较之下，去年曾经闪耀夺目的Zen3一下变得有点跟不上形势了。
　　我们使用的测试工具并非什么流行测试软件，Intel应该不会投入资源特别优化，这个测试结果纯属因为微架构内部的一些新设计带来的。
　　GoldenCove的sub或者说减法指令解码带宽能在4KB边界处维持每周期15字节，sub指令是双字节的，这意味着此时的解码性能至少有7。5IPC，这应该归功于4K条目大小的微操作缓存。
　　在接下来的更大区块里，GoldenCove依然能维持6IPC的解码性能，其范围达到了16MiB，从程序员的角度，对于双字节指令GoldenCove在取指工位上具备比较真实的每周期16字节能力，这个能力可以维持到从L3Cache取指。
　　Gracemont在这里垫底了，在8KiB范围内只有3IPC的水平，相当于GoldenCove的15。
　　从测试结果来看，GoldenCove对于更复杂指令（prefixedCMP8）的解码能力是有显著提升的，可以在32KiB的范围内维持每周期50字节的解码带宽结果，相当于每个周期6。25IPC。
　　Gracemont在这个测试中表现不逊色于Zen3，能在12KiB范围内维持4IPC的水平。底层测试分支预测器
　　分支预测维持流水线充盈的重要性能手段，但是对于现在的长流水线处理器来说，分支预测失败的话对性能惩罚会非常高，因为这意味着运算结果要被抛弃并且流水线要被洗刷，即使是1的命中缺失对性能来说也是非常致命的，当然这也意味着多增加1的命中率收益会非常大。
　　现在的处理器在内部提供了性能计数器，可以让我们了解处理器运行某个程序消耗的周期数、指令数、分支指令数、分支命中失败指令数等数据，我这里在Linux下对CPU2017的intrate测试包进行了分支预测数据采集，结果如下。
　　我们对AlderLake的GoldenCove和Gracemont编译时使用的架构代号都是AlderLake，目前没有专门的GoldenCove和Gracemont架构开关。
　　从测试记过来看，我认为GoldenCove的分支预测器在整数应用中的准确度是稍逊色于Zen3的，不过在浮点应用方面要好些，不过浮点应用的分支指令占比要低很多。底层测试乱序执行窗口特性探测
　　很多乱序执行处理器都采用了名为ReOrderBuffer（重排序缓存）的技术，使指令在乱序执行后能够按照原来的顺序提交结果。指令在以乱序方式执行后，其结果会被存放在ROB中，然后会被写回到寄存器或者内存中，如果有其它指令马上需要该结果，ROB可以直接向所需的数据。简而言之，ROB的大小对于确保有足够的乱序驻留指令以及动态分支预测的恢复，对提升指令集并行度有不可忽视的作用，例如Apple的M1处理器在某些情况下可以做到等效600多个条目。
　　我这里使用TravisDowns的robsize工具来测试，测试的指令时单字节NOP，单字节NOP的指令密度较高，可以减少微操作cache的影响。
　　测试结果如下：
　　正如大家所看到的，我们的测试结果和Intel官方提供的信息一致，GoldenCove和Gracemont的ROB大小分别是512和256，Gracemont不仅数量相差一倍，而且它表现出来的NOP指令测试耗时也要高出大约29。Zen3的ROB是256，但是它执行NOP指令的耗时要比GoldenCove更低，甚至在ROB溢出后依然比GoldenCove低，这可能和Zen3的微操作缓存有特别的压固优化有关。
　　接下来，让我们再看看指令窗口的物理寄存器堆（registerfile）大小。
　　从Cyrix在95年发布的CyrixM1处理器是史上第一款具备寄存器重命名和乱序执行能力的x86处理器算起，x86处理器的乱序执行至今已经有25年了。
　　在绝大部分情况下，寄存器重命名不一定和乱序执行是挂钩，例如IntelIA64就有多达128个通用整数寄存器，虽然也涉及寄存器重命名的概念，但这是编译时的事情，在编译时做寄存器重命名也不见得都是好事（容易导致代码膨胀，降低指令高速缓存命中率）。
　　对于x8664这种只有16个指令集架构寄存器的指令集架构而言，寄存器重命名是保障乱序执行必不可少的技术，要重命名，自然得需要有足够的物理寄存器才行，物理寄存器越多，可供重命名的资源也就越多，维持乱序执行的能力就越强。
　　我们使用robsize同样的测试程序进行了物理寄存器堆（PRF）大小的探测。这里说明一下，我们前面的rob大小探测使用的是nop（空操作）指令，不占用任何寄存器，而接下来做的PRF大小推测测试，使用的是一连串的寄存器add（加法）指令。
　　需要注意的是，物理寄存器堆里同时含有乱序执行中可用于推测执行的推测寄存器数量和已提交寄存器数量，因此这种测试方式不能把直观地把整个物理寄存器堆的大小给出来，它只能测量出可用于推测执行的寄存器数量。
　　从测试结果来看，GoldenCove可用于推测执行的寄存器堆大小和RocketLakeCypressCove没有什么大的区别，都是240个。Gracemont要小一些，也有192个，但是已经大于ComletLake（第十代酷睿或者说Skylake）的144个，Zen3采用分离式整数浮点调度器设计，它的推测可用寄存器堆大小大约是128个。
　　接下来我们看看SIMD向量物理寄存器堆的大小，这里使用的是AVX中的XOR指令，在x86指令集中AVX的寄存器名称一般都是使用ymm表示。
　　Gracemont的AVXymm寄存器队堆大小只有96个，GoldenCove和Zen3都是144个，当寄存器堆大小溢出的时候，GoldenCove的性能衰减程度较低，而Gracemont出现了非常显著的指令吞吐衰减，以Gracemont数量众多的执行端口，寄存器堆不够用时的压力相对明显些。LoadStoreBuffer大小测试
　　现在的处理器不仅可以乱序执行指令，还能乱序加载（Load），这就涉及到LoadStoreBuffer。
　　x86属于CISC指令集，它的指令里可以同时有访存、寄存器、立即数等操作，在SPECCPU2017中，SPECCINT2017和SPECCFP2017的LDST指令占比就分别高达34和39，LoadStoreBuffer对x86的性能影响也是不容小觑的。
　　从测试结果来看，Gracemont的Load缓存大小是80到82个条目，这点是非常清晰的。
　　GoldenCove的大小应该是192条目左右，作为对比，GoldenCove的台式酷睿上一代CypressCove是128，GoldenCove增加了50。
　　AMD官方的说法里Zen3的Loadbuffer只有44（外加28个地址生成器缓存，合计72）个，但是根据软件的测试结果，我觉得从软件角度或者程序员角度，其大小更像是114118条目之间（之前我说过是116）。
　　从测试结果来看，GolenCove的StoreBuffer大小大约是112个条目，Gracemont是48个，Zen3是64个。
　　翻查之前的测试数据，GoldenCove的上一代（CypressCove）是72个条目，这意味着GoldenCove在这方面的大小增加了56，实现乱序Store的概率会有一定的增强。
　　需说明的是，乱序LS的效果与其他乱序执行指令一样取决于多方面的因素，缓存或者说队列大小只是其中一个较为重要的影响因素。
　　SPEC2017测试结果4GHz定频
　　CPU2017是非盈利机构SPEC（标准性能评估公司）推出的CPU性能评估套件，SPEC成立于1998年，会员包括Intel、AMD、IBM、DELL、联想、华硕、技嘉等业界大公司，每隔大约10年就会推出一版新的CPU性能评估套件，CPU2017是该机构在2017年推出的，是所有处理器、电脑厂商做处理器性能评估的最重要手段之一（如果不是使用上有一定门槛，上面这句话的之一是可以省略的）。
　　SPECCPU的特点是由各个机构提供实际应用的源码，它的每一个子项目其实都是源自真实应用修改而来，其修改主要是针对可移植性和遵循的语言标准，例如x264的真实版本采用了大量的汇编代码，但是这样的形式不利于移植到不同指令集架构上测试，因此CPU2017中的x264采用的是纯C语言版本。
　　和上一版本CPU2006相比，CPU2017的代码已经全面更新，虽然依然使用CC和Fortran，但是相对以前的版本来说，已经变成了多语言的大混装。Fortran语言同时出现在浮点和整数测试集，而非像以往那样只出现在浮点测试集。
　　CPU2017的规则更加严谨，speed测试集允许使用OpenMP多线程处理，主要测试较大数据集和较大访存压力下的单任务多线程性能，而rate测试集则只允许单线程，禁止自动并行化，但是允许以多任务的方式跑多个rate测试，目的是测试吞吐率，单个rate任务的访存压力要比speed小很多。
　　不过speed测试集也不是全部项目都支持多线程，只有浮点密集型的fpspeed所有项目支持多线程，整数密集型的intspeed10个子项目中只有最后的657。xzs（数据压缩）是支持多线程的。
　　这样的规则让以往CPU2006以及更早版本中常见的编译器自动并行化优化手段被禁止使用，减少了测试结果的混乱（测试如果使用了编译器自动并行化后，实际上变成了编译器比拼），提高了可比性。
　　备注：CPU2017测试需时，目前我们的旧数据只有Zen34GHz使用了11。2版编译器，11。2版编译器在整数单线程、多线程和浮点多线程中有一点性能改善。其余旧处理器运行的均为10。2版编译器编译出来的代码。
　　首先看看锁定4GHz的测试结果。
　　从测试结果来看，单线程性能方面，GoldenCove的整数性能是Zen3快大约2，比RocketLake快大约14，浮点方面优势会大一些，分别是18和20。
　　在多线程项目中，GoldenCove的整数性能是Zen3快大约1，比RocketLake快大约15，浮点方面优势会大一些，分别是25和20。
　　Gracemont的性能和Zen非常接近，单线程整数浮点性能分别是Zen的120和92，多线程整数浮点分别120和102。
　　大家可能注意到了，我们这里单独列出了全核、单纯GoldenCove、单纯Gracemont的数据，这么多的测试对我们来说是非常耗时的，但是从结果来看也许是有一定意义的。
　　我们使用的Linux发行版是Ubuntu21。10，手动安装了Kernel5。15，按照理想的情况，IntelThreadDirector如果能正常运作，应该可以把重载的线程都扔到pcore或者说GoldenCove上运行，理论上单线程性能时全核和指定GoldenCove的数据应该是一致的。
　　然而事实并非如此，至少我们目前遇到的情况是ThreadDirector把几乎所有的线程都优先扔到ecore或者说Gracemont上，这使得全核的数据比较一般，基本就是Gracemont的数据（截图使用的是默频时候的状态）：
　　fpspeed的结果会好些，因为此时16个内核都在运作。然而，当我查看内核调用情况的时候，情况却是这样的：
　　此时虽然是16个内核都在运作，但是pcore的占用率只用了90左右，而ecore则是满载运行。
　　真是有点尴尬。SPEC2017测试结果默频
　　接下来让我们看看默频的测试结果，虽然说是默频，但是我们已经在Linux中启用了performance高性能模式，避免省电模式下那种频率大幅波动造成性能损失的情况。
　　备注：CPU2017测试需时，目前我们的默频旧数据10。2版编译器编译出来的代码，而ADL使用的编译器为最新的11。2，11。2版编译器会比10。2有一点性能提升效果，总体大约在1到3。
　　在默频下，12900K的pcore的单线程整数和浮点性能分别是5800X的1。12倍和1。24倍，在intspeed和fpspeed下分别是1。11倍和1。30倍。
　　默频下由于调度器支持并未完善造成的磨洋工情况比4GHz更甚：
　　多线程测试的时候pcore只有60不到的占用。测试总结
　　从微架构角度来看，AlderLake中的GoldenCove在指令解码、执行能力上较以往的x86处理器都有提高，特别是指令解码能力方面我认为达到了大幅度提升。
　　在同频下，作为ecore的Gracemont的整数和浮点性能达到了GoldenCove的80和60，默频时分别为63和48，文章中我没有放进功耗结果，我会在一会后将CPU2017的CPU功耗结果发表在我知乎的想法里，大家如果感兴趣的话可以先在关注一下我（EdisonChen）。
　　这次测试是和CloudLiu一起合作的，我负责的是微架构部分基本上是在Linux下测试，遇到的问题主要是ThreadDirector尚未完善，导致高负载情况下线程依然跑到ecore上，但是从CloudLiu的Windows测试来看，Windows下没有这个问题。
　　相对于Intel今年稍早之前的RocketLake主要是对AMD实行防守布局不同的是，AlderLake的出现意味着Intel开始吹响了反击的号角，让许多对RocketLake兴趣一般但是又有升级平台需要的消费者有了一个更好的选择。
　　AlderLake集成了XeLP2。2GPU，和其他XeGPU一样，具备在PremierePro2022中硬件解码HEVC4：2：210bit视频的能力，这对于EOSR5或者其他使用4K120pHEVC的视频用户来说也是一个不错的卖点。
　　从历史来看，Intel一直是一家具有深厚潜力的公司，性能出众的AlderLake再次证明了这点，来自帝国的反击已经展开
　　本次测试平台由华硕提供。