About the Rosetta Translation Environment • Hacker News Board

Re: About the Rosetta Translation Environment

#231

Post by tom_mellior » Wed, Jun 24, 2020, 2:44 PM UTC

derefr wrote: post #229

saagarjha wrote: post #189

Earlier quoted context omitted.

> Rosetta 2 is probably built on LLVM. Why wouldn't it be? LLVM is kind of slow; JavaScriptCore abandoned it years ago for their FTL backend. > The unique pattern of machine-code that must occur in any implementation of JIT, is a jump to a memory address that was computed entirely at runtime, i.e. with a https://en.wikipedia.org/wiki/Use-define_chain for that address value that leads back to a call to mmap(2) or mall…

Re: your rebuttal code — that’s still a use-define chain. You don’t need the same literal pointer; you just need to know that the value of the pointer ultimately depended on a the output of mmap(2). Since the mmap(2) region address is passed into memcpy(2)—and memcpy(2) can fail, producing NULL—the output of memcpy(2) does then depend on the input. (Even if it didn’t, you could just lie to the compiler and tell it to…

> and memcpy(2) can fail, producing NULL

Huh, this is news to me. The memcpy(3) man page on my Linux box (there is no memcpy(2) here) doesn't mention this either, is this some special MacOS or BSD feature of memcpy? Under what circumstances would it determine that it should fail?

Your reasoning is strange anyway since the memcpy has nothing to do with anything, the implicit information flow from mmap to mprotect would exist even if the memcpy and the region variable were removed:

  mmap(0x100000000, 0x1000, PROT_READ | PROT_WRITE, MAP_FIXED, 0, 0);
  mprotect(0x100000000, 0x1000, PROT_READ | PROT_EXEC);

Re: About the Rosetta Translation Environment

#232

Post by vmception » Wed, Jun 24, 2020, 3:07 PM UTC

coldtea wrote: post #205

vmception wrote: post #139

Earlier quoted context omitted.

> I'm not sure why they're making a big deal about this, couldn't the That's par for course with Apple. They never acknowledge competitors including when its themselves. Everything they do or describe is awesome and magical, right now! It could be an incremental improvement, it could be a half decade old established technology, it could be something completely unexpected and science fiction turned into reality. Thats…

> That's par for course with Apple. They never acknowledge competitors Unlike which company that does?

https://www.google.com/search?ei=CWzzXqODOLK90PEPhbi7uAY&q=%...

Re: About the Rosetta Translation Environment

#233

Post by BeeOnRope » Wed, Jun 24, 2020, 3:47 PM UTC

monocasa wrote: post #125

BeeOnRope wrote: post #121

Earlier quoted context omitted.

There's another option: 4) Translate x86 loads and stores to acquire load and release stores, to align with the x86 semantics. These already exist in the ARM ISA, so it's not much of a stretch at all. This is the one I'm betting on.

Expect you'd need to do that with every single store since the x86 instruction stream doesn't have those semantics embedded in it. That'd kill your memory perf by at least an order of magnitude, and kill perf for other cores as well. It'd be cheaper to just say "you only get one core in x86 mode". Essentially you'd be marking every store as an L1 and store buffer flush and only operating out of L2.

Yes, you need it for every store.

It absolutely does not imply that it would kill your memory perf by an order of magnitude! Remember that x86 does this as their normal store behavior and they don't take an order of magnitude hit.

The easiest approach that leads to fast release stores is just to have a stronger store pipeline that doesn't allow store-store or load-store reordring. The latter basically comes for free and most weak pipelines already preserve it.

The store-store ordering, on the other hand, does have a cost: primarily in requiring stores to drain order, and handling misses in order. Nothing close to an order of magnitude.

A higher performance design would allow store store reordering but not around release stores. Allowing most ARM code to the full benefit while allowing fast release stores for x86.

I think you are mixing up release stores with more expensive atomics like seq-cst stores or atomic RMWs. There is no need for a store buffer drain, ever, for release stores.

Re: About the Rosetta Translation Environment

#234

Post by ricketycricket » Wed, Jun 24, 2020, 3:59 PM UTC

reaperducer wrote: post #161

Mister_Snuggles wrote: post #143

I've been using Macs at work for a long time, but sadly this will mark the end of that era. In particular, this limitation on Rosetta rules out an ARM-based Mac for work: > Virtual Machine apps that virtualize x86_64 computer platforms My job requires me to use a piece of proprietary Windows-only software for a large portion of my work. If I can't use this software I can't do my job. Currently I run it in VMware Fusi…

Tim Cook says new Intel Macs are coming out this year. If you can convince your company to buy you one, you should be good until 2030. Not being able to do your job would be enough for even my craptastic company to buy me a new machine.

First Intel Macs were released in January 2006 and OS X dropped support for Power PC in August 2009 with 10.6 Snow Leopard. If the same timeline is followed here, Intel support will be dropped around 2024. I wouldn't expect to get 10 years out of an Intel Mac.

Re: About the Rosetta Translation Environment

#235

Post by hedora » Wed, Jun 24, 2020, 7:33 PM UTC

jojobas wrote: post #186

hedora wrote: post #179

Earlier quoted context omitted.

Valgrind does something similar (x86->intermediate language->x86), and is only about 4x slower than native with all the analyses disabled. I’d guess they left some optimizations out to make it easier to implement the dynamic checks it supports.

Valgrind leaves most instructions as they were doesn't it? If you're not touching the dynamic memory it should be as fast. You wouldn't be able to do that with complex MMX or SSE2 instructions with Arm translation.

It lifts them to a simplified version of x86 so they can be instrumented / transformed more easily. I think that implies you get different instructions when it lowers back to x86, but I could be wrong. (I’ve written a specialized valgrind instrumentation tool or two, but didn’t look too carefully at the execution half of their codebase.)

Re: About the Rosetta Translation Environment

#236

Post by larkost » Wed, Jun 24, 2020, 7:46 PM UTC

viro wrote: post #114

qubex wrote: post #84

Earlier quoted context omitted.

The “ARM world” is almost inconceivably varied by x 86 standards. There’s not even an agreed-upon boot procedure (the Raspberrry Pi’s CPU famously gets booted by the GPU). Efforts to standardise this in the server space are only just getting off the ground with the Arm Server Base Boot Requirements version 1.2 being ratified last year. I doubt you’ll find Apple subscribing to anything that they won’t develop in-house…

in all fairness the Lightening connector has been around a lot longer than usb-c

Beyond that, you have to acknowledge that Apple contributed heavily to USB-C. They are invested, but had to weigh the plusses and minuses of transitioning the iPhone. My guess is that it was something like this:

Plusses: - everyone shares the same connectors

Minuses: - all the old peripherals out there now don't work on the new phones - there are lots of debug systems for phones built into the Lightning ports that Apple uses internally, those are all gone - there are lots of junk chargers out there, and no real inspection scheme for USB-C, whereas Apple runs an inspection scheme already for Lighting

Since there is a large enough market for Apple products, Apple is not worried about the small bonus of everyone sharing the same connectors. Given that it seem pretty obvious that until there is something to push them off Lightening (e.g. power requirements, speed of connection, etc...), they will stay there.

Re: About the Rosetta Translation Environment

#237

Post by larkost » Wed, Jun 24, 2020, 7:49 PM UTC

monocasa wrote: post #49

Bigpet wrote: post #44

Earlier quoted context omitted.

I think I'm missing something. How is ARM closing things up? Does Apple have a bunch of processor extensions that make it incompatible with other ARM processors? Or do you think they'll take the chance to kill boot-camp or something?

They'll almost certainly only allow their signed kernels to run. And that's in addition to not documenting any of the peripherals.

Apple already has a program for select third party companies to get their own signing keys for kernel extensions. They have been tightening that circle over the last few years as they provide more and more generic interfaces so that companies can replace KEXTs with user space code. From what they said in the State of the Union keynote they want to get that down to nothing, but realize they can't do that yet. No details were provided, but there might be more in the KEXT sessions if you are interested.

Re: About the Rosetta Translation Environment

#238

Post by BeeOnRope » Wed, Jun 24, 2020, 9:51 PM UTC

gpderetta wrote: post #180

BeeOnRope wrote: post #121

Earlier quoted context omitted.

There's another option: 4) Translate x86 loads and stores to acquire load and release stores, to align with the x86 semantics. These already exist in the ARM ISA, so it's not much of a stretch at all. This is the one I'm betting on.

That would be too expensive, unless the emulation in general is ao high not to matter. If store releases and load aquires were very cheap already why make them distinct from normal one anyway? I suspect that either the CPU is already TSO in practice or has some TSO mode.

> If store releases and load aquires were very cheap already why make them distinct from normal one anyway?

Perhaps if the ARM ISA was designed today, they would, I'm not sure.

My impression is that ARM added them when (a) it became obvious the way the wind was blowing with respect to modern memory models, like Java (sort of), C and C++, where acquire and release are the dominant paradigm (and I doubt any other langue will stray very far), and (b) they could see that these operations implementations can be implemented at a relatively low complexity cost and reasonable performance, compared to the existing barrier approach.

That said, there is a lot of room between "very cheap" and "too expensive", and it is probably hardware dependent. On some simple microcontroller-like design that doesn't want to do any extra work to support these, they might be very expensive, just relying on something like a full barrier which they have to support anyways.

However, on bigger designs, it is not necessarily very expensive to implement efficient release stores. They will still be slower than plain stores, but may not all that much slower. It's nothing like sequentially consistent stores, or barrier types that require a full store buffer drain.

Mostly all you need to need is to ensure that the stores drain in order. Actually the requirement is even weaker: you can't let release stores pass older stores. So it depends on your store buffer design and prevents some optimizations like merging and out-of-order commit to L1D, but those are far from critical optimizations (and you can still do them for plain stores at the cost of a bit more complexity).

If you are designing a core where release stores only occur in concurrent code, e.g,. as a result of a release store in C++, or as a lock release or whatever, you don't need to make them that fast. If they are 10x slower than regular stores, it's probably OK.

However, if you are designing a chip where you know you are going to be running a lot of emulated x86 code where every store is a store release, then yeah you are doing to do a bit more work to make these fast.

What are the other options? (1) and (2) in the GPs list seem very unlikely to me. (1) would almost certainly be much worse than release stores for multithreaded apps and destroy performance in popular creator apps.

(3) is certainly plausible and one variant of what I'm suggesting here: it means making plain stores and release stores the same thing (and I guess for loads). Definitely possible but seems less likely to me than (4).

Another possibility is a TSO mode, as you suggest. Perhaps this is somewhat easier than dynamically handling release stores, I'm not sure.

Re: About the Rosetta Translation Environment

#239

Post by jjcon » Thu, Jun 25, 2020, 4:30 AM UTC

PaulDavisThe1st wrote: post #215

jjcon wrote: post #176

Earlier quoted context omitted.

> I do not intend to go with this experiment I’m sure they lost people when they switched off of ppc too but just like last time Apple is playing the long game. Intel just can’t keep up anymore.

Intel can't (maybe). AMD can. In fact right now, AMD doesn't even have to keep up, because it's substantially out in front.

AMD has worse thermals than intel does which is likely the reason Apple is switching in the first place

Re: About the Rosetta Translation Environment

#240

Post by m_mueller » Thu, Jun 25, 2020, 5:20 AM UTC

jmull wrote: post #198

Mister_Snuggles wrote: post #143

I've been using Macs at work for a long time, but sadly this will mark the end of that era. In particular, this limitation on Rosetta rules out an ARM-based Mac for work: > Virtual Machine apps that virtualize x86_64 computer platforms My job requires me to use a piece of proprietary Windows-only software for a large portion of my work. If I can't use this software I can't do my job. Currently I run it in VMware Fusi…

> Currently I run it in VMware Fusion That’s how you’d do it on an ARM Mac too. Rosetta is about executing Mac apps on ARM Macs. For Windows apps you’re still going to go to a third party, most likely the same third-parties as before.

It will be very slow to emulate a Windows x86 kernel on ARM.