ARMv9 tries to unify that a bit [1]. They add a new security model and SVE moves from a side option to a requirement. A bunch of the various v8 instructions also get bundled into the core requirements.
A14 vs X2 is a different question. A14/M1 really dropped the ball by not supporting SVE. I suspect they will support it in their next generation of processors, but the problem is adoption. Everyone is jumping on the M1 units and won't be upgrading their laptops for another few years. As such, they'll be held back for the foreseeable future.
Performance is no question and A14 will be retaining its lead for the next 2-3 years at least. X1 chips are already significantly slower than A14 chips. X2 only increases performance by 10-16% (as pointed out in the article, the 16% is a bit disingenuous as it compares X1 with 4mb cache to the x2 with 8mb of cache while X1 gets a decent speedup with the 8mb version). Furthermore, by the time X2 is actually in devices, Apple will already be launching their own next generation of processors (though I suspect we're about to see them move to small performance increases due to diminishing returns).
[0] https://en.wikipedia.org/wiki/AArch64
[1] https://www.anandtech.com/show/16584/arm-announces-armv9-arc...
Is there any discussion of this online, I'm curious to read more.
A14 is 3.1GHz while A13 is 2.66GHz. A14 is around 20% faster than A13 overall, but it is also clocked 14% higher which gives only around 6% more IPC. Power consumption all but guarantees that they won't be doing that too often.
That said, to get the best performance on vector math it has long been recommended to use Apple's own Accelerate.framework, which has the benefit of enabling use of their proprietary matrix math coprocessor. One can expect the framework to always take maximum advantage of the hardware wherever it runs with no extra development effort required.
* only use NEON to save developer time and lose performance and forward compatibility
* only use SVE to save developer time and lose backward compatibility
* Pay to support both and deal with the cost/headaches
Experience shows that AVX took years to adopt (and still isn't used for everything) because SSE2 was "good enough" and the extra costs and loss of backward compatibility weren't worth it.
If SVE were supported out of the gate, then the problem would simply never exist. Don't forget (as stated before) that there's been a huge wave of M1 buyers. People upgraded early either to get the nice features or not be left behind as Apple drops support.
Let's say you have 100M Mac users and an average of 20M are buying new machines any given year (a new machine every 5 years). The 1.5-2-year M1 wave gets 60-70M upgraders in the surge. Now sales are going to decline for a while as the remaining people stick to their update schedule (or hold on to their x86 machines until they die). Now the M2 with SVE only gets 5-10M upgraders. Does it make sense to target such a small group or wait a few years? I suspect there will be a lot of waiting.
SVE vs NEON performance will also hugely depend on the vector length the given algorithm requires, and the stress that the instructions put on the memory subsystem.
Memory hierarchy varies by product and will likely continue to do so regardless of what M2 does.
In the end, I echo eyesee's comment, for best performance one should really use Accelerate.framework on Apple's hardware.
Like other posters mentioned, for vector operations like this, you could be dynamically linking to a library that handles this for you in the best way for the hardware. Then when new instructions become available, you don't have to change any of your code to take advantage.
v9 has a bunch of neat features that improve security and performance (+ less baggage from ARMv7 which also improves area and power)
Many of them are already optional features in later ARMv8 revisions, however.
v9 brings a bunch of completely new stuff, specially in the security department.
See X1 vs. Firestorm: https://www.anandtech.com/show/16463/snapdragon-888-vs-exyno...
By the time products with ARM X2 ship, Apple will be shipping M2 or M3 processors.
X2 is not even out yet, you have no idea how it may perform.
Why has every post on HN drift into blindly praising an unrelated product?
Some idea how the X2 will perform.
If you read on a bit, there is some question that those performance metrics will be seen in the real world, due to existing thermal issues.
> I am admittedly pessimistic in regards to power improvements in whichever node the next flagship SoCs come in (be it 5LPP or 4LPP). It could well be plausible that we wouldn’t see the full +16% improvement in actual SoCs next year.
Removal of aarch32 has huge implications. And this is not limited to CPU but also touches MMU, caches and more that in v8 had to provide aarch32 compatible interfaces. This lead to really inefficient designs (for example, MMU walk which is extremely critical to performance is more than twice as complicated in ARMv8 compared to v7 and v9).
The space saved by removing these can be used for bigger caches, wider units, better branch prediction and other fun stuff.
Finally, note also that the baseline X1 numbers come from Samsung who we all know are worst in class right now. And they are using an inferior process. Let's see what qcomm, ampere and amazon can do with v9.