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

121–130 of 367 posts

Re: Why is Rosetta 2 fast?

#121

Post by com2kid »

kmeisthax wrote: post #103
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?)

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…

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

In theory JIT can be a lot more efficient, optimizing for not only the exact instruction set, and do per CPU architecture optimizations, such as instruction length, pipeline depth, cache sizes, etc.

In reality I doubt most compiler or JIT development teams have the resources to write and test all those potential optimizations, especially as new CPUs are coming out all the time, and each set of optimizations is another set of tests that has to be maintained.

Re: Why is Rosetta 2 fast?

#122

Post by EricE »

toast0 wrote: post #64
AnIdiotOnTheNet wrote: post #32

Earlier quoted context omitted.

It isn't their first rodeo: 68k->PPC->x86_64->ARM.

nitpick, they did PPC -> x86 (32), the x86_64 bit transition was later (no translation layer though). They actually had 64-bit PPC systems on the G5 when they switched to Intel 32-bit, but Rosetta only does 32-bit PPC -> 32-bit x86; it would have been rare to have released 64-bit PPC only software.

They had 64 bit Carbon translation layer, but spiked it to force Adobe and some other large publishers to go native Intel. There was a furious uproar at the time, but it turned out to be the right decision.

Re: Why is Rosetta 2 fast?

#123

Post by hamstergene »

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…

Could it be simply because many binaries were produced by much older, outdated optimizers. Or optimized for size.

Also, optimizers usually target “most common denominator” so native binaries rarely use full power of current instruction set.

Jumping from that peculiar finding to praising runtime JIT feels like a longshot. To me it’s more of an argument towards distributing software in intermediate form (like Apple Bitcode) and compiling on install, tailoring for the current processor.

Re: Why is Rosetta 2 fast?

#124

Post by masklinn »

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

> They've got 15 years experience Did you only start counting from 2007 when the iPhone was released? All the iPods prior to that were using ARM processors. The Apple Newton was using ARM processors.

> All the iPods prior to that were using ARM processors.

Most of the original device was outsourced and contracted out (for reasons of time constraint and lack of internal expertise). PortalPlayer built the SoC and OS, not Apple. Later SoC were sourced from SigmaTel and Samsung, until the 3rd gen Touch.

> The Apple Newton was using ARM processors.

The Apple Newton was a completely different Apple, and there were several years' gap between Jobs killing the Newton and the birth of iPod, not to mention the completely different purpose and capabilities. There would be no newton-type project until the iPhone.

Which is also when Apple started working with silicon themselves: they acquired PA in 2008, Intrinsity in 2010, and Passif in 2013, released their first partially in-house SoC in 2010 (A4), and their first in-house core in 2013 (Cyclone, in the A7).

Re: Why is Rosetta 2 fast?

#125

Post by masklinn »

mikepurvis wrote: post #104
pjmlp wrote: post #56

Earlier quoted context omitted.

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

It's also an argument for having much more expressive and precise type systems, so the compiler has better information.

Once you've managed to debug the codegen anyway (see: The Long and Arduous Story of Noalias).

Re: Why is Rosetta 2 fast?

#126

Post by darzu »

cwzwarich wrote: post #111
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.

I am the creator / main author of Rosetta 2. I don't have a blog or a Twitter (beyond lurking).

Should you feel inspired to share your learnings, insights, or future ideas about the computing spaces you know, me and I'm sure many other people would be interested to listen!

My preferred way to learn about a new (to me) area of tech is to hear the insights of the people who have provably advanced that field. There's a lot of noise to signal in tech blogs.

Re: Why is Rosetta 2 fast?

#127

Post by dev_tty01 »

scarface74 wrote: post #110
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 cod…

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

Yes, and that just confirms the original point. Mac apps often spend a lot of time in the OS apis and therefore the 68K code (the app) often ran faster on PPC than it did on 68K because apps often spend much of their time in OS apis. The earlier post said "so good that for some things the PPC Mac was the fastest 68k mac." That is true.

In my own experience, I found most 68K apps felt as fast or faster. Your app mix might have been different, but many folks found the PPC faster.

Re: Why is Rosetta 2 fast?

#128

Post by randyrand »

titzer wrote: post #89

Rosetta 2 is great, except it apparently can't run statically-linked (non-PIC) binaries. I am unsure why this limitation exists, but it's pretty annoying because Virgil x86-64-binaries cannot run under Rosetta 2, which means I resort to running on the JVM on my M1...

Why are static binaries with PIC so rare? I’m surprised position dependent code is ever used anymore in the age of ASLR.

But static binaries are still great for portability. So you’d think static binaries with PIC would be the default.

Re: Why is Rosetta 2 fast?

#129

Post by masklinn »

nordsieck wrote: post #69
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.

> I suspect the ppc->x86 stuff was slower because x86 just doesn't have the registers. My understanding is that part of the reason the G4/5 was sort of able to keep up with x86 at the time was due to the heavy use of SIMD in some apps. And I doubt that Rosetta would have been able to translate that stuff into SSE (or whatever the x86 version of SIMD was at the time) on the fly.

Rosetta actually did support Altivec. It didn't support G5 input at all though (but likely because that was considered pretty niche, as Apple only released a G5 iMac, a PowerMac, and an XServe, due to the out-of-control power and thermals of the PowerPC 970).

Re: Why is Rosetta 2 fast?

#130

Post by masklinn »

randyrand wrote: post #128
titzer wrote: post #89

Rosetta 2 is great, except it apparently can't run statically-linked (non-PIC) binaries. I am unsure why this limitation exists, but it's pretty annoying because Virgil x86-64-binaries cannot run under Rosetta 2, which means I resort to running on the JVM on my M1...

Why are static binaries with PIC so rare? I’m surprised position dependent code is ever used anymore in the age of ASLR. But static binaries are still great for portability. So you’d think static binaries with PIC would be the default.

> But static binaries are still great for portability.

macOS has not officially supported static binaries in... ever? You can't statically link libSystem, and it absolutely does not care for kernel ABI stability.

Post reply on HN