3 ms·

Well yes, x86 macs in those classes were using underpowered Intel CPUs :-). That said, I've yet to see any serious benchmarks of this kind of workload. We know

Well yes, x86 macs in those classes were using underpowered Intel CPUs :-). That said, I've yet to see any serious benchmarks of this kind of workload. We know the M1 is fast for single threaded UI code (fast as heck atomics sure help with ObjC reference counting), but that says nothing about SIMD and floating-point heavy audio processing. Rosetta adds overhead to that, potentially a lot vs native ARM code, depending on the code. There is no way to make a blanket "the M1 is so fast it overtakes Intel even under emulation" claim. I'd personally be more concerned about stability and drop-out issues. Apple sells Rosetta as an "ahead-of-time" translator, but that is necessarily best effort (because true transpiling is not a solvable problem, e.g. self-modifying code). Thus, there is always the possibility that the JIT gets invoked in the middle of the audio processing thread, and that won't end well for real-time guarantees. There are also programs that just don't work under Rosetta properly (for unclear reasons).

samatman 6y ago
These kinds of questions are why the post you're replying to asked if it was personal experience or speculation. You responded with some technically-detailed speculation, which, fair enough. I guess we'll have to wait and see.
saagarjha 6y ago
See https://lemire.me/blog/2020/12/13/arm-macbook-vs-intel-macbook-a-simd-benchmark/ https://lemire.me/blog/2020/12/13/arm-macbook-vs-intel-macbo... for SIMD performance. M1 is fairly competitive even under Rosetta. Also, if your audio code is self-modifying, I really have no idea what you could possibly be doing.
- marcan_42 6y ago
  Self-modifying code is just one example. The point is there is no way to positively identify all basic block entry points on x86 (especially due to its variable-length instructions). That means that there is always the possibility that the AoT didn't catch everything, and then your plug-in takes a novel uncached codepath at some point, the JIT fires, and you get a real-time constraint violation and a drop out. Also, audio companies sometimes like to use "fun" DRM/copy protection systems. Besides, audio apps themselves doing JIT would not be unheard of. For example, that'd be a very efficient way of implementing a modular synth. Those apps could JIT in a realtime-safe way; Rosetta can't (it doesn't have enough info).

samatman 6y ago

These kinds of questions are why the post you're replying to asked if it was personal experience or speculation. You responded with some technically-detailed speculation, which, fair enough. I guess we'll have to wait and see.

saagarjha 6y ago

See https://lemire.me/blog/2020/12/13/arm-macbook-vs-intel-macbook-a-simd-benchmark/ https://lemire.me/blog/2020/12/13/arm-macbook-vs-intel-macbo... for SIMD performance. M1 is fairly competitive even under Rosetta. Also, if your audio code is self-modifying, I really have no idea what you could possibly be doing.

marcan_42 6y ago
Self-modifying code is just one example. The point is there is no way to positively identify all basic block entry points on x86 (especially due to its variable-length instructions). That means that there is always the possibility that the AoT didn't catch everything, and then your plug-in takes a novel uncached codepath at some point, the JIT fires, and you get a real-time constraint violation and a drop out. Also, audio companies sometimes like to use "fun" DRM/copy protection systems. Besides, audio apps themselves doing JIT would not be unheard of. For example, that'd be a very efficient way of implementing a modular synth. Those apps could JIT in a realtime-safe way; Rosetta can't (it doesn't have enough info).