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

101–110 of 367 posts

Re: Why is Rosetta 2 fast?

#101

Post by rerx »

TillE wrote: post #16
stu2b50 wrote: 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.

Starting with Ventura, Linux VMs can use Rosetta 2 to run x64 executables. I expect x64 Docker containers to remain relevant for quite a few years to come. Running those at reasonable speeds on Apple Silicon would be huge for developers.

Re: Why is Rosetta 2 fast?

#102

Post by gpderetta »

vips7L wrote: post #98
freedomben wrote: post #83

Earlier quoted context omitted.

If JIT-ing a statically compiled input makes it faster, does that mean that JIT-ing itself is superior or does it mean that the static compiler isn't outputting optimal code? (real question. asked another way, does JIT have optimizations it can make that a static compiler can't?)

Yes, the JIT has more profile guided data as to what your program actually does at runtime, therefore it can optimize better.

On the other hand some optimization are so expensive that a JIT just doesn't have the execution budget to perform them.

Probably the optimal system is an hybrid iterative JIT/AOT compiler (which incidentally was the original objective of LLVM).

Re: Why is Rosetta 2 fast?

#103

Post by kmeisthax »

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

If JIT-ing a statically compiled input makes it faster, does that mean that JIT-ing itself is superior or does it mean that the static compiler isn't outputting optimal code? (real question. asked another way, does JIT have optimizations it can make that a static compiler can't?)

It's more the case that the ahead-of-time compilation is suboptimal.

Modern compilers have a thing called PGO (Profile Guided Optimization) that lets you take a compiled application, run it and generate an execution profile for it, and then compile the application again using information from the profiling step. The reason why this works is that lots of optimization involves time-space tradeoffs that only make sense to do if the code is frequently called. JIT only runs on frequently-called code, so it has the advantage of runtime profiling information, while ahead-of-time (AOT) compilers have to make educated guesses about what loops are the most hot. PGO closes that gap.

Theoretically, a JIT could produce binary code hyper-tailored to a particular user's habits and their computer's specific hardware. However, I'm not sure if that has that much of a benefit versus PGO AOT.

Re: Why is Rosetta 2 fast?

#104

Post by mikepurvis »

pjmlp wrote: post #56
travisgriggs wrote: post #40

Earlier quoted context omitted.

It was particularly poignant at the time because JITed languages were looked down on by the “static compilation makes us faster” crowd. So it was a sort of “wait a minute Watson!” moment in that particular tech debate. No one cares as much now days, we’ve moved our overrated opinion battlegrounds to other portions of what we do.

I eventually changed my opinion into JIT being the only way to make dynamic languages faster, while strong typed ones can benefit from having both AOT/JIT for different kinds of deployment scenarios, and development workflows.

I think I landed in a place where it's basically "the compiler has insufficient information to achieve ideal optimization because some things can only be known at runtime."

Which is not exclusively an argument for runtime JIT— it can also be an argument for instrumenting your runtime environment, and feeding that profiling data back to the compiler to help it make smarter decisions the next time. But that's definitely a more involved process than just baking it into the same JavaScript interpreter used by everyone— likely well worth it in the case of things like game engines, though.

Re: Why is Rosetta 2 fast?

#105

Post by scarface74 »

Asmod4n wrote: post #41
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.

Interactive 68K programs were usually fast. The 68K programs would still call native PPC QuickDraw code. It was processor intensive code that was slow. Especially with the first generation 68K emulator.

Connectix SpeedDoubler was definitely faster.

Re: Why is Rosetta 2 fast?

#106

Post by mockery »

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

If JIT-ing a statically compiled input makes it faster, does that mean that JIT-ing itself is superior or does it mean that the static compiler isn't outputting optimal code? (real question. asked another way, does JIT have optimizations it can make that a static compiler can't?)

In addition to the sibling comments, one simple opportunity available to a JIT and not AOT is 100% confidence about the target hardware and its capabilities.

For example AOT compilation often has to account for the possibility that the target machine might not have certain instructions - like SSE/AVX vector ops, and emit both SSE and non-SSE versions of a codepath with, say, a branch to pick the appropriate one dynamically.

Whereas a JIT knows what hardware it's running on - it doesn't have to worry about any other CPUs.

Re: Why is Rosetta 2 fast?

#107

Post by trollied »

darzu wrote: post #76

Does anyone know the names of the key people behind Rosetta 2? In my experience, exceptionally well executed tech like this tends to have 1-2 very talented people leading. I'd like to follow their blog or Twitter.

The original Rosetta was written by Transitive, which was formed by spinning a Manchester University research group out. See https://www.software.ac.uk/blog/2016-09-30-heroes-software-e...

I know a few of their devs went to ARM, some to Apple & a few to IBM (who bought Transitive). I do know a few of their ex staff (and their twitter handles), but I don’t feel comfortable linking them here.

Re: Why is Rosetta 2 fast?

#108

Post by wang_li »

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

That’s really interesting. You might enjoy reading about the VM embedded into the Busicom calculator that used the Intel 4004 [1] They squeezed a virtual machine with 88 instructions into less than 1k of memory! [1] https://thechipletter.substack.com/p/bytecode-and-the-busico...

In the mists of history S. Wozniak wrote the SWEET-16 interpreter for the 6502. A VM with 29 instructions implemented in 300 bytes.

https://en.wikipedia.org/wiki/SWEET16

Re: Why is Rosetta 2 fast?

#109

Post by Symmetry »

jrmg wrote: post #55
Vt71fcAqt7 wrote: post #38

Earlier quoted context omitted.

>That's not going to happen unless Apple decides to switch from ARM to RISC-V, and... why would they? They've got 15 years experience and essentially full control on ARM. Two points here. • First off, Apple developers are not binded to Apple. The knkwledge gained can be used elsewhere. See Rivos and Nuvia for example. • Second, Apple reportedly has already ported many of it's secondary cores to RISC-V. It's not unrea…

Apple reportedly has already ported many of it's secondary cores to RISC-V Really? In current hardware or is this speculation?

If you've got some management core somewhere in your silicon you can, with RISC-V, give it a MMU but no FPU and save area. You're going to be writing custom embedded code anyways so you get to save silicon by only incorporating the features that you need instead of having to meet the full ARM spec. And you can add your own custom instructions for the job at hand pretty easily.

That would all be a terrible idea if you were doing it for a core intended to run user applications, but that's not what Apple, Western Digital, NVidia are embracing RISC-V for embedded cores. If I were ARM I'd honestly be much more worried about RISC-V's threat to my R and M series cores than my A series cores.

Re: Why is Rosetta 2 fast?

#110

Post by scarface74 »

manv1 wrote: post #52

Apple's historically been pretty good at making this stuff. Their first 68k -> PPC emulator (Davidian's) was so good that for some things the PPC Mac was the fastest 68k mac you could buy. The next-gen DR emulator (and SpeedDoubler etc) made things even faster. I suspect the ppc->x86 stuff was slower because x86 just doesn't have the registers. There's only so much you can do.

> Their first 68k -> PPC emulator (Davidian's) was so good that for some things the PPC Mac was the fastest 68k mac you could buy.

This is not true. A 6100/60 running 68K code was about the speed of my unaccelerated Mac LCII 68030/16. Even when using SpeedDoubler, you only got speeds up to my LCII with a 68030/40Mhz accelerator.

Even the highest end 8100/80 was slower than a high end 68k Quadra.

The only time 68K code ran faster is when it made heavy use of the Mac APIS that were native.

Post reply on HN