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

171–180 of 367 posts

Re: Why is Rosetta 2 fast?

#171

Post by bonzini »

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.

Apple had a library of SIMD subroutines (IIRC Accelerate.framework) and Rosetta was able to use the x86 implementation when translating PPC applications that called it.

Re: Why is Rosetta 2 fast?

#172

Post by tomcam »

> Every one-byte x86 push becomes a four byte ARM instruction

Can someone explain this to me? I don’t know ARM but it just seems to me a push should not be that expensive.

Re: Why is Rosetta 2 fast?

#173

Post by com2kid »

saagarjha wrote: post #140
com2kid wrote: post #121

Earlier quoted context omitted.

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

The well funded production JIT compilers (HotSpot, V8, etc.) absolutely do take advantage of these. The vector ISA can sometimes be unwieldy to work with but things like replacing atomics, using unaligned loads, or taking advantage of differing pointer representations is common.

They do some auto-vectorization, but AFAIK they don't do micro-optimizations for different CPUs.

Re: Why is Rosetta 2 fast?

#174

Post by TazeTSchnitzel »

tomcam wrote: post #172

> Every one-byte x86 push becomes a four byte ARM instruction Can someone explain this to me? I don’t know ARM but it just seems to me a push should not be that expensive.

x86 has variable-length instructions, so they can be anything from 1 to 15 bytes long. AArch64 instructions are always 4 bytes long.

Re: Why is Rosetta 2 fast?

#175

Post by tomcam »

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…

I’m likely misunderstanding what you said, but I thought pre-compiled headers were pretty much standard these days.

Re: Why is Rosetta 2 fast?

#176

Post by bluGill »

saagarjha wrote: post #138
mark_undoio wrote: post #132

Earlier quoted context omitted.

Something that fascinates me about this kind of A -> A translation (which I associate with the original HP Dynamo project on HPPA CPUs) is that it was able to effectively yield the performance effect of one or two increased levels of -O optimization flag. Right now it's fairly common in software development to have a debug build and a release build with potentially different optimisation levels. So that's two builds…

It depends greatly on which optimization levels you’re going through. —O0 to -O1 can easily be a 2-3x performance improvement, which is going to be hard to get otherwise. -O2 to -O3 might be 15% if you’re lucky, in which case -O+LTO+PGO can absolutely get you wins that beat that.

-O2 to -O3 has in some benchmarks made things worse. In others it is a massive win, but in generally going above -O2 should not be done without bench marking code. There are some optimizations that can make things worse or better for reasons that compiler cannot know.

Re: Why is Rosetta 2 fast?

#177

Post by nwallin »

saagarjha wrote: post #144
karmakaze wrote: post #54

Vertical integration. My understanding was it's because the Apple silicon ARM has special support to make it fast. Apple has had enough experience to know that some hardware support can go a long way to making the binary emulation situation better.

That’s not correct, the article goes into details why.

That is correct, the article goes into details why. See the "Apple's Secret Extension" section as well as the "Total Store Ordering" section.

The "Apple's Secret Extension" section talks about how the M1 has 4 flag bits and the x86 has 6 flag bits, and how emulating those 2 extra flags would make every add/sub/cmp instruction significantly slower. Apple has an undocumented extension that adds 2 more flag bits to make the M1's flag bits behave the same as x86.

The "Total Store Ordering" section talks about how Apple has added a non-standard store ordering to the M1 than makes the M1 order its stores in the same way x86 guarantees instead of the way ARM guarantees. Without this, there's no good way to translate instructions in code in and around an x86 memory fence; if you see a memory fence in x86 code it's safe to assume that it depends on x86 memory store semantics and if you don't have that you'll need to emulate it with many mostly unnecessary memory fences, which will be devastating for performance.

Re: Why is Rosetta 2 fast?

#178

Post by Vt71fcAqt7 »

masklinn wrote: post #168
Vt71fcAqt7 wrote: post #163

Earlier quoted context omitted.

Is there a real source for this claim? It gets parroted a lot on HN and elsewhere, but I've also heard it's greatly exagerated. I don't think Apple engineers get to read the licences, and even if they did, how do we know they understood it corretly and that it got repeated correctlty? I've never seen a valid source for this claim.

For what claim? They they co-founded ARM? That’s historical record. That they extended the ISA? That’s literally observed from decompilations. That they can do so? They’ve been doing it for at least 2 years and ARM has yet to sue. > I've never seen a valid source for this claim. What is “a valid source”? The linked comment is from Hector Martin, the founder and lead of Asahi, who worked on and assisted with reversing…

>For what claim?

that they have "essentially full control on ARM"

Having an ALA + some extras doesn't mean "full control."

he also says:

>And apparently in Apple's case, they get to be a little bit incompatible

So he doesn't seem to actually know the full extent to which Apple has more rights, even using the phrase "a little bit" — far from your claim. And he (and certainly you) has not read the license. Perhaps they have to pay for each core they release on the market that breaks compatabilty? Do you know? Of course not. A valid source would be a statement from someone who read the license or one of the companies. There is more to a core than just the ISA. If not, why is Apple porring cores to RISC-V? If they have so much control ?

Re: Why is Rosetta 2 fast?

#179

Post by bluGill »

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…

The problem with JIT is not all information known at runtime is the correct information to optimize one.

In finance the performance critical code path is often the one run least often. That is you have a if(unlikely_condition) {run_time_sensitive_trade();}. In this case you need to tell the compiler to ensure the CPU will have a pipeline stall because of a branch misprediction most of the time to ensure the time that counts the pipeline doesn't stall.

The above is a rare corner case for sure, but it is one of those weird exceptions you always need to keep in mind when trying to make any blanket rule.

Re: Why is Rosetta 2 fast?

#180

Post by arianvanp »

nicoburns wrote: post #30
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?

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

And deleting the cache is undocumented (it is not in the file system) so if you run Mac machines as CI runners they will trash and brick themselves running out of disk space over time.
Post reply on HN