Interesting!

It's hard to guess when Arm v9 might make an appearance in Apple Silicon. The 64-bit v8 instruction set was introduced in October 2011 and was adopted by Apple two years later with the A7 in iPhone 5S. That was considered an aggressive move that caught competitors off guard and was a closely guarded secret, not even mentioned to developers during the annual developer conference a few months earlier.

So with Arm v9 being formally announced this year, it's not crazy to think it might be 2023. Then again, it's not as dramatic a departure so we could see it earlier. It's all speculation until Apple announces something. The one thing that isn't speculation is that existing software won't be affected by it directly. These are new instructions which, more or less by definition, existing software isn't using. As always, the most immediate gains won't come from the new instructions, but from architectural improvements in the CPU's implementation, plus the silicon manufacturing process Apple uses that determines the density, speed, and efficiency of the smallest fundamental elements of the design.

The v9 instruction set is still based on the v8 core, so code will run without modification but, as with all instruction set extensions, if it's the new instructions that are interesting then you need to recompile or redesign to take advantage of them. Some improvements will be free for developers courtesy of the new OS libraries that target new instructions, but if it's a developer's code that's the bottleneck then they have to do at least some work to make use of the new vector extensions, which are likely the most interesting aspects of the new extensions.

Great info, thanks. TSMC makes Apple's SoC, yes? If the new instructions end up being required for, say, interface - example NI's Massive X for the present generation - that would mean loss of backward compatibility though, wouldn't it? Meanwhile, sounds less stressful on the programmers for awhile, once wholesale migration has occurred.

Crazy really. Instead of the mobile processors being derived from / cut down versions of desktop chips, Apple have gone the other way. They created amazingly fast and power efficient mobile processors (iPads beating Intel desktop chips in single core benchmarks anyone?) and have scaled up to create killer desktop processors.

Samsung manufactured them up to the A7, if I remember correctly. Since then it has been all TSMC, though I don't doubt they'd jump to any foundry that provided a significant enough advantage..

None of the new instructions are required per se. Anything computable can be done with the current instruction set, but taking advantage of the new extensions could provide performance wins for some specific scenarios. It's typical to support both the slower and faster code paths, at least for some period of time.

The same thing has happened with a lot of new Intel instructions. Haswell in particular brought a number of extensions that developers supported, and in some cases you're starting to see the slow code path being eliminated. U-he's recent updates, for instance, won't run on pre-Haswell Intel processors.

Usually it's just some small subset of your code that has to exist in two forms, and sometimes these subtleties are entirely hidden from the developer when it's work assigned to the OS through some kind of abstraction. Anything using Core ML for machine learning, for example, can pretty seamlessly switch from CPU to using the Neural Engine. Likewise with work assigned to the GPU using Metal's Shading Language.

One of the advantages of Samsung is they have multiple fabs in different cities running the same or similar processes, so they can second-source themselves in-house for many products.

Although all the really cool Samsung linear stuff is now Fairchild... love those KSC2383s but Samsung doesn't see that as a growth market I suppose.
--scott

I have a 13" M1 MBP and a 16" M1 Max MBP with none of these problems other than Kontakt being sub-optimal under Rosetta.