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:

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 128 GB of RAM in 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 the CPU cores 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 3600 CPU while a package build was running in the background. All twelve CPU threads 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, CPU power.

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 faster PC on 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 fast CPU cores, 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” 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 to OOM. Having less than 2 GB of RAM per CPU core really sucks ;D

Summary

To use a desktop system you do not need many cores. As long as they are fast.

Marcin Juszkiewicz