Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple's M4 has reportedly adopted the ARMv9 architecture

wccftech.com

Post reply on HN
Print view View original

231–240 of 250 posts

Re: Apple's M4 has reportedly adopted the ARMv9 architecture

#231

Post by janwas »

brigade wrote: post #146
skavi wrote: post #138

Earlier quoted context omitted.

Does anyone have insight into why arm CPU vendors seem so hesitant about implementing SVE2? ~They seem~ *Apple seems to have no issue with SSVE2 or SME. Edit: Only Apple has implemented SSVE and SME I think.

What is the measurable benefit to implementing 128b SVE2? Like, ARM has CPUs that implement that, and it's not even disabled on some chips. So there must be benchmarks somewhere showing how worthwhile it is. And implementing 256b SVE has different issues depending on how you do it. 4x256b vector ALUs are more power hungry than generally useful. 2x256b is only beneficial over 4x128b if you're limited by decode width,…

Anyone interested in getting such numbers could run github.com/google/gemma.cpp on Arm hardware with hwy::DisableTargets(HWY_ALL_NEON) or HWY_ALL_SVE to compare the two :) I'd be curious to see the result.

Calling hwy::DispatchedTarget indicates which target is actually being used.

Re: Apple's M4 has reportedly adopted the ARMv9 architecture

#232

Post by snvzz »

skavi wrote: post #181
brigade wrote: post #152

Earlier quoted context omitted.

What is the percentage gain of using masked instructions on any benchmark/task of your choice? It can be negative on weird kernels that do lots of vector cmp since even ARM decided the cost of more than one write port in the predicate register file wasn't worth it, or if the masking adds lots of unnecessary and possibly false dependencies on the destination registers. > This is only true if we ignore more complex ins…

I think it's somewhat unfair to ask for real world examples when there really aren't many people writing optimized SVE code right now. Probably because there are hardly any devices with the extension. I think the transition from AVX2 to AVX512 is comparable in that it provided not only larger vectors, but also a much nicer ISA. There were certainly a few projects that benefited significantly from that move. simdjson…

>I think it's somewhat unfair to ask for real world examples when there really aren't many people writing optimized SVE code right now. Probably because there are hardly any devices with the extension.

Ironically, on the RISC-V side, RVV 1.0 hardware is readily available and cheap. BananaPI BPI-F3 (spacemiT K1) is RVA22+RVV, as well as some C908-based MCUs.

Re: Apple's M4 has reportedly adopted the ARMv9 architecture

#233

Post by ribit »

hajile wrote: post #141
skavi wrote: post #138

Earlier quoted context omitted.

Does anyone have insight into why arm CPU vendors seem so hesitant about implementing SVE2? ~They seem~ *Apple seems to have no issue with SSVE2 or SME. Edit: Only Apple has implemented SSVE and SME I think.

SVE2 is an extension on top of SVE which some stuff already implements. The issue is more likely to be the politics of moving to ARMv9 than anything else. As to SVE though, I'd guess variable execution time makes the implementation require a bit of work. Normally, multi-cycle tasks have a fixed number. Your scheduler knows that MUL takes N cycles and plans accordingly. SVE seems like it should require N-M cycles depe…

I am curious, which SVE instructions imply variable execution time? I’d guess that first fault load could be tricky to implement…

Re: Apple's M4 has reportedly adopted the ARMv9 architecture

#234

Post by alwillis »

threeseed wrote: post #162
alwillis wrote: post #122

Earlier quoted context omitted.

For those with MacBook Pro FOMO, do not read about the rumored foldable 18.8-inch screen MacBook Pro running on the M5 coming in 2026 [1]. [1]: https://www.macrumors.com/2024/05/23/18-8-inch-foldable-macb...

macOS does not support touch input. It would require the biggest UI redesign in the history of the company to ensure every input control is at least a centimetre away from anything else. And would require every Mac developer to absorb the cost for major updates to their apps as well. This would almost certainly be an iPad.

Obviously Apple knows how to do touch input.

