> x86-64-v3 is AVX2-capable CPUs.
Which unfortunately extends all the way to Intels newest client CPUs since they're still struggling to ship their own AVX512 instructions, which are required for v4. Meanwhile AMD has been on v4 for two generations already.
At least Intel and AMD have settled on a mutually supported subset of AVX-512 instructions.
The hard part was getting Intel and Intel to agree on which subset to keep supporting.
Even on the same chip.
Having a non-uniform instruction set for one package was a baffling decision.
I think that stemmed from their P-core design being shared between server and client. They needed AVX512 for server so they implemented it in the P-cores, and it worked fine there since their server chips are entirely P-cores or entirely E-cores, but client uses a mixture of both so they had to disable AVX512 to bring the instruction set into sync across both sides.
Server didn't really have anything to do with it. They were fine shipping AVX 512 in consumer silicon for Cannon Lake (nominally), Ice Lake, Tiger Lake, and most damningly Rocket Lake (backporting an AVX 512-capable core to their 14nm process for the sole purpose of making a consumer desktop chip, so they didn't even have the excuse that they were re-using a CPU core floorplan that was shared with server parts).
It's pretty clear that Alder Lake was simply a rush job, and had to be implemented with the E cores they already had, despite never having planned for heterogenous cores to be part of their product roadmap.
It’s a manifestation of Conway’s law: https://en.wikipedia.org/wiki/Conway%27s_law
They had two teams designing the two types of cores.