月光下的新探索：Lunar Lake CPU (Lion Cove / Skymont) 微架构测试

最近这些年的CPU市场上，虽然表面上看Intel和AMD打的如火如荼，但是Intel事实上从未满足于在笔记本电脑领域仅仅跟AMD展开竞争——他们的许多规划都是剑指Apple Silicon与MacBook。

这也并不难理解。早些年Intel Mac时期，虽然MacBook的市场份额一直不温不火，但Apple向来都是Intel最优质的客户，为Intel带来了相当高的利润。Apple不仅以高出同行的价格购买特挑、高功耗高性能的SKU，还经常提出大量的定制需求。例如Iris Plus核显的主要客户就是Apple，而Apple带来的需求扶持了Intel的GPU业务。除此之外，Apple × Intel的高端形象也使得Intel的品牌更进一步深入人心。相比之下，微软/PC阵营的高端轻薄本一直略显逊色。

因此，现任CEO Pat Gelsinger上任后多次提出想要赢回Apple这个客户。怎么赢？今天我们要测试的这颗处理器就是Intel交出的答卷。

声明：本文仅为个人测试，测试使用的一切设备、工具等资产与本人所在公司/职位无关，也没有接受任何赞助。由于使用非正式版系统固件/软件，测试结论可能与零售设备有少许差异，仅供参考

Lunar Lake给我们带来了两种新微架构，因此本文测试微架构的部分较为冗长。如果对微架构不感兴趣，可以直接跳到性能测试部分。

处理器规格

Lunar Lake (LNL-V)是一个新的处理器系列，它不隶属于前代的U/P/H等系列，也不直接与AMD的移动端处理器竞争。本次测试的型号是Intel Core Ultra 7 258V，主要规格：

由两个主要的tile组成
- TSMC N3B Compute tile，包含所有的CPU/GPU/NPU/fabric/内存控制器等
- TSMC N6 PCH tile，包含一部分外部IO接口
4个Lion Cove大核心
- 单核4.8 GHz，全核频率4.2 GHz
- 64 KB L1指令缓存，48 KB “L0”数据缓存
- 192 KB “L1”数据缓存（新增层级）
- 每个核心2.5 MB L2
- 共享12 MB L3
4个Skymont小核心
- 单核、全核均为3.7 GHz
- 64 KB L1指令缓存，32 KB L1数据缓存
- 共享4 MB L2，没有L3
32 GB LPDDR5X-8533内存
- 8 MB Memory Side Cache 也就是ARM SoC常说的SLC，或者类似AMD的Infinity Cache
8核心Xe2核显
- 1024sp规格，与Meteor Lake相同
- SIMD单元的宽度增加到16，因此EU数量对应的从128个降低到64个
- 独占8MB GPU L2

如果一定要给它找一个前身，它可能与Lakefield最为接近：

使用最先进的制造工艺，并且SoC整体的设计偏向于低功耗而不是高性能；
为未来的主流SoC架构提供了一些设计方向参考；
使用类似手机与平板电脑的定制PMIC供电，而非传统PC的VRM架构，提高供电效率；
MoP (Memory on Package)将DRAM集成在package内，减少主板面积需求。

不同之处在于Lunar Lake是4大核+4小核的设计，而不是Lakefield那种尴尬的1+4。不过二者在砍掉SMT这方面倒是殊致同归。

很容易看出，Lunar Lake在SoC层面是Intel几乎1:1复刻Apple M-series的产物，并且Intel在这个产品系列中用上了能用的一切手段去增强它的竞争力。

微架构

我们先从Lion Cove、Skymont两个微架构层面的细节入手，观察Intel在Lunar Lake中加入的这两个全新微架构有哪些明显的改变。

注意：由于笔者的Meteor Lake机器已经二手出售，本次并不是所有测试都有Redwood Cove / Crestmont对比数据。考虑到Redwood Cove / Crestmont本身相比前代改动不大，一部分微架构分析与对比我会使用Raptor Lake (13700H)的Raptor Cove与Gracemont进行。

指令吞吐

使用clamchowder的InstructionRate工具测试Lunar Lake两种不同核心的吞吐，并与13代Raptor Lake以及竞争对手AMD的同代微架构“Zen 5”进行对比

可以看到无论是Lion Cove还是Skymont在指令吞吐方面相比前代都有非常明显的提升。Lion Cove的提升注重于scalar指令的吞吐，Skymont的scalar与vector都有大幅度提升，不少指令组合的性能翻倍。Lion Cove与Zen 5相比，则是表现得各有千秋。

大/小核两种微架构都是8-wide级别，小核的一部分指令吞吐甚至超过大核。这也代表着，某些写的不太好、考察不太全面、不够现实世界的跑分软件极其容易出现大小核IPC倒挂的现象。例如PC DIY圈子常用的CPU-Z就会受到小核128bit SSE fadd/fmul同频性能显著超过大核的影响，导致小核跑出特别搞笑的分数。当然了，正如我一直以来所说的那般，CPU-Z自古以来就是个搞笑跑分。如果看到有谁做评测带CPU-Z分数还把它的性能一本正经分析一通而不理解CPU-Z本质上是在跑毫无意义的垃圾指令，基本就可以关掉这个评测不看了，没什么参考价值。

取指令

与AMD Zen 5相同的是，Intel在Lion Cove / Skymont也正式迈入8-wide微架构的时代。不过与AMD那种取巧的方式不同，Intel保质保量地为大核都实现了单周期解码不低于8条x86指令的能力，小核虽然略有局限性但也整体好于单线程的Zen 5。

