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

291–300 of 367 posts

Re: Why is Rosetta 2 fast?

#291

Post by kllrnohj »

titzer wrote: post #208
duped wrote: post #164

Earlier quoted context omitted.

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…

Nearly all JS engines are doing concurrent JIT compilation now, so some of the compilation cost is moved off the main thread. Java JITs have had multiple compiler threads for more than a decade.

But they all still optimize their JITs to prioritize compilation speed & RAM usage (JIT'd code is dirty pages after all) over maximum optimizations. This is why you see things like WebKits multi-tier JIT strategy: https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/

They still want to swap in that JIT'd result ASAP since after all by the time it's been flagged for compilation it's already too late & is a hot hot hot function.

Re: Why is Rosetta 2 fast?

#292

Post by webwielder2 »

(Apologies for the flame war quality to this comment, I’m genuinely just expressing an observation)

It’s ironic that Apple is often backhandedly complimented by hackers as having “good hardware” when their list of software accomplishments is amongst the most impressive in the industry and contrasts sharply with the best efforts of, say, Microsoft, purportedly a “software company.”

Re: Why is Rosetta 2 fast?

#293

Post by scarface74 »

classichasclass wrote: post #194
dev_tty01 wrote: post #127

Earlier quoted context omitted.

>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." T…

Part of that was the greater clock speeds on the 601 and 603, though. Those started at 60MHz. Clock for clock 68K apps were generally poorer on PowerPC until PPC clock speeds made them competitive, and then the dynamic recompiling emulator knocked it out of the park. Similarly, Rosetta was clock-for-clock worse than Power Macs at running Power Mac applications. The last generation G5s would routinely surpass Mac Pros…

The first gen 68K emulator performed worse on the PPC 603 than the 601.

Re: Why is Rosetta 2 fast?

#294

Post by mrpippy »

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.

This should work (Wine obviously needs it when running 32-bit apps). Are you explicitly specifying a small PAGEZERO when compiling?

Re: Why is Rosetta 2 fast?

#295

Post by scarface74 »

GeekyBear wrote: post #226
savoytruffle wrote: post #206

Earlier quoted context omitted.

I agree it was a bit worryingly short-lived. However the first version of Mac OS X that shipped without Rosetta 1 support was 10.7 Lion in summer 2011 (and many people avoided it since it was problematic). So nearly-modern Mac OS X with Rosetta support was realistic for a while longer.

> However the first version of Mac OS X that shipped without Rosetta 1 support was 10.7 Lion Yes, but I was pointing out when the last version of OS X that did support Rosetta shipped. I have no concrete evidence that Apple dropped Rosetta because IBM wanted to alter the terms of the deal after they bought Transitive, but I've always found that timing interesting. In comparison, the emulator used during the 68k to PP…

> In comparison, the emulator used during the 68k to PPC transition was never removed from Classic MacOS, so the change stood out.

It was never removed because Classic MacOS itself was never fully native.

Re: Why is Rosetta 2 fast?

#296

Post by dev_tty01 »

ChuckNorris89 wrote: post #21
dynjo wrote: post #17

It is quite astonishing how seamless Apple has managed to make the Intel to ARM transition, there are some seriously smart minds behind Rosetta. I honestly don't think I had a single software issue during the transition!

If that blows your mind, you should see how Microsoft did the emulation of the PowerPC based Xeon chip to X86 so you can play Xbox 360 games on Xbox One. There's an old pdf from Microsoft researchers with the details but I can't seem to find it right now.

They also bought a boat load of PPC Macs for much of the early Xbox dev work.

Re: Why is Rosetta 2 fast?

#297

Post by Klonoar »

mrpippy wrote: post #294
Klonoar wrote: post #191

Earlier quoted context omitted.

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.

This should work (Wine obviously needs it when running 32-bit apps). Are you explicitly specifying a small PAGEZERO when compiling?

Yup!

Re: Why is Rosetta 2 fast?

#298

Post by josephg »

astrange wrote: post #209
hamstergene wrote: post #123

Earlier quoted context omitted.

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

> 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. This turns out to be quite difficult, especially if you're using bitcode as a compiler IL. You have to know what the right "intermediate" level is; if assumptions change too much under you then it's still too specific. And it means you can't use things…

> That's why bitcode is dead now.

WebAssembly seems alive and well. I'm not sure how similar it is to java bitcode but its the same core idea.

That said, WASM through v8 is ~3x slower than the same code compiled natively. (Some of this might be due to the lack of SIMD in wasm).

Re: Why is Rosetta 2 fast?

#299

Post by my123 »

Symmetry wrote: post #161
my123 wrote: post #153

Earlier quoted context omitted.

Arm64 allows FPU-less designs. There are some around…

Sure. The FPU is optional on a Cortex M2, for instance. But those don't have MMUs. You'd certainly need an expensive architectural license to make something with an MMU but no FPU if you wanted to and given all the requirements ARM normally imposes for software compatibility[1] between cores I'd tend to doubt that they'd let you make something like that. [1] Explicitly testing that you don't implement total store ord…

There are arm64 designs with MMUs but not FPUs. See Cortex-R82.

That [1] is wrong too. Tegra Xavier shipped with sequential consistency out of the box :)

Re: Why is Rosetta 2 fast?

#300

Post by KMag »

astrange wrote: post #283
lmm wrote: post #235

Earlier quoted context omitted.

> This turns out to be quite difficult, especially if you're using bitcode as a compiler IL. You have to know what the right "intermediate" level is; if assumptions change too much under you then it's still too specific. And it means you can't use things like inline assembly. > That's why bitcode is dead now. Isn't this what Android does today? Applications are distributed in bytecode form and then optimized for the…

I don't know what Android does… some kind of Java but not Java, right? In that case it's much less expressive, so developers simply can't do the unsafe/specialized code in the first place. Which means they can't write in C or assembly. Bitcode was a specific Apple feature that used LLVM's compiler IL and might have promised extra portability, but it didn't really work out and was removed this year. ("LLVM" stands for…

LLVM is lower level than Python or Java bytecode. LLVM is also virtual machine in the sense of an abstract machine, similar in idea to a process virtual machine. Most usages of "virtual machine" today are talking about system virtual machines, but it's important to note that "virtual machine" is an overloaded phrase.
Post reply on HN