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

Why is Rosetta 2 fast?

dougallj.wordpress.com

Post reply on HN
Print view View original

11–20 of 367 posts

Re: Why is Rosetta 2 fast?

#11

Post by quux »

masklinn wrote: post #6
Vt71fcAqt7 wrote: post #4

I hope Rosetta is here to stay and continues developement. 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 be much easier than x86 to ARM as I understand it, so one could conceivably do x86 -> ARM -> RISC-V.

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

It would be funny/not funny if in a few years Apple removes Rosetta 2 for Mac apps but keeps the Linux version forever so docker can run at reasonable speeds.

Re: Why is Rosetta 2 fast?

#12

Post by stu2b50 »

masklinn wrote: post #6
Vt71fcAqt7 wrote: post #4

I hope Rosetta is here to stay and continues developement. 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 be much easier than x86 to ARM as I understand it, so one could conceivably do x86 -> ARM -> RISC-V.

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

Re: Why is Rosetta 2 fast?

#13

Post by qsort »

peatmoss wrote: 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…

You would need a hybrid architecture with a NN generating guesses and a "watchdog" shutting down errors.

Neural models are basically universal approximators. Machine code needs to be obscenely precise to work.

Unless you're doing something else in the backend, it's just a turbo SIGILL generator.

Re: Why is Rosetta 2 fast?

#14

Post by menaerus »

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

Re: Why is Rosetta 2 fast?

#15

Post by hinkley »

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 took in one architecture and spit out machine code for the same architecture. The output was faster than the input. Meaning that even native code has some room for improvement with JIT technology.

I have been wishing for years that we were in a better place with regard to compilers and NP complete problems where the compilers had a fast mode for code-build-test cycles and a very slow incremental mode for official builds. I recall someone telling me the only thing they liked about the Rational IDE (C and C++?) was that it cached precompiled headers, one of the Amdahl’s Law areas for compilers. If you changed a header, you paid the recompilation cost and everyone else got a copy. I love whenever the person that cares about something gets to pay the consequence instead of externalizing it on others.

And having some CI machines or CPUs that just sit around chewing on Hard Problems all day for that last 10% seems to be to be a really good use case in a world that’s seeing 16 core consumer hardware. Also caching hints from previous runs is a good thing.

Re: Why is Rosetta 2 fast?

#16

Post by TillE »

stu2b50 wrote: post #12
masklinn wrote: 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.

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.

Re: Why is Rosetta 2 fast?

#17

Post by dynjo »

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!

Re: Why is Rosetta 2 fast?

#18

Post by dmitriid »

stu2b50 wrote: post #12
masklinn wrote: 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.

> Jobs was more opinionated on “principles” - Cook is more than happy to sell what people will buy.

Well, the current "principle" is "iOS is enough, we're going to run iOS apps on MacOS, and that's it".

Rosetta isn't needed for that.

Re: Why is Rosetta 2 fast?

#19

Post by wombat-man »

dynjo wrote: 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!

There's an annoying dwarf fortress bug but other than that, same

Re: Why is Rosetta 2 fast?

#20

Post by nilsb »

menaerus wrote: post #14

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

Yes, it does. The delay of the first start of an app is quite noticeable. But the transpiled binary is apparently cached somewhere.
Post reply on HN