我们测试Lion Cove / Skymont在不同指令长度下的取指带宽，以IPC的形式展现，并与Raptor Cove / Gracemont组合以及Zen 5进行对比。指令长度为4的对比图里，也加入了最新的ARM Cortex-X4与A720。

从测试中我们可以看出，Lion Cove具有当之无愧的本代最强x86取指令/解码能力：

整体与Raptor Cove表现较为相似，不过在规模方面有所增强（6 wide -> 8 wide）；
解码较短指令时可以在整个L2区域内实现每周期解码8条指令，甚至超出L2也依然有很高的吞吐；
从不同指令长度在L2区域的IPC可以看出，L2到L1i的带宽为16B/cycle；
对于较长的指令（例如8字节），超出op cache容量之后的指令吞吐能力会受到L1i取指带宽的限制，而非指令数量限制；
同样4字节指令的情况下，Lion Cove的指令吞吐能力不亚于ARM最新的Cortex-X4，这对x86处理器来说是极其难得的一件事情。

作为对比，虽然Skymont的模块化前端具有3×3的解码能力且具备单线程使用所有解码器的能力：

Skymont仅在非常小的范围内达到每周期8条指令的理论吞吐，超出后IPC迅速下降到6；
全L1i内取指令的带宽至少为48B/cycle，L2到L1i的带宽为同样的16B/cycle；
Pre-decode cache可以缓存大约192K条指令的边界，并且这些指令并不一定需要存放在L1i中，只是L2到L1i的取指令带宽受限使得只有部分情况下能观察到超过3的IPC；
这些表现与Gracemont整体相近，表现出非常大的局限性。意味着虽然理论发射宽度达到了5/8-wide，实际由于指令的长度/排布等影响，最大IPC有大打折扣的可能；
同样4字节指令的情况下，Skymont的指令吞吐能力显著优于ARM最新的Cortex-A720，这使得其作为一个中核在指令吞吐方面的性能高于ARM的方案。

总的来说，Lion Cove是传统的作派，设计一个较长流水线的monolithic decoder，使用op cache缓解前端的延迟并节省功耗；Skymont延续Gracemont/Crestmont的思路使用模块化解码器提高指令吞吐，使用Pre-decode cache替代op cache实现单线程利用多个解码器模块；AMD的Zen 5则维持单线程4宽x86解码并继续扩展与优化op cache，将双前端设计用于优化SMT性能，单线程的microbenchmark数字略显逊色。

当然，单纯地从顺序取指令的吞吐这个角度并不能评价处理器的实际应用性能。正如我上一篇Zen 5评测里讲到，单线程环境里大部分场景的op cache命中率都是极高的水平。但Lion Cove如此强大解码能力的出现，足以让数码圈子里的很多ARM一派armchair分析师所谓的类似“x86微架构的IPC不如ARM是因为变长指令的解码宽度不够”的论调不攻自破。在2024年，如果说AMD Zen 5架构在指令吞吐方面依然还有所争议，Intel则是毫无疑问地彻底解决了这一问题，使得ARM架构的指令吞吐优势彻底化为虚无。

分支预测

高吞吐的前端需要优秀的分支预测来使其得到充分发挥，现实世界里的很多应用都对前端的延迟非常敏感。接下来我们测试Lion Cove、Skymont与分支预测相关的一些结构，观察前端的综合延迟表现，并与前代Raptor Cove、Gracemont，同代竞品Zen 5等微架构进行简单对比。

BTB测试

大核

从Lion Cove与Raptor Cove的对比中，我们可以观察到

Lion Cove在32分支以内可以单周期执行最多3-4个taken branch，而Raptor Cove为2-3个。这代表着Lion Cove的loop buffer获得了进一步的增强，但是容量疑似略有缩减；
L0 BTB的覆盖范围和容量都有较明显的提升，尤其是对于分支密度较高的场景，但分支较为稀疏的部分场景的等效容量有所下降；
L1/L2 BTB的最大等效容量没有发生特别明显的改动，但是不同test pattern下的表现发生了较大的变化。这里推测实际容量发生下降，但通过一些简单压缩来实现部分场景等效容量维持不变。

与Zen 5相比，我们可以观察到

看不见尾灯了

本代Intel核心在分支预测上的改动，很明显并不完全是奔着性能去。即便使用了远比Intel 10nm (Intel 7)或者7nm (Intel 4/3)更先进的TSMC N3B工艺，他们也没有进一步加大规模，而是在现有规模下进行调整。

个人猜测，这样的调整背后可能是为了更好的能效，毕竟Intel过去几年在这方面一直饱受诟病。而尽管I系御用KOL和某些市场部门的员工在互联网上嘴硬不承认，从我私底下与研发人员的交谈看，Intel自己却是非常希望可以大幅度改进能效一雪前耻的。

小核

小核组这边的状况比大核要好得多。由于规格相近，为了方便直观的对比，我把AMD的Zen 4核心也加入了这一组（希望AMD粉丝们不要把我挂到贴吧黑三天三夜）

可以看到小核与大核比起来，对极其密集无条件跳转的处理能力依然比较差。不过在现实世界中这种情况本身较少，作为一个小核心，在这种边边角角的地方作裁剪可以理解；
- 借助这个测试，我们可以观测到decoder override的延迟，从大约5个周期上升到了7个周期。
  这代表着Skymont的前端取指与解码的延迟周期数相比Gracemont显著变高，这可能是为了更低的SRAM设计压力、更低的电压、高负载下更好的能效，以及更好的极限频率、极限性能这些目的中的一个或多个。同时增长的流水线长度这也体现了Atom团队对于分支预测准确度的信心。
