Comment by hajile | Hacker News Reader

Comment by hajile | Hacker News Reader

Parent Full thread

ARMv8 is a big target [0]. You have 6 major ISA extensions of which recent ARM designs support 2 and Apple's support 5. There's also SVE which was a kind of side-option. In addition, there's the 32-bit version, the 64-bit version, the R and A versions all with different capabilities and support levels.

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...

"I suspect we're about to see [Apple Silicon] move to small performance increases due to diminishing returns"

Is there any discussion of this online, I'm curious to read more.

This has already happened.

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.

Where does the A14/M1 suffer due to the lack of SVE? The performance of M1 is well known to be terrific, so it’s hard to characterize that as dropping the ball in my book. More like they prioritized other features instead, and they ended up creating a great processor.

Let's say M2 has SVE. Do you:

* 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.

It's even harder than that.

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.

My point was that it probably doesn’t matter. M1 is already very fast, even without SVE. At some point you just have to decide to ship a product, even if it doesn’t have every possible feature.

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.

I don't think any code sensitive enough to performance to warrant SVE instructions will want to tolerate a jump in a very tight loop.

The libraries are either header-only to permit inlining or written to operate over batches of data.

I suppose they "dropped the ball" in the sense that those instructions cannot be assumed to be available, thus will not be encoded by the compiler by default. Any future processors which include the instructions may not benefit until developers recompile for the new instructions and go through the extra work required to conditionally execute when available.

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.

I would think that Apple would make a new fat slice for ARMv9 where SVE was the baseline.

Reply on news.ycombinator.com