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

181–190 of 367 posts

Re: Why is Rosetta 2 fast?

#181

Post by jasonwatkinspdx »

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…

All reasonable points, but examples where JIT has an advantage are well supported in research literature. The typical workload that shows this is something with a very large space of conditionals, but where at runtime there's a lot of locality, eg matching and classification engines.

Re: Why is Rosetta 2 fast?

#182

Post by bluGill »

com2kid wrote: post #121
kmeisthax wrote: post #103

Earlier quoted context omitted.

It's more the case that the ahead-of-time compilation is suboptimal. Modern compilers have a thing called PGO (Profile Guided Optimization) that lets you take a compiled application, run it and generate an execution profile for it, and then compile the application again using information from the profiling step. The reason why this works is that lots of optimization involves time-space tradeoffs that only make sense…

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

The Javascript V8 engine, and the JVM both are popular and supported enough that I expect the teams working on them take advantage of every trick they can for specific CPUs, they have a lot of resources for this. (at least the major x86 and ARM chips - maybe they don't for MIPS or some uncommon variant of ARM...). Of courses there are other JIT engines, some uncommon ones don't have many resources and won't do this.

Re: Why is Rosetta 2 fast?

#183

Post by chrisseaton »

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've run Ruby C extensions on a JIT faster than on native, due to things like inlining and profiling working more effectively at runtime.

Re: Why is Rosetta 2 fast?

#184

Post by saagarjha »

nwallin wrote: post #177
saagarjha wrote: post #144

Earlier quoted context omitted.

That’s not correct, the article goes into details why.

That is correct, the article goes into details why. See the "Apple's Secret Extension" section as well as the "Total Store Ordering" section. The "Apple's Secret Extension" section talks about how the M1 has 4 flag bits and the x86 has 6 flag bits, and how emulating those 2 extra flags would make every add/sub/cmp instruction significantly slower. Apple has an undocumented extension that adds 2 more flag bits to make…

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.

Re: Why is Rosetta 2 fast?

#185

Post by ksherlock »

Vt71fcAqt7 wrote: post #163
masklinn wrote: post #95

Earlier quoted context omitted.

> Do they? They do, yes. They were one of the founding 3 members of ARM itself, and the primary monetary contributor. Through this they acquired privileges which remain extant: they can literally add custom instructions to the ISA ( https://news.ycombinator.com/item?id=29798744 ), something there is no available license for. > ARM made it very clear that they consider all ARM cores their own[1] The Qualcomm situation…

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 license for its processor cores. East declined to elaborate on ARM's new partner, but EETimes' Peter Clarke could think of only one smartphone maker who would be that interested in shaping and controlling the direction of the silicon inside its phones: Apple."

https://en.wikipedia.org/wiki/Mac_transition_to_Apple_silico...

"In 2008, Apple bought processor company P.A. Semi for US$278 million.[28][29] At the time, it was reported that Apple bought P.A. Semi for its intellectual property and engineering talent.[30] CEO Steve Jobs later claimed that P.A. Semi would develop system-on-chips for Apple's iPods and iPhones.[6] Following the acquisition, Apple signed a rare "Architecture license" with ARM, allowing the company to design its own core, using the ARM instruction set.[31] The first Apple-designed chip was the A4, released in 2010, which debuted in the first-generation iPad, then in the iPhone 4. Apple subsequently released a number of products with its own processors."

https://www.anandtech.com/show/7112/the-arm-diaries-part-1-h...

"Finally at the top of the pyramid is an ARM architecture license. Marvell, Apple and Qualcomm are some examples of the 15 companies that have this license."

Re: Why is Rosetta 2 fast?

#186

Post by jasonwatkinspdx »

tomcam wrote: post #172

> Every one-byte x86 push becomes a four byte ARM instruction Can someone explain this to me? I don’t know ARM but it just seems to me a push should not be that expensive.

The general principle is that RISC style instruction sets are typically fixed length and with only a couple different subformats. Like the prototypical RISC design has one format with an opcode and 3 register fields, and then a second with an opcode and an immediate field. This simplicity and regularity makes the fastest possible decoding hardware much more simple and efficient compared to something like x86 that has a simply dumbfounding number of possible variable length formats.

The basic bet of RISC was that larger instruction encodings would be worth it due to the micro architectural advantages they enabled. This more or less was proven out, though the distinction is less distinct today with x86 decoding into uOps and recent ARM standards being quite complex beasts.

Re: Why is Rosetta 2 fast?

#187

Post by Vt71fcAqt7 »

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…

I should have been more explicit. I am questioning the claim that Apple has "full control on ARM" with no restriction on the cores they make, grandfathered in from the 1980s. Nobody has ever substantiated that claim.

Re: Why is Rosetta 2 fast?

#188

Post by classichasclass »

qsort wrote: post #13
peatmoss wrote: post #9

Not having any particular domain experience here, I've idly wondered whether or not there's any role for neural net models in translating code for other architectures. We have giant corpuses of source code, compiled x86_64 binaries, and compiled arm64 binaries. I assume the compiled binaries represent approximately our best compiler technology. It seems predicting an arm binary from an x86_64 binary would not be insa…

You would need a hybrid architecture with a NN generating guesses and a "watchdog" shutting down errors. Neural models are basically universal approximators. Machine code needs to be obscenely precise to work. Unless you're doing something else in the backend, it's just a turbo SIGILL generator.

> turbo SIGILL generator

This gave me the delightful mental image of a CPU smashing headlong into a brick wall, reversing itself, and doing it again. Which is pretty much what this would do.

Re: Why is Rosetta 2 fast?

#189

Post by titzer »

masklinn wrote: post #130
randyrand wrote: post #128

Earlier quoted context omitted.

Why are static binaries with PIC so rare? I’m surprised position dependent code is ever used anymore in the age of ASLR. But static binaries are still great for portability. So you’d think static binaries with PIC would be the default.

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

Re: Why is Rosetta 2 fast?

#190

Post by titzer »

randyrand wrote: post #128
titzer wrote: post #89

Rosetta 2 is great, except it apparently can't run statically-linked (non-PIC) binaries. I am unsure why this limitation exists, but it's pretty annoying because Virgil x86-64-binaries cannot run under Rosetta 2, which means I resort to running on the JVM on my M1...

Why are static binaries with PIC so rare? I’m surprised position dependent code is ever used anymore in the age of ASLR. But static binaries are still great for portability. So you’d think static binaries with PIC would be the default.

Virgil doesn't use ASLR. I'm not sure what value it adds to a memory-safe language.
Post reply on HN