L1 BTB依然为1024条，并且对于密集分支的处理能力相比Gracemont有所调整，密集分支的处理延迟上升一个周期左右；
L2 BTB从5K增加到8K，达到了Zen 4级别。分支类型和密度的覆盖相比Zen 4和Gracemont有较大的优势，但是延迟依然维持了Gracemont的3周期，比Zen 4略高1周期。

从BTB的角度看，Skymont确实做到了上一代x86大核心（Zen 4）的级别。

分支历史追踪能力

Lion Cove

Raptor Cove

Zen 5

Skymont

Gracemont

可以看出，Lion Cove对于分支历史的追踪能力并没有非常显著的提升，与Raptor Cove基本相同；但Skymont再次在这项测试里展现出极大的提升——规模增加到24K分支历史，相比Gracemont与Raptor Cove高出50%。

当然，前面BTB测试里观察到的Skymont流水线的加长也能从这项测试里体现出来。但同时有趣的是Lion Cove的流水线却缩短了。大小核心双向奔赴，左右互搏？

从上述这些测试中，我们可以看到Lion Cove对分支预测相关结构的规模改动比较保守，部分测试里相比Raptor Cove甚至出现了一些倒退；而Skymont相比Gracemont大幅度增加了相关结构。这一点在后续的实际测试数据中也能得到较好的体现。

与AMD Zen 5那令人感到惊讶的分支预测规格相比，Intel的改动则是平平无奇的一代。

实测分支预测准确度：喜忧参半

由于进行测试时最新的Linux内核对Lunar Lake的支持依然比较初级，我们只能收集一些最基本的数据。好在分支预测准确度相关的PMC可以采集，我们收集这些计数器在不同微架构之间作出横比。

根据上述实测数据可以作出一些总结

Lion Cove的分支预测准确度相比Redwood Cove略有下降，后者与Zen 4的水平接近；
Skymont的分支预测准确度获得巨大的改进，超越Lion Cove/Redwood Cove/Zen 4；
Zen 5的分支预测准确度依然稳坐头把交椅。

当我最初看到这个测试数据时，我整个人都是震惊的，并且是对于大、小核分别震惊一次。

很难想象Lion Cove在Golden Cove发布之后的3年间在分支预测这个对CPU来说最为重要的方面不仅没有任何的提升，反而还有倒退。虽然从前面的分支预测相关测试可以看出Lion Cove在这方面的调整并不完全是为了性能，但面对规模小得多的Zen 4与Skymont时依旧力不从心，让人有些开始怀疑Intel的大核团队到底还有没有人有能力在这方面作出改动。

另一方面，Skymont却又向我们展现了Intel出色的微架构迭代能力。在Gracemont发布的3年之后，仅靠与Zen 4相近的BTB规格便做到超越Zen 4的分支预测准确度。考虑到前文所述Atom微架构发展的种种趋势，我认为Atom在本代至少在某些方面已经展现出成为主力大核微架构的潜质。

不得不说在同一家公司内见到差距如此之大的两个团队，属实让人感到唏嘘。也许这就是Intel的特色吧。

内部结构

现代处理器内部为了实现更高的性能所设计的乱序执行结构众多，这里选取一部分比较关键的结构展示，以便直观感受这些微架构的规模与乱序执行能力。部分架构的测试在不太干净的系统环境进行，因此可能会有一些明显的波动，不过不影响大致结果。

从上面两个测试中不难看出，Lion Cove进一步小幅度增加了ROB与整数寄存器的规格，而Skymont在这方面的规格已经增加到大核级别，接近甚至部分超越Zen 5。

在Load/Store方面，Lion Cove的load queue略有缩减，而store queue略有提升；Skymont在这里则是暴露了自己仍然是一个小核心的本质，规模只是相比Gracemont略有提升，远小于大核。

Lion Cove与Skymont在这里都迎来了非常大的提升，但本代向量寄存器容量被Zen 5夺得头筹。

向量寄存器是大/小核心差距最大的地方。这也不难理解，小核的设计目标是以标量/整数负载为主，AVX等指令集以维持软件兼容性为目的。此外，Skymont虽然加倍了向量吞吐，但它的原生向量寄存器位宽依然为128-bit，因此在执行128-bit向量代码时的等效寄存器容量时上述测试里的两倍；而原生256-bit向量寄存器的大核则不会有这种变化。

Lion Cove与Zen 5一样，相比各自的前代都大幅度修改了调度器的设计。

Lion Cove完全放弃了从P6时期沿用至Golden Cove的祖传scalar / vector统一调度器设计，将scalar与vector执行单元的调度器完全分离（Sunny Cove已经改过一次，将load / store拆分）。所以我们可以看到，前代Raptor Lake的scalar / vector指令观察到的调度器容量相近，但本代却各自可观察到不同容量。Zen 5则是Zen架构之后首次设计了scalar执行单元的统一调度器。在连续几代作出修改后，现在Intel与AMD两者的scalar部分的调度器设计基本趋同。

访存

相比常见的Intel H系列处理器，Lunar Lake的缓存规模比较保守：大核L3缓存只有12 MB，是Meteor Lake-H的一半，与Meteor Lake-U相当。但它也有自己的特色，那就是增加了一个8 MB的MSC缓存。我们运行一些内存延迟与带宽测试，来看看这些独特缓存结构的实际表现如何。

延迟

本次我们使用4K page观察随机访问不同容量缓冲区的延迟，以更好地模拟PC处理器日常使用场景，同时可以观察不同层级TLB的影响。

从大核心的延迟测试我们很容易观察到：

