5 ms·

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.
          • valuearb 6y ago
            Benchmarks are now out, and x86 Chrome is faster on the M1 MacBook Air than the x86 MacBook Air.
    • dylan604 6y ago
      Oh dear lawd, Electron apps can get slower?
      • sroussey 6y ago
        Oh yes. JS -> bytecode-> JIT for x64 -> interpreted and converted to ARM (both using CPU and memory). And most use electron-builder which does not have Mac Arm support. Expect super slow mode for a while!
    • marcan_42 6y ago
      "Emulation" is a catch-all term that includes binary translation, static and dynamic, which every modern emulator uses (Apple just doesn't want you to use that name because people think emulation is slow). Rosetta2 is not a pure static translator, because such a thing can't exist (see: self-modifying code). Just because binary translation is used doesn't mean it's magically as fast as native code. Converting code that runs on architecture A to run on architecture B always has corner cases where things end up a lot slower by necessity.
• 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.