Live data from Hacker News

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

lemire.me

61–70 of 70 posts

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

#61

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

>The fact we are still using UTF-16 still irks me to this day.

Windows, unfortunately.

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

#62

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?

Well, there is SIMD proposal for C++23 with kind-of-reference implementation. But I don't know how well it works for AVX0512

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

#63

Earlier quoted context omitted.

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?

Well, there is SIMD proposal for C++23 with kind-of-reference implementation. But I don't know how well it works for AVX0512

From what I have seen, this is unfortunately not very useful: it mainly only includes operations that the compiler is often able to autovectorize anyway (simple arithmetic). Support for anything more interesting such as swizzles seems nonexistent. Also, last I checked, this was only available on GCC 11+; has that changed?

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

#64
post #46
post #43

Earlier quoted context omitted.

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

The hatred is specifically directed at "FP" which I understand to be floating-point. Makes sense inside an OS kernel but a large majority of HPC would indeed consider this irrational.

I understand that dark silicon is helpful, but am not so sure that fixed-function HW is the way to go. Perhaps video _de_coding is the most convincing from your list; codec generations are 5+ years, so enough time to benefit from HW. Encoding, on the other hand, tends not to be impressive unless perhaps there is also a software component.

For the rest, programmability and deployability (can we rely on it?) is a major issue. Software has often been the limiting factor.

Another big concern is the 'hardware lottery'. The algorithms we develop and get are selected for, and tuned to, the current hardware. Perhaps this gets us 5x energy efficiency vs CPU/SIMD. But by painting ourselves ever further into the corner of dense linear algebra, which is definitely not the way that nature implements intelligence, we are missing out on far larger opportunities. For example: spiking nets or memristors have the potential to be 2 or 3 orders of magnitude better. Or actual sparsity, not the fixed-pattern thing (now that is a prime example of an irrelevent benchmark, because AFAIK algorithms haven't yet been able to use them well).

> A general purpose CPU however should specialize on unpredictable memory access.

Should it really? I think rather we should avoid such accesses whenever possible, because their energy cost now dwarfs that of computation.

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

I have difficulty understanding how a reasonable person can come to such a conclusion. Lemire (the author linked here) has a long series of results showing nice speedups from AVX-512. I personally have seen gains in image compression, string processing, cryptography, linear algebra, integer coding, hash tables, databases, sorting, and compression.

[Opinions are my own.]

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

#65
post #64
post #46

Earlier quoted context omitted.

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

The hatred is specifically directed at "FP" which I understand to be floating-point. Makes sense inside an OS kernel but a large majority of HPC would indeed consider this irrational. I understand that dark silicon is helpful, but am not so sure that fixed-function HW is the way to go. Perhaps video _de_coding is the most convincing from your list; codec generations are 5+ years, so enough time to benefit from HW. En…

> I have difficulty understanding how a reasonable person can come to such a conclusion.

The applications are very niche. Compilers are usually not smart enough to utilize SIMD, it is a hit or miss. And in order to implement properly efficient SIMD algorithms you need experts that are rare. Furthermore many algorithms that work great with SIMD work even better as compute shader on your run of the mill cheap iGPU.

The application of this article is the best example how irrelevant SIMD really is: How many Terabytes of UTF8 are you converting to UTF16 per day? probably zero.

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

#66
post #34

Earlier quoted context omitted.

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.

Intel also decided to disable AVX-512 on their consumer CPUs going forward, presumably as long as their P+E core strategy remains in place.

Is there a source for a decision having been made for _all_ their consumer CPUs, not just ADL?

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

#67
post #65
post #64

Earlier quoted context omitted.

The hatred is specifically directed at "FP" which I understand to be floating-point. Makes sense inside an OS kernel but a large majority of HPC would indeed consider this irrational. I understand that dark silicon is helpful, but am not so sure that fixed-function HW is the way to go. Perhaps video _de_coding is the most convincing from your list; codec generations are 5+ years, so enough time to benefit from HW. En…

> I have difficulty understanding how a reasonable person can come to such a conclusion. The applications are very niche. Compilers are usually not smart enough to utilize SIMD, it is a hit or miss. And in order to implement properly efficient SIMD algorithms you need experts that are rare. Furthermore many algorithms that work great with SIMD work even better as compute shader on your run of the mill cheap iGPU. The…

What leads you to think the list of applications I enumerated is 'niche'?

> in order to implement properly efficient SIMD algorithms you need experts that are rare

Some truth to this, but many algorithms can be implemented once and then reused, like a standard library.

> many algorithms that work great with SIMD work even better as compute shader on your run of the mill cheap iGPU

Also agree to some extent, except that you'd have more concerns about availability, vendor lock-in, and performance portability.

> best example how irrelevant SIMD really is: How many Terabytes of UTF8 are you converting to UTF16 per day? probably zero.

First, how does one example of a SIMD-enabled algorithm show that SIMD itself is irrelevant? Second, have you considered that some databases store UTF-16 and want to convert it for interoperability (or vice versa)? IBM apparently has dedicated instructions for this. Would they have been added if there was no demand?

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

#68
post #54
post #53

Earlier quoted context omitted.

UCS-32 is at least directly indexable, even though it's ludicrously space-inefficient.

Only in codepoints, but it still has the problem GP mentions of ` + e = è being two codepoints (so two elements in UCS-32), but being logically one character https://manishearth.github.io/blog/2017/01/14/stop-ascribing...

This, it's pointless to have char32_t if you still need to pull several megabytes of ICU to normalize the string first in order to remove characters spanning over multiple codepoints. UTF32 is arguably dangerous because of this, it's yet another attempt to replicate ASCII but with Unicode. The only sane encoding out there is UTF-8, and that's it. If you have to always assume your string is not really splittable without a library, you won't do dangerous stuff such as assuming `wcslen(L"menù") == 4`.

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

#69
post #63

Earlier quoted context omitted.

Well, there is SIMD proposal for C++23 with kind-of-reference implementation. But I don't know how well it works for AVX0512

From what I have seen, this is unfortunately not very useful: it mainly only includes operations that the compiler is often able to autovectorize anyway (simple arithmetic). Support for anything more interesting such as swizzles seems nonexistent. Also, last I checked, this was only available on GCC 11+; has that changed?

I think proposed Vc lib is tested under clang as well.

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

#70
post #63

Earlier quoted context omitted.

From what I have seen, this is unfortunately not very useful: it mainly only includes operations that the compiler is often able to autovectorize anyway (simple arithmetic). Support for anything more interesting such as swizzles seems nonexistent. Also, last I checked, this was only available on GCC 11+; has that changed?

I think proposed Vc lib is tested under clang as well.

Here is my source: https://github.com/VcDevel/std-simd

Ah, but this repo mentions that the GCC 11 implementation apparently also works with clang: https://github.com/VcDevel/Vc. Thanks!

Post reply on HN