Non-ARM optimized plugins in a ARM hosts

[Markus Krause]

I am wondering if this does work. And also the opposite direction.
According to what i have read it works this way: A non-ARM software ist launched for the first time. The bytecode is translated to ARM. This can take up to 20 seconds. The next time it is faster.
But what happens if non ARM plugins/hosts and ARM plugins/hosts are combined?
Does this work?

[BertKoor]

According to what i have read it works this way: A non-ARM software ist launched for the first time. The bytecode is translated to ARM. This can take up to 20 seconds. The next time it is faster.

From a source reference on the Rosetta article on Wikipedia (granted, not the best source) :

It translates the apps when you install them, so they can launch immediately and can be instantly responsive. And Rosetta 2 can also translate code on the fly when needed.

But what happens if non ARM plugins/hosts and ARM plugins/hosts are combined?
Does this work?

I'd expect that works seamlessly. Anything which gets loaded for execution should go through Rosetta2 if it's not yet translated.

As I read it, for plugins it could already happen at install time.

And as per the title:

ARM optimized plugins in a non-ARM host

Once the host actually runs, it is translated. So at runtime there should not be a difference with a host that was optimised for ARM by the developer. Hence it should be able to use ARM-optimised plugins. In theory...

[FigBug]

I just tried scanning Intel VST plugins for an ARM host (Waveform) and they fail to scan. I scanned Intel AU plugins in ARM Logic and they scanned very slowly (I assume they were being compiled). They then showed up in Waveform. (I should have tried scanning them in Waveform first)

So maybe there is something the host needs to do to trigger the compile process? Or maybe there is a special work around for AU plugins. Will need to investigate more.

Then I tried Intel Waveform and it loaded Intel VST fine. When loading fat binary VST it loaded the Intel version. I figured the Intel VST should be compiled now, so went back to ARM Waveform, they still won't load.

[Markus Krause]

Thanks for your tests.
Did yo run your tests with VST3 or VST 2.4 plugins?
So VST plugins which were not compiled for the ARM cpu will not longer work in an ARM host. The users wil not longer be able to load their old projects.
AU plugins take longer to scan, but might work in an ARM host.
If this should be true Apple did mess up the Audio world again

[Markus Krause]

If i understand it correctly nearly all recent vst plugins do not longer work in hosts that support ARM on the Mac. This is a bummer

[FigBug]

If i understand it correctly nearly all recent vst plugins do not longer work in hosts that support ARM on the Mac. This is a bummer

Assuming the host is a fat binary, users have the option of running the Intel version of the host.

[FigBug]

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.

[Markus Krause]

From the technical side this would make sense. I already assumed that this scenario would come true.
As a result all hosts on the Mac that support ARM need to implement a bit-bridge. Otherwise the intel-plugins can not longer be used

[Richard_Synapse]

On a related topic, has anyone done performance measurements on emulated plugin code on an ARM? Is the performance at least somewhat acceptable? If the plugins work at all in any host, that is.

Either way it sounds like we will have to make custom versions for ARM

Richard

[waltercruz]

Either way it sounds like we will have to make custom versions for ARM

I think that it's possible to distribute Universal Binaries with ARM+IA64 on the same binary, but I have no idea if this is possible on plugins.

[Richard_Synapse]

Either way it sounds like we will have to make custom versions for ARM

I think that it's possible to distribute Universal Binaries with ARM+IA64 on the same binary, but I have no idea if this is possible on plugins.

It used to work with PPC if I recall correctly (has been a while), so probably yes.

Richard

[FigBug]

Either way it sounds like we will have to make custom versions for ARM

I think that it's possible to distribute Universal Binaries with ARM+IA64 on the same binary, but I have no idea if this is possible on plugins.

Yes, this is possible.

[FigBug]

On a related topic, has anyone done performance measurements on emulated plugin code on an ARM? Is the performance at least somewhat acceptable? If the plugins work at all in any host, that is.

Either way it sounds like we will have to make custom versions for ARM

Running Nexus under Rosetta I can run about 50 instances playing a sequence preset. Native code I can do about 80. This is on pre-release hardware. I have ordered a MacBook Pro and will update these results with real hardware.

[syntonica]

Running Nexus under Rosetta I can run about 50 instances playing a sequence preset. Native code I can do about 80. This is on pre-release hardware. I have ordered a MacBook Pro and will update these results with real hardware.

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.

As an aside, when does your secret squirrel ARM Mini have to go back?

[FigBug]

As an aside, when does your secret squirrel ARM Mini have to go back?

Not sure, they haven't given a date yet.