Arm desktop: so many cores, not enough speed

# so many cores, not enough speed – Marcin Juszkiewicz Source: [https://marcin.juszkiewicz.com.pl/2026/06/01/arm-desktop-so-many-cores-not-enough-speed](https://marcin.juszkiewicz.com.pl/2026/06/01/arm-desktop-so-many-cores-not-enough-speed) This post is part 6 of the "Let me try to use an AArch64 system as a desktop" series: 1. [AArch64 desktop: day one](https://marcin.juszkiewicz.com.pl/2015/09/21/aarch64-desktop-day-one/) 2. [AArch64 desktop: day two](https://marcin.juszkiewicz.com.pl/2015/09/22/aarch64-desktop-day-two/) 3. [AArch64 desktop: last day](https://marcin.juszkiewicz.com.pl/2015/09/25/aarch64-desktop-last-day/) 4. [Arm desktop: 2025 attempt, part one](https://marcin.juszkiewicz.com.pl/2025/07/07/arm-desktop-2025-attempt-part-one/) 5. [Arm desktop: emulation](https://marcin.juszkiewicz.com.pl/2025/07/22/arm-desktop-emulation/) 6. [Arm desktop: so many cores, not enough speed](https://marcin.juszkiewicz.com.pl/2026/06/01/arm-desktop-so-many-cores-not-enough-speed/) Using a system with 80 AArch64 cores can be a pleasure\. Or a pain… ### Multicore heaven? Having 80 cores sounds nice, doesn’t it? But not so much during actual use… You see, building Fedora packages was flying by\. With all cores in use, ccache buffers filling up \(in case of rebuilds\), and 128GBofRAMin constant use, etc\. But at the same time, 100% load on all cores means you cannot listen to music on Spotify or watch online videos, etc\. All that because theCPUcores are occupied by the build processes\. I tried to use cgroups to limit`cpu\.max`for each`fedpkg mockbuild`call\. It did not help much: the audio was still jerky\. To compare: I wrote this post on a system powered by a Ryzen 5 3600CPUwhile a package build was running in the background\. All twelveCPUthreads were 100% busy, yet the music did not skip\. All of this shows that cores\-heavy CPUs are perhaps not a good choice for a desktop machine\. Latencies, the scheduler and context switching — all of this introduces enough noise to make a desktop user suffer\. ### The lack of single\-thread speed Arm processors are good in many cases, as long as you do not need pure, single\-thread,CPUpower\. It is very noticeable in a web browser\. For example, Bitwarden unlocks with a noticeable delay, while on a Ryzen 5 3600, it is nearly instant\. And it feels even worse when you watch some YouTube videos like “who will make fasterPCon a €100 budget”, and then you run the same browser benchmark and get worse results… Many software builds also highlight this problem\. I have a feeling that developers have grown used to a small number of fastCPUcores, which is the norm on the x86\-64 architecture, and their code is written to take it for granted\. And then you look at your machine, where 70 cores do nothing, waiting for some code to finally compile or link\. I have seen one software package where the bootstrap was composed of**TWO**source files\. Both were over two megabytes in size and full of machine\-generated C code\. Two cores were kept busy for quite a while, while the other 78 had to wait\. Not much has changed since my[the “From the diary of AArch64 porter — parallel builds”](https://marcin.juszkiewicz.com.pl/2018/06/06/from-the-diary-of-aarch64-porter-parallel-builds/)blog post from eight years ago\. Of course, there are also packages which will take all cores, whole memory and as much swap as possible, and do magic in nearly no time\. When I started build of the PrusaSlicer package, I had to add some swap because Firefox was gone due toOOM\. Having less than 2GBofRAMperCPUcore really sucks ;D ### Summary To use a desktop system you do not need many cores\. As long as they are fast\.