Why is Rosetta 2 fast? • Hacker News Board

Re: Why is Rosetta 2 fast?

#271

Post by monocularvision » Thu, Nov 10, 2022, 1:00 AM UTC

lmm wrote: post #235

astrange wrote: post #209

Earlier quoted context omitted.

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

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

The bitcode Apple used for their platforms was at a much, much lower level than bytecode used on Android.

Re: Why is Rosetta 2 fast?

#272

Post by musicale » Thu, Nov 10, 2022, 1:06 AM UTC

Rosetta 2 is beautiful - I would love it if they kept it as a feature for the long term rather than deprecating it and removing it in the next release of macOS (basically what they did during previous architectural transitions.)

If Apple does drop it, maybe they could open source it so it could live on in Linux and BSD at least. ;-)

Adding a couple of features to ARM to drastically improve translated x86 code execution sounds like a decent idea - and one that could potentially enable better x86 app performance on ARM Windows as well. I don't know the silicon cost but I'd hope it wasn't dropped in the future.'

Thinking a bit larger, I'd also like to see Apple add something like CHERI support to Apple Silicon and macOS to enable efficient memory error checking in hardware. I'd be surprised if they weren't working on something like this already.

Re: Why is Rosetta 2 fast?

#273

Post by saagarjha » Thu, Nov 10, 2022, 1:09 AM UTC

dougall wrote: post #257

saagarjha wrote: post #158

Earlier quoted context omitted.

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.

Indeed, see the _platform_*$VARIANT$Rosetta implementations in libsystem_platform.dylib.

Re: Why is Rosetta 2 fast?

#274

Post by saagarjha » Thu, Nov 10, 2022, 1:13 AM UTC

KMag wrote: post #251

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…

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…

Guess what Apple has? :)

Re: Why is Rosetta 2 fast?

#275

Post by travisgriggs » Thu, Nov 10, 2022, 1:15 AM UTC

bluGill wrote: post #179

mikepurvis wrote: post #104

Earlier quoted context omitted.

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…

The problem with static compilation is not all information known at compile time is the correct information to optimize on.

Assuming either source of data is the single source of truth for all optimizations is a fallacy.

Use the right tool for the right job. Use all the tools if you can.

Re: Why is Rosetta 2 fast?

#276

Post by saagarjha » Thu, Nov 10, 2022, 1:17 AM UTC

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.

Pretty sure mmap goes almost directly to the kernel in Rosetta 2, and Apple silicon requires at least 4 GB.

Re: Why is Rosetta 2 fast?

#277

Post by DonHopkins » Thu, Nov 10, 2022, 1:17 AM UTC

iainmerrick wrote: post #66

klelatti wrote: post #34

Earlier quoted context omitted.

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

That is nifty! Sounds very similar to a Forth interpreter.

There's also OpenFirmware's platform independent Forth bytecode "FCode":

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

>Open Firmware Forth Code may be compiled into FCode, a bytecode which is independent of instruction set architecture. A PCI card may include a program, compiled to FCode, which runs on any Open Firmware system. In this way, it can provide boot-time diagnostics, configuration code, and device drivers. FCode is also very compact, so that a disk driver may require only one or two kilobytes. Therefore, many of the same I/O cards can be used on Sun systems and Macintoshes that used Open Firmware. FCode implements ANS Forth and a subset of the Open Firmware library.

Re: Why is Rosetta 2 fast?

#278

Post by [deleted] » Thu, Nov 10, 2022, 1:18 AM UTC

fuckstick wrote: post #201

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…

> The output was faster than the input. So if you ran the input back through the output multiple times then that means you could eventually get the runtime down to 0.

[deleted]

Re: Why is Rosetta 2 fast?

#279

Post by olliej » Thu, Nov 10, 2022, 1:19 AM UTC

skrrtww wrote: post #162

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

Are you able to speak at all to the known performance struggles with x87 translation? Curious to know if we're likely to see any updates or improvements there into the future.

There are two ways to approach x87: either saying to heck with it and just using doubles for everything (this is essentially what Qemu does) or creating a software fp80 implementation. Both approaches get burned by the giant amount of state, and state weirdness, that x87 brings to the table. It's also not possible to "fix" things by optimizing for the cases where the x87 unit's precision is set to the same as fp32 or fp64, as the precision flags don't impact the exponent range.

But even on native hardware using x87 is vastly slower than fp64, and it's just a shame that only win64 had the good sense to define long double as being fp64 instead of fp80 as every other x86_64 platform did :-/

Re: Why is Rosetta 2 fast?

#280

Post by saagarjha » Thu, Nov 10, 2022, 1:24 AM UTC

0x000xca0xfe wrote: post #253

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?

Shouldn’t be hard under this scheme, it tracks indirect branches anyways. Just swap which table you do lookups based on whether you’re in thumb mode or not.