Live data from Hacker News

Why is Rosetta 2 fast?

dougallj.wordpress.com

21–30 of 367 posts

Re: Why is Rosetta 2 fast?

#21
post #17

It is quite astonishing how seamless Apple has managed to make the Intel to ARM transition, there are some seriously smart minds behind Rosetta. I honestly don't think I had a single software issue during the transition!

If that blows your mind, you should see how Microsoft did the emulation of the PowerPC based Xeon chip to X86 so you can play Xbox 360 games on Xbox One.

There's an old pdf from Microsoft researchers with the details but I can't seem to find it right now.

Re: Why is Rosetta 2 fast?

#22
post #9

Not having any particular domain experience here, I've idly wondered whether or not there's any role for neural net models in translating code for other architectures. We have giant corpuses of source code, compiled x86_64 binaries, and compiled arm64 binaries. I assume the compiled binaries represent approximately our best compiler technology. It seems predicting an arm binary from an x86_64 binary would not be insa…

> It seems predicting an arm binary from an x86_64 binary would not be insane?

If you start with a couple of megabytes of x64 code, and predict a couple of megabytes of arm code from it, there will be errors even if your model is 99.999% accurate.

How do you find the error(s)?

Re: Why is Rosetta 2 fast?

#23
This is a great writeup. What a clever design!

I remember Apple had a totally different but equally clever solution back in the days of the 68K-to-PowerPC migration. The 68K had 16-bit instruction words, usually with some 16-bit arguments. The emulator’s core loop would read the next instruction and branch directly into a big block of 64K x 8 bytes of PPC code. So each 68K instruction got 2 dedicated PPC instructions, typically one to set up a register and one to branch to common code.

What that solution and Rosetta 2 have in common is that they’re super pragmatic - fast to start up, with fairly regular and predictable performance across most workloads, even if the theoretical peak speed is much lower than a cutting-edge JIT.

Anyone know how they implemented PPC-to-x86 translation?

Re: Why is Rosetta 2 fast?

#24
post #17

It is quite astonishing how seamless Apple has managed to make the Intel to ARM transition, there are some seriously smart minds behind Rosetta. I honestly don't think I had a single software issue during the transition!

having total control on the hardware and the software didn't hurt for sure

Re: Why is Rosetta 2 fast?

#25
post #15

I remember years ago when Java adjacent research was all the rage, HP had a problem that was “Rosetta lite” if you will. They had a need to run old binaries on new hardware that wasn’t exactly backward compatible. They made a transpiler that worked on binaries. It might have even been a JIT but that part of the memory is fuzzy. What made it interesting here was that as a sanity check they made an A->A mode where they…

https://www.hpl.hp.com/techreports/1999/HPL-1999-78.html

Re: Why is Rosetta 2 fast?

#26
post #16
post #12

Earlier quoted context omitted.

Rosetta 1 had a ticking time bomb. Apple was licensing it from a 3rd party. Rosetta 2 is all in house as far as we know. Different CEO as well. Jobs was more opinionated on “principles” - Cook is more than happy to sell what people will buy. I think Rosetta 2 will last.

What important Intel-only macOS software is going to exist in five years? It's basically only games and weird tiny niches, and Apple is pretty happy to abandon both those categories. The saving grace is that there's very few interesting Mac-exclusive games in the Intel era.

Yeah, Apple killed all "legacy" 32-bit support, so one would think there's not much software which is both x86-64 and not being actively developed.

Re: Why is Rosetta 2 fast?

#27
post #12
post #6

Earlier quoted context omitted.

> I hope Rosetta is here to stay and continues developement. It almost certainly is not. Odds are Apple will eventually remove Rosetta II, as they did Rosetta back in the days, once they consider the need for that bridge to be over (Rosetta was added in 2006 in 10.4, and removed in 2011 from 10.7). > And I hope what is learned from it can be used to make a RISC-V version of it. translating native ARM to RISC-V should…

Rosetta 1 had a ticking time bomb. Apple was licensing it from a 3rd party. Rosetta 2 is all in house as far as we know. Different CEO as well. Jobs was more opinionated on “principles” - Cook is more than happy to sell what people will buy. I think Rosetta 2 will last.

> Rosetta 1 had a ticking time bomb. Apple was licensing it from a 3rd party.

Yes, I'm sure Apple had no way of extending the license.

> Cook is more than happy to sell what people will buy. I think Rosetta 2 will last.

There's no "buy" here.

Rosetta is complexity to maintain, and an easy cut. It's not even part of the base system.

And “what people will buy” certainly didn’t prevent essentially removing support for non-hidpi displays from MacOS. Which is a lot more impactful than Rosetta as far as I’m concerned.

Re: Why is Rosetta 2 fast?

#28
post #8

Apple is doing some really interesting but really quiet work in the area of VMs. I feel like we don’t give them enough credit but maybe they’ve put themselves in that position by not bragging enough about what they do. As a somewhat related aside, I have been watching Bun (low startup time Node-like on top of Safari’s JavaScript engine) with enough interest that I started trying to fix a bug, which is somewhat unusua…

> feel like we don’t give them enough credit but maybe they’ve put themselves in that position by not bragging enough about what they do.

And maybe also by keeping the technology closed and Apple-specific. Many people who could be interested in using it don't have access to it.

Re: Why is Rosetta 2 fast?

#29
post #9

Not having any particular domain experience here, I've idly wondered whether or not there's any role for neural net models in translating code for other architectures. We have giant corpuses of source code, compiled x86_64 binaries, and compiled arm64 binaries. I assume the compiled binaries represent approximately our best compiler technology. It seems predicting an arm binary from an x86_64 binary would not be insa…

I think we are on the cusp of machine aided rules generation via example and counter example. It could be a very cool era of “Moore’s Law for software” (which I’m told software doubles in speed roughly every 18 years).

Property based testing is a bit of a baby step here, possibly in the same way that escape analysis in object allocation was the precursor to borrow checkers which are the precursor to…?

These are my inputs, these are my expectations, ask me some more questions to clarify boundary conditions, and then offer me human readable code that the engine thinks satisfies the criteria. If I say no, ask more questions and iterate.

If anything will ever allow machines to “replace” coders, it will be that, but the scare quotes are because that shifts us more toward information architecture from data munging, which I see as an improvement on the status quo. Many of my work problems can be blamed on structural issues of this sort. A filter that removes people who can’t think about the big picture doesn’t seem like a problem to me.

Re: Why is Rosetta 2 fast?

#30

> Rosetta 2 translates the entire text segment of the binary from x86 to ARM up-front. Do I understand correctly that the Rosetta is basically a transpiler from x86-64 machine code to ARM machine code which is run prior to the binary execution? If so, does it affect the application startup times?

> If so, does it affect the application startup times?

It does, but only the very first time you run the application. The result of the transpilation is cached so it doesn't have to be computed again until the app is updated.

Post reply on HN