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

201–210 of 367 posts

Re: Why is Rosetta 2 fast?

#201

Post by fuckstick »

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.

Re: Why is Rosetta 2 fast?

#202

Post by titzer »

pjmlp wrote: post #56
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 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.

Dynamic languages need inline caches, type feedback, and fairly heavy inlining to be competitive. Some of that can be gotten offline, e.g. by doing PGO. But you can't, in general, adapt to a program that suddenly changes phases, or rebinds a global that was assumed a constant, etc. Speculative optimizations with deopt are what make dynamic languages fast.

Re: Why is Rosetta 2 fast?

#203

Post by titzer »

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…

Darn it, replied too early. See sibling comment I just posted. The problem with dynamic languages is that you need to speculate and be ready to undo that speculation.

Re: Why is Rosetta 2 fast?

#204

Post by NavinF »

masklinn wrote: post #27
stu2b50 wrote: post #12

Earlier quoted context omitted.

Rosetta 1 had a ticking time bomb. Apple was licensing it from a 3rd party. Rosetta 2 is all in house as far as we know. Different CEO as well. Jobs was more opinionated on “principles” - Cook is more than happy to sell what people will buy. I think Rosetta 2 will last.

> Rosetta 1 had a ticking time bomb. Apple was licensing it from a 3rd party. Yes, I'm sure Apple had no way of extending the license. > Cook is more than happy to sell what people will buy. I think Rosetta 2 will last. There's no "buy" here. Rosetta is complexity to maintain, and an easy cut. It's not even part of the base system. And “what people will buy” certainly didn’t prevent essentially removing support for n…

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

Re: Why is Rosetta 2 fast?

#205

Post by avidiax »

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.

Probably the output of the decade-old compiler that produced the original binary had no optimizations.

Re: Why is Rosetta 2 fast?

#206

Post by savoytruffle »

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.

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.

Re: Why is Rosetta 2 fast?

#207

Post by jonny_eh »

arianvanp wrote: post #180
nicoburns wrote: post #30

Earlier quoted context omitted.

> If so, does it affect the application startup times? It does, but only the very first time you run the application. The result of the transpilation is cached so it doesn't have to be computed again until the app is updated.

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.

You mean the cache is ever expanding?

Re: Why is Rosetta 2 fast?

#208

Post by titzer »

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…

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.

Re: Why is Rosetta 2 fast?

#209

Post by astrange »

hamstergene wrote: post #123
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…

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 like inline assembly.

That's why bitcode is dead now.

By the way, I don't know why this thread is about how JITs can optimize programs when this article is about how Rosetta is not a JIT and intentionally chose a design that can't optimize programs.

Re: Why is Rosetta 2 fast?

#210

Post by astrange »

bluGill wrote: post #176
saagarjha wrote: post #138

Earlier quoted context omitted.

It depends greatly on which optimization levels you’re going through. —O0 to -O1 can easily be a 2-3x performance improvement, which is going to be hard to get otherwise. -O2 to -O3 might be 15% if you’re lucky, in which case -O+LTO+PGO can absolutely get you wins that beat that.

-O2 to -O3 has in some benchmarks made things worse. In others it is a massive win, but in generally going above -O2 should not be done without bench marking code. There are some optimizations that can make things worse or better for reasons that compiler cannot know.

Over-optimizing your "cold" code can also make things worse for the "hot" code, eg by growing code size so much that briefly entering the cold space kicks everything out of caches.
Post reply on HN