No, because non-"FMA unit" (mostly SIMD FP) AVX2 instructions don't cause license-based downclocking on recent Intel CPUs.

To get downclocking to L1 license (the middle speed tier), you need to use either FMA unit AVX/AVX2 insructions or any AVX-512 instructions. This algo doesn't use any of this, staying in the integer domain.

Here's a longer description:

https://stackoverflow.com/a/56861355

Of course this doesn't address say power or temperature based throttling which might be more likely to occur when wide SIMD is used, but it's not possible to give a precise answer there, other than many low or moderate core count setups won't see this kind of throttling outside of extreme use cases.

I can't remember where I read this, but there was an argument somewhere that worrying about downclocking only really makes sense when the instruction set in question is new. (Which AVX-512 certainly is, to be fair.) Eventually, when the instruction set is more widely used, you'll probably already be paying the downclocking penalty anyway because of someone else's code, and you might as well go ahead and use the fancy instructions in your own code. Do you think that's valid?

(not op) Somewhat, although it's fairly minimal for avx2. The serious downclocking problem comes from avx512 instructions, which the author seems interested in:

> This algorithm should map fairly nicely to AVX-512, and should in fact be a bit faster than 2x the speed of AVX2 since a few instructions can be saved

In general, you aren't going to make a faster wheel without some trickery (vectorization usually). All the obvious optimizations have already been made in the stdlibs.

There's a really good comment on reddit on the subject:

https://www.reddit.com/r/rust/comments/dx6e0h/comment/f7o8av...

TL;DR; yes but not too much if your CPU is high-end and if the number of AVX instructions is low enough (and the slowdown is negligible in front of the gains if the number of instructions is high).