Sure, for the instruction set all the CPUs are required to be compatible. However, Apple seems to be going in the direction of having many many hardware accelerators builtin to their SoC and integrated into their software ecosystem. I assume that if Google and Amazon were to build their own chips, they'd do the same. Those accelerators will not be intercompatible, and we'll have a dozen different vendored drivers, like how GPUs work.

> However, Apple seems to be going in the direction of having many many hardware accelerators builtin to their SoC and integrated into their software ecosystem.

I think this is overstated. There are quite a few differences between Intel and AMD extensions these days and they don’t create much of a problem. Apple’s architecture isn’t reliant on accelerators or special instructions to get good performance on general purpose code.

But it could exist right? For instance, what if MS created an ARM variant with special instructions to accelerate C# garbage collection? You could imagine a world where vertical integration throughout the entire stack leads to software which kind of works everywhere, but only really gives a good experience on 1st party hardware.

I'm no expert but put too many extensions in there and you're looking less like RISC and more like CISC. It would make more sense on x86 platforms.

> Sure, for the instruction set all the CPUs are required to be compatible. However, Apple seems to be going in the direction of having many many hardware accelerators builtin to their SoC and integrated into their software ecosystem.

There is little evidence that Apple has built anything truly non-standard in the M1 so far, the closest thing they have is the TSO mode, and that's not an optimisation since it provides stronger guarantees (and thus lower performances) than normal. That cost happens to be recouped tenfolds when emulating a TSO architecture (aka x86) rather than having to do it in software, but that's got nothing to do with ARM workloads.

Not specializing in this area, I'm somewhat at a loss to understand what is so unique about the M1 that competitors could not implement similar in other ARM based systems or instead on Intel/AMD? Maybe another way to ask is what of the M1 performance is due to ARM and what from the Apple implementation?

I'm not a specialist either but my understanding is that Apple has thrown a lot of resources (and hardware) at the problem (and have been doing so for a while, the M1 is simply the apotheosis), and it has paid off: https://news.ycombinator.com/item?id=25257932

Nothing stops other ARM manufacturers from doing that, but it's expensive, and most manufacturers don't really have a reason to work this hard at it, they have a fairly low-margin biz and their clients aren't going to pay big bucks. For Apple however, these chips are completely structural, they already underlie huge amounts of their business and with the switch of Macs to ARM are slated to do so even more.

It may not be possible for x86 though, because of the architecture's complexity limits e.g. how wide you can decode, and more generally how much hardware you can keep fed concurrently.

Being willing to be inefficient in terms of performance per square millimetre of silicon to be more efficient in terms of performance per watt was how it started. Having less cruft in the ISA that let them be more creative in other areas might be the more important factor now.

>Sure, for the instruction set all the CPUs are required to be compatible.

Isn't that the only thing we care about?

Anything else is a lot like saying that Intel based PCs aren't really compatible with each other because they can use different implementations of things like graphics chips, sound chips, and NICs.

> However, Apple seems to be going in the direction of having many many hardware accelerators builtin to their SoC and integrated into their software ecosystem

I mean, so have Intel and AMD, for decades.

Their specialized audio/ video/ image/ machine learning cores aren't helping with general purpose tasks like building code.

It's also not much different from the PC world where you have video cards and Nvidia's CUDA.