Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

About the Rosetta Translation Environment

developer.apple.com

Post reply on HN
Print view View original

151–160 of 249 posts

Re: About the Rosetta Translation Environment

#151

Post by GeekyBear »

monocasa wrote: post #148
GeekyBear wrote: post #145

Earlier quoted context omitted.

The more interesting point... >The demo wasn't perfect: the game ran at 1080p with fairly middling settings, but did so at what appeared to be at the very least a steady 30FPS, all while being run as an emulated x86 version of the game. That is: the game wasn't even natively compiled for ARM. But consider that Intel's most powerful laptop chipset GPU, found in the 10th generation Ice Lake series, is not capable of br…

We all know that Intel iGPUs are terrible (at least until the new Xe based GPUs start to come out). The comparison I don't see enough people making is to throw out as an option the one company that regularly ships semi custom, secure, x86 SoCs with GPUs, AMD. An Xbox One SoC is literally half of the transistor count of an A12Z (5B and 10B respectively). And the frame rate was anything but steady there. And calling it…

Yet the marketing push for Ice Lake was that even if the CPU cores lost most of their IPC gains to lower clock speeds, the GPU itself was to be a massive improvement.

I'm looking forward to seeing if the demos were on the Dev Kit hardware, because if that was the performance on a specially binned two year old iPad Pro chip, it's pretty darn impressive.

Re: About the Rosetta Translation Environment

#152

Post by Mister_Snuggles »

empthought wrote: post #146
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…

It will be at least several years before you will not be able to purchase a new Intel-based Mac.

From another article, Apple claims that the transition will be complete in two years. I have 2.5 years left before I will be eligible to have my work computer replaced.

Depending on the exact timing of Apple's product cycles and the procurement cycle, I'll either be getting one of the last Intel Macs or a Windows machine of some description.

If an Intel Mac is still available at this time, that brings other concerns - in particular, Macs are on a five-year replacement cycle at my work, so even if they are available it may not be prudent to buy one. Will it get new MacOS versions for its 5-year lifetime? Will it still get security updates five years down the road? Will the developers of the applications I use still ship x86_64 versions of their Mac applications?

Because of all of that uncertainty, it may end up being a better option to just get a Windows machine when I'm eligible. Fortunately, a lot of that uncertainty should be cleared up by the time that happens.

EDIT: Another remote possibility is that VMware figures out some way to fill in the gaps that Rosetta doesn't. After all, they did figure out how to do virtualization on a platform that didn't even support it.

Re: About the Rosetta Translation Environment

#153

Post by hn_check »

monocasa wrote: post #150
hn_check wrote: post #149

Earlier quoted context omitted.

https://youtu.be/GEZhD3J89ZE?t=6070 It doesn't stutter whatsoever (you've claimed this in multiple posts, and I think you need to look at your playback device because the game is buttery smooth). And for integrated graphics of a binary translated x86-64 game running on ARM @ 1080p, that is pretty amazing. No one is going to claim that the GPU on the A12Z beats a dedicated GPU, even a low-end one. But as someone whose…

An A12Z's GPU is around double an Xbox One's in gate count. On a GPU limited title like that it should be doing way better than this. Also it still appears to be stuttering, and opening other videos doesn't show the same stutter.

You're really veering all over the place to dismiss this (which is funny given that it was on the A12Z, and we know production machines will be much more powerful).

Now this tiny (less than 1/3rd the die size of the Xbox One SoC...hell, 1/4) SoC needs to game better than an Xbox One whose SoC draws 4X+ the power. Also note that the A12Z has a 5TFlop+ neural engine (in addition to everything else), dedicated video encoders and decoders (separate from the GPUs), and loads of other hardware that consumes transistor counts.

And for that matter, the gameplay looks easily comparable to walkthroughs of this same game on an Xbox One.

Re: About the Rosetta Translation Environment

#154

Post by monocasa »

GeekyBear wrote: post #151
monocasa wrote: post #148

Earlier quoted context omitted.

We all know that Intel iGPUs are terrible (at least until the new Xe based GPUs start to come out). The comparison I don't see enough people making is to throw out as an option the one company that regularly ships semi custom, secure, x86 SoCs with GPUs, AMD. An Xbox One SoC is literally half of the transistor count of an A12Z (5B and 10B respectively). And the frame rate was anything but steady there. And calling it…

