几个月前，我曾有机会测试Intel专为超轻薄笔记本打造的Lunar Lake处理器。尽管其独特的设计让它脱颖而出，但在绝对性能方面的弱势意味着它可能并不适合大多数用户的主流PC需求。
对于主流笔记本产品线来说，Intel推出了Arrow Lake H45作为Meteor Lake的继承者。本次，我将对Arrow Lake H45中的酷睿Ultra 7型号（255H）进行测试。
声明：本文仅为个人测试，测试使用的一切设备、工具等资产与本人所在公司/职位无关，也没有接受任何赞助。
自从大语言模型开始流行以来，一直在AI领域深耕细作的NVIDIA直接获得了大量订单，导致产品供不应求，人们也一直在寻找更便宜的方案。这给了我们评估许多其它方案的机会，例如我前些时尝试搭建的W7900方案就是一个可行的替代。
碰巧的是，Apple刚好在LLM大火的时间点前后接连发布M1 / M2 Ultra，最大带来了128 / 192 GB且带宽高达800 GB/s的内存。考虑到本地运行LLM最大的瓶颈是显存容量和显存带宽，两者似乎是一拍即合，在数码媒体的渲染下创造了多个类似“Mac Studio > 6 * RTX 4090”的名场面。
事实真的是如此吗？经过实际测试，我发现尽管Apple Silicon可以将超大显存装进常规轻薄笔记本电脑，但在运行LLM方面存在各种妥协，使得苹果平台并没有比NVIDIA方案的性价比更高。
devil’s in the details
本文我们使用一组实测数据来介绍目前的现状。 继续阅读
简单举例讲一下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的跨核心同步延迟，并提供一些大致的数据参考。
继续阅读