Non-ARM optimized plugins in a ARM hosts

[Markus Krause]

https://www.pro-tools-expert.com/produc ... at-we-know

A great article. It sums up all pitfalls and trouble that we will be dealing with the M1 chipsets

[Zaphod (giancarlo)]

I had a lot of issues in Rosetta traslated code, especially when code is loaded from ram
I had good performances in native mode, around 1/3 of Intel desktops (i9) but
1) stable
2) the computer is cold and running for weeks!!! Completely cold

Waiting for M1 now...

[Zaphod (giancarlo)]

Just got confirmation from Apple Developer forum that all dylib in the same process must be the same architecture. I assume that means AU plugins run in their own process? So if ARM hosts want to run Intel plugins, they must have a plugin bridge, similar to the bridges used for running 32 bit plugins in 64 bit processes.

Yes

[Zaphod (giancarlo)]

The memory performance bottleneck is more or less my experience


Edit: my bad, this is the correct link
https://www.anandtech.com/show/16252/ma ... -m1-tested

[Richard_Synapse]

Ow! That's a bigger hit than I've heard before. 37.5%. I'm surprised since most ARM substitutions look to be one-to-one, clock-speed wise. It's probably in the SIMD, where they may be substituting code loops for vector calls. It's been a while since I compared NEON to Intel.

I can confirm there's a performance hit, should be in that ballpark roughly at first glance, but need to experiment more. Anyway it looks like we won't get around making custom versions for the M1 processors, using native code+NEON.

Richard