为什么 E 核心让 Apple Silicon 更快
Source: Hacker News
观察启动时的 CPU 使用情况
- 从冷启动启动你的 Apple Silicon Mac。
- 打开 Activity Monitor，切换到 CPU 视图，并打开 CPU History 窗口。
在前五到十分钟内，你会看到 E 核心被以下进程点亮：
- Spotlight 索引服务
CGPDFServicemediaanalysisdBackgroundShortcutRunner- Siri 组件
- 初始的 Time Machine 备份
- XProtect Remediator 扫描
与此同时，P 核心基本保持空闲，为你启动的应用留出充足的容量。
看到许多进程的 CPU 使用率超过 100 % 对于以前使用 Intel‑Mac 的用户来说可能会感到惊慌，因为他们知道单核的高负载会削弱前台性能。然而在 Apple Silicon 上，这些高百分比往往属于同时占用约 50 % CPU 的数十个 mdworker 进程——这正是该架构设计来处理的情况。视觉上的对比具有误导性，因为在“100 %”下运行的 E 核心的频率大约只有同等百分比的 P 核心的四分之一，所以原始数字 不可 直接比较。（参见关于 Activity Monitor 中 CPU 使用率为何可能误导的讨论： .）
big.LITTLE 概念与服务质量（QoS）
Apple 在 2016 年的 iPhone 7 中引入了独立的 P 核心和 E 核心，采用了 Arm 的 big.LITTLE 架构（该架构于 2011 年公布）。这一想法早先曾被 Cray 等组织探索过（）。
Apple Silicon Mac 与众不同之处在于，线程会根据 服务质量（Quality of Service，QoS） 分配到两类核心上。QoS 是在 OS X 10.10 Yosemite（）中引入的度量标准。当所有核心相同的时候，QoS 相比传统的调度优先级（如 POSIX nice）的收益有限。后台任务仍然需要运行，降低它们的优先级只会延长它们的执行时间，从而延长它们与用户应用竞争 CPU 周期的时间。
基于 QoS 的线程调度
Apple 在 iOS 设备上的经验促成了 macOS 的精细化做法：
- 前台线程 – 在有可用的 P 核心时优先调度到 P 核心，但在需要时也可以回退到 E 核心。
- 后台线程 – 限制在 E 核心上；即使 E 核心负载很高，也不会提升到 P 核心。
这种行为可以通过 St. Clair Software 的 App Tamer（）以及命令行工具 taskpolicy 观察到，后者无法强制将后台线程放到 P 核心上。
因此，即使你看到在启动后不久大量后台进程已经饱和了 E 核心，macOS 仍会刻意让 P 核心保持空闲，以供前台工作使用。若让后台线程占用 P 核心，会模糊前台/后台的界限，降低应用响应速度，并增加电池消耗。这也消除了过去经常导致卡顿的 “mdworker 进程崩溃” 问题（）。
对软件架构和性能的影响
后台任务显示的高 CPU 百分比看起来可能令人畏惧，但它们反映了软件设计的转变：
- 应用程序正日益被拆分为离散的进程，按需在后台运行。
- 一台空闲的 Mac 可能拥有 超过 2,000 条线程，跨 600 多个进程；这些线程越多地在 E 核心上运行，前台体验就会越快。
Apple 的 M 系列芯片逐步增加了 E 核心的数量。M1 Pro 和 M1 Max 是最后只配备两个 E 核心的型号；更新的机型至少配备四个 E 核心，有的甚至提供六个或八个。
由于效率核心负责后台工作，性能核心则保留给用户最关心的任务，从而实现速度与能效的双重提升。