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

281–290 of 367 posts

Re: Why is Rosetta 2 fast?

#281

Post by vinyl7 »

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…

> where the compilers had a fast mode for code-build-test cycles and a very slow incremental mode for official builds.

That already exists with c/c++...unity builds aka single translation unit builds. Compiling and linking a ton of object files takes an inordinate amount of time, often the majority of the build time

Re: Why is Rosetta 2 fast?

#282

Post by hoosieree »

klelatti wrote: post #34
iainmerrick wrote: post #23

This is a great writeup. What a clever design! I remember Apple had a totally different but equally clever solution back in the days of the 68K-to-PowerPC migration. The 68K had 16-bit instruction words, usually with some 16-bit arguments. The emulator’s core loop would read the next instruction and branch directly into a big block of 64K x 8 bytes of PPC code. So each 68K instruction got 2 dedicated PPC instructions…

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

And here I was feeling impressed with myself for implementing the Nand2Tetris VM translator in ~2k of python... wow. Respect for the elders!

Re: Why is Rosetta 2 fast?

#283

Post by astrange »

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…

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 "low level virtual machine" which is funny because it isn't low level and isn't a virtual machine.)

Re: Why is Rosetta 2 fast?

#284

Post by funstuff007 »

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 can also be an argument for instrumenting your runtime environment

Aren't JITs already self-instrumenting? What would you instrument that the JIT is not already keeping track of?

Re: Why is Rosetta 2 fast?

#285

Post by happyopossum »

rowanG077 wrote: post #234
arianvanp wrote: post #180

Earlier quoted context omitted.

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.

What in the actual fuck. That is such an insane decision. Where is it stored then? Some dark corner of the file system inaccessible via normal means?

GP is incorrect - they’re stored in individual files inside /var/db/oah, and can be deleted without causing harm.

Re: Why is Rosetta 2 fast?

#286

Post by Klonoar »

anyfoo wrote: post #259
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.

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

's not my doing, it's just an older project that's slowly migrating to a newer system but is held back by everyone having lives. I wouldn't do it normally, heh.

Re: Why is Rosetta 2 fast?

#287

Post by Klonoar »

saagarjha wrote: post #276
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.

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

This works fine in Big Sur and Monterey on Apple Silicon, hence my point about if something changed in Ventura.

Edit: Big Sur -> Ventura.

Re: Why is Rosetta 2 fast?

#288

Post by kllrnohj »

travisgriggs wrote: post #40
wmf wrote: post #25

Earlier quoted context omitted.

https://www.hpl.hp.com/techreports/1999/HPL-1999-78.html

It was particularly poignant at the time because JITed languages were looked down on by the “static compilation makes us faster” crowd. So it was a sort of “wait a minute Watson!” moment in that particular tech debate. No one cares as much now days, we’ve moved our overrated opinion battlegrounds to other portions of what we do.

I think you're over estimating the impact or relevance of that anecdote. Particularly since the "static compilation makes us faster" crowd turned out to be correct, and people use JITs for non-performance reasons and just pay the performance tax they so often come with. The time-constrained nature in which a JIT has to run just largely kills it's theoretical runtime information gathering advantages. Devirtualization remains about the most advanced trick in the JIT book, which is generally not an issue static compiled languages struggle with in the first place.

Re: Why is Rosetta 2 fast?

#289

Post by kllrnohj »

travisgriggs wrote: post #275
bluGill wrote: post #179

Earlier quoted context omitted.

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.

Static compilers usually don't have to make such a tradeoff, though. They are free to spend arbitrarily long amounts of time optimizing all branches. And they often do exactly that.

Static + LTO w/ PGO is pretty much the practical ideal. JITs don't offer much until you start adding dynamically loaded code where LTO just isn't possible anymore.

Re: Why is Rosetta 2 fast?

#290

Post by Dylan16807 »

adgjlsfhk1 wrote: post #252
masklinn wrote: post #223

Earlier quoted context omitted.

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

DPI works fine as long as the type of device is in the context. The context here is desktop/laptop.
Post reply on HN