Arm desktop: so many cores, not enough speed

Arm desktop: so many cores, not enough speed – Marcin Juszkiewicz

This post is part 6 of the "Let me try to use an AArch64 system as a desktop" series:

AArch64 desktop: day one

AArch64 desktop: day two

AArch64 desktop: last day

Arm desktop: 2025 attempt, part one

Arm desktop: emulation

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 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.

aarch64 computers desktop fedora

Comments?

If you want to comment, head over to my post on Mastodon.

Arm desktop: emulation

Arm desktop: 2025 attempt, part one

I got HoneyComb

AArch64 desktop hardware?

AArch64 desktop: day one

3D printing at home "

About me

I work at Red Hat. Mostly on AArch64 support in several projects.

I am also known as 'hrw' (/hʌ eə vʊ/).

This website does not use cookies. Server logs contain IP address and user agent info. You can leave if you disagree.

GDPR information if you want to read such policies.

Useful tables

AArch64 SoC features

AArch64 cpu core information

Arm BSA/PC-BSA/SBSA checklist

FOSDEM videos

Linux kernel system calls for all architectures

Arm desktop: so many cores, not enough speed

Related Articles

The Newest Instagram "Exploit" Is the Goofiest I've Seen

It's Not Just X. It's Y

Amazon, Facebook, FBI have access to a private intelligence-sharing network

Show HN: GoPeek – open links in live mini browser windows without new tabs

Agent Memory: An Anatomy