Live data from Hacker News

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

lemire.me

41–50 of 70 posts

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

#41
post #10

Earlier quoted context omitted.

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

thanks for that! so it sounds like, if i purchase a chip that supports avx512, and run an operating system and compiler that supports avx512, i can write "plain old c code" with a minimal amount of compiler arguments and compile that code on my machine (aka not just running someone else's binary). and then the full power of avx512 is right there waiting for me? :)

A compiler turning C(++) code into SIMD instructions is called "autovectorization". In my experience this works for simple loops such as dot products (even that requires special compiler flags to enable FMA and reorders), but unfortunately the wheels often fall off for more complex code. Also, I haven't seen the compiler generate the more exotic instructions.

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

#42

Earlier quoted context omitted.

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?

It would be simpler to use the portable intrinsics from github.com/google/highway (disclosure: I am the main author). You include a header, and use the same functions on all platforms; the library provides wrapper functions which boil down to the platform's intrinsics.

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

#43

Wonder if this piece by Linus about AVX512 is still relevant https://news.ycombinator.com/item?id=23809335

Before we consider the technical merits, let us note that Linus admits to "irrational hatred" and "bias" on this topic. It's also not clear to me how much experience he has developing and testing AVX-512.

As others mentioned, throttling is basically nonexistent on Icelake (and AMD Genoa). It can hurt on Xeon Silver (so let's not use those?) and if you only sporadically use SIMD instructions (again, don't do that).

I claim that just about any reasonable code which sustains SIMD instructions over several milliseconds would still be a net win even with throttling.

Un-nuanced concerns about throttling are outdated and unhelpful. Perhaps I'll write up a paper on this.

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

#44

Wonder if this piece by Linus about AVX512 is still relevant https://news.ycombinator.com/item?id=23809335

AVX-512 one major problem and a bunch of minor ones. The major problem is that most computers still don't have it. Intel tried to segment their lineup and only put AVX-512 in their high end server CPUs for the first 2 generations that had it, but as a result normal programmers didn't have access to it, compiler devs didn't have access to it, and users didn't have access to it. As a result, most compilers don't do a g…

Hopefully it's available in AMD CPUs from now on. I already got it with 7950X and I am looking forward to trying it out!

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

#45
post #23
post #12

Earlier quoted context omitted.

How much code is compiled with `-march=native` or function multiversioning? I would guess the percentage is relatively small, at least when it comes to distributed binaries. Compiler autovectorizers also aren't very good at producing fast AVX512 code, so most of the benefit would probably come from using optimized libraries like Intel's MKL or simdjson.

> How much code is compiled with `-march=native` Any installation of Gentoo is, presumably. (Otherwise, what's the point of compiling it all yourself?) More interestingly, possibly all OEM firmware-installed copies of ChromeOS are -march=native builds as well, given that ChromeOS is based off of a Gentoo upstream.

True. I have never gone down the Gentoo rabbit hole. Might be fun to try sometime, but I'd seriously doubt that the time spent compiling would be won back from better performance.

Clear Linux is probably a more practical alternative. I used it a couple years ago, and found that they had a lot of avx2 and avx512 versions of random libraries built, with the appropriate ones presumably being loaded based on the hardware.

Random glibc math function calls, for example, were much faster on Clear Linux than Arch or Fedora. But development of Clear seems to have stopped, libraries like llvm aren't being updated anymore so the toolchains are outdated. I'd wanted to avoid the blood and sweat of managing my own toolchains, and ironically being on bleeding edge distros (Arch,Fedora,etc) was the way to keep that to a minimum. Next time I reinstall an OS, I'll look at Clear again. Or maybe Guix or Nix. Or maybe use spack for package management on top of some other distro.

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

#46
post #43

Wonder if this piece by Linus about AVX512 is still relevant https://news.ycombinator.com/item?id=23809335

Before we consider the technical merits, let us note that Linus admits to "irrational hatred" and "bias" on this topic. It's also not clear to me how much experience he has developing and testing AVX-512. As others mentioned, throttling is basically nonexistent on Icelake (and AMD Genoa). It can hurt on Xeon Silver (so let's not use those?) and if you only sporadically use SIMD instructions (again, don't do that). I…

The hatred is probably not that "irrational". We live in an era where specialized hardware for specialized problems is required because new manufacturing processes may give us a (seemingly slowing down) increase of transistor budget but not really better switching frequencies. We will have units for matrix multiplication, video codecs, AI cores or full blown GPUs. All those units can only be fast in specialized hardware because of predictable memory access patterns and arranging memory/cache topology accordingly "solving" the problem of low switching frequency with high bandwidth. A general purpose CPU however should specialize on unpredictable memory access. This means AVX-512 is somewhat misplaced on a CPU and probably only exists because it served Intel to create nice numbers in irrelevant benchmarks.

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

#47
post #34
post #15

Earlier quoted context omitted.

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.

Until the Intel Sapphire Rapids server CPUs will be launched later this month, the Ice Lake/Tiger Lake/Rocket Lake microarchitecture is the best AVX-512 implementation available from Intel, after 15 years since this ISA has been publicly disclosed.

Those differ only in the clock frequency and in a few details that are irrelevant for this particular benchmark.

So the comparison normalized by clock frequency, as done here, is legit, no other better comparison is possible for now.

Even if someone had a Sapphire Rapids sample, they would not be allowed to publish any benchmark yet.

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

#48
> However, we have two popular Unicode formats: UTF-8 and UTF-16

The fact we are still using UTF-16 still irks me to this day. UTF-16 (which is actually two different encodings, not one, hence the need for a BOM) is basically a way to salvage all those platforms that hurried on the UCS-2 (aka, the original "UNICODE") bandwagon in the '90s hoping that by just doing s/char/wchar_t/g all their internationalization problems would be solved.

It did not go well, to say the least. UTF-16 and 32 are objectively worse than UTF-8, because they still are multibyte encodings, you still have to do normalization, ... while also having to deal with "char16_t" and the likes (I will not enter into the whole "TCHAR" fiasco).

Spoiler alert, the world is still full of allegedly "UTF-16 compliant" platforms out there are not, indeed, UTF-16 compliant, they just use 16 bit chars and hope for the best.

The whole idea "1 char = 1 character" is arguably a terrible idea in Unicode, though. You not only can have multibyte characters, but you can also have multirune characters, where multiple codepoints are normalized into a single displayed character (just think about ` + e = è). It's a mess and it's bound to be broken, and there's no real way to "fix that up" - ASCII's assumption of "1 value = 1 char" was the broken concept here, and it unfortunately flawed how every developer (me included) thinks about strings. Sigh.

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

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

512bits is 64 bytes, a cache line on x86_64.

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

#50

Wonder if this piece by Linus about AVX512 is still relevant https://news.ycombinator.com/item?id=23809335

AVX-512 one major problem and a bunch of minor ones. The major problem is that most computers still don't have it. Intel tried to segment their lineup and only put AVX-512 in their high end server CPUs for the first 2 generations that had it, but as a result normal programmers didn't have access to it, compiler devs didn't have access to it, and users didn't have access to it. As a result, most compilers don't do a g…

Eh, intel, reminds me how they arbitrarily fused virtualization on like half of desktop CPUs.

But hey this time it literally gave AMD time to catch up...

Post reply on HN