And it would be possible to update macOS to enable basic touch input for unmodified apps if they wanted to.

Re: Apple's M4 has reportedly adopted the ARMv9 architecture

#235

Post by camel-cdr »

brigade wrote: post #146
skavi wrote: post #138

Earlier quoted context omitted.

Does anyone have insight into why arm CPU vendors seem so hesitant about implementing SVE2? ~They seem~ *Apple seems to have no issue with SSVE2 or SME. Edit: Only Apple has implemented SSVE and SME I think.

What is the measurable benefit to implementing 128b SVE2? Like, ARM has CPUs that implement that, and it's not even disabled on some chips. So there must be benchmarks somewhere showing how worthwhile it is. And implementing 256b SVE has different issues depending on how you do it. 4x256b vector ALUs are more power hungry than generally useful. 2x256b is only beneficial over 4x128b if you're limited by decode width,…

> What is the measurable benefit to implementing 128b SVE2

Probably not much, SVE2 has some nicer instructions, but neon already is quite solid.

> And implementing 256b SVE has different issues depending on how you do it

For in-order, and not very aggressively out-of-order cores having a larger vector length can be very useful to still get a lot of throughput out of your design. It also helps hide memory latency.

Here is a paper: https://ar5iv.labs.arxiv.org/html/2309.06865

and presentation: http://riscv.epcc.ed.ac.uk/assets/files/sc23/Short-reasons-f...

For aggressively out-of-order cores it should, for the most part, just be about decode, and some what memory latency hiding.

> 2x256b is only beneficial over 4x128b if you're limited by decode width [...] 3x256b would probably imply 3x128b which would regress existing NEON code.

I agree, that's why I don't get why people are "excited" for Zen5 to have 512b execution units, instead of 256b ones. At best there won't be a performance improvement for avx/avx2 code, at worst a regression.

Re: Apple's M4 has reportedly adopted the ARMv9 architecture

#236

Post by ribit »

hajile wrote: post #197
brigade wrote: post #146

Earlier quoted context omitted.

What is the measurable benefit to implementing 128b SVE2? Like, ARM has CPUs that implement that, and it's not even disabled on some chips. So there must be benchmarks somewhere showing how worthwhile it is. And implementing 256b SVE has different issues depending on how you do it. 4x256b vector ALUs are more power hungry than generally useful. 2x256b is only beneficial over 4x128b if you're limited by decode width,…

I'd say that the theoretical ability to gang units together would be appealing. If you have four 128-bit packed SIMD, you must execute 4 different instructions at once or the others go to waste. With SVE, you could (in theory) use all 4 as a single, very wide vector for common operations if there weren't a lot of instructions competing for execution ports. You could even dynamically allocate them based on expected ve…

I don't see how this would work out beneficially. Let's say your hardware can join 4x128b units as a virtual 512-bit SVE SIMD unit. This means you have to advertise VL as 512bit for reasons of consistency. Yes, you will save some entries in the reorder buffer if you encounter a single SVE instruction, but if the code contains independent SVE streams, you will be stalled. Moreso, not all operations will utilize all 512 register bits, so your occupancy might suffer. The only scenario I see this feature working out is if you are decode or reorder buffer limited. Neither is a problem for modern high-performance ARM cores. With x86, it might be a different story. From what I understand, AVX512 instructions can be quite large.

Modern out-of-order cores are already good at superscalar execution, so why not let them do their job? 4x128b units give you much more flexibility and better execution granularity.

Re: Apple's M4 has reportedly adopted the ARMv9 architecture

#237

Post by tonyarkles »

ziml77 wrote: post #164
tonyarkles wrote: post #142

Earlier quoted context omitted.

From having worked on Windows, OSX, and Linux desktop software over the years there's a few factors at play off the top of my head: - Windows DLLs don't usually have strong versioning baked into the filename. On OSX or Linux, there's usually the full version number baked in (libfoo.so.3.32.0) with symlinks stripping off version components. (libfoo.so, libfoo.so.3, libfoo.so.3.32) would all be symlinks to libfoo.so.3.…

