Demonstrating the Power of Apple Silicon using Actuated CI
As you may have read in my previous blog posts, my main developer workstation is an Apple Mac Studio with an Apple Silicon M1 Max CPU. But instead of running macOS on it, I run Linux – specifically Fedora Asahi Remix, which is Fedora Linux for ARM + the native Apple hardware support provided by the Asahi Linux project.
While I prefer Linux to other operating systems, the main reason I do this is for speed – running Linux natively on my Mac Studio is at least twice as fast for every task compared to running macOS natively on it. Linux is simply faster and more optimized, and it can fully harness the power of the M1 Max.
A short while back, Alex Ellis, the founder of Actuated, reached out to me because he read my blog on Fedora Asahi Remix and knew I had a Mac Studio with an M1 Max running it. He was particularly interested in seeing the performance of running Actuated for ARM on it compared to his other ARM-based Linux systems. In the cloud and developer communities, it’s common courtesy to support each other with these kinds of requests, so I gladly agreed.
Background information:
-
What is Continuous Integration (CI)?
- CI focuses on automatically integrating code changes into a shared code repository and validating those changes through automated builds and tests. The tasks performed by CI are called runners if you use the GitLab code repository, or actions if you use the GitHub code repository.
- CI is sometimes confused with Continuous Delivery/Deployment (CD), which builds upon CI by automating the release process, either delivering code to a staging environment for testing or to a production server.
-
What are Firecracker microVMs?
- Firecracker microVMs are fast-booting, small virtual machines (VMs) that provide the lightweight benefits of a container, but with full isolation (including security) from the system running it. While originally designed by AWS to provide serverless functionality, they can be used for any purpose, including providing CI functionality.
- If you’re interested in learning more about the difference between Firecracker microVMs and containers, you can watch Alex’s video on this topic. To try out Firecracker on your own machine, you can follow these steps.
-
What is Actuated?
- Actuated is a platform that offers secure and fast CI for GitHub and GitLab using fast Firecracker microVMs on your own infrastructure, with support for the ARM platform that is fast becoming ubiquitous for developer workstations and servers. With Actuated, each microVM is created just in time to perform a CI task, and is removed immediately after.
So, how did we do this?
Well, firstly, Alex needed to be able to perform the same benchmark – in this case, the time to compile a large kernel with container and eBPF capabilities (a CPU-intensive task) – that he performed on his other ARM-based Linux systems. Alex was using a Mac Mini M1 (running Asahi Linux) and Ampere Altra Q80 (using credits from Equinix Metal prior to their acquisition). To peform the benchmark, Alex provided instructions to deploy the Actuated agent on my system, in a way that he could connect to it behind my home NAT router.
Here’s what was involved on my end:
- Installing the Actuated agent
- Using
inlets-pro
to create an outbound-initiated tunnel from behind my home NAT router to a cloud server that Alex could use to access my local Actuated agent service. Inlets, another project developed by Alex, provides options for both self-hosted and managed tunnel servers. - Troubleshooting issues (this is Linux after all!). A few initial issues caused the Actuated agent to crash, but after collaborating with Alex via LinkedIn chat and examining the system, I was able to figure out how to solve them. I had to add some SELinux exceptions and define a
WorkingDirectory
directive in the Actuated Systemd unit file to ensure PAM could run tasks as the root user. After that, the agent started perfectly:
Alex then connected remotely to perform his benchmarking. In the end, the results of the large kernel build for make Image
(the equivalent of make vmlinux
) were:
- Mac Studio M1 Max (20 cores allocated) = 121.4 seconds
- Mac Mini M1 (8 cores allocated) = 301.9 seconds
- Ampere Altra Q80 (32 cores allocated) = from 158.1 to 231.2 seconds
Impressively, the M1 Max outperforms the Ampere Altra, even with a dozen fewer cores allocated. And Alex is thinking of getting a Mac Studio M2 Ultra (with 24 cores) to get even better results, since Asahi Linux supports that model as well (support for the M3 and M4 is still in progress, as the Asahi team remains focused on refining compatibility with the M1 and M2 chips).
Alex also noted that the Ampere Altra might have performed better if all 80 cores had been allocated. However, Firecracker imposes a hard limit of 32 cores per VM.
In a world where developer time is precious and CI performance can quickly become a bottleneck, fast ARM hardware like Apple Silicon makes a compelling case for running Actuated on personal infrastructure. The performance gains mainly come from higher CPU clock speeds and reduced storage and memory latency – thanks in large part to the unified memory architecture. Whether you’re building in the cloud or locally, cutting even a few minutes from your pipelines can add up quickly. Perhaps most importantly, collaborating with others to validate and fine-tune these setups benefits everyone working toward faster, more efficient builds.