Lion Cove的L1延迟下降到4周期，相比Redwood Cove减少一个周期，与Zen 5相同；
Lion Cove在L1与L2之间新增的192K缓存显著降低了这一区域的访存延迟；
Lion Cove的2.5 MB L2缓存在延迟曲线上非常接近Meteor Lake，容量更进一步；
在核心频率相同的情况下，Lion Cove的L3延迟远远低于Meteor Lake的Redwood Cove，从80周期下降到55周期，非常接近AMD的水平；
- 不过这并不是本代的提升，而是Meteor Lake的ring频率倒退导致；
- Meteor Lake的ring频率只有3.3 GHz，而Lunar Lake的L3 cache频率高达4.4 GHz（hwinfo Windows读数），在这方面Lunar Lake甚至要明显强于Arrow Lake；
- 通过对比Raptor Cove很容易发现Lion Cove与其L3延迟周期数相近；
虽然Lion Cove的L3肉眼可见的容量较小，但是由于L2较大，且8MB MSC可以被CPU访问，很好地填补了这一缺失部分。这使其L3容量以外的访存延迟上升的趋势放缓，实际等效缓存容量与Strix Point大核相比并不逊色，只是后段的延迟偏高，这可以通过合适的缓存交换策略来弥补；
Lunar Lake内存延迟大幅度改善，相比Meteor Lake降低了大约180周期，从160ns降低到120ns附近，与Strix Point大致在同一水平。

而观察Skymont的延迟测试曲线：

Skymont L1延迟上升到4周期，相比Gracemont增加一个周期，与大核来到同一水平；
- 这是一个非常重要的变化，与前文里提到的前端取指解码延迟上升相同，这一改变显著放松了缓存的时序，缓解Skymont的L1 cache / SRAM性能压力，提升极限频率；
- 但这也意味着核心需要掩盖的L1延迟显著增加，对核心乱序执行掩盖延迟的能力提出了更高的要求；
Skymont L2缓存在容量翻倍的情况下延迟略有上升；
虽然Skymont LPE没有L3缓存，但其MSC缓存对小核也有非常明显的作用，使其L2缓存外的访存表现远好于Meteor Lake的LPE核心，等效容量与Strix Point的Zen 5c接近，访问延迟高出几十个周期。

单线程带宽

Lunar Lake在单线程内存带宽方面也有不少变化：

相比Meteor Lake的大核，Lunar Lake大核的L2与L3均出现了较大幅度的带宽下降；
- ~~这可能是Intel为了节能而特意为Lunar Lake上的Lion Cove进行的缩减，并不代表Arrow Lake等高性能Lion Cove核心的表现；~~
- 2024/10/26更新：在Arrow Lake中我们也能观察到类似的现象。对于L2，个人推测是由于“L1.5”的加入使得Intel认为L2的带宽压力会下降，而对于L3则可能是因为更大的L2会使得L3的带宽压力下降；
Lion Cove单线程内存读取带宽显著增加，不过从数值上看这并不意味着微架构层面发生了很大的改变，而是因为内存延迟大幅度降低使其prefetcher能够在相近的队列深度下显著提升带宽（参考Little’s Law）。
Skymont将L1的带宽从32B/cycle提升到了48B/cycle，意味着其128-bit向量读取吞吐从2增加到了3。
Skymont LPE单核读取内存的带宽翻倍，考虑到其访存延迟周期数与Meteor Lake LPE并没有太大区别，这代表着其prefetch队列更深。

多线程带宽

从多线程的测试中我们也可以看出Lunar Lake一些变化：

4个P核可以达到96 GB/s的内存读取带宽，比上代6个P核的76 GB/s还要强，远强于AMD单个CCX的61 GB/s；4个E核则有48 GB/s的带宽；
在全核心的测试里依然能观察到大核的L2/L3带宽缩减；
4个E核不再只有两倍于单核的L2读取带宽，而是完整的4倍读取带宽；
全核心带宽可达108 GB/s，远强于Meteor Lake的88 GB/s，也强于Strix Point的96 GB/s。这得益于Lunar Lake更高的理论带宽（128bit LPDDR5x-8533也就是136 GB/s）

总的来说，可以看出Lunar Lake在缓存方面作出了相当多的调整与改进。但我们看到的更多的是“调整与裁剪”而不是继续加大规模，这与其本身注重低功耗的平台特性相符。

除此之外，尽管在缓存带宽方面的缩水较为严重，Lion Cove在延迟方面的改进却相当大，而这正是对整数测试最重要的点，也是本文重点关注的对象。这一点也能体现在后面的SPEC CPU测试的部分子项成绩里。

GPU访存

虽然本文的主要重心是两种CPU核心的测试与对比，不过从GPU侧我们也可以进行一些观察，尤其是带宽方面可以充分检验SoC的真正实力

Lunar Lake的GPU频率较低，远不及HX 370 （2 GHz vs 2.9 GHz），因此其绝对延迟方面的劣势较大，甚至不少缓存区域的延迟差距超过了一倍以上。此外，其访问内存的延迟也有巨大的劣势。

但即便是频率较低的情况下，其L1缓存带宽依然毫不示弱，达到了与Strix Point相近的水平，说明同频下的带宽更高。L2带宽则显得略微乏力。

可以很容易观察到Lunar Lake的GPU末级缓存容量远高于Strix Point，其GPU独占8 MB L2，而相比之下Strix Point则只有2 MB。除此之外，可以很容易看出在8 MB的GPU L2之外，Lunar Lake依然可以在相当大的区域内维持带宽缓慢下降，说明SLC对GPU的访存也有一定的作用。这足以见得Intel在GPU方面的投入之大，当然实际疗效如何还需要看游戏测试，本文不多加分析。

Lunar Lake的LPDDR5x-8533内存在带宽方面相比前代提升较大，测试中的峰值达到了109 GB/s左右。不过Intel GPU在实际测试的带宽方面相比同样内存规格的AMD处理器依然略显逊色。

