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

361–367 of 367 posts

Re: Why is Rosetta 2 fast?

#361

Post by savoytruffle »

xattt wrote: post #330
savoytruffle wrote: post #206

Earlier quoted context omitted.

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.

I could have have sworn that a unibody MacBook Pro where I did an in-place upgrade to Lion somehow held onto Rosetta.

I guess that's perjury because it cannot be true! Even Snow Leopard didn't even include Rosetta 1. But if it was deemed necessary, it would download and install it on-demand, similar to how the Java system worked.

Re: Why is Rosetta 2 fast?

#362

Post by neerajsi »

saagarjha wrote: post #353
menaerus wrote: post #334

Earlier quoted context omitted.

> 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 genera…

You can approximate it fairly well without much impact.

Not true. The required fencing has huge impact. I led development of the chpe compiler for windows on arm, and the fencing was major source of our gains.

Re: Why is Rosetta 2 fast?

#363

Post by saagarjha »

neerajsi wrote: post #362
saagarjha wrote: post #353

Earlier quoted context omitted.

You can approximate it fairly well without much impact.

Not true. The required fencing has huge impact. I led development of the chpe compiler for windows on arm, and the fencing was major source of our gains.

I don't think we disagree :) If you're going for full accuracy you morally need barriers all over the place. If have TSO in your chips that makes things far easier, alternatively you can do stuff with RCpc if your hardware supports it. Otherwise you get stuck with fences everywhere, or you force your hardware into TSO compliance mode (read: turn off all the other cores) and that sucks.

The other option is you relax on the "required fencing", with the assumption that most accesses do not actually exercise the full semantics that TSO guarantees. Obviously some synchronization does matter, so you need heuristics and those won't always work. My understanding was that XTA has some of these, with knobs to turn them off if they don't work? You probably know more about that than I do. In iSH we play it even more fast-and-loose, with all regular memory accesses being lowered to ARM loads and stores, and locked operations to whatever seemed the closest. It's definitely not production-grade but we have shockingly good compatibility for what it is.

Re: Why is Rosetta 2 fast?

#364

Post by olliej »

phire wrote: post #356
olliej wrote: post #355

Earlier quoted context omitted.

> The key to this optimisation idea is the exponent gets truncated back to 8 bits when being written back to memory. That's incorrect - the clamping of the exponent only occurs if you were to use FST/m32 or FST/m64, but if you're using x87 you're presumably doing FSTP/m80fp so there is no truncation or rounding on store, regardless of the prevision flag in the control word. It sounds like what you're trying to arrang…

I was thinking more about functions along the lines of this vertex transform function that you might theoretically find as hot code in a late 90s or early 2000s windows game (before hardware transform and lighting). void transform_verts(fp32 *m, fp32 *verts, size_t vert_count) { // it's a game, decent chance it applies percision32 across the whole process // Especially since directx Would be nice if we could optimise…

Sorry for delay (surgery funsies)

> So it's already producing inaccurate results for code that sets precision control? Might as well just switch over to hardware fp32 and fp64 /s

:D

But in practice the only reason for changing the x87 precision is performance, which was then simply retained in hardware for backwards compatibility. Modern code (as in >= SSE era) simply uses fp32 or fp64 which is faster, more memory compact, has vector units, has a much more sane ISA, etc. Anyone who does try to toggle x87 mode in general is in for a world of hurt because the system libraries all assume the unit is operating in default state.

You are correct that the only reason x86_64 needs x87 is that the unix x86_64 ABI decided to specify the already clearly deprecated format the implementation of long double. I often looked wistfully at win64 where long double == double.

Re: Why is Rosetta 2 fast?

#365

Post by menaerus »

mikepurvis wrote: post #269
ridiculous_fish wrote: post #262

Earlier quoted context omitted.

How does the compiler arrange for the CPU to mispredict the branch most of the time? I didn't think there were any knobs for the branch predictor other than static ones (e.g. backwards-jumps statically predicted as taken, or PowerPC branch hint bit).

C++20 is gaining the [[likely]] attribute for guiding the predictor in a portable way: http://eel.is/c++draft/dcl.attr.likelihood Prior to this it was also possible, but required compiler-specific macros like GCC's __builtin_expect, which is used all over the kernel: https://github.com/torvalds/linux/search?q=__builtin_expect

To my knowledge this does not have any direct impact to the CPU branch prediction mechanism. If that had been the case then we would at least have some x86-(64) instruction to manipulate with the BP. If I write a quick example such as https://godbolt.org/z/j7Y81j5fe, I also see no such instruction in the generated output.

But what likely/unlikely mechanism can do is that it can serve as a hint to the compiler which the compiler can then use to generate more optimal code layout. For example, if we provide the compiler with likely/unlikely hints in our code, compiler will try to use that hint to stitch together the more probable code paths first. In theory this approach should result with better utilization of CPU instruction cache and thus it may lead to better performance.

Re: Why is Rosetta 2 fast?

#366

Post by lzooz »

>The Apple M1 has an undocumented extension that, when enabled, ensures instructions like ADDS, SUBS and CMP compute PF and AF and store them as bits 26 and 27 of NZCV respectively, providing accurate emulation with no performance penalty.

If there is no performance penalty why is it implemented as an optional extension?

Re: Why is Rosetta 2 fast?

#367

Post by tambourine_man »

GeekyBear wrote: post #226
savoytruffle wrote: post #206

Earlier quoted context omitted.

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.

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

The Classic environment was removed from OS X and all the IP involved was Apple’s.

The timing is interesting, but I wouldn’t put beyond Apple to remove a feature simply to sediment a transition (and decrease support cost).

Post reply on HN