Arm desktop: emulation | Hacker News Reader

Arm desktop: emulation

marcin.juszkiewicz.com.pl

98 pointsPaulHoule50 comments

I'm curious how long until most users just don't care if their CPU has native x86 support.

As someone developing HPC applications, I generally don't care either, as long as the hardware has good fundamentals, and is well supported by the available compilers and profiling tools.

Honestly at this point the only reason that I'm aware of to prefer Intel for my workloads is the awesomeness of VTune.

How's the quality of the equivalent AMD or Arm tooling these days?

I have an M1 MacBook Air I bought used a year ago for $800.

I edit a ton of 4K video, photos off my Sony Mirrorless, write articles, web, etc.

It is by far the fastest computer I’ve ever used. I have never once known or cared if anything is running x86.

The first time I got one of the ARM MacBooks from a job after years of being given the x86 ones, even my cats could immediately tell the difference. The x86 ones were basically constantly operating at a warm temperature that caused them to both want to nap on it, so they'd scuffle a few times a week when inevitably one of them tried to get on my desk only to find the other already napping there. In around 20 months of using M1 and newer laptops from employers, I've had a cat nap on them maybe three times total, because it pretty rarely is noticeably warmer than anything else in the room, so they have no special interest in it compared to much more enticing furniture like my keyboard.

I now want the benchmark for laptop thermals to be time to cat.

The difference to my 2015 intel MacBook Pro is staggering. Not just speed, but as you said heat, noise and battery life.

ARM for laptops is a monster leap forward

Sadly some companies are stubborn and just won't support ARM. For instance if you need to use Autodesk Revit for work, you are sentenced to Windows x86 hell.

By what mechanism is Revit locked to x86?

E.g., does it refuse to run on an emulator? Or some bizarre license issue?

It works on an emulator, but user experience is poor.

Is that an x86 translation issue, or a graphics issue? The chips Qualcomm has shipped so far for ARM PCs have bad graphics hardware and worse drivers. And that's the best case, where the ARM system is at least running Windows and nominally supporting DirectX. If you try to run on a Linux system, you add in more layers of API translation that have nothing to do with the CPU instruction set.

My favorite unsupported configuration is Homebrew, they support Arm-OSX but do not support Arm-Linux and now that they have moved to binary downloads, I find it difficult to even build the homebrew recipes.

Back when homebrew was source build first and Linux was first class, it was the best. Now it has become the thing it replaced, MacPorts.

Personally for me I only care about x86 for 2 reasons.

1) Steam library.

2) And the just works combo of ATX & the ability to use any ISO on almost any x86 machine.

I'm personally scared if x86 dies the open market of ATX and bring your own OS won't exist as every company will just lock you in to only there stuff on their devices.

My hope is that the death of x86 results in everyone flocking to RISC-V.

Which will drastically improve things with how the boot sequence(s) work and non-CPU devices are discovered, initialized, and managed, I am sure. So far, SBI doesn't look very promising.

SBI doesn't attempt to handle that, just like EFI doesn't really handle that on x86. Just about every device your x86 computer uses looks like PCI (or on a bus hooked up to PCI), and is handled through those configuration mechanisms rather than via boot firmware.

RISC-V being an open source ISA does not imply that devices using that ISA won't be locked down.

An open ecosystem in the way that historically emerged around the PC platform seems to be a completely orthogonal issue.

Who is this "everyone"? Just because RISCV ISA is open doesn't mean the ecosystem will be too. Because wile the ARM ISA is licensable by everyone so in theory everyone can be making X86 PCs, the current PC ARM ecosystem is way worse and way more locked down than X86.

Reminds me when people wanted Intel to die and then they realized AMD started raising their prices with no competition and they tough that maybe AMD isn't their friend and is like any other for profit corporation.

So I have no idea why people want to see the most open PC ecosystem die. What kind of short sighted masochism is this?

I suspect part of it is just the desire for something different. I browse eBay and still get the irrational urge to buy unusual hardware, even though my Sparcstations and Alpha have proven time and time again that the novelty dies away quickly.

Another part is the desire for a fresh start. x86 carries a lot of baggage. There's this idea that a new CPU architecture would somehow stop holding us back. Problem with that idea is that for the most part, x86 doesn't hold us back.