多核心互联

与AMD、Apple、高通Oryon类似，这一代Intel的小核也不再与大核位于同一个L3 cache domain内，也就是说Lunar Lake的小核是一个类似Meteor Lake LPE的核心。这样做的好处是小核心单独工作时不需要带着整个大核缓存一起唤醒，可以降低低功耗下的静态功耗；坏处是小核不再能享受大缓存带来的性能提升，并且当核心分布于不同cluster时，缓存一致性通常需要在SoC fabric上处理，而这样做通常显著慢于cluster内部。

Intel在Hot Chips 2024上展示了这样一组数据，从结果上看似乎是每次都将cache line分配在测试的两个核心之一附近的best case测试的场景。而我们这次针对Lunar Lake也使用与之前相同的程序测试worst case（也就是每一次核心同步都使用最初分配的cache line进行同步），并与此前相同测试程序测试出Strix Point、Apple Silicon的延迟进行对比。

可以看到，非常令人惊讶的是，Lunar Lake的大小核一致性延迟并没有前面提到的其他SoC那样的问题——在测试缓存一致性时，所有核心仿佛位于同一个cluster。除此之外可以观察到这些细节：

P核之间的最低延迟相比Meteor Lake大幅度下降，回到13700H相近水平；
即便Lunar Lake的L3 cache频率相比Meteor Lake大幅度提升，基本回到13700H的水平，其P核之间每间隔一个节点的延迟增量却反而大幅度提高：从13700H (Raptor Lake) / 155H (Meteor Lake) 的延迟几乎稳定不变改为每跨越一个节点就稳定增加大约5ns；
这一趋势延续到P-E的延迟，整体相比延迟最高的P-P还要多出>5ns；
E-E的延迟的趋势与155H（Meteor Lake）相近，都要高于P-P/P-E延迟；

考虑到Lunar Lake的ring/L3频率并无异常，可以根据这些现象作出以下几点推测

多核心互联一致性不再传统地与L3绑定，而是分离出来作为一个独立的网络运行；
这个互联的频率/性能显著低于此前SoC的ring频率，但是功耗表现可能更佳；
小核心尽管共享同一块L2数据缓存，其在这个一致性网络上却表现出两两一组的设计；
尽管官方公布的测试结果里P/E核心类似两个CCX，但与一般多CCX设计不同的是，Lunar Lake小核进行同步时并不会将cache line拷贝到自己的L2缓存。这点与此前ring上的小核有一定的相似之处，与N305等纯小核的多cluster atom略有不同；
也许可以理解成小核依然跟大核挂在同一个ring上，但是被禁止填充L3。

Lunar Lake这样做的好处很多，可以说是两全其美：既没有双cluster超高互联延迟的问题，又能一定程度避免小核心带起太多的高性能组件产生太高的静态功耗影响低功耗能效。

代价则是一定程度上牺牲大核之间的互联性能，因为跨越节点的潜在互联代价变大，也就是核心数量上的扩展性会变差。Lunar Lake在ring频率不存在明显缺陷的情况下，仅在4大核节点内就有50ns的worst case延迟，在5-6节点内就已经能出现将近70ns的worst case延迟。按照这个趋势，如果扩展到更多的核心数则会产生更严重的问题。因此也不太能根据Lunar Lake的表现去指导Strix Point或者Snapdragon X Elite这类12核心产品的设计。

当然，由于Intel在Hot Chips上公布的细节有限，上述这些内容许多都仅仅只是猜测。但可以肯定的是，我们从Lunar Lake的测试中可以观测到一个比Apple Silicon更加优雅、更适合低功耗使用场景的少量核心多cluster互联设计。

性能测试

本次还是照例分别对大/小核进行SPEC CPU 2017/Geekbench单线程性能测试，并适当选取一些内存配置相近的前代产品、本代竞品进行对比。SPEC CPU数据已与本文同步更新到排行榜。

SPEC CPU 2017

考虑到移动端散热局限性和SPEC CPU长时间高压运行带来的潜在频率不稳定性，本次对大核心选取默频与定频4.2 GHz分别进行测试。除此之外，为了直观对比各个微架构的同频性能，本文也会提供3 GHz附近的Perf / GHz数据。

需要注意的是，本次测试的HX 370与155H均为散热能力较弱的ZenBook系列，因此默频成绩可能会偏低。Lunar Lake为散热相对较好的模具，可以稳定单核4.8 GHz。

默频性能

258V的Lion Cove @ 4.8 GHz在这些测试里，

相比前代Meteor Lake的Redwood Cove（同频）提升约12%；
相比HX 370的Zen 5 @ 5.1 GHz落后约4.4%；
相比M1 Max (Linux) @ 3.23 GHz领先约12.6%；
相比M2 Pro (Linux) @ 3.5 GHz落后约4.9%。

258V的Skymont LP E @ 3.7 GHz在这些测试里，

相比Meteor Lake ring上的Crestmont E核（3.8 GHz）提升约15%；
相比Meteor Lake的Crestmont LP E @ 2.5 GHz核心性能提高一倍；
与HX 370的Zen5c @ 3.3 GHz核心性能差距大约在3%左右。

大核同频性能

在4.2 GHz的同频测试中，

