6 ms·

Rosetta's goal is to support legacy Mac apps. It's quite finely scoped, but I hope Apple will go above this and make it available as part of their virtualizatio

by DCKing 6y ago

Rosetta's goal is to support legacy Mac apps. It's quite finely scoped, but I hope Apple will go above this and make it available as part of their virtualization framework. This way e.g. Parallels and Docker could use this to provide some way to tap in probably the fastest way to run x86 on ARM Macs. This would mean Rosetta would go beyond its stated scope, and certainly go beyond what the relatively short-lived Rosetta 1 did, but would make it easier to integrate ARM Macs in what is still an x86 world. I'm worried they're not going to do this because x86 emulation is probably too slow (people will attempt to run their AAA games in a VM). It would also mean that Apple will need to support Rosetta 2 forever. If they're not going to do this, everybody will have to rely on qemu. Qemu is great, but I hope it will perform adequately for at least basic Docker stuff...

Angostura 6y ago
FWIW they showed the latest Tombraider game running on Rosetta on a dev Mac said to be using the ARM chip from the high-end iPad. It ran pretty well. Not sure if I would quite count this as AAA
- DCKing 6y ago
  I don't think that was running on Rosetta 2's dynamic recompiler, but instead used Rosetta 2's other stated feature of being able to translate existing apps at install time. In the demo they state that they downloaded the game from the Mac App store. Certainly static recompilation yields somewhat-close-to-native performance when it is available, but that is not possible for x86 "VMs".
- toyg 6y ago
  > It ran pretty well It was a postproduced, recorded promotional video, not a live demo. They could have shown laptops reaching Mars and you’d have thought “that landing gear looks pretty solid”.
- monocasa 6y ago
  IDK, what I saw was a several year old game running on the lowest settings and still stuttering a bit.
  - GeekyBear 6y ago
    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 breaking single digit frame rates on this game at 1080p. Apple received some snark about this demo being lame, but it's only lame if you don't understand at all just how terrible modern integrated laptop GPUs are. https://www.androidpolice.com/2020/06/22/apples-chipset-advantage-has-me-more-jealous-than-ever https://www.androidpolice.com/2020/06/22/apples-chipset-adva...
    - monocasa 6y ago
      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 "middling settings" is pushing it as well, the env lighting wasn't even on Lara. It looks like they dropped the settings as far down as they would go.
      - GeekyBear 6y ago
        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.
rezmason 6y ago
I think the longer Rosetta exists and macOS thereby supports a wider variety of binary executables, the more people will rely on it to deliver them day-to-day functionality in increasingly complex configurations, and the more Apple will expose itself to those users' criticisms. If Apple's rationale for the transition is to gain further control over their product design and manufacture, the prospect of having to appease folks who won't give up their old software (like me!) but who come to expect indefinite Rosetta-type backwards compatibility doesn't sound all that appealing from Apple's perspective. We're talking about a company who denied Carbon support in the 64-bit transition while some of their largest software developers still clung to it. Furthermore, the old software they're temporarily supporting through Rosetta represents the agreements and policies Apple followed with third party developers during earlier periods in their history, which I'm sure they want to get away from. In their eyes, the sooner they can ditch those policies and impose iOS-type restrictions on any and all macOS software development, the better. This is probably my last Mac, after thirty years. It's been fun, watching them rise in power, but they've had to become a very different kind of company to get to where they are.
- burlesona 6y ago
  Your first two paragraphs track, but I think the second two are quite a leap. Sure it’s possible, but I think it’s exceptionally unlikely that Apple will try to lock down the Mac the way the iPhone is. The reason is they think of them as fundamentally different products with fundamentally different purposes, and for the most part the trend line has been moving to more opening of the iOS ecosystem rather than more lockdown of the Mac. (For instance in the last few iOS releases they’ve added file system support, removing the default apps, and in this new release they’re allowing users to set alternative default apps, etc.) Apple views the iPhone as a pure consumer device where the most important thing is that everything “just works.” It’s locked down in the same way a video game console is locked down, and for the same reasons: they gain a lot of “just works” benefits from keeping things very standardized. And most consumers LIKE that. Most consumers hate that their PC (or even Mac) often fails them in “mysterious” ways that require tech support or just living with a broken experience. Apple talks about iOS as a “car” and Mac as a “truck.” They see Mac as their development platform, and literally called that out in their keynote. There is certainly a desire on Apple’s part to make the Mac also an excellent consumer product, hence things like the existence of the App Store and app signing, but on the Mac there have always been “escape hatches” for those who know what they’re doing. Now, the part that Apple does want to lock down and is able to lock down even more with this move is the Hardware. They’ve never made Hackintosh easy and have never done anything to indicate support for tinkering with their hardware, to the point that when the pro community began to bail they brought back a highly “configurable” Mac Pro (configurable with official parts but not really tinkerable). But anyway, I don’t think Mac OS is going to get locked down substantially more than it already is. It’s a nice OS with some trade offs, if those trade offs have worked for you in the past they’re likely to keep being fine, and if not then you probably wouldn’t be a Mac user anyway.
