Yes and no.
If for example the application uses frameworks (like uh... every macOS and iOS app) it can call native versions of the frameworks included in the OS.
So... sure... if you are writing AVX code directly you might see an issue. But if you are using say, Metal or OpenCL, or any one of the other provided macOS frameworks for doing the heavy lifting, as recommended, then your application simply links to the provided framework and uses whatever the best hardware the end device has to do the job, the best way it can.
Didn't Apple deprecate OpenCL? I can't find the mention in their documentation at the moment. You're right that it shouldn't be an issue if they're linking to macOS frameworks for the costly portions. It still doesn't make emulation fast in any sense, as you are still effectively running this portion via an interpreter.
I didn't say anything about writing in assembly, apart from an earlier comment that referenced a low level library.
I'm going to rephrase slightly.
If you're trying to achieve ABI compatibility with some older application code, which requires more than trivial changes to be recompiled for ARM, the parts that were compiled for an older architecture are likely to be much slower, both due to having an interpreter layer in between and due to other details such as scheduling differences between the two architectures.
Things that would require more than a trivial recompile are stuff like removal of deprecated components and other various api changes.
As you mention though, parts that link to .dylib files aren't really impacted, because those are natively compiled from day one.
Last edited: