[Sticky] Will Unify ever run natively on Apple Silicon?
User @fleer has asked "will Unify ever run natively on Mac silicon (instead of through Rosetta 2)?"
This question came up under an unrelated topic, but it's important enough that I wanted to give it a dedicated topic, because more and more people are likely to wonder about this over the next several months.
The short answer: Unify for ARM would not be able not load a mix of ARM and Intel plug-ins, so wouldn't be much use. To fix this, we would need to add a custom bridging solution. This would take a long time, and other priorities may preempt it forever.
First, a bit of background for those that may not fully understand the issue.
What's the difference? Central processing unit (CPU) chip designs differ in many ways, but the most fundamental is the so-called Instruction-Set Architecture (ISA), which is the collection of basic operations the CPU can carry out, and how they are encoded in memory. Software (apps, plug-ins, drivers, operating systems) prepared for one ISA cannot run on a CPU that uses a different ISA. Intel CPUs use an ISA called x86-64; the new "Apple Silicon" (not silicone--that's synthetic rubber) chips use the ARM ISA. The two are very different, and hence incompatible.
Why does this matter? Most software is written ("coded") in a "high-level language" like C++, which is NOT specific to any ISA, but this "source code" is not executable by any CPU. A special program called a compiler is used to translate the source code into a binary executable file, which is encoded to match one specific ISA, and hence can only run on CPUs that use that ISA. To achieve very high performance, small parts of the original source-code may be rewritten to take better advantage of a target ISA; this is called optimization. Optimizations for one ISA must usually be re-done from scratch for a different ISA.
How can Apple Silicon CPUs run Intel code? Apple has switched ISAs three times, and each time, have had to somehow ensure that their new CPUs can run executables compiled for the previous ISA. The first transition was made easier because the new PowerPC CPUs had built-in capabilities to emulate the older Motorola 68000 architecture. For the second transition, from PowerPC to Intel, they developed the Rosetta software, which works by translating blocks of binary PowerPC instructions into functionally-equivalent blocks of Intel instructions. For the latest transition, from Intel to ARM, they reworked Rosetta into "Rosetta 2".
Why does Apple even do this? Apple charges premium prices for their computers, so they need the best (fastest, coolest-running, most power-efficient) CPUs available. CPU companies must spend outrageous amounts of money to stay at the head of the race to produce the most powerful processors, and over the years, many have simply dropped out. Apple must therefore switch to the current front-runner every time. This time around the front-runner just happens to be Apple themselves.
OK, with those basics covered, let's look at how this applies to Unify.
Unify is a plug-in host. Much of Unify's value comes from the fact that it can load third-party plug-ins, just like a DAW. It would be a lot less useful if it could only load its own plug-ins.
Host and plug-in ISAs must match. This is the crux of the whole matter. Nearly all plug-ins are dynamically-linked libraries, which are chunks of executable code which are dynamically linked into the executable code of the host application. Whatever ISA the host app has been compiled for, it can only link directly to plug-ins compiled for the same ISA, because Rosetta is not smart enough to deal with a mixture of ISAs.
An ARM version of Unify will only load ARM plug-ins. Because host and plug-in ISAs must match, you can either have Unify compiled for Intel, which can run every available plug-in, or Unify for ARM, which will only be able to load plug-ins which are also compiled for ARM. (Apple allows both Intel and ARM versions of an executable to be delivered in a single bundle called a "universal binary", which is why you don't see separate ARM-only versions of plug-ins, but this is just a bit of file-management trickery. There are separate Intel and ARM binaries hidden inside these bundles.)
How does Logic Pro run Intel plug-ins? For a host program to connect to a plug-in built for a different ISA, it must use some kind of bridging technique. The plug-in is actually hosted by an invisible program compiled for the matching ISA, and the host DAW communicates with this invisible second host instead of linking directly to the plug-in. Apple developed their own bridging software for Logic Pro X, which is (a) not available to other companies, but it only works for Audio Unit plug-ins, which we avoid in order to have Windows/Mac compatibility.
Can Unify be compiled for ARM? Yes, but it's not useful. I did it, months before Apple started selling their new M-series Macs, using a special Apple-silicon Mac they provided on loan to developers. It works beautifully, but cannot load any Intel-only plug-ins. How useful is a version of Unify that can only load the few plug-ins that have been updated to universal-binary format, and can never combine them with the others that remain Intel-only?
When will Unify have its own bridging ability? I can't give realistic estimate. I've been working on bridging for a long time (see my NetVST project), but to create a solution that will work as well as anyone would expect will take a lot longer--probably months longer. The bigger issue, though, is that time spent working on bridging is time not spent working on other things, which we and our customers (especially Windows users, for whom all of this is meaningless) would value more highly.
Quite interesting read, Shane, even for me as a Windows user.
Thanks for taking your time to elaborate on this so straight and detailed at the same time. 👍
I think if unify core run native or not give no speed enhance, because all time consuming thing is done in the plugins. only maybe the guru sampler or effect plugins can get i guess 1-3% speedup when they run native. I think this speedup is not much because today all CPU use a set of most used risc instructions all CPU have. X86 is cisc architecture but only few instructions are use in today compiler, because only this is fast. Intel and AMD have a built in CPU core more or less slow CISC to RISC translator which is only here to be compatible. so it is possible that 1 intel CISC instruction is slower as the 4 used RISC instructions need for this function
That bridging project looks pretty, pretty good I must say. Kudos!
Another perspective: now that Unify does so much, maybe it’s time for a simplified Unify Player version or versions (one of which could run natively on Apple Silicon).
Interesting discussion on this subject today on YT. Thanks @getdunne for the information and your patience.
Which Compiler you use for crosscompiling my husband ask?
Some years ago when he did Initiate the Osirix Project IT was important for him to Go in direction to Mac. This was a stratetic question because medicine world was running with Windows only. This way they keep the big players in distance.
Which Compiler you use for crosscompiling my husband ask?
Unify for Mac is built with Xcode 12.4.
Hey Shane, a fascinating read and great explanation. Ahh yes: the complexity of product differentiation. The nerd in me loves to understand, in an overview kind of way, how things work. Too bad Apple won't share its bridging software. Ahh... I always wondered why only AU plugins seemed to work directly in Logic but hey that's why UNIFY fills a unique niche.