Hacker News Reader

Comment by CoastalCoder | Hacker News Reader

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?

View on HN

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.

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

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.

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.

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

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.

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

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

Reply on news.ycombinator.com