6 ms·

Until all software is ported to ARM, it will run in emulation, which is going to be slower in most cases. People invested in plug-in ecosystems, like DAWs or vi

Until all software is ported to ARM, it will run in emulation, which is going to be slower in most cases. People invested in plug-in ecosystems, like DAWs or video editing, will likely have an endless long tail of plug-ins that aren't getting ported, or that require a re-purchase to get an ARM version. And due to Rosetta's architecture, you can't mix ARM and x86 plug-ins (in-process, like VSTs - Apple wants you to use AUv3 which is out of process but nobody does that), so you will be running your entire workflow under emulation until you can make the switch hard and all at once. And some of your software will never make it. Mark my words, this is going to be a massive shit show for people using those ecosystems, for 5 years if not 10. It already happened with the PPC transition.

asah 6y ago
won't emulation catch up in those timeframes ? still, 3+ yrs which is a long time...
- AnthonyMouse 6y ago
  Three years isn't that long for CPU performance gains anymore, but even if it was, it isn't the emulation that gets faster, it's the hardware. Contemporary ARM machines emulating x64 would still be slower than contemporary x64 machines natively executing x64. You're also going to be in a bind if Apple decides they don't care about the long tail and stops supporting emulation before all of your plugins have been converted (if they ever are).
  - sroussey 6y ago
    There is no emulation per se, there is a one time AOT translation of Intel to Arm. Then that native code just runs. So no emulator is running on the cpu while the app is. There is an exception for apps with JIT and those will perform poorly (think Chrome and every Electron app).
    - AnthonyMouse 6y ago
      > So no emulator is running on the cpu while the app is. Nonetheless, the translated code is going to be slower than ordinary native code because a lot of the information compilers use for optimization isn't available in the resulting binary, so the translator has to be extremely conservative in its assumptions.
      - valuearb 6y ago
        Yet the translated code will still run faster on the M1 than the original code runs on x86.
        marcan_42 6y ago
        Citation needed. Not a microbenchmark, or a single example of some software. Actual sustained mixed workload usage of real life applications. Especially realtime-sensitive stuff like DAWs (where you have the added risk that calling into the JIT in the middle of a realtime thread can completely screw you over; keeping realtime-safe code realtime-safe under dynamic or even static binary translation is a whole extra can of worms).
        valuearb 6y ago
        Sustained benchmarks await production hardware. But it will be surprising if Rosetta2 translated apps run slower. Not only will system calls be native, but common operations like retain/release are 2x faster under Rosetta3. https://mobile.twitter.com/hhariri/status/1326788546502463494 https://mobile.twitter.com/hhariri/status/132678854650246349...
        marcan_42 6y ago
        That's a microbenchmark. There are a myriad reasons why one specific thing might be faster under a new CPU even under emulation. That doesn't mean other things won't be much slower.
        6y ago
- marcan_42 6y ago
  We still can't emulate some 20+ year old machines at native speed on modern hardware under certain conditions. Emulation always has corner cases where some awkward impedance mismatch between both architectures causes severe performance loss.
bigfudge 6y ago
Apple is a lot bigger market now than PPC transition though
valuearb 6y ago
Rosetta2 is mind blowing. “ fun fact: retaining and releasing an NSObject takes ~30 nanoseconds on current gen Intel, and ~6.5 nanoseconds on an M1” https://mobile.twitter.com/hhariri/status/1326788546502463494 https://mobile.twitter.com/hhariri/status/132678854650246349... “…and ~14 nanoseconds on an M1 emulating an Intel”
- marcan_42 6y ago
  How does it handle DSP inner loops? SIMD? x87 code? Floating point corner cases like denormals? What about the inevitable cases where impedance mismatch between the architectures causes severe performance loss? Is Rosetta2 binary translated code guaranteed to be realtime-safe if the original code was? What about the JIT? There's no way that is realtime-safe. What happens if some realtime code triggers the JIT? We still can't emulate some 20-year-old machines at full speed on modern hardware due to platform impedance mismatches. Rosetta2 may be good, but until someone runs a DAW on there with a pile of plug-ins and shows a significant performance gain over contemporary Intels (and zero unexpected dropouts), I'm not buying the story of Rosetta2 amazingness.
  - valuearb 6y ago
    Rosetta2 is not emulation. Edit: And Apple has already discussed how Rosetta2 handles complexities like self modifying code. It probably won’t help with performance but the M1 has a lot of power to keep even that code running fast. But more importantly video/audio apps aren’t going to be using Rosetta2 for very long. 99% of code written for x86 MacOS is going to be a simple recompile to native, if not more. Not going native when your competitors did and got 2-5x faster is corporate suicide.
    - marcan_42 6y ago
      Rosetta2 is emulation just as much as qemu and Dolphin are emulation, both of which also use binary translation like every other modern emulator. Apple marketing just doesn't want you to call Rosetta2 an emulator because "emulators are slow". Anything running software on a different architecture is an emulator. If you read my parent comment you'll see how DAWs are going to be using Rosetta2 for years to come, maybe even a decade, for many people. Even if there are ARM versions, you won't be able to use them until all your dozens if not hundreds of plug-ins, some of which won't be actively developed any more or will require a re-purchase for an ARM version, have also migrated. People invested in such ecosystems aren't just going to up and give up half their collection of software, or spend thousands re-purchasing upgrades to get ARM versions.

