Apple 的 M1 处理器是世界一流的台式机和笔记本电脑处理器，但对于通用最终用户系统而言，速度甚至比速度还要好。当然，我们指的是 感觉快——这更多地与系统可预测和可靠地满足用户期望有关，而不是原始速度。
Howard Oakley是 Cormorant、Spundle 和 Stibium 等Mac 原生实用程序的作者， 他深入挖掘了为什么他的 M1 Mac 感觉比英特尔 Mac 更快，他得出的结论是 QoS。如果您不熟悉这个术语，它是 Quality of Service 的缩写，它与任务调度有关。
更多的吞吐量并不总是意味着更快乐的用户
将“性能”等同于吞吐量是一种非常普遍的趋势——粗略地说，每单位时间完成的任务。尽管吞吐量通常是最容易衡量的指标，但它与人类的感知并没有很好的对应关系。人们通常注意到的不是吞吐量，而是延迟——不是任务可以完成的次数，而是完成单个任务所需的时间。
在 Ars，我们自己的Wi-Fi 测试指标遵循这个概念——我们测量在合理正常的网络条件下加载模拟网页所需的时间，而不是测量网页(或其他任何东西)可以加载的次数每秒运行一次。
我们还可以看到一个反面的例子——最快的吞吐量对应于明显不满意的用户——大约在 2006 年 在 Linux 内核中引入了完全公平队列 ( cfq) I/O 调度程序。cfq可以广泛调整，但在其开箱即用的配置中，它通过重新排序磁盘读取和写入以最大限度地减少查找，然后为所有活动进程提供循环服务来最大化吞吐量。
不幸的是，虽然cfq实际上确实显着提高了最大吞吐量，但它是在增加任务延迟的情况下实现的——这意味着中等负载的系统对其用户感觉迟钝且反应迟钝，从而导致大量投诉。
尽管cfq可以针对更低的延迟进行调整，但大多数不满意的用户只是将其完全替换为类似noop 或deadline 相反的竞争调度程序——尽管最大吞吐量较低，但降低的个人延迟使桌面/交互式用户对他们的机器感觉速度更满意。
在发现以延迟为代价的次优吞吐量最大化之后，大多数 Linux 发行版都cfq 像许多用户一样远离了。Red Hat在 2013 年放弃cfq 了deadline，RHEL 7 也是如此——Ubuntu 紧随其后在 2014 年Trusty Tahr (14.04)版本中也紧随其后。截至 2019 年，Ubuntu 已 完全弃用 cfq。
Big Sur 和 Apple M1 的 QoS
当 Oakley 注意到 Mac 用户经常称赞 M1 Mac 感觉非常快时——尽管性能测量并不总是支持这些感觉——他仔细研究了 macOS 原生任务调度。
MacOS的提供四种直接指定任务的优先级别，从低到高，它们是background，utility，userInitiated，和userInteractive。还有第五个级别(默认值，当没有手动指定 QoS 级别时)允许 macOS 自行决定任务的重要性。
无论您的 Mac 是由 Intel 驱动还是 Apple Silicon 驱动，这五个 QoS 级别都是相同的，但 QoS 的施加方式有所不同。在八核 Intel Xeon W CPU 上，如果系统空闲，macOS 将在所有八核上安排任何任务，而不管 QoS 设置如何。但在 M1 上，即使系统完全空闲，background 优先级任务也仅在 M1 的四个高效/低功耗Icestorm 内核上运行，而让四个更高性能的Firestorm 内核处于空闲状态。
尽管这使得 Oakley 在 M1 Mac 上用压缩 10GB 测试文件来测试系统的低优先级任务比 Intel Mac 慢，但在“空闲系统”到“非常繁忙的系统”的范围内，操作更加一致。 ”
与Operations 更高的QoS设置也比Intel的Mac-Mac系统的意愿，抛售低优先级任务到执行更一致的M1Icestorm 内核只留下一个更高性能的Firestorm 内核卸载，并准备迅速和持续时回应都userInitiated 与userInteractive 任务所需的处理。
Apple 针对 M1 Mac 的 QoS 策略是针对工作负载中的实际痛点而不是追逐任意指标的工程设计的绝佳示例。离开高性能Firestorm 执行时内核空闲background 任务意味着他们可以把他们的全部性能的userInitiated 和userInteractive 任务，因为他们进来，避免了看法，认为系统没有反应，甚至“忽略”的用户。
值得注意的是，Big Sur 肯定 可以采用与八核英特尔处理器相同的策略。尽管 x86 上的内核性能没有类似的大/小差异，但没有什么能阻止操作系统随意声明一定数量的内核background 。让 Apple M1 感觉如此快的原因并不是它的四个核心比其他核心慢——而是操作系统愿意牺牲最大吞吐量来支持更低的任务延迟。
还值得注意的是，M1 Mac 用户看到的交互性改进首先严重依赖于正确安排的任务——如果开发人员不愿意background 在适当的时候使用低优先级 队列，因为他们不希望他们的应用程序看起来慢，大家都输了。Apple 异常的垂直软件堆栈在这里可能有很大帮助，因为 Apple 开发人员更有可能优先考虑整体系统响应能力，即使如果仔细检查它可能会使他们的代码“看起来很糟糕”。
如果您对有关如何在 M1 和 Intel Mac 上应用 QoS 级别及其产生的影响的更多详细信息感兴趣，我们强烈建议您在此处和此处查看 Oakley 的原创作品，以及macOS 活动中的 CPU 历史截图监控 Oakley 在两种不同的架构上以不同的优先级运行任务。