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

41–50 of 367 posts

Re: Why is Rosetta 2 fast?

#41

Post by Asmod4n »

iainmerrick wrote: post #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…

I don't know how they did it, but they did it very very slowly. Anything "interactive" was unuseable.

Re: Why is Rosetta 2 fast?

#42

Post by vxNsr »

flomo wrote: post #26
TillE wrote: post #16

Earlier quoted context omitted.

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.

2006 Apple was very different from 2011 Apple, renewing that license in 2011 was probably considered cost prohibitive for the negligible benefit.

Re: Why is Rosetta 2 fast?

#43

Post by iamstupidsimple »

porcc wrote: post #39
manv1 wrote: post #35

Earlier quoted context omitted.

Qualcomm (and Broadcomm) has total control on the hardware and software side of a lot of stuff and their stuff is shit. It's not about control, it's about good engineering.

So many parts across the stack need to work well for this to go well. Early support for popular software is a good example. This goes from partnerships all the way down to hardware designers. I'd argue it's not about engineering more than it is about good organizational structure.

And having execs who design the organizational structure around those goals is part of what makes good engineering :)

Re: Why is Rosetta 2 fast?

#44

Post by jeffbee »

I wonder how much hand-tuning there is in Rosetta 2 for known, critical routines. One of the tricks Transmeta used to get reasonable performance on their very slow Crusoe CPU was to recognize critical Windows functions and replace them with a library of hand-optimized native routines. Of course that's a little different because Rosetta 2 is targeting an architecture that is generally speaking at least as fast as the x86 architecture it is trying to emulate, and that's been true for most cross-architecture translators historically like DEC's VEST that ran VAX code on Alpha, but Transmeta CMS was trying to target a CPU that was slower.

Re: Why is Rosetta 2 fast?

#45

Post by kitsunesoba »

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.

We’ll see, but even post-Cook Apple historically hasn’t liked the idea of third parties leaning on bridge technologies for too long. Things like Rosetta are offered as temporary affordances to allow time for devs to migrate, not as a permanent platform fixture.

Re: Why is Rosetta 2 fast?

#46

Post by throw10920 »

qsort wrote: post #13
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.

This is all true - machine code needs to be "basically perfect" to work.

However, there are lots of problems in CS that are easier to check the answer to a solution than to solve in the first place. It may turn out to be the case that a well-tuned model can quickly produce solutions to some code-generation problems, that those solutions have a high enough likelihood of being correct, that it's fast enough to check (and maybe try again), and that this entire process is faster than state-of-the-art classical algorithms.

However, if that were the case, I might also expect us to be able to extract better algorithms from the model - intuitively, machine code generation "feels" like something that's just better implemented through classical algorithms. Have you met a human that can do register allocation faster than LLVM?

Re: Why is Rosetta 2 fast?

#47

Post by jeffbee »

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

Post-build optimization of binaries without changing the target CPU is common. See BOLT https://github.com/facebookincubator/BOLT
Post reply on HN