Found a bug in the article. Maximum for signed bytes is +127, not +128. Minimum is correct, it's -128.
You can always tell when someone counts on their fingers.
Why those particular integer multiplies?
21–30 of 39 posts
Re: Why those particular integer multiplies?
#22It's a shame that SIMD is still a dark art. I've looked at writing a few simple algorithms with it but have to do it in my own time as it'll be difficult to justify it with my employer. I do know that gcc is generally terrible at auto-vectorising code, clang is much better but far from perfect. Using intrinsics directly will just lead to code that's unmaintainable by others not versed in the dark art. Even wrappers over intrinsics don't help much here. I feel there's a lot of efficiency being left on the table because these instructions aren't being used more.
Re: Why those particular integer multiplies?
#23How can software run on different CPUs when they support different operations? When you download "debian-live-12.7.0-amd64-kde.iso", all the programs in the repos support all current Intel and AMD CPUs, right? Do they just target the lowest common denominator of operations? Or do they somehow adapt to the operations supported by the user's CPU? Do dynamic languages (Javascript, Python, PHP...) get a speed boost becau…
> the lowest common denominator of operations?
Note that in recent years the chosen LCD for some distros has changed - they're starting to target the v2 feature set rather than the original.
See https://developers.redhat.com/blog/2021/01/05/building-red-h...
> Do dynamic languages (Javascript, Python, PHP...) get a speed boost because they can compile just in time and use all the features of the user's CPU?
Dynamically-typed languages can't benefit from this at all (they may include a C library that uses runtime dispatch though). Statically-typed JIT'ed languages like Java can (and you see occasional "look, Java is faster than C" benchmarks citing this), but only if you avoid classes and use only arrays. C# can do better than Java but still suffers from its Windows-centric history.
Re: Why those particular integer multiplies?
#24It's a shame that SIMD is still a dark art. I've looked at writing a few simple algorithms with it but have to do it in my own time as it'll be difficult to justify it with my employer. I do know that gcc is generally terrible at auto-vectorising code, clang is much better but far from perfect. Using intrinsics directly will just lead to code that's unmaintainable by others not versed in the dark art. Even wrappers o…
The problem is that the different SIMD instruction sets are genuinely... different. The basics of “8-bit unsigned add” and similar are possible to abstract over, but for a lot of cases, you may have to switch your entire algorithm around between different CPUs to get reasonable performance (or even gain over the scalar code at all). There's no way a compiler or SIMD abstraction library will do that for you.
Re: Why those particular integer multiplies?
#25Re: Why those particular integer multiplies?
#26Found a bug in the article. Maximum for signed bytes is +127, not +128. Minimum is correct, it's -128.
BTW, this asymmetry makes unary negation in C an unexpected source of Undefined Behavior.
Re: Why those particular integer multiplies?
#27How can software run on different CPUs when they support different operations? When you download "debian-live-12.7.0-amd64-kde.iso", all the programs in the repos support all current Intel and AMD CPUs, right? Do they just target the lowest common denominator of operations? Or do they somehow adapt to the operations supported by the user's CPU? Do dynamic languages (Javascript, Python, PHP...) get a speed boost becau…
I recently implemented a runtime for `__builtin_cpu_init()`, `__builtin_cpu_supports()`, and `__builtin_cpu_is()` for x86-64. Using these compiler intrinsics, or a higher level feature such as `[[gnu::cpu_dispatch]]`, you can write functions that behave differently on different CPUs. Fortunately the implementation isn't terribly complex. On x86, it's based around a neat `cpuid` instruction, and other ISAs have similar features.
https://github.com/Cons-Cat/libCat/blob/main/src%2Flibraries...
Re: Why those particular integer multiplies?
#28How can software run on different CPUs when they support different operations? When you download "debian-live-12.7.0-amd64-kde.iso", all the programs in the repos support all current Intel and AMD CPUs, right? Do they just target the lowest common denominator of operations? Or do they somehow adapt to the operations supported by the user's CPU? Do dynamic languages (Javascript, Python, PHP...) get a speed boost becau…
Just to add, Debian has a nice alternatives system that can tailor the correct version of libraries for your specific system. What happens for a few performance sensitive ones.
But yeah, it's mostly code compiled to the lowest common spec, and a bit of code with dynamic dispatching.
Re: Why those particular integer multiplies?
#29I suspect Intel uses 32x32b multipliers instead of his theorised 16x16b, just that it only has one every second lane. It lines up more closely with VPMULLQ, and it seems odd that PMULUDQ would be one uOp vs PMULLD's two. PMULLD is probably just doing 2x PMULUDQ and discarding the high bits. (I tried commenting on his blog but it's awaiting moderation - I don't know if that's ever checked, or just sits in the queue fo…
Makes sense to me. I have some code that uses a lot of mullo, so I get to pay twice the latency compared to if I wanted full multiplies...
Re: Why those particular integer multiplies?
#30How can software run on different CPUs when they support different operations? When you download "debian-live-12.7.0-amd64-kde.iso", all the programs in the repos support all current Intel and AMD CPUs, right? Do they just target the lowest common denominator of operations? Or do they somehow adapt to the operations supported by the user's CPU? Do dynamic languages (Javascript, Python, PHP...) get a speed boost becau…
Others gave you the general answer, but in OPs line of work they just manually rewrite and tune all of the core algorithms a dozen times for different CPU architectures and dispatch to the most suitable one at runtime. I don't have a link to hand but IIRC they go a step beyond dispatching based on CPU features, and dispatch different code paths for CPUs with the same features but significantly different instruction c…
A recent example of "feature detection vs specific cpus with different costs for the same features" thing is pext on zen2. It's implemented in microcode and the implementation is so slow that we'd honestly be better off if the chips reported that they did not have the feature.