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

211–220 of 367 posts

Re: Why is Rosetta 2 fast?

#211

Post by AussieWog93 »

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…

Outside of gaming, or hyper-CPU-critical workflows like video editing, I'm not really sure if people actually even care about that last 10% of performance.

I know most of the time I get frustrated by everyday software, its doing something unnecessary in a long loop, and possibly forgetting to check for Windows messages too.

Re: Why is Rosetta 2 fast?

#212

Post by r00fus »

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.

Apple is also not tied to reverse compatibility.

Their customers are not enterprise, and consequently they are probably the best company in the world at dictating well-managed, reasonable shifts in customer behavior at scale.

So they likely had no need for Rosetta as of 2009.

Re: Why is Rosetta 2 fast?

#213

Post by hinkley »

avidiax wrote: post #205
fuckstick wrote: post #201

Earlier quoted context omitted.

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

That too but the eternal riddle of optimizer passes is which ones reveal structure and which obscure it. Do I loop unroll or strength reduce first? If there are heuristics about max complexity for unrolling or inlining then it might be “both”.

And then there’s processor family versus this exact model.

Re: Why is Rosetta 2 fast?

#214

Post by titzer »

bluGill wrote: post #182
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…

gcc and clang at least have options so you can optimize for specific CPUs. I'm not sure how good they are (most people want a generic optimization that runs well on all CPUs of the family, so there likely is lots of room for improvement with CPU specific optimization), but they can do that. This does (or at least can, again it probably isn't fully implemented), account for instruction length, pipeline depth, cache si…

> take advantage of every trick they can for specific CPUs

Not to the extent clang and gcc do, no. V8 does, e.g. use AVX instructions and some others if they are indicated to be available by CPUID. TurboFan does global scheduling in moving out of the sea of nodes, but that is not machine-specific. There was an experimental local instruction scheduler for TurboFan but it never really helped big cores, while measurements showed it would have helped smaller cores. It didn't actually calculate latencies; it just used a greedy heuristic. I am not sure if it was ever turned on. TurboFan doesn't do software pipelining or unroll/jam, though it does loop peeling, which isn't CPU-specific.

Re: Why is Rosetta 2 fast?

#215

Post by astrange »

bluGill wrote: post #182
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…

gcc and clang at least have options so you can optimize for specific CPUs. I'm not sure how good they are (most people want a generic optimization that runs well on all CPUs of the family, so there likely is lots of room for improvement with CPU specific optimization), but they can do that. This does (or at least can, again it probably isn't fully implemented), account for instruction length, pipeline depth, cache si…

> gcc and clang at least have options so you can optimize for specific CPUs. I'm not sure how good they are

They are not very good at it, and can't be. You can look inside them and see the models are pretty simple; the best you can do is optimize for the first step (decoder) of the CPU and avoid instructions called out in the optimization manual as being especially slow. But on an OoO CPU there's not much else you can do ahead of time, since branches and memory accesses are unpredictable and much slower than in-CPU resource stalls.

Re: Why is Rosetta 2 fast?

#216

Post by howinteresting »

saagarjha wrote: post #160
howinteresting wrote: post #85

Earlier quoted context omitted.

Here you go for a concrete example: https://news.ycombinator.com/item?id=33493276

This has nothing to do with Rosetta being incomplete (it has pretty good fidelity).

It was direct corroboration of:

> Apple users not being able to use the same hardware peripherals or same software as other people is not a problem, it's a feature. There's no doubt the M1/M2 chips are fast. It's just a problem that they're only available in crappy computers that can't run a large amount of software or hardware.

Re: Why is Rosetta 2 fast?

#217

Post by masklinn »

titzer wrote: post #189
masklinn wrote: post #130

Earlier quoted context omitted.

> But static binaries are still great for portability. macOS has not officially supported static binaries in... ever? You can't statically link libSystem, and it absolutely does not care for kernel ABI stability.

> 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 support for direct syscalls. That is why, again, you can't statically link libSystem.

> (Virgil actually does call the kernel directly).

That's completely unsupported ¯\_(ツ)_/¯

Re: Why is Rosetta 2 fast?

#219

Post by saltcured »

kijiki wrote: post #151
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.

Similar to DEC's FX!32 in that regard. FX!32 allowed running x86 Windows NT apps on Alpha Windows NT.

There was also an FX!32 for Linux. But I think it may have only included the interpreter part and left out the transpiler part. My memory is vague on the details.

I do remember that I tried to use it to run the x86 Netscape binary for Linux on a surplus Alpha with RedHat Linux. It worked, but so slowly that a contemporary Python-based web browser had similar performance. In practice, I settled on running Netscape from a headless 486 based PC and displaying remotely on the Alpha's desktop over ethernet. That was much more usable.

Re: Why is Rosetta 2 fast?

#220

Post by kccqzy »

> The instructions from FEAT_FlagM2 are AXFLAG and XAFLAG, which convert floating-point condition flags to/from a mysterious “external format”. By some strange coincidence, this format is x86, so these instruction are used when dealing with floating point flags.

This really made me chuckle. They probably don't want to mention Intel by name, but this just sounds funny.

https://developer.arm.com/documentation/100076/0100/A64-Inst...

Post reply on HN