Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

About the Rosetta Translation Environment

developer.apple.com

Post reply on HN
Print view View original

141–150 of 249 posts

Re: About the Rosetta Translation Environment

#141

Post by oppositelock »

mkl wrote: post #41

> Rosetta can translate most Intel-based apps, including apps that contain just-in-time (JIT) compilers. How on Earth does it do that? If executable code is being generated at runtime, it's going to be x86_64 binary machine code still (there are too many ways to generate valid machine code, and it won't know right away whether you're JITting, or cross compiling and actually want x86_64), so Rosetta would need to dete…

The original PowerPC on Intel Rosetta was pretty amazing.

First, most programs do much of their work inside the OS - rendering, network, interaction, whatever, so that's not emulated, Rosetta just calls the native OS functions after doing whatever input translation is necessary. So, nothing below a certain set of API's is translated.

You have to keep a separate translated binary in memory, and be able to compile missing bits as you encounter them, while remembering all your offset adjustments. It worked amazingly well during the PowerPC transition. Due to so many things running natively on x86, the translated apps frequently faster than running native on PowerPC macs!

Re: About the Rosetta Translation Environment

#142

Post by monocasa »

dtech wrote: post #140
monocasa wrote: post #120

Earlier quoted context omitted.

Electron doesn't support aarch64 builds compiled from aarch64 hosts yet (so you have to cross compile), and doesn't support cross compiling if you have any native code addons. Some apps out there are between a rock and a hard place if it weren't for rosetta.

I suspect this will change fairly soon now that there will be a significant non-mobile aarch64 market in the future

There's still a non trivial amount of time to get that propagated. First merged into chromium, the merged into electron, then actually used by the client programs.

Re: About the Rosetta Translation Environment

#143

Post by Mister_Snuggles »

I've been using Macs at work for a long time, but sadly this will mark the end of that era.

In particular, this limitation on Rosetta rules out an ARM-based Mac for work:

> Virtual Machine apps that virtualize x86_64 computer platforms

My job requires me to use a piece of proprietary Windows-only software for a large portion of my work. If I can't use this software I can't do my job. Currently I run it in VMware Fusion on an Intel Mac, which is a perfect solution for me - I get the great features of MacOS, plus I can run the proprietary toolset that my job requires.

There is a very remote possibility that Windows for ARM could be virtualized by some future version of VMware and the proprietary toolset could run under that, but I'm not holding my breath.

Due to budget constraints, I don't think there's any way that my work would spring for a MacBook Pro plus a Windows machine for me.

On the flip side, Windows 10 seems to be getting really good, so I expect that I'll be just as happy and productive with Windows 10+WSL2.

Re: About the Rosetta Translation Environment

#144

Post by Someone »

amaranth wrote: post #135
Someone wrote: post #78

Earlier quoted context omitted.

AAA games spend lots of times inside system libraries. Porting those to native could be enough to get acceptable performance. So, chess could be more of a challenge for emulation than AAA games (but probably less of an issue, as it would be easily ported, and have fewer users, anyways)

The page we're discussing here actually says you can't mix arm64 and amd64 code in a single process, if your binary is amd64 all your libraries will be too. I'd be surprised if they put in the work to generate thunks for all their system libraries and then didn't make it possible to use any others. More likely macOS will just have two copies of all the (non-iOS) libraries and the only point they work together is the…

If I read it correctly, it says it prevents you from doing that, “including all code modules that the process loads dynamically”, but I don’t think that means Rosetta won’t call arm64 libraries for libraries linked at program startup.

Think about it: Rosetta translates your code to arm64, and your code calls a function in a system library. Why would Rosetta use the x64 version of the library and translate its code to arm64 if an arm64 version is available? there may be ABI differences that aren’t trivial to correct for, but for expensive calls, I would think that’s dwarfed by the gains of running native code.

Certainly, how is this going to run the Accelerate framework API at decent speed, given the emulator doesn’t emulate AVX, AVX2, and AVX512?

Re: About the Rosetta Translation Environment

#145

Post by GeekyBear »

monocasa wrote: post #130
Angostura wrote: post #59

Earlier quoted context omitted.

FWIW they showed the latest Tombraider game running on Rosetta on a dev Mac said to be using the ARM chip from the high-end iPad. It ran pretty well. Not sure if I would quite count this as AAA

IDK, what I saw was a several year old game running on the lowest settings and still stuttering a bit.

The more interesting point...

>The demo wasn't perfect: the game ran at 1080p with fairly middling settings, but did so at what appeared to be at the very least a steady 30FPS, all while being run as an emulated x86 version of the game. That is: the game wasn't even natively compiled for ARM.

