Arm Desktop: Many Cores, Not Enough Speed

In the sixth installment of the Let me try to use an AArch64 system as a desktop series, Marcin Juszkiewicz turns his attention from the raw joy of compiling thousands of packages to the quieter, more personal side of computing: listening to music, watching videos, and browsing the web while the machine is busy building software. The experiment uses a server‑grade board that houses 80 AArch64 cores and 128 GB of RAM. On paper, such a configuration should make any developer’s heart race, yet the day‑to‑day experience tells a different story.

The Core Argument

Juszkiewicz observes that when all 80 cores are saturated by Fedora package builds, the system becomes unresponsive to interactive workloads. Audio playback on Spotify stutters, video streams buffer, and even simple UI actions feel laggy. By contrast, a modest Ryzen 5 3600 (12 threads) running the same background build keeps the music smooth, despite the identical CPU utilisation.

The discrepancy, he argues, stems from two intertwined factors:

1. Low single‑thread throughput – Arm cores in this platform prioritize power efficiency and parallel density over raw clock speed. When a task cannot be split across many threads, the latency of each individual core becomes noticeable.
2. Scheduler and context‑switch overhead – With dozens of runnable threads, the Linux scheduler must constantly shuffle tasks, and each switch adds latency that compounds for interactive processes.

Evidence from Real‑World Usage

• Build performance – Compiling Fedora packages is fast in aggregate; the massive core count reduces wall‑clock time for large, well‑parallelised builds.
• Resource contention – The same builds consume most of the 128 GB RAM, leaving little headroom for desktop applications. During a PrusaSlicer build, the author had to add swap because Firefox was terminated by the OOM killer.
• Uneven workload distribution – Some packages, such as a bootstrap step consisting of two massive generated C files, only occupy two cores while the remaining 78 sit idle, waiting for the next stage. This illustrates that many codebases are not written to exploit extreme parallelism.

Implications for Desktop Design

The experiment suggests that a desktop does not benefit from a sheer number of cores unless the software stack is explicitly engineered for that scale. For the average user, high per‑core performance remains the decisive metric. This has several practical consequences:

• Hardware selection – When choosing a workstation for development, a balance between core count and clock speed should be struck. A mid‑range x86‑64 CPU with strong single‑thread numbers often delivers a smoother interactive experience than a high‑core Arm server chip.
• Operating‑system tuning – Simple cgroup limits (cpu.max) were insufficient to protect interactive latency. More sophisticated approaches, such as real‑time scheduling classes or priority boosting for UI threads, may be required.
• Software engineering – Developers need to revisit assumptions about the target architecture. Parallelising algorithms is valuable, but they must also consider the quality of parallelism: avoiding long serial sections, reducing contention for shared resources, and ensuring that background workloads can be throttled without starving the foreground.

Counter‑Perspectives

Proponents of high‑core Arm systems argue that the problem is not the hardware but the ecosystem. They point out that many server‑oriented distributions already provide mechanisms like nice levels, ionice, and systemd slice configurations to isolate interactive workloads. Moreover, as compilers and build systems evolve (e.g., Meson, Ninja), they can better distribute work across many cores, potentially narrowing the gap.

Another view is that the use‑case presented—running a full Fedora build while simultaneously demanding low‑latency UI—represents a worst‑case scenario rather than typical desktop behaviour. Users who primarily run containerised services, compile intermittently, or employ dedicated build machines may find the trade‑off acceptable.

Concluding Thoughts

Juszkiewicz’s narrative underscores a timeless lesson: more hardware does not automatically translate to a better user experience. For a desktop, the sweet spot lies where the processor can finish background tasks quickly and return cycles to the foreground with minimal delay. Until the Arm ecosystem delivers cores that combine high parallelism with competitive single‑thread performance, developers and power users will likely continue to favour traditional x86‑64 CPUs for their day‑to‑day machines.

If you wish to discuss these findings, the author invites comments on his Mastodon post.