Not all vendors' Arm-powered kit is created equally, benchmark fan finds
Shiny silicon plus Rusty drivers will eventually equal openly saucy happiness
Arm-powered laptops and desktops are appearing on the market, but external appearances are deceptive. These are very different from familiar x86-based PCs, as the accounts of those experimenting with them reveal.
Compared to x86 machines, which have the widest range of interchangeable, modular hardware in the history of computing, devices such as phones and tablets are almost polar opposites. A fondleslab is a relatively sealed unit, with a known combination of main processor, graphics processor, various networking interfaces and so on, designed and built to run a single OS that is customized for that hardware. If you're lucky, several versions of that single OS.
When it comes to the inexpensive highly integrated Arm device you are probably holding in mid air, the problems start with booting: there's usually no standardized firmware able to load multiple unknown OSes in the typical ad hoc PC way. There's no need if you're building it to run just one specific payload, meaning that, from the vendor's point of view, it's cheaper to do without.
Trying to get a general-purpose OS to load up on this and drive its hardware is not a trivial task, which is why the Armbian project exists. For example, while OpenBSD 7.1 boasted support for the Apple M1 and version 7.2 added the M2, this shows that definitions of "support" vary quite widely. OpenBSD dropped support for Bluetooth completely in 2014, and for the typical uses of the OS, a flat unaccelerated framebuffer is good enough.
Various posts online are revealing some of how Apple's M1 kit works, the performance gap between M1 and M2, and how some rivals' kit compares.
Berlin-based developer Christian Adam has published an exhaustive blog post examining the issues around running Windows 11 on a 64-bit Arm machine, the Samsung Galaxy Book Go 5G.
In the end, Adam bought three different laptops, plus a commercial driver manager and various other bits of hardware, and paid for someone to replace the LCD screen of one of them, then did another screen replacement on a second laptop himself. He managed to download the Windows installation image from a Microsoft Surface Pro X – running Arm hardware means no ready-to-run ISO images.
In the end, his verdict was:
It has a plastic feel to it, not very solid, seems more like a toy. The keyboard is not that great.
As for the last machine's performance:
It's like half of the CPU performance of an Apple M1.
And in order to get one fully working machine to use as his main computer, as he put it:
All in all I've spent €1,281, for which I could have bought an Apple MacBook Air Midnight, M2 - 8 Core CPU / 8 Core GPU, 8GB RAM, 256GB SSD priced at €1,274, but I wouldn't have had so much fun.
We suspect that not many people would be prepared to go to such lengths, but it does explain the levels of interest in Apple's Arm-instruction-set machines. The M1 and M2 family of in-house designed M1 SoCs set new performance standards for personal computers – so long as you're happy to run Apple's own macOS, of course. The Reg has covered the user experience of Asahi Linux, as well as the difficulty of reverse engineering its GPU.
- Microsoft ships non-Surface PC: a cheap Arm box for devs
- Google reveals another experimental operating system: KataOS
- Microsoft unveils native Arm64 support in the .NET Framework
- Arm confirms IPO delay till later in 2023, blames global markets
Asahi continues to make progress and improve its device drivers. Most recently, project lead Hector "Marcan" Martin announced support for USB 3.0 devices, and better power management, but not yet for MacBooks' onboard speakers:
I decided to take one for the team and run some tests on my MacBook Air M2, and even with some sensible volume limits I quickly managed to blow up my tweeters. Oops!
Graphics driver developer "Asahi Lina" also described her adventures reverse-engineering GPU drivers in a lengthy post, which contains a lot of exclamation marks and more emojis than we're used to seeing in such technical matters, but is nonetheless fascinating. The early stages used a kernel driver which, although it sounds implausible, was partially written in Python. A more complete driver is being implemented in Rust, which she praises highly – although not without some reservations. We've looked at the difficulties of incorporating Rust into the kernel and the modest scope of the initial support in the forthcoming kernel 6.1. As Lina put it:
The kernel driver will not be heading upstream for many months.
We suspect that this could mean more complete support in the mainline kernel may not appear until version 6.2 or even later.
While the performance gap between Apple's M1 silicon and competing products such as the Qualcomm Snapdragon 8cx Gen 2 that Christian Land tested remains substantial, an interesting Geekbench benchmark score was noted on Twitter by ShrimpApplePro.
This appears to show the performance of one of the forthcoming M2 Max models. It's a relatively modest step up from the released M2 hardware… but then again, some of the main designers of the M1 already left Apple, including Gerard Williams to Nuvia (later acquired by Qualcomm), and subsequently Jeff Wilcox to Intel, and Mike Filippo to Microsoft. It is possible that Apple may yet face some stiff new competition. ®