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

AVX2 is slower than SSE2-4.x under Windows ARM emulation

blogs.remobjects.com

Post reply on HN
Print view View original

21–30 of 88 posts

Re: AVX2 is slower than SSE2-4.x under Windows ARM emulation

#21

Post by kbolino »

leeter wrote: post #10
kbolino wrote: post #5

I suspected this was because the vector units were not wide enough, and it seems that is the case. AVX2 is 256-bit, ARM NEON is only 128-bit. The big question then is, why are ARM desktop (and server?) cores so far behind on wider SIMD support? It's not like Intel/AMD came up with these extensions for x86 yesterday; AVX2 is over 15 years old.

[removed]

Part of the reason, I think, is that Qualcomm and Apple cut their teeth on mobile devices, and yeah wider SIMD is not at all a concern there. It's also possible they haven't even licensed SVE from Arm Holdings and don't really want to spend the money on it.

In Apple's case, they have both the GPU and the NPU to fall back on, and a more closed/controlled ecosystem that breaks backwards compatibility every few years anyway. But Qualcomm is not so lucky; Windows is far more open and far more backwards compatible. I think the bet is that there are enough users who don't need/care about that, but I would question why they would even want Windows in the first place, when macOS, ChromeOS, or even GNU/Linux are available.

Re: AVX2 is slower than SSE2-4.x under Windows ARM emulation

#23

Post by kccqzy »

bhouston wrote: post #19
kbolino wrote: post #5

I suspected this was because the vector units were not wide enough, and it seems that is the case. AVX2 is 256-bit, ARM NEON is only 128-bit. The big question then is, why are ARM desktop (and server?) cores so far behind on wider SIMD support? It's not like Intel/AMD came up with these extensions for x86 yesterday; AVX2 is over 15 years old.

Hasn't there been issues with AVX2 causing such a heavy load on the CPU that frequency scaling would kick in a lot of cases slowing down the whole CPU? https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Dow... My experience is that trying to get benefits from the vector extensions is incredibly hard and the use cases are very narrow. Having them in a standard BLAS implementation, sure, but outside of that I thi…

That’s only on very old CPUs. Getting benefits from vector extensions is incredibly easy if you do any kind of data crunching. A lot of integer operations not covered by BLAS can benefit including modern hash tables.

Re: AVX2 is slower than SSE2-4.x under Windows ARM emulation

#24

Post by justincormack »

kbolino wrote: post #11
jsheard wrote: post #8

Earlier quoted context omitted.

SVE was supposed to be the next step for ARM SIMD, but they went all-in on runtime variable width vectors and that paradigm is still really struggling to get any traction on the software side. RISC-V did the same thing with RVV, for better or worse.

Yeah, the extensions exist , and as pointed out by a sibling comment to yours, have been implemented in supercomputer cores made by Fujitsu. However, as far as I know, neither Apple nor Qualcomm have made any desktop cores with SVE support. So the biggest reason there's no desktop software for it is because there's no hardware support.

I think the CIX P1 has support, but I havent got one yet to verify, this is a cheap SOC core.

Re: AVX2 is slower than SSE2-4.x under Windows ARM emulation

#25

Post by camel-cdr »

jsheard wrote: post #8
kbolino wrote: post #5

I suspected this was because the vector units were not wide enough, and it seems that is the case. AVX2 is 256-bit, ARM NEON is only 128-bit. The big question then is, why are ARM desktop (and server?) cores so far behind on wider SIMD support? It's not like Intel/AMD came up with these extensions for x86 yesterday; AVX2 is over 15 years old.

SVE was supposed to be the next step for ARM SIMD, but they went all-in on runtime variable width vectors and that paradigm is still really struggling to get any traction on the software side. RISC-V did the same thing with RVV, for better or worse.

> SVE was supposed to be the next step for ARM SIMD, but they went all-in on runtime variable width vectors and that paradigm is still really struggling to get any traction on the software side.

You can treat both SVE and RVV as a regular fixed-width SIMD ISA.

"runtime variable width vectors" doesn't capture well how SVE and RVV work. An RVV and SVE implementation has 32 SIMD registers of a single fixed power-of-two size >=128. They also have good predication support (like AVX-512), which allows them to masked of elements after certain point.

If you want to emulate avx2 with SVE or RVV, you might require that the hardware has a native vector length >=256, and then you always mask off the bits beyond 256, so the same code works on any native vector length >=256.