asah 6y ago

won't emulation catch up in those timeframes ? still, 3+ yrs which is a long time...

AnthonyMouse 6y ago
Three years isn't that long for CPU performance gains anymore, but even if it was, it isn't the emulation that gets faster, it's the hardware. Contemporary ARM machines emulating x64 would still be slower than contemporary x64 machines natively executing x64. You're also going to be in a bind if Apple decides they don't care about the long tail and stops supporting emulation before all of your plugins have been converted (if they ever are).
- sroussey 6y ago
  There is no emulation per se, there is a one time AOT translation of Intel to Arm. Then that native code just runs. So no emulator is running on the cpu while the app is. There is an exception for apps with JIT and those will perform poorly (think Chrome and every Electron app).
  - AnthonyMouse 6y ago
    > So no emulator is running on the cpu while the app is. Nonetheless, the translated code is going to be slower than ordinary native code because a lot of the information compilers use for optimization isn't available in the resulting binary, so the translator has to be extremely conservative in its assumptions.
    - valuearb 6y ago
      Yet the translated code will still run faster on the M1 than the original code runs on x86.
      - marcan_42 6y ago
        Citation needed. Not a microbenchmark, or a single example of some software. Actual sustained mixed workload usage of real life applications. Especially realtime-sensitive stuff like DAWs (where you have the added risk that calling into the JIT in the middle of a realtime thread can completely screw you over; keeping realtime-safe code realtime-safe under dynamic or even static binary translation is a whole extra can of worms).
        valuearb 6y ago
        Sustained benchmarks await production hardware. But it will be surprising if Rosetta2 translated apps run slower. Not only will system calls be native, but common operations like retain/release are 2x faster under Rosetta3. https://mobile.twitter.com/hhariri/status/1326788546502463494 https://mobile.twitter.com/hhariri/status/132678854650246349...
        marcan_42 6y ago
        That's a microbenchmark. There are a myriad reasons why one specific thing might be faster under a new CPU even under emulation. That doesn't mean other things won't be much slower.
        6y ago
marcan_42 6y ago
We still can't emulate some 20+ year old machines at native speed on modern hardware under certain conditions. Emulation always has corner cases where some awkward impedance mismatch between both architectures causes severe performance loss.

bigfudge 6y ago

Apple is a lot bigger market now than PPC transition though

valuearb 6y ago

Rosetta2 is mind blowing. “ fun fact: retaining and releasing an NSObject takes ~30 nanoseconds on current gen Intel, and ~6.5 nanoseconds on an M1” https://mobile.twitter.com/hhariri/status/1326788546502463494 https://mobile.twitter.com/hhariri/status/132678854650246349... “…and ~14 nanoseconds on an M1 emulating an Intel”

marcan_42 6y ago
How does it handle DSP inner loops? SIMD? x87 code? Floating point corner cases like denormals? What about the inevitable cases where impedance mismatch between the architectures causes severe performance loss? Is Rosetta2 binary translated code guaranteed to be realtime-safe if the original code was? What about the JIT? There's no way that is realtime-safe. What happens if some realtime code triggers the JIT? We still can't emulate some 20-year-old machines at full speed on modern hardware due to platform impedance mismatches. Rosetta2 may be good, but until someone runs a DAW on there with a pile of plug-ins and shows a significant performance gain over contemporary Intels (and zero unexpected dropouts), I'm not buying the story of Rosetta2 amazingness.
- valuearb 6y ago
  Rosetta2 is not emulation. Edit: And Apple has already discussed how Rosetta2 handles complexities like self modifying code. It probably won’t help with performance but the M1 has a lot of power to keep even that code running fast. But more importantly video/audio apps aren’t going to be using Rosetta2 for very long. 99% of code written for x86 MacOS is going to be a simple recompile to native, if not more. Not going native when your competitors did and got 2-5x faster is corporate suicide.
  - marcan_42 6y ago
    Rosetta2 is emulation just as much as qemu and Dolphin are emulation, both of which also use binary translation like every other modern emulator. Apple marketing just doesn't want you to call Rosetta2 an emulator because "emulators are slow". Anything running software on a different architecture is an emulator. If you read my parent comment you'll see how DAWs are going to be using Rosetta2 for years to come, maybe even a decade, for many people. Even if there are ARM versions, you won't be able to use them until all your dozens if not hundreds of plug-ins, some of which won't be actively developed any more or will require a re-purchase for an ARM version, have also migrated. People invested in such ecosystems aren't just going to up and give up half their collection of software, or spend thousands re-purchasing upgrades to get ARM versions.