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

41–50 of 88 posts

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

#41

Post by my123 »

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.

The Oryon 3rd gen in the Snapdragon X2 has SVE2 (as does NVIDIA N1x, currently pre-launched of sorts on the DGX Spark)

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

#42

Post by my123 »

nwellnhof wrote: post #38
winstonwinston wrote: post #33

Earlier quoted context omitted.

Not really, Intel Celeron/Pentium/Atom (apollo lake) that was made in the last decade does not have AVX. These CPUs were very popular for low-cost, low-tdp quad-core machines such as Intel NUC mini PC. Edit. Furthermore, i think that none of these (pre-2020) low budget CPUs support AVX2, until Tiger lake released in 2020.

I think the last Intel CPUs that didn't support AVX were 10th gen (Comet Lake) Pentiums and Celerons, released in 2019. Edit: That's wrong. Jasper Lake from 2021 also came without AVX support.

It took until Alder Lake-N for the atom-grade stuff to have AVX2 across the board.

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

#43

Post by vintagedave »

TheJoeMan wrote: post #31

I tried searching "SSE2-4.x" and this is the top result in DDG and Google, so I was initially confused what instruction set the article is referring to. However, this appears to be shorthand for SSE2 through SSE4? Perhaps a rephrasing of the article title could be helpful.

Author here - yes, it's shorthand for the set of SSE2, SSE3, SSSE3 (not a typo), and SSE4 including SSE 4.1 and SSE 4.2. My bad for confusion!

That set matches the x86-64-v2 x64 microarchitecture level. Most of the articles uses 'v2' or 'v3' or 'x86-64-v2', but I thought that more people would be familiar with the names of the instruction sets than that x64 was versioned. The versions only appeared quite recently (2020) and are rather retroactive.

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

#44

Post by vintagedave »

Aissen wrote: post #4

Spoiler is in the conclusion: > Yes, it is absolutely key to build your app as ARM, not to rely on Windows ARM emulation.

Author here - have to say, thanks for reading all the way to the end, you don't always see people do that ;)

I put a spoiler at the top too, to avoid trying to make people read the whole thing. The real bit is that chart, which I think is quite an amazing result.

You're right re building. We're a compiler vendor, so we have a natural interest in what people should be targeting. But even for us the results here were not what we expected ahead of time.

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

#46

Post by jsheard »

camel-cdr wrote: post #25
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.

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

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

Kind of, but the part which looks particularly annoying is that you can't put variable-width vectors on the stack or pass them around as values in most languages, because they aren't equipped to handle types with unknown size at compile time.

ARM seems to be proposing a C language extension which does require compilers to support variably sized types, but it's not clear to me how the implementation of that is going, and equivalent support in other languages like Rust seems basically non-existent for now.

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

#47

Post by Aurornis »

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.

> The big question then is, why are ARM desktop (and server?) cores so far behind on wider SIMD support?

Very wide SIMD instructions require a lot of die space and a lot of power.

The AVX-512 implementation in Intel's Knight's Landing took up 40% of the die area (Source https://chipsandcheese.com/p/knights-landing-atom-with-avx-5... which is an excellent site for architectural analysis)

Most ARM desktop/mobile parts are designed to be low power and low cost. Spending valuable die space on large logic blocks for instructions that are rarely used isn't a good tradeoff for consumer apps.

Most ARM server parts are designed to have very high core counts, which requires small individual die sizes. Adding very wide SIMD support would grow die space of individual cores a lot and reduce the number that could go into a single package.

Supporting 256-bit or 512-bit instructions would be hard to do without interfering with the other design goals for those parts.

Even Intel has started dropping support for the wider AVX instructions in their smaller efficiency cores as a tradeoff to fit more of them into the same chip. For many workloads this is actually a good tradeoff. As this article mentions, many common use cases of high throughput SIMD code are just moving to GPUs anyway.

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

#48

Post by Aissen »

vintagedave wrote: post #44
Aissen wrote: post #4

Spoiler is in the conclusion: > Yes, it is absolutely key to build your app as ARM, not to rely on Windows ARM emulation.

Author here - have to say, thanks for reading all the way to the end, you don't always see people do that ;) I put a spoiler at the top too, to avoid trying to make people read the whole thing. The real bit is that chart, which I think is quite an amazing result. You're right re building. We're a compiler vendor, so we have a natural interest in what people should be targeting. But even for us the results here were n…

Having written an emulator, the conclusion was a bit less surprising. It's also probably not definitive, as it might depend on the specific hardware (and future emulator optimizations); you even say in your blog that the hardware you use is not the hardware Microsoft targeted.

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

#49

Post by camel-cdr »

jsheard wrote: post #46
camel-cdr wrote: post #25

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

> You can treat both SVE and RVV as a regular fixed-width SIMD ISA. Kind of, but the part which looks particularly annoying is that you can't put variable-width vectors on the stack or pass them around as values in most languages, because they aren't equipped to handle types with unknown size at compile time. ARM seems to be proposing a C language extension which does require compilers to support variably sized types…

> Kind of, but the part which looks particularly annoying is that you can't put variable-width vectors on the stack or pass them around as values in most languages, because they aren't equipped to handle types with unknown size at compile time

Yes, you can't, which is annoying, but you can if you compile for a specific vector length.

This is mostly a library structure problem. E.g. simdjson has a generic backend that assumes a fixed vector length. I've written fixed width RVV support for it. A vector length agnostic backend is also possible, but requires writing a full new backend. I'm planning to write it in the future (I alreasy have a few json::minify implementations), but it will be more work. If the generic backend used a SIMD abstraction, like highway, that support scalable vectors this wouldn't be a problem.

Toolchain support should also be improved, e.g. you could make all vregs take 512-bit on the stack, but have the codegen only utilize the lowee 128 bit, if you have 128-but vregs, 256-bit if you have 256-bit vregs and 512-bit if you have >=512-bit vregs.

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

#50

Post by adrian_b »

jorvi wrote: post #12
SecretDreams wrote: post #3

Earlier quoted context omitted.

Almost every x86 cpu made in the last decade should have avx2. Maybe you're thinking of avx512 or avx10?

Yeah, sounds like they're confusing AVX2 for AVX512. AVX2 has been common for a decade at least and greatly accelerates performance. AVX512 is so kludgy that it usually leads to a detriment in performance due to the extreme power requirements triggering thermal throttling.

That was true only for the 14-nm Intel Skylake derivatives, which had very bad management of the clock frequency and supply voltage, so they scaled down the clock prophylactically, for fear that they would not be able to prevent overheating fast enough.

All AMD Zen 4 and Zen 5 and all of the Intel CPUs since Ice Lake that support AVX-512, benefit greatly from using it in any application.

Moreover the AMD Zen CPUs have demonstrated clearly that for vector operations the instruction-set architecture really matters a lot. Unlike the Intel CPUs, the AMD CPUs use exactly the same execution units regardless whether they execute AVX2 or AVX-512 instructions. Despite this, their speed increases a lot when executing programs compiled for AVX-512 (in part for eliminating bottlenecks in instruction fetching and decoding, and in part because the AVX-512 instruction set is better designed, not only wider).

Post reply on HN