Lion Cove (Lunar Lake)相比Redwood Cove的提升幅度下降到8.96%；
- 从子项分数变化的趋势看，可能是Meteor Lake测试机散热不佳与Meteor Lake Ring频率偏低共同作用导致其默频测试性能较差；
- Lion Cove提升较大的子项为perlbench与exchange2，这是SPEC整数测试里指令吞吐瓶颈最大的两项，也是从6宽提升到8宽理论上最容易获得提升的两项；
- 提升最小乃至倒退的子项是xalancbmk与leela，前者对缓存延迟较为敏感，后者是较为难以分支预测成功的测试，对流水线长度、前后端延迟较为敏感；
- 这说明Lion Cove在吞吐方面进步明显，在前后端整体延迟方面进步不大；
Lion Cove (Lunar Lake)与Zen 5 (APU)的同频综合性能非常接近；
- 由于缺乏具体的PMC数据，以下只能根据以往的profiling经验进行一些粗略的猜测；
- 优势项目为gcc、omnetpp与perlbench；
  - 16 MB L3缓存的AMD平台在这些测试中一直表现不佳，意味着Intel大核心在本代依然有更好的prefetcher，可以在相近的总缓存容量下获得更好的性能；
  - 除此之外新增的192 KB L1缓存和增大的2.5 MB L2缓存也使Lion Cove在更多的情况下有访存优势。
- 劣势项目为xalancbmk、x264与exchange2；
  - xalancbmk对缓存延迟比较敏感，而Lunar Lake的L3较小且延迟相比Zen 5略高，MSC延迟较大等因素可能导致其并不能相比Meteor Lake获得大幅度提升；
  - x264对SIMD整数性能有一定要求，而Lion Cove虽然相比Redwood Cove降低了延迟，但与Zen 5相比依然差距明显；
  - Intel前几代大核在exchange2测试中bad speculation占比较高，本代分支预测提升不大的情况下合理怀疑其分支预测是导致性能差距的主要因素之一。

低频PPC

在 3 GHz附近进行测试，并计算各个处理器的Perf / GHz数据，可以得到下面的结果。为了进一步抹平缓存容量带来的差距，下面这张图表里也额外提供了“非内存/缓存敏感”的子项综合分数（525/531/541/548的geomean）。

当然，小核心相对更保守、更节能的prefetch机制，更小的乱序结构带来的更弱的延迟掩盖能力也会影响其在内存、缓存敏感的测试里使用相同缓存、内存配置时的性能表现，因此“内存/缓存敏感”子项的性能差异并不完全由缓存容量或者内存延迟差异导致。

除此之外需要注意的是，此处的Skymont使用了uncore降频的数据（本文的能效测试部分有详细的解释），因此相比前面3.7 GHz的数据会有明显偏高的访存开销。

在这项测试中，我们更注重观察小核的表现。很容易看出Skymont LPE的表现受到内存、缓存性能的严重拖累：

在缓存/内存不敏感的4个子项里，Skymont的IPC与Lion Cove同频性能相差无几；
这些子项里Skymont相比Crestmont的性能提升也最为明显（+16.5%），超过了Redwood Cove；
与Zen 5c的性能差异也体现出类似的趋势。

Geekbench

相比于SPEC CPU 2017，Geekbench对缓存与内存的压力小得多，并且非常偏向于高指令吞吐而不是流水线延迟敏感。可以看到无论是大核还是小核，在这些测试里的平均提升都要远大于SPEC CPU 2017。这里由于篇幅所限，我们不做过多的分析。

能效测试

新平台的能效测试是一件非常困难的事情，更困难的是对比多个新平台。尤其是对于Lunar Lake这种连供电结构都发生了很大改变的平台，很难确保传感器读数与其它平台具备可比性。

在此基础上，Linux目前对Lunar Lake电源管理的支持较差，idle时会有接近2W左右的package功耗读数。这一点倒是意外地与Strix Point很类似，后者可以观察到一个2.5W左右的idle package读数，通过读取pm table可以看到其中SoC uncore功耗大约1W+。

因此，受限于测试的局限性，本文所提到的Package能效数据仅用作粗略参考，且不针对其进行细致分析。我们会将分析的重点放在Intel IA / AMD VDDCR功耗曲线上。

单线程能效

使用Linux的RAPL接口记录Lunar Lake运行SPEC CPU 2017的功耗，我们可以得到Package功耗与IA功耗的读数。

Package功耗

IA / VDDCR 功耗

此前测试AMD新品时没有时间折腾这个，这是因为AMD处理器常规的MSR / RAPL接口并不能读取到核心VDD的数据，必须自行使用MMIO读取SMU / pm table才能做到。最近也终于抽了点时间把Strix Point的pm table给dump下来解析。不过需要注意一点，那就是从pm table里读取到的是一个瞬时值，会显著受到读取它这一操作本身的影响，因此测得的数值会略微偏高，不如RAPL这种单増energy counter准确。本文我们使用cpupower工具通过CPPC接口将所有不参与测试的核心锁定在较低频率，以尽可能减少影响。

Intel在Linux下的RAPL接口相对比较完善，IA功耗可以与Package功耗一并采集。

排除SoC uncore影响之后，我们能更好地观测核心能效，并且在不同代的SoC之间对比。

Lion Cove在4.6 GHz以上相比移动端Zen 5有2-3%的能效优势，4.6 GHz以下与移动端Zen 5相比能效几乎完全相同；
Skymont LPE在其覆盖的整个功耗范围内性能基本全程遥遥领先所有其他核心，甚至2 GHz下的IA功耗读数只有0.05W；
- 考虑到Intel过去曾经将小核的L2缓存使用uncore FIVR进行供电，我们目前暂时无法确认Lunar Lake RAPL IA功耗读数覆盖小核多少范围以及与其它核心的可比性，因此这一组数据仅供参考。
上一代Meteor Lake两种不同工艺制造的Crestmont核心在低功耗下的IA功耗读数接近，也就是说所谓的“Intel 4”工艺的能效在这一区间约等于TSMC N6水平。
- 同样的功耗下，使用TSMC N3B制造的Skymont的性能大约领先前代Crestmont 50%-125%左右。