Yet the marketing push for Ice Lake was that even if the CPU cores lost most of their IPC gains to lower clock speeds, the GPU itself was to be a massive improvement. I'm looking forward to seeing if the demos were on the Dev Kit hardware, because if that was the performance on a specially binned two year old iPad Pro chip, it's pretty darn impressive.

It's Tiger Lake that's supposed to see the passable GPU, when they use the same cores as their new discrete GPU.

Not that I'm really defending Intel here, they fell behind the curve.

Re: About the Rosetta Translation Environment

#156

Post by monocasa »

hn_check wrote: post #153
monocasa wrote: post #150

Earlier quoted context omitted.

An A12Z's GPU is around double an Xbox One's in gate count. On a GPU limited title like that it should be doing way better than this. Also it still appears to be stuttering, and opening other videos doesn't show the same stutter.

You're really veering all over the place to dismiss this (which is funny given that it was on the A12Z, and we know production machines will be much more powerful). Now this tiny (less than 1/3rd the die size of the Xbox One SoC...hell, 1/4) SoC needs to game better than an Xbox One whose SoC draws 4X+ the power. Also note that the A12Z has a 5TFlop+ neural engine (in addition to everything else), dedicated video enc…

Die size doesn't matter here, because they're on radically different process nodes; it's gate count that matters to compare apples to apples (or Apple to AMD, I guess, lol).

Xbox One has 5B, an A12Z has 10B.

And when you look at the layout, it's you can see that in each it's about a third of the space for the GPU cores, with each having very large L3 like banks of SRAM before the memory controller.

Re: About the Rosetta Translation Environment

#157

Post by anyfoo »

monocasa wrote: post #57
lsllc wrote: post #53

Earlier quoted context omitted.

It probably just hooks mmap() (or mprotect()) and looks for when the JIT sets PROT_EXEC on memory it hasn't translated yet. Here's a tutorial for a simple JIT that uses mmap() with PROT_EXEC to write machine code to before executing: https://github.com/spencertipping/jit-tutorial

Since they don't enforce W^X you need to go a little deeper than that since some JITs reuse the same memory later for new traces. So what you'll do is silently enforce W^X to trap code modifications, but not propagate those traps to the emulated code.

Pages containing x86 code are never actually being marked executable in the (ARM) pagetables, because that would be nonsensical: The CPU itself does not know how to run x86 code. mmap/mprotect from x86 with the exec bit therefore does something else than native code.

Re: About the Rosetta Translation Environment

#158

Post by JimmyAustin »

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…

My understanding is that that line only refers to VM applications written and compiled for x86, and doesn't stop a VirtualBox (or any other VM provider) from compiling an ARM binary that doesn't require Rosetta.

I don't think this is a policy restriction so much as there not being support for Intel virtualisation technologies that that might rely on.

Re: About the Rosetta Translation Environment

#159

Post by anyfoo »

himinlomax wrote: post #131
mkl wrote: post #41

> Rosetta can translate most Intel-based apps, including apps that contain just-in-time (JIT) compilers. How on Earth does it do that? If executable code is being generated at runtime, it's going to be x86_64 binary machine code still (there are too many ways to generate valid machine code, and it won't know right away whether you're JITting, or cross compiling and actually want x86_64), so Rosetta would need to dete…

> If executable code is being generated at runtime, it's going to be x86_64 binary machine code still JITs have to explicitly make the memory they write the generated code to executable. The OS "just" needs to fail to actually make the page executable, and then handle the subsequent page fault by transpiling or interpreting the x86 code therein.

And it wouldn't make sense to make any x86 process originating pages actually executable on a page table level anyway, as the CPU can never actually "execute" it, as machine code.

Re: About the Rosetta Translation Environment

#160

Post by phire »

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.

ARMv8.1 adds a bunch of improved atomic instructions that basically implement the same functionality as x86. Because x86 has atomic read-modify-write instructions by default; You need emulate those too.

The ARMv8.1 extensions look like they have been explicitly designed to allow emulation of x86.

The implication is that implementations of ARMv8.1 can (and perhaps should) implement cache/coherency subsystems with high preformance atomic operations.

And I'm willing to bet Apple has made sure their implementation is good at atomics.

Post reply on HN