On Windows isn't it possible to have the OS deal with the DLL version issue by using side-by-side assemblies? I believe in practice that's only ever used by DLLs provided by the OS, but I thought it was possible to apply the mechanism to other DLLs as well.

Maybe? I haven’t really done a deep dive into that. You’d still have to bundle them along with the installer though since there isn’t a good way to request 3rd-party DLLs (heck, there isn’t even a good way to request a specific version of MSVCRT…)

Re: Apple's M4 has reportedly adopted the ARMv9 architecture

#238

Post by janwas »

ribit wrote: post #236
hajile wrote: post #197

Earlier quoted context omitted.

I'd say that the theoretical ability to gang units together would be appealing. If you have four 128-bit packed SIMD, you must execute 4 different instructions at once or the others go to waste. With SVE, you could (in theory) use all 4 as a single, very wide vector for common operations if there weren't a lot of instructions competing for execution ports. You could even dynamically allocate them based on expected ve…

I don't see how this would work out beneficially. Let's say your hardware can join 4x128b units as a virtual 512-bit SVE SIMD unit. This means you have to advertise VL as 512bit for reasons of consistency. Yes, you will save some entries in the reorder buffer if you encounter a single SVE instruction, but if the code contains independent SVE streams, you will be stalled. Moreso, not all operations will utilize all 51…

On x86 at least, the cost of OoO is astonishing - more pJ per instruction dispatch than the operation itself. Amortizing that over more operations is the whole point of SIMD. I have not yet seen such data for Arm.

That aside, see the "cmp" sibling thread for a major (4x penalty) downside to 4x128.

Re: Apple's M4 has reportedly adopted the ARMv9 architecture

#239

Post by camel-cdr »

ribit wrote: post #236
hajile wrote: post #197

Earlier quoted context omitted.

I'd say that the theoretical ability to gang units together would be appealing. If you have four 128-bit packed SIMD, you must execute 4 different instructions at once or the others go to waste. With SVE, you could (in theory) use all 4 as a single, very wide vector for common operations if there weren't a lot of instructions competing for execution ports. You could even dynamically allocate them based on expected ve…

I don't see how this would work out beneficially. Let's say your hardware can join 4x128b units as a virtual 512-bit SVE SIMD unit. This means you have to advertise VL as 512bit for reasons of consistency. Yes, you will save some entries in the reorder buffer if you encounter a single SVE instruction, but if the code contains independent SVE streams, you will be stalled. Moreso, not all operations will utilize all 51…

> but if the code contains independent SVE streams, you will be stalled.

Can you explain why thats bad?

Don't you still get full utilisation of the 4x128b units?

Re: Apple's M4 has reportedly adopted the ARMv9 architecture

#240

Post by ribit »

janwas wrote: post #238
ribit wrote: post #236

Earlier quoted context omitted.

I don't see how this would work out beneficially. Let's say your hardware can join 4x128b units as a virtual 512-bit SVE SIMD unit. This means you have to advertise VL as 512bit for reasons of consistency. Yes, you will save some entries in the reorder buffer if you encounter a single SVE instruction, but if the code contains independent SVE streams, you will be stalled. Moreso, not all operations will utilize all 51…

On x86 at least, the cost of OoO is astonishing - more pJ per instruction dispatch than the operation itself. Amortizing that over more operations is the whole point of SIMD. I have not yet seen such data for Arm. That aside, see the "cmp" sibling thread for a major (4x penalty) downside to 4x128.

Yes, OoO is expensive — after all, that is the cost of performance. Very wide SIMD is great for energy efficiency if that is what your compute patterns require (there is a good reason why GPUs are in-order very wide SMT SIMD processors). Is this the best choice for a general-purpose CPU? That I am not so sure about. A CPU needs to be able to run all kinds of code. A single wide SIMD unit is great for some problems, but it won't deliver good performance if you need more flexibility.

Could you point me to the "cmp" thread you mentioned? I don't know where to look for it.

Post reply on HN