几个月前，我曾有机会测试Intel专为超轻薄笔记本打造的Lunar Lake处理器。尽管其独特的设计让它脱颖而出，但在绝对性能方面的弱势意味着它可能并不适合大多数用户的主流PC需求。
对于主流笔记本产品线来说，Intel推出了Arrow Lake H45作为Meteor Lake的继承者。本次，我将对Arrow Lake H45中的酷睿Ultra 7型号（255H）进行测试。
声明：本文仅为个人测试，测试使用的一切设备、工具等资产与本人所在公司/职位无关，也没有接受任何赞助。
简单举例讲一下Linux的调度器是如何顾此失彼，以及一些硬件厂商的贡献者和维护者不在乎feature是否真的工作，造成用户困扰的。
前阵子在测试Strix Point与Lunar Lake等平台的CPU时，我偶然发现本代处理器在核间延迟这一指标上的一些变化。众所周知同步与互斥是现代复杂多线程软件高度依赖的原语之一，对其进行性能优化也是多线程编程的一大难点。多核处理器在硬件层面高效率地设计并实现同步，在工程上也是一个不小的挑战。
事实上，同步延迟这一概念不仅是对于CPU，其对于GPU也是一个重要的指标。在理想世界里，GPU可以以极高的吞吐并行处理大量毫不相关的数据。但现实是随着GPU规模的不断扩大，在一部分例如Gaming的领域的GPU应用已经出现了非常严重的并行度瓶颈，小规模数据的计算之间互相依赖导致不同层级的交互延迟成为瓶颈。
与CPU核心相对应，在GPU上处于类似层级的结构是SM (NVIDIA) / CU (OpenCL | AMD GCN)等等，一些厂商如Intel和Apple也将其直接称为GPU核心。而家用GPU的SM/CU核心数量远远超过普通家用CPU (144/96 vs 24)，数据中心GPU更是如此(160/304 vs 32-128)，这意味着为这些处理器核心的缓存一致性互联设计也会更加具有挑战性。
本文以我手边可用的一些硬件，搭配ROCm/HIP编程环境讲解如何使用类似测试CPU的手段来测量GPU的跨核心同步延迟，并提供一些大致的数据参考。
继续阅读
上一篇文章里，我们浅显地聊到了Zen 5的微架构层面的变化，主要是规模的扩大、指令吞吐的提升，以及最关键的关于分支预测的改动。
本文我们将会进行一些性能分析与对比，观察Zen 5微架构这些改动会对实际负载造成怎样的影响，与前代相比会发生怎样的变化。
由于桌面Zen 5也就是Ryzen 9000系列的高端型号暂时没有发售，因此本文目前依然是使用移动端HX 370进行测试。后续会直接将有价值的数据补充在本文。
2024/08/13 更新：修正了因为GCC bug引起的x264子项测试数据问题。此前沿用了部分znver3的老数据，但是新测试的数据使用znver4导致得出x264几乎无提升的结论。统一flag之后无论是znver3还是znver4/5均可获得类似的提升幅度。更新后将所有此前使用-march=znver4测试的Zen 4/5的数据使用-march=znver3重新测试。