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

311–320 of 367 posts

Re: Why is Rosetta 2 fast?

#311

Post by bogomipz »

GeekyBear wrote: post #192
kijiki wrote: post #146

Earlier quoted context omitted.

> Anyone know how they implemented PPC-to-x86 translation? They licensed Transitive's retargettable binary translator, and renamed it Rosetta; very Apple. It was originally a startup, but had been bought by IBM by the time Apple was interested.

> It was originally a startup, but had been bought by IBM by the time Apple was interested. Rosetta shipped in 2005. IBM bought Transitive in 2008. The last version of OS X that supported Rosetta shipped in 2009. I always wondered if the issue was that IBM tried to alter the terms of deal too much for Steve's taste.

>"The last version of OS X that supported Rosetta shipped in 2009."

Interesting, so was Rosetta 2 written from the ground up then? Did Apple manage to hire any of the former Transitive engineers after IBM acquired them? It seems like this would be a niche group of engineers that worked in this area no?

Re: Why is Rosetta 2 fast?

#312

Post by astrange »

Someone wrote: post #10
MikusR wrote: post #3

The main reason, M1/2 being incredibly fast. Is listed last.

I don’t think that’s the main reason. The article lists a few things that, I think the main reason is that they made several parts of the CPU behave identical to x86. The M1 and M2 chips: - can be told to do total store ordering, just as x86 does - have of a few status flags that x86 has, but regular arm doesn’t - can be told to make the FPU behave exactly as the x86 FPU It also helps that ARM has many more registers…

None of those custom features are used in Linux/in VMs, and it's still fairly fast.

Re: Why is Rosetta 2 fast?

#313

Post by pjmlp »

kllrnohj wrote: post #289
travisgriggs wrote: post #275

Earlier quoted context omitted.

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.

Tooling and real data sets.

Most PGO for AOT scenarios suffers from tooling experience and not using data sets similar to production workflows.

Re: Why is Rosetta 2 fast?

#314

Post by comex »

masklinn wrote: post #217
titzer wrote: post #189

Earlier quoted context omitted.

> it absolutely does not care for kernel ABI stability That may be true on the mach system call side, but the UNIX system calls don't appear to change. (Virgil actually does call the kernel directly).

> That may be true on the mach system call side, but the UNIX system calls don't appear to change. They very much do, without warning, as the Go project discovered (after having been warned multiple times) during the Sierra betas: https://github.com/golang/go/issues/16272 https://github.com/golang/go/issues/16606 That doesn't mean Apple goes outs of its way to break syscalls (unlike microsoft), but there is no suppor…

Another example: https://github.com/jart/cosmopolitan/issues/426

Re: Why is Rosetta 2 fast?

#315

Post by pjmlp »

hinkley wrote: post #224
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.

Before I talked myself out of writing my own programming language, I used to have lunch conversations with my mentor who was also speed obsessed about how JIT could meet Knuth in the middle by creating a collections API with feedback guided optimization, using it for algorithm selection and tuning parameters by call site. For object graphs in Java you can waste exorbitant amounts of memory by having a lot of “childre…

That is in a sense what JIT caching with PGO feedback loop does to a certain extent.

As for mobile, this isn't far off from the whole set of hand written Assembly interpreter, JIT with PGO data caching, AOT compilation on idle with the PGO collected data, sharing PGO metadata with other devices via the PlayStore, that Android happens to do since version 7, and refined later.

Re: Why is Rosetta 2 fast?

#316

Post by pjmlp »

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…

Bitcode is dead because Apple got fed up to keep maintaining their own fork with guarantees that regular LLVM doesn't offer.

Since 1961 plenty of systems have used bytecodes as executable formats, the most sucessfull still in use, IBM and Unisys mainframes and microcomputers.

Re: Why is Rosetta 2 fast?

#317

Post by pjmlp »

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…

There is no C or Assembly in IBM and Unisys mainframes and microcomputers.

Re: Why is Rosetta 2 fast?

#318

Post by pjmlp »

monocularvision wrote: post #271
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…

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

Yeah, it was also a custom version, somehow people keep thinking they used LLVM bitcode straight out of the box.

Re: Why is Rosetta 2 fast?

#319

Post by pjmlp »

kllrnohj wrote: post #288
travisgriggs wrote: post #40

Earlier quoted context omitted.

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…

Sure, because everyone ships static linked binaries.

Re: Why is Rosetta 2 fast?

#320

Post by pjmlp »

kllrnohj wrote: post #291
titzer wrote: post #208

Earlier quoted context omitted.

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…

Which is why in the Java world (including Android), and .NET, now we use JIT caches as well, so that this data isn't lost between runs.
Post reply on HN