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

251–260 of 367 posts

Re: Why is Rosetta 2 fast?

#251

Post by KMag »

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

Like another commented, JIT compilers do this today. The thing that makes this mostly theoretical is that the underlying assumption is only true when you neglect that an AOT has zero run-time cost while a JIT compiler has to execute the code it's optimizing and the code to decide if it's worth optimizing and generate new code. So JIT compiler optimizations are a bit different than AOT optimizations since they have to…

But, JIT vs. AoT is a false dichotomy. Given light-weight enough profiling utilizing cooperation between hardware designers and compiler writers, one could have AoT with feedback-guided optimization and link-time optimization, and still have just-in-time re-optimization.

Concretely, I think you'd want hardware that supported reservoir sampling of where CPU cycles are spent, sampling of which branches are mispredicted, and which code locations are causing cache misses. You'd also want lightweight hardware recording of execution traces.

Re: Why is Rosetta 2 fast?

#252

Post by adgjlsfhk1 »

masklinn wrote: post #223
NavinF wrote: post #204

Earlier quoted context omitted.

> removing support for non-hidpi displays from MacOS Did that really reduce sales? Consider that the wide availability of crappy low end hardware gave Windows laptops a terrible reputation. Eg https://www.reddit.com/r/LinusTechTips/comments/yof7va/frien...

> Consider that the wide availability of crappy low end hardware gave Windows laptops a terrible reputation. Standard DPI displays are not "crappy low-end hardware"? I don't think there's a single widescreen display which qualifies as hiDPI out there, that more or less doesn't exist: a 5K 34" is around 160 DPI (to say nothing of the downright pedestrian 5K 49" like the G9 or the AOC Agon).

dpi isn't the right metric. you don't keep a phone the same distance as a 49" monitor.

Re: Why is Rosetta 2 fast?

#253

Post by 0x000xca0xfe »

I wonder if such a direct translation from ARM to another architecture would even be possible given that the instruction set can be changed at runtime (thumb mode). Does anybody know how often typical ARM32 programs execute this mode switching or if such sections can be recognized statically?

Re: Why is Rosetta 2 fast?

#254

Post by manv1 »

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…

That's not true for the 6100 but for the 8100 it was totally true. And at some point my 8500 ran 68k faster than any 68040 ever made, which isn't really fair since the 8500 was rocking good.

Re: Why is Rosetta 2 fast?

#255

Post by manv1 »

Wowfunhappy wrote: post #63
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.

> 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. Not arguing the facts here, but I'm curious—are these successes related? And if so, how has Apple done that? I would imagine that very few of the engineers who programmed Apple's 68k emulator are still working at Apple today. So,…

I suspect that there's a design document somewhere that has secrets and tips. Plus MacOS and NeXTstep have been ported so many times that by now any arch-level things are well-isolated. A lot of the pain of MacOS on x86 were related to kernel extensions and driver API changes. And a lot of stuff fell out during the 64-bit transition.

In general, MacOS/iOS/iPadOS owe everything to the excellent architecture laid down by the NeXT team back in the day. NeXTstep now has the dream that MS tried and failed to do back in the day: an OS that runs on every kind of device they make. Funny how that is.

Re: Why is Rosetta 2 fast?

#256

Post by Wowfunhappy »

spacedcowboy wrote: post #230
Wowfunhappy wrote: post #63

Earlier quoted context omitted.

> 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. Not arguing the facts here, but I'm curious—are these successes related? And if so, how has Apple done that? I would imagine that very few of the engineers who programmed Apple's 68k emulator are still working at Apple today. So,…

FWIW, I know several current engineers at Apple who wrote ground-breaking stuff before the Mac even existed. Apple certainly doesn't have any problem with older engineers, and it turns out that transferring that expertise to new chips on demand isn't particularly hard for them.

> Apple certainly doesn't have any problem with older engineers

Just to be clear, I never meant to suggest that they did—I just didn't realize employees remained with the company for that long, instead of switching.

Re: Why is Rosetta 2 fast?

#257

Post by dougall »

saagarjha wrote: post #158
jeffbee wrote: post #44

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…

Haven’t spotted any in particular.

Yeah, I haven't either, but I haven't looked. So, I'm not sure, but I wouldn't expect any "function recognition" tricks, since there isn't really static linking, but I would expect the e.g. memcpy and strcpy implementations in the ahead-of-time translated shared cache to be written in arm64 assembly rather than translated.

Re: Why is Rosetta 2 fast?

#258

Post by anyfoo »

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…

That's a lesson Intel had to (re-?)learn with Itanium as well.

Re: Why is Rosetta 2 fast?

#259

Post by anyfoo »

Klonoar wrote: post #191
cwzwarich wrote: post #111

Earlier quoted context omitted.

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

Huh, this is timely. Incredibly random but: do you know if there was anything that changed as of Ventura to where trying to mmap below the 2/4GB boundary would no longer work in Rosetta 2? I've an app where it's worked right up to Monterey yet inexplicably just bombs in Ventura.

Not affiliated and don't know, but curious why you're doing that in the first place?

Re: Why is Rosetta 2 fast?

#260

Post by dougall »

saagarjha wrote: post #170

One thing that’s interesting to note is that the amount of effort expended here is not actually all that large. Yes, there are smart people working on this, but the performance of Rosetta 2 for the most part is probably the work of a handful of clever people. I wouldn’t be surprised if some of them have an interest in compilers but the actual implementation is fairly straightforward and there isn’t much of the stuff…

Yeah, agreed. I get the impression it's a small team.

But there is a long-tail of weird x86 features that are implemented, that give them amazing compatibility, that I regret not mentioning:

* 32-bit support for Wine

* full x87 emulation

* full SSE2 support (generally converting to efficient NEON equivalents) for performance on SIMD code

I consider all of these "compatibility", but that last one in particular should have been in the post, since that's very important to the performance of optimised SIMD routines (plenty of emulators also do SIMD->SIMD, but others just translate SIMD->scalar or SIMD->helper-runtime-call).

Post reply on HN