Someone 6y ago
AAA games spend lots of times inside system libraries. Porting those to native could be enough to get acceptable performance. So, chess could be more of a challenge for emulation than AAA games (but probably less of an issue, as it would be easily ported, and have fewer users, anyways)
- AlphaSite 6y ago
  It would be extremely bizarre if x86 programs are linking against arm libraries.
  - Someone 6y ago
    They would link against, say, OpenGL. The emulator wouldn’t emulate the x86 OpenGL, but call ARM OpenGL. If Apple wants to, they could even support selected third-party libraries that way.
  - monocasa 6y ago
    Apple has said that a Rosetta process is entirely x86_64 client code, including shared libraries, but I suppose that might be a "what's good for the goose isn't good for the gander" style white lie.
- amaranth 6y ago
  The page we're discussing here actually says you can't mix arm64 and amd64 code in a single process, if your binary is amd64 all your libraries will be too. I'd be surprised if they put in the work to generate thunks for all their system libraries and then didn't make it possible to use any others. More likely macOS will just have two copies of all the (non-iOS) libraries and the only point they work together is the kernel since that's a nice clear barrier.
  - Someone 6y ago
    If I read it correctly, it says it prevents you from doing that, “including all code modules that the process loads dynamically”, but I don’t think that means Rosetta won’t call arm64 libraries for libraries linked at program startup. Think about it: Rosetta translates your code to arm64, and your code calls a function in a system library. Why would Rosetta use the x64 version of the library and translate its code to arm64 if an arm64 version is available? there may be ABI differences that aren’t trivial to correct for, but for expensive calls, I would think that’s dwarfed by the gains of running native code. Certainly, how is this going to run the Accelerate framework API at decent speed, given the emulator doesn’t emulate AVX, AVX2, and AVX512?
qalmakka 6y ago
I think Rosetta is mostly about userspace, and a Hypervisor is definitely not something that sticks to that - modern VMs run on the bare metal thanks to CPU acceleration and dedicated instructions (i.e. VT-x and AMD-V). Getting an app to run on a foreign architecture it's different than emulating a whole machine in order to get an unmodified OS kernel to run. You can do it this very day with QEMU, yesterday I tried just for fun to boot Windows XP on my Raspberry Pi 4 (it boots but it's horrendously slow, if you're interested). Maybe with time and effort, an emulator can get a satisfactory level of speed (probably never enough to run Windows games on emulated Windows though, but who knows).

by DCKing 6y ago

Angostura 6y ago

FWIW they showed the latest Tombraider game running on Rosetta on a dev Mac said to be using the ARM chip from the high-end iPad. It ran pretty well. Not sure if I would quite count this as AAA

DCKing 6y ago
I don't think that was running on Rosetta 2's dynamic recompiler, but instead used Rosetta 2's other stated feature of being able to translate existing apps at install time. In the demo they state that they downloaded the game from the Mac App store. Certainly static recompilation yields somewhat-close-to-native performance when it is available, but that is not possible for x86 "VMs".
toyg 6y ago
> It ran pretty well It was a postproduced, recorded promotional video, not a live demo. They could have shown laptops reaching Mars and you’d have thought “that landing gear looks pretty solid”.
monocasa 6y ago
IDK, what I saw was a several year old game running on the lowest settings and still stuttering a bit.
- GeekyBear 6y ago
  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 breaking single digit frame rates on this game at 1080p. Apple received some snark about this demo being lame, but it's only lame if you don't understand at all just how terrible modern integrated laptop GPUs are. https://www.androidpolice.com/2020/06/22/apples-chipset-advantage-has-me-more-jealous-than-ever https://www.androidpolice.com/2020/06/22/apples-chipset-adva...
  - monocasa 6y ago
    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 "middling settings" is pushing it as well, the env lighting wasn't even on Lara. It looks like they dropped the settings as far down as they would go.
    - GeekyBear 6y ago
      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.

rezmason 6y ago