从结果上看，不论是看Package功耗还是看核心本体功耗，Lion Cove的能效曲线都与Zen 5几乎重合，相比前代Intel大核心进步明显。但这个表现并不那么令人满意，主要考虑到以下因素

领先一个大节点（N3B vs N4P）
使用类似Apple Silicon的更有利于低功耗的PMIC供电（vs 传统VRM）
极限性能、IPC等关键指标并没有明显优势

在这样的情况下，一个优秀的微架构设计理应做到明显优于竞品的功耗表现，例如Apple M3/M4的单线程能效和性能就远比Strix Point要强。但Lion Cove的表现却只是做到了M2的性能与M1的能效。

另一边的Skymont相比上一代ring上的Crestmont略有性能/能效提升，低功耗下提升更为明显。

需要注意的是，目前版本的Linux下Lunar Lake的uncore频率跟随大核频率变化（Windows无此问题），这导致单独给小核跑负载时内存性能偏低，影响测试成绩。在测试极限性能时我们可以在大核上跑一个main() {for (;;){}} 实现测出最佳内存性能时的小核表现，但测试能效时由于大核必须完全闲置，我们只能测试uncore降频的能效曲线。

考虑到小核本身的现实世界用途是低功耗，这样测试倒也不是没有道理。不过当uncore频率表现正常时（例如Windows下），小核能效曲线末端并不会出现与大核能效倒挂的现象。

无论如何，这都代表Intel一雪前耻，为Windows高端笔记本用户带来了不输AMD的单线程高负载能效与显著优于AMD的低负载功耗。

多线程能效

在高功耗段，Lunar Lake的多线程性能与能效明显不那么好看。特别是Lion Cove在全功耗段都表现出非常差的性能与能效：由于测试平台的局限性，全核频率大约只能稳定在3.8 GHz左右；而在这个频率下，4个Lion Cove核心也只能发挥同频单核的2.7倍性能。在这个范围内哪怕是不使用SMT的4核心Zen 5甚至Zen 5c也能大幅度超越规模相近的Lion Cove。

Skymont LPE在低功耗下的表现则是亮点。虽然图中Strix Point的曲线范围没有完全覆盖，但可以看出4个小核在低功耗下能效超越Zen 5的趋势。4核心Skymont LPE在高功耗段与4核心Zen 2 (Renoir)的表现相近。

而当我们把目光转向仅限核心的功耗，则可以观察到更有效的数据。这里我们引入前代Meteor Lake的Crestmont核心的数据，并且将HX370的数据替换为Zen 5c核心进行对比

Zen 5c 4核8线程的能效略优于2模块8线程的Crestmont。考虑到单个Zen 5c核心不含L2仅仅只有2 mm²左右的面积而Crestmont为1 mm²且后者有3倍大的L3缓存，这体现了Zen 5c核心不俗的PPA指标；
Lion Cove依然表现的相当惨淡，多线程性能甚至不如关闭SMT测试的Zen 5c核心；
同样是单模块4核心4线程的情况下，Skymont LP E在8W附近相比Crestmont多线程性能提升20%左右。这对于LP E核心来说是相当难得的，毕竟少了24 MB L3缓存，替换为性能较低的8 MB SLC缓存；
Skymont与不开启SMT的4核心4线程Zen 5c相比各有千秋，在4W以上略逊于Zen 5c，4W以下则略强一些。作为一个缓存更弱、核心本体面积更小的核心，它在这里展现出了一些PPA优势。
当然，Skymont的制程优势也不能忽略，也许使用同为3nm的Turin dense来进行对比更为合适（可惜这个多半玩不到）。

很显然这样一颗SoC是为了低功耗日常负载而非高性能生产力工作而设计，整体表现也符合它的定位。相比之下Strix Point更适合与Arrow Lake-H进行比较。

多线程Scaling

上面Lion Cove惨淡的多线程表现让我非常好奇，因此我顺便收集了Lunar Lake同频的单/多线程性能数据。

我们可以很容易看出，凡是对内存、缓存访问负载压力较重的测试项里，Lion Cove多线程均体现出了相当差的scaling，尽管它与Skymont相比拥有更强的缓存结构和内存带宽资源。从前文中的测试我们也可以看出，Lion Cove访存的带宽和延迟等并不存在明显问题。

这一现象可能可以归结为早期BIOS固件、系统支持不成熟，也可能是本身设计使然，有待后续进一步测试。

待机功耗

Lunar Lake除了高负载的能效改进巨大之外，其低负载下的待机功耗也非常优秀。上图是Lunar Lake在Windows桌面静置时的hwinfo功耗读数。

从上面的这些测试结论里我们可以看出，Lunar Lake无论是大核、小核的高负载能效，还是静置下的待机功耗，都是非常优秀的水准。可以预期的是Lunar Lake会成为x86的续航王者，并且很长一段时间内不会被超越。

总结与评价

在这样一个新的产品出现时，我们自然也要分别评价产品本身以及对Intel本代产品、未来发展的整体看法。

Lunar Lake

如果要用一句话来概括Lunar Lake，那么我会说它是高端Windows笔记本PC的强心剂。在Intel多年饱受高功耗、低续航困扰，且Intel以外的竞品如AMD、高通等进军高端笔记本多年也并不顺利的情况下，Lunar Lake的出现为Windows高端轻薄本重新带来了生机。

毫无疑问，如果你对Windows/Linux PC阵营类似MacBook Air定位的产品感兴趣，那么我会向你推荐Lunar Lake高端轻薄本。如果你对多线程性能有任何需求，Lunar Lake则没有Arrow Lake合适，尽管日常体验方面它的表现确实会更好。

