Hacker News Reader

Comment by poemxo | Hacker News Reader

I usually agree with Apple but I don't agree with this. Rosetta 28 is basically magic, why would they take away one of their own strongest features? If they want big name apps to compile to Apple Silicon, why can't they exert pressure through their codesigning process instead?

View on HN

The “big name apps” have already moved to Apple Silicon. Rosetta helped them with that process a few years ago. We’re down to the long tail apps now. At some point, Rosetta is only helping a couple people and it won’t make sense to support it. I just looked, and right now on my M1 Air, I have exactly one x86 app running, and I was honestly surprised to find that one (Safari plug-in). Everything else is running ARM. My workload is office, general productivity, and Java software development. I’m sure that if you allow your Mac to report back app usage to Apple, they know if you’re using Rosetta or not, and if so, which apps require it. I suspect that’s why they’re telegraphing that they are about ready to pull the plug.

How do you check if you're running any x86 apps?

1. From the Apple menu, click "About This Mac."

2. In the resulting window, click the "More Info..." button. This will open the System Settings window.

3. Scroll to the bottom of that window and click "System Report."

4. In the left side of the resulting window, under "Software," click "Applications." This will provide a list of installed applications. One of the columns for sorting is "Kind"; all apps that are x86 will be listed with the kind, "Intel."

You can replace steps 1–3 with “Open /System/Applications/Utilities/System Information.app”.

Does the MacOS shell not split at spaces, or how does that work without quotation?

That’s not a shell command (otherwise “open” would be lowercase), it’s just an instruction.

Can you explain where you type that for non macOS users?

No it's an instruction for humans

Funny, that didn't occur to me at all. :-/ Maybe that's because I'm used to the FHS and I expected a path starting with /System to be either a path that is interpreted by some command or a description of an UI flow, not a path in the file system. So the thing you would type in the shell is just '/System/Applications/Utilities/System Information.app'? Does the Finder support starting programs by typing the path in the pathbar, like MS Explorer on Windows?

Adobe Acrobat, Steam, and PDF Reader Pro...

To see what’s running,

1. Go into Activity Monitor

2. From the CPU or memory tab, look at the “Kind” column. It’ll either say “Apple” or “Intel.” If the Kind column isn’t visible, right-click on the column labels and select Kind.

There's this Silicon app that scans your disk for them: https://github.com/DigiDNA/Silicon.

In macOS 26, you can see every Rosetta app that has recently run on your machine by going to System Information and then Software / Rosetta Software. It includes the "Fallback Reason" (e.g. if you manually forced the app under Rosetta or if it was an Intel-only binary).

FWIW, I have zero Rosetta apps on my M1 laptop and I've been a Mac user since the earliest days.

I'm super aware of the issues involved--I oversaw the transition from PPC to Intel at a university back in the day, using OG Rosetta. Even then, we had users who would only stop using their PPC apps when you took them from their cold, dead hands.

How much die area does it use that could be used for performance? How much engineering time does it use? Does it make sense to keep it around, causing ~30% more power usage/less performance?

There are many acceptable opposing answers, depending on the perspective of backwards compatibility, cost, and performance.

My naive assumption is that, by the time 2027 comes around, they might have some sort of slow software emulation that is parity to, say, M1 Rosetta performance.

Rosetta is a software translation layer, not a hardware translation layer. It doesn't take any die space.

Hardware acceleration [1]:

> One of the key reasons why Rosetta 2 provides such a high level of translation efficiency is the support of x86-64 memory ordering in the M1 SoC. The SoC also has dedicated instructions for computing x86 flags.

[1] https://en.wikipedia.org/wiki/Rosetta_(software)

While true, we're not talking about the chips losing TSO; Apple plans to keep Rosetta 2 for games and it has to remain fast because, well, it's video games. It also seems like they plan to keep their container tool[1]. This means they can't get rid of TSO at the silicon level and I have not heard this discussed as a possibility. We're only discussing the loss of the software support here. The answer to "How much die area does it use that could be used for performance?" is zero--they have chosen to do a partial phase-out that doesn't permit them to save the die space. They'd need to kill all remaining Rosetta 2 usage in order to cull the die space, and they seem to be going out of their way not to do this.

[1] https://github.com/apple/container -- uses Rosetta translation for x64 images.

> Rosetta is a software translation layer, not a hardware translation layer. It doesn't take any die space.

There is hardware acceleration in place that that only exists for it to, as you just stated, give it acceptable performance.

It does take up die space, but they're going to keep it around because they've decided to reduce the types of applications supported by Rosetta 2 (and the hardware that it exists only for it) will support.

So, seems like they've decided they can't fight the fact that gaming is a Windows thing, but there's no excuse for app developers.

Sure, this seems to be a restatement of my post, which started with "While true...", rather than a disagreement. I was pointing out which one of the "many acceptable opposing answers" Apple had chosen. They can't use that die area for performance because they're still using it even after this phase-out. (I'm not the person who wrote the original post.)

> We're only discussing the loss of the software support here

Schematically "Rosetta 2" is multiple things:

- hardware support (e.g TSO)

- binary translation (AOT + JIT)

- fat binaries (dylibs, frameworks, executables)

- UI (inspector checkbox, arch(1) command, ...)

My bet is that beyond the fancy high-level "Rosetta 2" word what will happen is that they'll simply stop shipping fat x86_64+aarch64 system binaries+frameworks[0], while the remainder remains.

[0]: or rather, heavily cull

So, the way to "use die area for performance" is to add more cache and branch predictor space. Because of this, anything that costs a lot of code size does consume it because it's using the cache up.

Reply on news.ycombinator.com