I think the longer Rosetta exists and macOS thereby supports a wider variety of binary executables, the more people will rely on it to deliver them day-to-day functionality in increasingly complex configurations, and the more Apple will expose itself to those users' criticisms. If Apple's rationale for the transition is to gain further control over their product design and manufacture, the prospect of having to appease folks who won't give up their old software (like me!) but who come to expect indefinite Rosetta-type backwards compatibility doesn't sound all that appealing from Apple's perspective. We're talking about a company who denied Carbon support in the 64-bit transition while some of their largest software developers still clung to it. Furthermore, the old software they're temporarily supporting through Rosetta represents the agreements and policies Apple followed with third party developers during earlier periods in their history, which I'm sure they want to get away from. In their eyes, the sooner they can ditch those policies and impose iOS-type restrictions on any and all macOS software development, the better. This is probably my last Mac, after thirty years. It's been fun, watching them rise in power, but they've had to become a very different kind of company to get to where they are.

burlesona 6y ago
Your first two paragraphs track, but I think the second two are quite a leap. Sure it’s possible, but I think it’s exceptionally unlikely that Apple will try to lock down the Mac the way the iPhone is. The reason is they think of them as fundamentally different products with fundamentally different purposes, and for the most part the trend line has been moving to more opening of the iOS ecosystem rather than more lockdown of the Mac. (For instance in the last few iOS releases they’ve added file system support, removing the default apps, and in this new release they’re allowing users to set alternative default apps, etc.) Apple views the iPhone as a pure consumer device where the most important thing is that everything “just works.” It’s locked down in the same way a video game console is locked down, and for the same reasons: they gain a lot of “just works” benefits from keeping things very standardized. And most consumers LIKE that. Most consumers hate that their PC (or even Mac) often fails them in “mysterious” ways that require tech support or just living with a broken experience. Apple talks about iOS as a “car” and Mac as a “truck.” They see Mac as their development platform, and literally called that out in their keynote. There is certainly a desire on Apple’s part to make the Mac also an excellent consumer product, hence things like the existence of the App Store and app signing, but on the Mac there have always been “escape hatches” for those who know what they’re doing. Now, the part that Apple does want to lock down and is able to lock down even more with this move is the Hardware. They’ve never made Hackintosh easy and have never done anything to indicate support for tinkering with their hardware, to the point that when the pro community began to bail they brought back a highly “configurable” Mac Pro (configurable with official parts but not really tinkerable). But anyway, I don’t think Mac OS is going to get locked down substantially more than it already is. It’s a nice OS with some trade offs, if those trade offs have worked for you in the past they’re likely to keep being fine, and if not then you probably wouldn’t be a Mac user anyway.

Someone 6y ago

AAA games spend lots of times inside system libraries. Porting those to native could be enough to get acceptable performance. So, chess could be more of a challenge for emulation than AAA games (but probably less of an issue, as it would be easily ported, and have fewer users, anyways)

AlphaSite 6y ago
It would be extremely bizarre if x86 programs are linking against arm libraries.
- Someone 6y ago
  They would link against, say, OpenGL. The emulator wouldn’t emulate the x86 OpenGL, but call ARM OpenGL. If Apple wants to, they could even support selected third-party libraries that way.
- monocasa 6y ago
  Apple has said that a Rosetta process is entirely x86_64 client code, including shared libraries, but I suppose that might be a "what's good for the goose isn't good for the gander" style white lie.
amaranth 6y ago
The page we're discussing here actually says you can't mix arm64 and amd64 code in a single process, if your binary is amd64 all your libraries will be too. I'd be surprised if they put in the work to generate thunks for all their system libraries and then didn't make it possible to use any others. More likely macOS will just have two copies of all the (non-iOS) libraries and the only point they work together is the kernel since that's a nice clear barrier.
- Someone 6y ago
  If I read it correctly, it says it prevents you from doing that, “including all code modules that the process loads dynamically”, but I don’t think that means Rosetta won’t call arm64 libraries for libraries linked at program startup. Think about it: Rosetta translates your code to arm64, and your code calls a function in a system library. Why would Rosetta use the x64 version of the library and translate its code to arm64 if an arm64 version is available? there may be ABI differences that aren’t trivial to correct for, but for expensive calls, I would think that’s dwarfed by the gains of running native code. Certainly, how is this going to run the Accelerate framework API at decent speed, given the emulator doesn’t emulate AVX, AVX2, and AVX512?

qalmakka 6y ago

I think Rosetta is mostly about userspace, and a Hypervisor is definitely not something that sticks to that - modern VMs run on the bare metal thanks to CPU acceleration and dedicated instructions (i.e. VT-x and AMD-V). Getting an app to run on a foreign architecture it's different than emulating a whole machine in order to get an unmodified OS kernel to run. You can do it this very day with QEMU, yesterday I tried just for fun to boot Windows XP on my Raspberry Pi 4 (it boots but it's horrendously slow, if you're interested). Maybe with time and effort, an emulator can get a satisfactory level of speed (probably never enough to run Windows games on emulated Windows though, but who knows).