不幸的是，尽管有这样一个定位清晰、表现优秀的产品，Intel的市场部门似乎依然永远无法停止他们那厚颜无耻的整活行为。尽管Lunar Lake定位类似iPad、MacBook Air的低功耗移动设备，他们依然试图使用Lunar Lake去碰瓷其他高性能平台的性能，以便把不懂电脑的小白忽悠去买不适合他们的机器。在Intel Lunar Lake Tech Day和Hot Chips 2024之后，我还在Twitter评论区公开赞扬Intel展示的数据与我所实际测得的数据高度一致，比隔壁AMD整天只知道AI AI AI要有干货得多；谁又能想到9月3日的Lunar Lake正式发布会上我能看到如此震撼人心的内容。

Intel在9月3日发布的宣传材料以及媒体通稿里至少有以下几点明显的问题：

Intel声称Lunar Lake的DRAM延迟是90ns，比前代Meteor Lake、竞品Strix Point分别低40%和30%；
这是一个非常无耻的偷梁换柱行为，甚至与Intel自己此前Hot Chips的数据相矛盾，专门忽悠电脑小白。
Intel在footnote里提到90ns的延迟使用AIDA64测得，但Meteor Lake、Strix Point的数字来自第三方，使用的是别的工具。真实的内存延迟水平如Intel的Hot Chips PPT与本文所测得，Lunar Lake相比Strix Point并无明显优势，相比Meteor Lake有提升但也只是低了25%左右。
Intel声称Lunar Lake的SPEC int 单线程整数性能比Strix Point高21%（相比X1E78100提升+33% vs +61%）
Intel在其网站页面上并未给出竞争对手的详细的编译器参数和测试报告，而不提供编译器参数细节的SPEC测试可以基本被认定为无法复现的无效测试，其成绩操作空间极大。
这项测试的结论也与本文严重不符。本文的测试里使用不偏向于任何一方的编译器参数和系统环境时，两者同频性能非常接近。
Intel声称Lunar Lake“相比前代最高3倍的Performance Per Thread”
实际上是做了类似ARM服务器喜欢做的事情：通过消灭超线程来“大幅度提升” “每线程性能”，而不是老老实实与前代同等规模处理器，比如关闭到4+4无SMT的Meteor Lake，进行对比。想不到2024年的Intel也会堕落到玩这种文字游戏。
Intel声称Lunar Lake在Geekbench AI CPU测试里的性能大幅度领先Strix Point
实际上Intel使用性能最好的OpenVINO CPU模式测试Lunar Lake，使用性能较差的ONNX CPU模式测试Strix Point。当二者使用相同模式时（OpenVINO CPU推理也支持AMD处理器），Strix Point比Lunar Lake的性能大约高出60%甚至更高（取决于功耗墙）
Intel使用的Strix Point测试机正好是我目前使用的这一台华硕Zenbook S16 OLED（也就是灵耀16 Air），而这是市面上能找到的性能、散热与供电效率最差的Strix Point机型，没有之一。
这不仅影响功耗墙和多核性能上限，也会影响同功耗下的效能与单核性能。譬如，同为HX 370的散热良好机型，其运行Cinebench单线程可以稳定在5.15 GHz，而Zenbook在长时间高负载的单线程应用里会降频到4.8 GHz附近。而哪怕固定在28W的功耗墙下，Zenbook的多线程跑分与核显游戏性能也远远落后于其余所有Strix Point机型。
华硕在这一台机器上为了极致的厚度牺牲性能和效率可以理解，我正是看中这一点才选择购买这个型号。但这是一个相对小众的昂贵产品，其余任何Strix Point机型并不是这样。因此Intel的营销材料里所有与HX 370相关的性能测试都是故意找的完全没有任何普遍参考价值的极端案例。

前阵子看到有网友开玩笑说Intel的核心技术是营销，当时我还不怎么当真。但在看了Intel对Lunar Lake的营销里这么多神奇操作之后，我也不得不思考这样的说法是否真的有一定的道理，毕竟Intel最近刚刚宣布大裁员，其搅混水的营销能力却丝毫未曾减弱。

Intel

对于整个Intel来说，Lunar Lake虽然表现出色，但它所展示的并不完全是一个好的兆头，反而让我们看到了一丝隐忧：

Lunar Lake的能效与续航用了非常大的代价才得以实现（先进工艺+高级封装+定制PMIC），并牺牲了绝对性能。这使其脱离一部分对性能有需求但又不追求极致轻薄续航的主流、价格敏感型用户；
Intel未来数年没有接替Raptor Lake H45的廉价产品路线图。现今13500H的竞争力和毛利率已经非常惨淡，竞争对手又会连续多年更新主流价位的廉价SoC型号；
Lion Cove作为Intel的主力大核微架构，虽然是全新的微架构设计并且有不少亮点，但依然能看到Intel与Apple、AMD等厂商的微架构设计实力差距大到甚至连领先一代工艺都补不回来；
Skymont小核虽然进步巨大，但是性能与大核架构的差距依然客观存在，且作为一个相对偏科的选手暂时难以完全扛起大梁。坊间传闻还经常有Intel内斗导致Atom团队拿不到高性能核心的项目的故事。

虽然这些与Lunar Lake产品本身的表现没有任何关系，并不能作为对产品本身的批评，但它也确实是这个产品折射出的一些现实问题。

不管Intel的未来如何，这都不能否认Lunar Lake作为一款高端产品的整体表现非常优秀。而性能更强的Lion Cove、Skymont核心也将会跟随着Arrow Lake走入我们的视野，期待后续的测试可以让这些新的微架构发挥它们最强的性能。