Live data from Hacker News

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

lemire.me

1–10 of 70 posts

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

#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 attempt to implement it and within which market sectors. And surely there's discussion to be had about the design tradeoffs to be made chasing after this nonsense.

But, no, performance parity with chips that are nearing end of life has to be viewed as table stakes here. It's certainly not "remarkable".

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

#4
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?

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

#6
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.

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.

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

#7
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".

> keep the CPU "dumb".

a 240+ entry reorder buffer has entered the chat.

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

#8
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.

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?

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

#9
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.

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.

I wonder to what extent compilers even emit avx512 instructions apart from the common ones (load, store, shuffle, arithmetic) in case you don’t want to manually optimize for sse / avx / avx2 / avx512.

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

#10

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?

Potentially both. Most compilers have vectorization optimizations if you compile for an architecture that supports it.

However, a lot of software is compiled on one machine to be run on potentially many possible architectures, so they target a very lowest common denominator arch like x86-64. This will have some SIMD instructions but (I don't think) AVX-512.

So if a developer wants to ensure those instructions are used if they're supported, they'll write two code paths. one path will explicitly call the avx512 instructions with compiler intrinsics and then the other path will just use the manual code and let the compiler decide how to turn it into x86-64 safe instructions.

Post reply on HN