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

81–88 of 88 posts

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

#81

Post by pertymcpert »

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…

You can definitely SVE vectors on the stack, there are special instructions to load and store with variable offsets. What you can't do is to put them into structs which need to have concretely sized types (i.e. subsequent element offset need to have a known byte offset).

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

#82

Post by pertymcpert »

josefx wrote: post #26
jovial_cavalier wrote: post #13

Earlier quoted context omitted.

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?

Those are extremely performance critical operations. A lot of people use their phone many times an hour.

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

#83

Post by malkia »

Const-me wrote: post #75
vintagedave wrote: post #72

Earlier quoted context omitted.

Author here - thanks - my bad. Fixed 'fast' -> 'fused' :) I don't have insight into how Prism works, but I have wondered if the right debugger would see the ARM code and let us debug exactly what was going on for sure.

You’re welcome. Sadly, I don’t know how to observe ARM assembly produced by Prism. And one more thing. If you test on an AMD processor, you will probably see much less profit from FMA. Not because it’s slower, but because SSE4 version will runs much faster. On Intel processors like your Tiger Lake, all 3 operations addition, multiplication and FMA compete for the same execution units. On AMD processors however, multi…

You can ... to a degree - Google for "XtaCache"

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

#84

Post by rbanffy »

When doing feature detection for execution path selection, it’s sometimes useful to run some quick benchmarks to see which path is objectively best.

Now we have two-ish implementations or x86, but back in the 1980s and 1990s we had quite a few, some with wildly different performance characteristics.

And, if we talk about ARM and RISC-V, we’ll have an order of magnitude more.

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

#85

Post by wtallis »

Aurornis wrote: post #74
aseipp wrote: post #70

Earlier quoted context omitted.

Knights Landing is a major outlier; the cores there were extremely small and had very few resources dedicated to them (e.g. 2-wide decode) relative to the vector units, so of course that will dominate. You aren't going to see 40% of the die dedicated to vector register files on anything looking like a modern, wide core. The entire vector unit (with SRAM) will be in the ballpark of like, cumulative L1/L2; a 512-bit re…

True! But even if only 20% of the die area goes to AVX-512 in larger cores, that makes a big difference for high core count CPUs. That would be like having a 50-core CPU instead of a 64-core CPU in the same space. For these cloud native CPU designs everything that takes significant die area translates to reduced core count.

You're still grossly overestimating the area required for AVX-512. For example, on AMD Zen4, the entire FPU has been estimated as 25% of the core+L2 area, and that's including AVX-512. If you look at the extra area required for AVX-512 vs 256-bit AVX2, as a fraction of total die area including L3 cache and interconnect between cores, it's definitely not going to be a double digit percentage.

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

#86

Post by arka2147483647 »

jsheard wrote: post #52
camel-cdr wrote: post #49

Earlier quoted context omitted.

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

> 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. SVE theoretically supports hardware up to 2048-bit, so conservatively reserving the worst-case size at compile time would be pretty wasteful. That's 16x overhead i…

Surely you could have compiler types for 128, 256, 512, etc, and then choose the correct codepath with simple if statement at runtime?

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

#87

Post by mschuster91 »

kbolino wrote: post #64
Aurornis wrote: post #47

Earlier quoted context omitted.

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

The rarity of use is a chicken-egg problem, though. The hardware makers consider it a waste because the software doesn't use it, and the software makers won't use it because it's not widely supported enough. Apple and Qualcomm not supporting it at all on any of their hardware tiers just exacerbates it. I think this is a good explanation for why mobile devices lack it, and even why say a MacBook Air or Mac Mini lacks…

> I think this is a good explanation for why mobile devices lack it, and even why say a MacBook Air or Mac Mini lacks it, but not why a MacBook Pro or Mac Studio lacks it.

Apple has the problem they "have to" have a professional "studio" lineup, but the prices are too high / the market volume too low to justify creating and validating what essentially is a fork of their SoC architecture.

Post reply on HN