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

Transcoding Unicode with AVX-512: AMD Zen 4 vs. Intel Ice Lake

lemire.me

Post reply on HN
Print view View original

31–40 of 70 posts

Re: Transcoding Unicode with AVX-512: AMD Zen 4 vs. Intel Ice Lake

#31

Post by snvzz »

jonstewart wrote: post #22
snvzz wrote: post #5

AVX-512 is wider, but also needs special instructions to leverage the hardware. This is unlike RISC-V V extension, where the same code will run and utilize the hardware, regardless of vector unit width.

Is there a RISC-V chip with SIMD available for purchase with roughly comparable price/performance to current Intel/AMD offerings?

If you specifically prefer SIMD over Vector, Andes has offerings with draft P extension.

If you otherwise want vector (V extension), "right now" would limit you to pre-1.0 V extension implementations.

If you need to license hardware IP, there are several very high performance implementations as of RISC-V Summit[0]. Actual hardware will pop up throughout 2023.

0. https://www.youtube.com/@RISCVInternational/videos

Re: Transcoding Unicode with AVX-512: AMD Zen 4 vs. Intel Ice Lake

#32

Post by brigade »

snvzz wrote: post #5

AVX-512 is wider, but also needs special instructions to leverage the hardware. This is unlike RISC-V V extension, where the same code will run and utilize the hardware, regardless of vector unit width.

Vectorizing text handling is likely to use generalized register permutes (and I spy some _mm512_shuffle_epi8 here), which are the bugaboo in length-agnostic SIMD. Fundamentally, the maximum index you can read from in a register depends on the register size.

So yeah, even in RISC-V V, vrgather has explicitly different per-element operation depending on VLMAX, which obviously depends on the HW's VLEN. So depending on the table size, you have to assume constraints on VLEN or execute different permute sequences.

Re: Transcoding Unicode with AVX-512: AMD Zen 4 vs. Intel Ice Lake

#33

Post by snvzz »

chris6f wrote: post #13
snvzz wrote: post #5

AVX-512 is wider, but also needs special instructions to leverage the hardware. This is unlike RISC-V V extension, where the same code will run and utilize the hardware, regardless of vector unit width.

Vector length agnostic programming has its own share of problems. I'm not familiar with the RISC-V V extension, but I assume it's similar to ARM's SVE. There's a good critical look at SVE and VLA here: https://gist.github.com/zingaburga/805669eb891c820bd220418ee...

V extension and SVE2 are very different.

Here is a quite recent introduction to RISC-V Vector[0].

0. https://erikexplores.substack.com/p/grokking-risc-v-vector-p...

Re: Transcoding Unicode with AVX-512: AMD Zen 4 vs. Intel Ice Lake

#34

Post by Dalewyn »

sakras wrote: post #15
ajross wrote: post #3

> These results suggest that AMD Zen 4 is matching Intel Ice Lake in AVX-512 performance. Given that the Zen 4 microarchitecture is the first AMD attempt at supporting AVX-512 commercially, it is a remarkable feat. Um... Ice Lake shipped over three years ago. I mean, there's a real question as to whether or not "senselessly wide SIMD" is a good or bad feature in a datacenter part, and how or whether AMD should attemp…

The Ice Lake chips being benchmarked against are server chips, while the 7950X Zen 4 chip used is a consumer chip. So while Ice Lake has been out for a while, it’s also several times more expensive. It’s also worth noting that it took Intel several generations of trying AVX512 to get it working well, so AMD doing it first try really is impressive (even if they did cheat by just having AVX512 be double pumped AVX2).

Whether it's comparing latest gen architectures against old architectures or comparing consumer CPUs against enterprise CPUs (or an unholy combination of both), it's all insincere hogwash.

Comparing apples to oranges is not how you determine how good a peach is.

Re: Transcoding Unicode with AVX-512: AMD Zen 4 vs. Intel Ice Lake

#35

Post by readonlybarbie »

Iwan-Zotow wrote: post #30
readonlybarbie wrote: post #8

Earlier quoted context omitted.

Noob question- must one write avx512 assembly directly by hand, or is this something a c compiler would do for you?