Re: AVX2 is slower than SSE2-4.x under Windows ARM emulation

#26

Post by josefx »

jovial_cavalier wrote: post #13
leeter wrote: post #10

Earlier quoted context omitted.

[removed]

A ton of vector math applications these days are high dimensional vector spaces. A good example of that for arm would I guess be something like fingerprint or face id. Also, it doesn't just speed up vector math. Compilers these days with knowledge of these extensions can auto-vectorize your code, so it has the potential to speed up every for-loop you write.

> A good example of that for arm would I guess be something like fingerprint or face id.

So operations that are not performance critical and are needed once or twice every hour? Are you sure you don't want to include a dedicated cluster of RTX 6090 Ti GPUs to speed them up?

Re: AVX2 is slower than SSE2-4.x under Windows ARM emulation

#27

Post by jsheard »

iberator wrote: post #2

AVX2 should be banned anyway. Only expensive CPUs have it, ruining mininum games requirements and making hardware obsolete. Most of the world lives of 300$ per month

https://store.steampowered.com/hwsurvey

Other Settings > AVX2 > 95.11% supported (+0.30% this month)

Re: AVX2 is slower than SSE2-4.x under Windows ARM emulation

#28

Post by kbolino »

bhouston wrote: post #19
kbolino wrote: post #5

I suspected this was because the vector units were not wide enough, and it seems that is the case. AVX2 is 256-bit, ARM NEON is only 128-bit. The big question then is, why are ARM desktop (and server?) cores so far behind on wider SIMD support? It's not like Intel/AMD came up with these extensions for x86 yesterday; AVX2 is over 15 years old.

Hasn't there been issues with AVX2 causing such a heavy load on the CPU that frequency scaling would kick in a lot of cases slowing down the whole CPU? https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Dow... My experience is that trying to get benefits from the vector extensions is incredibly hard and the use cases are very narrow. Having them in a standard BLAS implementation, sure, but outside of that I thi…

This is a bit short-sighted. Yes, it is kinda tricky to get right, and a number of programming languages are quite behind on good SIMD support (though many are catching up).

SIMD is not limited to mathy linear algebra things anymore. Did you know that lookup tables can be accelerated with AVX2? A lot of branchy code can be vectorized nowadays using scatter/gather/shuffle/blend/etc. instructions. The benefits vary, but can be significant. I think a view of SIMD as just being a faster/wider ALU is out of date.

Re: AVX2 is slower than SSE2-4.x under Windows ARM emulation

#29

Post by 0x000xca0xfe »

jsheard wrote: post #8
kbolino wrote: post #5

I suspected this was because the vector units were not wide enough, and it seems that is the case. AVX2 is 256-bit, ARM NEON is only 128-bit. The big question then is, why are ARM desktop (and server?) cores so far behind on wider SIMD support? It's not like Intel/AMD came up with these extensions for x86 yesterday; AVX2 is over 15 years old.

SVE was supposed to be the next step for ARM SIMD, but they went all-in on runtime variable width vectors and that paradigm is still really struggling to get any traction on the software side. RISC-V did the same thing with RVV, for better or worse.

RISC-V chip designers at least seem to be more bullish on vectors. There is seriously cool stuff coming like the SpacemiT K3 with 1024-bit vectors :)

Re: AVX2 is slower than SSE2-4.x under Windows ARM emulation

#30

Post by camel-cdr »

jsheard wrote: post #18
kbolino wrote: post #11

Earlier quoted context omitted.

Yeah, the extensions exist , and as pointed out by a sibling comment to yours, have been implemented in supercomputer cores made by Fujitsu. However, as far as I know, neither Apple nor Qualcomm have made any desktop cores with SVE support. So the biggest reason there's no desktop software for it is because there's no hardware support.

ARMs Neoverse IP does support SVE, so it's at least already relevant in cloud applications. Apparently AWS Graviton3 had 256bit SVE, but Graviton4 regressed back to 128bit SVE for some reason? https://ashvardanian.com/posts/aws-graviton-checksums-on-neo...

The problem with SVE is that ARM vendors need to make NEON as fast as possible to stay competitive, so there is little incentive to implement SVE with wider vectors.

Graviton3 has 256-bit SVE vector registers but only four 128-bit SIMD execution units, because NEON needs to be fast.

Intel previously was in such a dominant market position that they could require all performance-critical software to be rewritten thrice.

Post reply on HN