21–30 of 36 posts
Isn't this the kind of thing that was missing from the "go on different platforms" benchmark a little while back. The intel platform has crazy optimization for encryption algorithms on Inteil, while ARM was severely lacking.
One thing to note is that the benchmark is running on a Skylake Platinum chip which has two AVX512 FMAs. You need a Gold 6000 series and above to see any benefit from AVX512. In most other cases the CPU throttles down some insane amount and there’s no to little benefit.
Earlier quoted context omitted.
Not without tying Go to one architecture, no. When C programmers write inline assembly, they don't pretend it's C code.
Go has it's own form of assembly which it compiles to multiple architectures.
A recent blog post by Vlad Krasnov, author of a bunch of the crypto assembly code in openssl and in golang, about frequency scaling when using AVX-512 making it not worth it: https://blog.cloudflare.com/on-the-dangers-of-intels-frequen... He doesn't like the title of the OP and provided links: > Very misleading title. Could just as well name it "accelerate sha256 up to 134x". You need to compare apples to apples. If…
Most of the Gold and Platinum series chips don't start frequency scaling down below baseline until around half the cores are using AVX512. The fanciest Platinum chips can use it on all cores with the only limit being that you can't Turbo quite as much: https://en.wikichip.org/wiki/intel/xeon_platinum/8180m
Without that capability, cloud providers wouldn't be able to offer multitenant VMs with access to the new instructions
A recent blog post by Vlad Krasnov, author of a bunch of the crypto assembly code in openssl and in golang, about frequency scaling when using AVX-512 making it not worth it: https://blog.cloudflare.com/on-the-dangers-of-intels-frequen... He doesn't like the title of the OP and provided links: > Very misleading title. Could just as well name it "accelerate sha256 up to 134x". You need to compare apples to apples. If…
He's using the "cheap" Xeon Silver chips that clock down all cores immediately and aggressively when any are using AVX-512 Most of the Gold and Platinum series chips don't start frequency scaling down below baseline until around half the cores are using AVX512. The fanciest Platinum chips can use it on all cores with the only limit being that you can't Turbo quite as much: https://en.wikichip.org/wiki/intel/xeon_plat…
One thing to note is that the benchmark is running on a Skylake Platinum chip which has two AVX512 FMAs. You need a Gold 6000 series and above to see any benefit from AVX512. In most other cases the CPU throttles down some insane amount and there’s no to little benefit.
Earlier quoted context omitted.
He's using the "cheap" Xeon Silver chips that clock down all cores immediately and aggressively when any are using AVX-512 Most of the Gold and Platinum series chips don't start frequency scaling down below baseline until around half the cores are using AVX512. The fanciest Platinum chips can use it on all cores with the only limit being that you can't Turbo quite as much: https://en.wikichip.org/wiki/intel/xeon_plat…
Can't turbo as much is still a net loss of performance. Even on Platinum turbo frequency is almost 10% lower with AVX512 on single core, and 30% lower with all cores. So you really want the majority of your software to use AVX512 to gain net benefit. It takes the system 2ms to recover after an AVX512 instruction. But you are correct that the Silvers are way worse. I suspect Intel intentionally killed AVX512 performan…
> The sad thing is there is no CPUID flag to distinguish good AVX512 from useless AVX512.
You can read the the avx512_2ndFMA bit from the PIROM, according to this Intel datasheet: https://www.intel.com/content/www/us/en/processors/xeon/scal...
Linux doesn't implement reading PIROM over SMBus, but it sure would be nice to expose this flag in /proc/cpuinfo.
In WireGuard we're at the moment just disabling the zmm AVX512F implementation on Skylake-X, falling back to the still-fast-but-not-as-fast AVX512VL implementation that only touches ymm and doesn't downclock as much (following OpenSSL's reasoning on +/- Andy Polyakov's same implementation):
https://git.zx2c4.com/WireGuard/tree/src/crypto/chacha20poly...
I may look into trying to read the PIROM so that I can make a more informed decision. I've tested those Platinum boxes, and indeed it's a lot faster there, even with the [lesser] downclocking, whereas a Gold box didn't perform as well, making the ymm-only implementation necessary.
Earlier quoted context omitted.
Can't turbo as much is still a net loss of performance. Even on Platinum turbo frequency is almost 10% lower with AVX512 on single core, and 30% lower with all cores. So you really want the majority of your software to use AVX512 to gain net benefit. It takes the system 2ms to recover after an AVX512 instruction. But you are correct that the Silvers are way worse. I suspect Intel intentionally killed AVX512 performan…
Of interest regarding this might be: https://twitter.com/InstLatX64/status/934093081514831872 > The sad thing is there is no CPUID flag to distinguish good AVX512 from useless AVX512. You can read the the avx512_2ndFMA bit from the PIROM, according to this Intel datasheet: https://www.intel.com/content/www/us/en/processors/xeon/scal... Linux doesn't implement reading PIROM over SMBus, but it sure would be nice to exp…
Earlier quoted context omitted.
Not without tying Go to one architecture, no. When C programmers write inline assembly, they don't pretend it's C code.
Not without tying Go to one architecture, no. Not trying hard enough to prove the null hypothesis. If you're going full pedantic mode, why stop at one ISA? Just throw in the most relevant dozen. (Heck, I even spelled that out!)