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

331–340 of 367 posts

Re: Why is Rosetta 2 fast?

#331

Post by xattt »

scarface74 wrote: post #295
GeekyBear wrote: post #226

Earlier quoted context omitted.

> However the first version of Mac OS X that shipped without Rosetta 1 support was 10.7 Lion Yes, but I was pointing out when the last version of OS X that did support Rosetta shipped. I have no concrete evidence that Apple dropped Rosetta because IBM wanted to alter the terms of the deal after they bought Transitive, but I've always found that timing interesting. In comparison, the emulator used during the 68k to PP…

> In comparison, the emulator used during the 68k to PPC transition was never removed from Classic MacOS, so the change stood out. It was never removed because Classic MacOS itself was never fully native.

> It was never removed because Classic MacOS itself was never fully native.

Are there any current OSes that have the same level of historical cruft that Mac OS Classic had?

Re: Why is Rosetta 2 fast?

#332

Post by phire »

olliej wrote: post #279
skrrtww wrote: post #162

Earlier quoted context omitted.

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…

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

I've been meaning to look into this. Certainly you can't blindly optimise all x87 code sequences to fp32 or fp64. But some sequences are safe.

For example, adding two numbers and saving back to memory is safe to optimise (at least for the infinity case, I haven't double-checked the subnormal behaviour). It's only when you need to add three or more numbers that you run into issues (though you can go further, if all N numbers have the same sign, you will get the correct result, you just might have saturated at infinity a few operations earlier than native x87)

Same goes for multiplication of two numbers (and N numbers that all provably >= 1.0)

The question is if such code sequences are common enough to bother trying to identify at compile time and optimise.

Re: Why is Rosetta 2 fast?

#333

Post by menaerus »

saagarjha wrote: post #170

One thing that’s interesting to note is that the amount of effort expended here is not actually all that large. Yes, there are smart people working on this, but the performance of Rosetta 2 for the most part is probably the work of a handful of clever people. I wouldn’t be surprised if some of them have an interest in compilers but the actual implementation is fairly straightforward and there isn’t much of the stuff…

I think it's about the incentive and not about other companies not doing it. Apple decided to move to ARM and the reason is probably in their strong connection to the ARM ecosystem which basically means that they have an edge with their vertical-integration approach when compared to the other competitors. Apple is one of the three _founding_ companies of ARM. Other two were VLSI Technology and Acorn.

Re: Why is Rosetta 2 fast?

#334

Post by menaerus »

dougall wrote: post #265
saagarjha wrote: post #184

Earlier quoted context omitted.

I’m aware of both of these extensions; they’re not actually necessary for most applications. Yes, you trade fidelity with performance, but it’s not that big of a deal. The majority of Rosetta’s performance is good software decisions and not hardware.

Yeah, these features exist, and they help, but I don't think they should be given all the credit. Both "Apple's Secret Extension" and "Total Store Ordering" are features that other emulators can choose to disable to get exactly the same performance. "Apple's Secret Extension" isn't even used by Rosetta 2 on Linux (opting for, at least, explicit parity flag calculations rather than reduced fidelity). It's still fast.…

> TSO is only required for accuracy on multithreaded applications

If by accuracy you mean not segfaulting then yes. Every moderately complex x86-64 application will have memory fences in the generated machine code. x86-64 design of store-buffers and load-buffers are making the memory fences a necessity. In reality it's enough just to use the mutex or atomics in your code to end up with the memory fence in your generated machine code. So, I'd say that this particular part of Rosetta/M1 design is quite important, if not the most important. Without it applications wouldn't run.

Re: Why is Rosetta 2 fast?

#335

Post by kalleboo »

ksherlock wrote: post #185
Vt71fcAqt7 wrote: post #163

Earlier quoted context omitted.

Is there a real source for this claim? It gets parroted a lot on HN and elsewhere, but I've also heard it's greatly exagerated. I don't think Apple engineers get to read the licences, and even if they did, how do we know they understood it corretly and that it got repeated correctlty? I've never seen a valid source for this claim.

Why does it need a "real source"? ARM sells architecture licenses, Apple has a custom ARM architecture. 1 + 1 = 2. https://www.cnet.com/tech/tech-industry/apple-seen-as-likely... "ARM Chief Executive Warren East revealed on an earnings conference call on Wednesday that "a leading handset OEM," or original equipment manufacturer, has signed an architectural license with the company, forming ARM's most far-reaching lic…

The common refrain is that "Since Apple helped found ARM they have a super special relationship that gives them more rights than anyone else."

That they had to specifically sign an architectural license in 2008 sounds like that is not at all true but that they are just another standard licensee (albeit one with very deep pockets).

Re: Why is Rosetta 2 fast?

#336

Post by bigDinosaur »

NavinF wrote: post #264
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).

Ehh I had a 2013 MacBook pro back in 2013 with a 2560x1600 display. That's 227 dpi. A decade later, I think it's safe to say that anything smaller than that is extremely low-end in 2022. I agree it's kinda sad how few desktop monitors are high dpi. It gets even worse if you limit yourself to low latency monitors. Anyway I haven't used macos in a while so I'm not sure what you mean by Apple not supporting non-hidpi

The actual screen dimensions make a huge difference to whether or not a given DPI value is low or high end. My current monitor is 157 DPI and I can assure you it is not an extremely low end monitor at all. Unless your frame of reference is anything below $5k is low end or something.

Re: Why is Rosetta 2 fast?

#337

Post by bluGill »

wumpus wrote: post #301
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…

> In finance Isn't low-latency trading only a subset of finance?

Yes. And the part I mentioned is a subset of low latency. See the other reply.

Re: Why is Rosetta 2 fast?

#338

Post by bluGill »

dahfizz wrote: post #195
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 other issue with JIT is that it is unreliable. It optimizes code by making assumptions. If one of the assumptions is wrong, you pay a large latency penalty. In my field of finance, having reliably low latency is important. Being 15% faster on average, but every once in a while you will be really slow, is not something customers will go for.

I'm not in finance. I just remember one talk by a finance guy and it was a mind bender so I remember it.

Re: Why is Rosetta 2 fast?

#339

Post by tomcam »

tomcam wrote: post #175
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…

I’m likely misunderstanding what you said, but I thought pre-compiled headers were pretty much standard these days.

What on earth did I say to merit the downvotes?

Re: Why is Rosetta 2 fast?

#340

Post by kllrnohj »

pjmlp wrote: post #313
kllrnohj wrote: post #289

Earlier quoted context omitted.

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.

Perhaps, but that's orthogonal. JITs don't just come with ideal production set sampling either after all. They only capture snippets, and rarely re-optimize already compiled functions in the face of changing workloads or new information. You can do crowd-sourced profiles (like Android does), but that's a completely independent set of infrastructure from JIT vs. AOT. You can feed that same profile to PGO for AOT. In fact, that's how Android uses it. They don't feed the profile to the JIT, they feed it to their offline, install-time or idle-maintenance AOT compiler.
Post reply on HN