Then of course there's the remnants of the old RISC vs CISC debate that never quite died away.

People will always be fascinated by the what-ifs and if-onlys - "if only Sun had survived to the cloud era" is my personal favorite. It's harmless fun.

> I'm personally scared if x86 dies the open market of ATX and bring your own OS won't exist as every company will just lock you in to only there stuff on their devices.

I share this fear, and have for a while. x86/the WinTel era has offered a lot of computing freedom, both hardware and OS wise and I believe we are in real danger of losing that. Not just because of an architecture change in isolation either, but also with the recent age verification stuff, and pushes for requiring "verified platforms" to access certain services, we are quickly heading down a proprietary-OS only world if you actually want to interact with web services.

The majority of compute users do not care.

Everyone who uses a tablet or smartphone obviously doesn’t care.

Anyone on a Mac doesn’t care, and even on windows, only very performance sensitive people would care if Prism isn’t doing its thing.

You’d essentially be left with AAA PC gamers and other performance sensitive people, which are a small percentage of overall users.

They don’t care until they can’t print... I had a user buy an ARM Windows device last year. I thought it was a sweet little computer, but the large multi-function Sharp printers don’t have drivers, so the best I could do was get basic printing working. Not double sided, not finishing options, etc. Pretty much a bummer that I expect to go away in the next few years, but still currently a place that can matter and cause people to lean x86.

Isn't there some big standardized/common print driver push going on in Windows 11 these days? I wonder if that's related.

There's "driverless" printing in the form of Mopria https://en.m.wikipedia.org/wiki/Mopria_Alliance

(known as "IPP Everywhere" in the Linux universe)

As far as I know, AirPrint is a superset of IPP Everywhere, so most printers that support macOS/iPad/iOS will accidentally support printing on Linux too.

It makes sense, seeing that CUPS is used on all of them.

Why is Prism unable to emulate the x86 drivers?

Because so far Microsoft has not implemented such feature.

https://learn.microsoft.com/en-us/windows/arm/apps-on-arm-x8...

> Note that emulation only supports user mode code and does not support drivers; any kernel mode components must be compiled as Arm64.

Yes, Prism isn't as good as Rosetta.

Working on the back-end side, there are still edge cases where ARM just doesn't work. You'll be using some container image and there's no ARM build. So you build it yourself and the build fails. After two days of poking and prodding it turns out the image is based on some wonky base image that has a libc that has never been ported to ARM. Re-creating the image on a different base turns out to be a big project. I've run into 2-3 similar but different issues like this in the past couple of years.

It's always fun when you peel apart that onion only to discover the Docker image was built with a binary blob (.so or similar) that's AMD64.

Yeah. I’ve found it helpful to have a server in the basement for weird dependencies like this. Somehow running SQL Server in a container on an old Mac Pro feels like I’m still (somewhat) in control of my own destiny. Plus, it’s old enough that 64G of RAM was cheap.

I think we are already past that point. With Apple Macbook, Google Chromebook and Microsoft Surface, we pretty much have all consumer computer echo system become ARM based. Thanks to AMDs resurgence the server space is still heavily x86 based.

MacBooks, Chromebooks, and Surfaces do not account for all consumer computer sales. And there are plenty of x86 Chromebooks out there.

No consumer to a first approximation chooses to buy Chromebooks any more than they choose to run Salesforce at home.

Chromebooks are the B2B SaaS of hardware where the buyer is not the user - mostly school systems.

I work at an e-waste recycling company. I can confirm that the vast majority of Chromebooks we have are from schools.

> I'm curious how long until most users just don't care if their CPU has native x86 support.

None of the machines I regularly use are x86-native, this has been the case for 4 years now. I only care because deploying x86 containers is still a thing.

I might be getting a gaming PC at some point, but there are very few titles I'm actually really interested in.

have you looked at tracy : https://github.com/wolfpld/tracy ?

it seems to at par, if not better than the other offering.

Tablet and phone users don't care, but that is a mix of bytecode based languages, forced upgrades, and shop cleanup from apps that don't want to keep up.

Unless something bad really happens on Windows land, users will care for a long time about native x86 support, Microsoft not being as hardliner as Apple, is the main reason all Windows on ARM efforts keep failing.