You should use Intel intrinsics - generally, they are supported by all compilers. E.g. https://www.intel.com/content/www/us/en/develop/documentatio...

if you are targeting more than one specific platform, do you like, include the immintrin.h header and use #ifdef to conditionally use avx512 if it's available on someone's platform?

Re: Transcoding Unicode with AVX-512: AMD Zen 4 vs. Intel Ice Lake

#36

Post by dotnet00 »

svnpenn wrote: post #2

I saw this once before, and both times, it's pretty shocking. Is this really something that needs to be inside the CPU itself? I don't want my CPU doing this. I would rather just take the performance hit and keep the CPU "dumb".

x86 CPUs have been essentially black magic for a while now. If anything, what's described here is on the dumber side for things an x86 CPU from the past decade or two is doing behind the scenes to operate as fast as it does.

Re: Transcoding Unicode with AVX-512: AMD Zen 4 vs. Intel Ice Lake

#37

Post by gulikoza »

readonlybarbie wrote: post #8
moonchild wrote: post #6

Earlier quoted context omitted.

Most of what's interesting about avx512 is the new instructions; the wider vectors are just icing on the cake. You would need to rewrite your code regardless.

Noob question- must one write avx512 assembly directly by hand, or is this something a c compiler would do for you?

I wonder how much compilers could be improved with AI?

I'd imagine outputting optimized avx code from an existing C for() loop would be much easier than going from a "write me a python code that..." prompt.

Re: Transcoding Unicode with AVX-512: AMD Zen 4 vs. Intel Ice Lake

#38

Post by celrod »

brrrrrm wrote: post #17
readonlybarbie wrote: post #8

Earlier quoted context omitted.

Noob question- must one write avx512 assembly directly by hand, or is this something a c compiler would do for you?

typically if it's available, compilers will use the avx512 register file. This means you'll see things like xmm25 and ymm25 (128 and 256 bit registers) and those are avx512 only. However, compilers using 512-wide instructions is kinda rare from what I've seen

You can use `-mprefer-vector-width=512` to use 512 bit vectors, or if you want a particular function to use 512, you could try the min-vector-width attribute: https://clang.llvm.org/docs/AttributeReference.html#min-vect...

In my experience, clang unrolls too much, so you end up spending all your time in the non-vectorized remainder. Using smaller vectors cuts the size of the non-vectorized remainders in half, so smaller vectors often give better performance for that reason. (Unrolling less could have the same effect while decreasing code size, but alas)

Re: Transcoding Unicode with AVX-512: AMD Zen 4 vs. Intel Ice Lake

#39

Post by stingraycharles »

wtallis wrote: post #4
svnpenn wrote: post #2

I saw this once before, and both times, it's pretty shocking. Is this really something that needs to be inside the CPU itself? I don't want my CPU doing this. I would rather just take the performance hit and keep the CPU "dumb".

Are you saying you don't want your CPU to have SIMD/vector capabilities, or you want it to have a limited SIMD instruction set without the extra flexibility that AVX-512 brings, or have you wildly misinterpreted the headline (twice?) to assume that AVX-512 adds special-purpose instructions for Unicode conversions?

I think the parent must not understand what SIMD/vector operations are, and probably thinks there is native Unicode support in the CPU. At least, that’s my most favorable interpretation of his critique.

Re: Transcoding Unicode with AVX-512: AMD Zen 4 vs. Intel Ice Lake

#40

Post by janwas »

snvzz wrote: post #33
chris6f wrote: post #13

Earlier quoted context omitted.

Vector length agnostic programming has its own share of problems. I'm not familiar with the RISC-V V extension, but I assume it's similar to ARM's SVE. There's a good critical look at SVE and VLA here: https://gist.github.com/zingaburga/805669eb891c820bd220418ee...

V extension and SVE2 are very different. Here is a quite recent introduction to RISC-V Vector[0]. 0. https://erikexplores.substack.com/p/grokking-risc-v-vector-p...

I'm curious why you say they are very different? From where I sit, RVV also supports mask-like predication, and adds two concepts: LMUL (in-HW unrolling of each instruction) plus the ability to limit operations to a given number of elements.

The former is nifty, though intended for single-issue machines, and the latter seems redundant because masks can also do that.

Post reply on HN