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? :)
Transcoding Unicode with AVX-512: AMD Zen 4 vs. Intel Ice Lake
41–50 of 70 posts
Re: Transcoding Unicode with AVX-512: AMD Zen 4 vs. Intel Ice Lake
#42Earlier 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?
Re: Transcoding Unicode with AVX-512: AMD Zen 4 vs. Intel Ice Lake
#43Wonder if this piece by Linus about AVX512 is still relevant https://news.ycombinator.com/item?id=23809335
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
#44Wonder 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…
Re: Transcoding Unicode with AVX-512: AMD Zen 4 vs. Intel Ice Lake
#45Earlier 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.
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
#46Wonder 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…
Re: Transcoding Unicode with AVX-512: AMD Zen 4 vs. Intel Ice Lake
#47Earlier 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.
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
#48The 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
#49AVX-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.
Re: Transcoding Unicode with AVX-512: AMD Zen 4 vs. Intel Ice Lake
#50Wonder 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…
But hey this time it literally gave AMD time to catch up...