Arm桌面：核心众多，速度不足

# 核心太多，速度不够 – Marcin Juszkiewicz 来源：https://marcin.juszkiewicz.com.pl/2026/06/01/arm-desktop-so-many-cores-not-enough-speed 本文是“让我试试用 AArch64 系统当桌面”系列的第 6 篇： 1. AArch64 桌面：第一天 (https://marcin.juszkiewicz.com.pl/2015/09/21/aarch64-desktop-day-one/) 2. AArch64 桌面：第二天 (https://marcin.juszkiewicz.com.pl/2015/09/22/aarch64-desktop-day-two/) 3. AArch64 桌面：最后一天 (https://marcin.juszkiewicz.com.pl/2015/09/25/aarch64-desktop-last-day/) 4. Arm 桌面：2025 年尝试，第一部分 (https://marcin.juszkiewicz.com.pl/2025/07/07/arm-desktop-2025-attempt-part-one/) 5. Arm 桌面：模拟 (https://marcin.juszkiewicz.com.pl/2025/07/22/arm-desktop-emulation/) 6. Arm 桌面：核心太多，速度不够 (https://marcin.juszkiewicz.com.pl/2026/06/01/arm-desktop-so-many-cores-not-enough-speed/) 用一台有 80 个 AArch64 核心的系统，可能很爽，也可能很痛苦…… ### 多核天堂？ 有 80 个核心听起来不错吧？但实际用起来可就不是那么回事了…… 你看，编译 Fedora 软件包时跑得飞快——所有核心都在干活，ccache 缓冲区（重编时）被塞满，128GB 内存一直在用，等等。 但与此同时，核心 100% 满载意味着你没法在 Spotify 上听歌，也没法看在线视频之类的——因为 CPU 核心全被编译进程占用了。 我试过用 cgroups 限制每次 `fedpkg mockbuild` 调用的 `cpu.max`，但效果不大：音频还是卡顿。 对比一下：这篇文章是在一台搭载 Ryzen 5 3600 CPU 的系统上写的，后台同时运行着软件包编译。所有 12 个 CPU 线程 100% 繁忙，但音乐却一点没卡。 这说明，核心多的 CPU 可能并不适合当桌面机。延迟、调度器、上下文切换——这些都会引入足够的干扰，让桌面用户难受。 ### 单线程速度的缺失 Arm 处理器在很多场景下表现不错，前提是你不需要纯粹的单线程 CPU 性能。 在网页浏览器里这一点尤其明显。比如 Bitwarden 解锁时会有明显的延迟，而在 Ryzen 5 3600 上几乎是瞬间完成。当你观看一些 YouTube 视频（比如“谁能在 100 欧元预算下造出更快的 PC”），然后自己跑同样的浏览器基准测试却得到更差的结果时，这种感觉会更糟。 很多软件编译也凸显了这个问题。我感觉开发者们已经习惯了少量但快速的 CPU 核心（这是 x86-64 架构的常态），并且他们的代码默认就依赖这种条件。 然后你看着自己的机器，70 个核心闲在那里，等着某些代码终于编译或链接完成。我曾见过一个软件包，它的引导部分只有**两个**源文件。两个文件都超过两兆字节，里面全是机器生成的 C 代码。两个核心忙活了好一阵子，而其他 78 个核心只能等着。 八年前我写过一篇博文《从 AArch64 移植者日记看并行编译》(https://marcin.juszkiewicz.com.pl/2018/06/06/from-the-diary-of-aarch64-porter-parallel-builds/)，情况到现在也没太大变化。 当然，也有一些软件包会用满所有核心、全部内存和尽可能多的交换空间，然后几乎瞬间完成魔法般的工作。当我开始编译 PrusaSlicer 包时，不得不加一些交换空间，因为 Firefox 已经因为 OOM 崩溃了。每核心不到 2GB 内存真是糟透了 ;D ### 总结 要使用桌面系统，你并不需要很多核心。只要它们足够快就行。