But consider that Intel's most powerful laptop chipset GPU, found in the 10th generation Ice Lake series, is not capable of breaking single digit frame rates on this game at 1080p.

Apple received some snark about this demo being lame, but it's only lame if you don't understand at all just how terrible modern integrated laptop GPUs are.

https://www.androidpolice.com/2020/06/22/apples-chipset-adva...

Re: About the Rosetta Translation Environment

#146

Post by empthought »

Mister_Snuggles wrote: post #143

I've been using Macs at work for a long time, but sadly this will mark the end of that era. In particular, this limitation on Rosetta rules out an ARM-based Mac for work: > Virtual Machine apps that virtualize x86_64 computer platforms My job requires me to use a piece of proprietary Windows-only software for a large portion of my work. If I can't use this software I can't do my job. Currently I run it in VMware Fusi…

It will be at least several years before you will not be able to purchase a new Intel-based Mac.

Re: About the Rosetta Translation Environment

#147

Post by wmf »

bjpirt wrote: post #37

Having big flashbacks to the switch from PPC to x86 here. Rosetta worked relatively smoothly during that transition so fingers crossed it will be ok here too. Though with Docker support on the mac already being a second class citizen to running on Linux I wonder if a lot of devs will stop using macs for dev

People weren't running PowerPC VMs (besides Classic which was dropped in 10.5) so they didn't notice the loss of that functionality. Many people are running x86 VMs today which won't work on ARM.

Re: About the Rosetta Translation Environment

#148

Post by monocasa »

GeekyBear wrote: post #145
monocasa wrote: post #130

Earlier quoted context omitted.

IDK, what I saw was a several year old game running on the lowest settings and still stuttering a bit.

The more interesting point... >The demo wasn't perfect: the game ran at 1080p with fairly middling settings, but did so at what appeared to be at the very least a steady 30FPS, all while being run as an emulated x86 version of the game. That is: the game wasn't even natively compiled for ARM. But consider that Intel's most powerful laptop chipset GPU, found in the 10th generation Ice Lake series, is not capable of br…

We all know that Intel iGPUs are terrible (at least until the new Xe based GPUs start to come out).

The comparison I don't see enough people making is to throw out as an option the one company that regularly ships semi custom, secure, x86 SoCs with GPUs, AMD. An Xbox One SoC is literally half of the transistor count of an A12Z (5B and 10B respectively).

And the frame rate was anything but steady there. And calling it "middling settings" is pushing it as well, the env lighting wasn't even on Lara. It looks like they dropped the settings as far down as they would go.

Re: About the Rosetta Translation Environment

#149

Post by hn_check »

monocasa wrote: post #130
Angostura wrote: post #59

Earlier quoted context omitted.

FWIW they showed the latest Tombraider game running on Rosetta on a dev Mac said to be using the ARM chip from the high-end iPad. It ran pretty well. Not sure if I would quite count this as AAA

IDK, what I saw was a several year old game running on the lowest settings and still stuttering a bit.

https://youtu.be/GEZhD3J89ZE?t=6070

It doesn't stutter whatsoever (you've claimed this in multiple posts, and I think you need to look at your playback device because the game is buttery smooth). And for integrated graphics of a binary translated x86-64 game running on ARM @ 1080p, that is pretty amazing.

No one is going to claim that the GPU on the A12Z beats a dedicated GPU, even a low-end one. But as someone whose kid has an iMac with a Iris Pro integrated graphics, this looks a world better than what Intel integrates, not even accounting for the whole binary translation thing.

And clearly the higher end Macs with Apple silicon will still have dedicated GPUs as well. Why wouldn't they?

Re: About the Rosetta Translation Environment

#150

Post by monocasa »

hn_check wrote: post #149
monocasa wrote: post #130

Earlier quoted context omitted.

IDK, what I saw was a several year old game running on the lowest settings and still stuttering a bit.

https://youtu.be/GEZhD3J89ZE?t=6070 It doesn't stutter whatsoever (you've claimed this in multiple posts, and I think you need to look at your playback device because the game is buttery smooth). And for integrated graphics of a binary translated x86-64 game running on ARM @ 1080p, that is pretty amazing. No one is going to claim that the GPU on the A12Z beats a dedicated GPU, even a low-end one. But as someone whose…

An A12Z's GPU is around double an Xbox One's in gate count. On a GPU limited title like that it should be doing way better than this.

Also it still appears to be stuttering, and opening other videos doesn't show the same stutter.

Post reply on HN