What I'm wondering though is if/why those users would care about native x86 support on the CPU's ISA, if the OS provides a decent x86 emulator layer.

(By "decent", I mean that it can handle their particular software, and with acceptable performance.)

It is clear that Prism and Arm64EC still aren't enough to make Windows ARM fly off the shelves at best buy or similar shops per each country.

Tangential: Google engs recently presented RISC-V -> x64 binary translation in Android viz. Berberis: https://youtube.com/watch?v=HjhzXZqjFrU

Also: https://github.com/MattPD/cpplinks/blob/master/assembly.risc...

Tried box64 on a Raspberry Pi 5 the other day and it worked above expectations. Except for a minor glitch with OGG audio, I got about 60 FPS in Xonotic (x86_64 emulated on AArch64).

For games in particular, the best performance comes if you use a dedicated GPU [1]. Though the CPU emulation can still be a limiting factor.

I'm able to play most 5-10 year old games that aren't tied to DRMs at 30-60 fps on a Pi [2] (and certainly on Ampere) using box64 and an AMD GPU (or Nvidia on an Ampere system), haven't spent much time with FEX-emu though.

[1] https://www.jeffgeerling.com/blog/2025/system76-built-fastes...

[2] https://www.jeffgeerling.com/blog/2024/use-external-gpu-on-r...

I spent some time testing Steam with FEX on the Orion O6 using an AMD RX570. Really surprised it worked as well as it did.

Portal 2 was hitting over 100 FPS. Half-Life 2 and DOOM 2016 hovered around 60 FPS. Shadow of the Tomb Raider and Control mostly stayed above 30 FPS, while The Witcher 3 and God of War usually hung out in the low to mid 40s.

- https://interfacinglinux.com/2025/06/30/fex-emu-gaming-on-th...

Orion O6 has so much potential, just wish Radxa had a little more focus on just getting one product launched really nicely, instead of spraying out more hardware every couple months.

Indeed, the rollout of the O6 has been disappointing. At least we have two additional companies releasing SBCs with the CD8180, so development won’t be limited to one board.

God of war runs great on my snapdragon 8 v2 or whatever x13s laptop...but gots so hot the GPU clitches since I don't think that laptop has active cooling

The biggest issue of ARM to me is the fact that ARM hardware never seems to have good or updated drivers.

If I pull an x86 machine or even laptop off the shelf, I'm like 90% sure I can perpetually support that machine for 30 or so years with the latest linux kernel.

For arm, I'm almost guaranteed that the only kernel support I can get is their custom kernel, which I'd have to scrape out of their custom OS. That means being locked into a vendored 3.10 linux kernel forever because there was never any real effort to upstream drivers into the kernel.

It's frankly a bit bizarre that it's so bad. x86 just works even with the latest CPUs. ARM doesn't.

From my experience working on GPU drivers, the ISA is one of the least important parts of porting. 99% of the time, it's just changing a compiler flag. Thankfully, the era of "Ancient Quirky Proprietary Toolchain" is a thing of the past, even on small embedded platforms.

Sure, you might have have a little "optimised" ASM for some specific conversions, but that's always just performance, and a driver even touching bulk data on the CPU means you're already in the slow path.

Stuff like how the busses are enumerated, cache coherency specifics, and interoperability with other devices (some mobile SoCs can be a grab bag of different GPU/Display block/Video encoder/Image processing/whatever else) is waayyyyy more important from what I've seen/.

And while we all hate on stuff like PCI and ACPI, at least it's (kinda) standard and (somewhat) works.

There's a handful of Windows game emulators taking off for Android. Using a modern snapdragon GPU, folks are playing Witcher 3, GTA 5. Some suffering gamer is playing through Dark Souls 2 using touch controls

Problem is, I assume, being stuck relying on some brittle apps that might or might not still run after some OS upgrade or after buying a new device. Like the DOSBox app I use on my Android phone is amazing but knowing that eventually it will suddenly expire (when the developer abandons it), like the previous one, makes me enjoy the games a lot less than I do when I have a more stable platform set up like when playing using some fully open source emulator on a rpi or x86 desktop pc.

When are Google going to get chrome up and running on Linux aarch64? I can't believe there isn't already enough demand.

Why ignore box64?

Reply on news.ycombinator.com