Thanks for pointing this out. He has his own set of candidate submissions to the NIST post quantum competition, so throwing shade at other candidates makes a bit more sense now.
I've done some analysis on one of his candidates and it was by far the slowest on cores which do not feature wide vector operations. My opinion is that you shouldn't just optimise for Intel (as many submissions do) for all the obvious reasons.
Edit:
A quote from the slides by Nigel Smart which Bernstein criticises - "[We] Would caution NIST against putting too much emphasis on academic measures of performance of algorithms for this reason"
This is all rather disingenuous (the bit on anti-vector campaigners, which is probably the point of the entire blog post).
> Do they seriously believe that Intel and AMD and ARM have all screwed up by supporting vectorization?
The benefit of vectorization of course depends on the total workload. In a web/application server where e.g. 5% of resources is spent on encryption and 95% on other things like networking it could very well be that enabling vectorization and thus having lower clock speeds results in decreased performance.
> You might run into an anti-vectors campaigner who wants to take this freedom away
I really don't see much campaigning in the slides, that merely say:
> We do not give a machine code implementation using SSE etc
> – We (and others) have found that using these extensions causes overall performance of cryptographic systems to slow down
> – Just looking at run times of algorithms on their own is not a good measure of overall performance in the wild
> – Would caution NIST against putting too much emphasis on
academic measures of performance of algorithms for this reason
I don't see any indication they're against the option of vectorization, but merely warn that systems performance is going to be what matters, and not just the algorithm.
Does the clock speed permanently reduce as soon as you use a vector instruction? I would have thought that the clock speed goes back up once the temperature has gone down.
It isn't about temperature directly. Recent Intel CPUs instantly incur a noticeable penalty as soon as certain 256 bit or wider instructions are encountered. It doesn't matter if it's only a single instruction, you pay the penalty before anybody notices the temperature.
After some fraction of a second it does revert to normal, if you haven't used any such instructions again.
> Does the clock speed permanently reduce as soon as you use a vector instruction? I would have thought that the clock speed goes back up once the temperature has gone down.
It's not about temperature, some instructions lower the clock speed as soon as they're processed, and for about 1 millisecond, by design. CPUs from a few years ago do it for all the cores in the socket, more modern ones only for the affected core IIRC.
1ms is a lot of time, your core just needs to be processing 1000QPS to have a permanently degraded system.
The issue is that the AVX circuitry is actually powered down when not in use to save power and run cooler, so as soon as an instruction is used, the CPU starts to power up the circuits but this takes ~70 microseconds (and this reduces the base clock of the chip pretty much immediately), and after ~700 microseconds of not using the instructions it powers down the circuits again.
So if you know you have a batch of milliseconds (or more) of intensive work to do (eg crypto, rendering), it may be worth it. But I work on a maths library and while I have written SSE2 and AVX vectorised version of key routines, calling the AVX ones is for us generally a net slowdown as it slows down all the logic that occurs around those routines (eg most of our matrix operations are around 20x20 to 200x200 size... these are worth speeding up when we do lots of them, but we rarely do "batches")
11 comments
[ 0.20 ms ] story [ 35.6 ms ] threadI've done some analysis on one of his candidates and it was by far the slowest on cores which do not feature wide vector operations. My opinion is that you shouldn't just optimise for Intel (as many submissions do) for all the obvious reasons.
Edit: A quote from the slides by Nigel Smart which Bernstein criticises - "[We] Would caution NIST against putting too much emphasis on academic measures of performance of algorithms for this reason"
- I couldn't agree more.
> Do they seriously believe that Intel and AMD and ARM have all screwed up by supporting vectorization?
The benefit of vectorization of course depends on the total workload. In a web/application server where e.g. 5% of resources is spent on encryption and 95% on other things like networking it could very well be that enabling vectorization and thus having lower clock speeds results in decreased performance.
> You might run into an anti-vectors campaigner who wants to take this freedom away
I really don't see much campaigning in the slides, that merely say:
> We do not give a machine code implementation using SSE etc
> – We (and others) have found that using these extensions causes overall performance of cryptographic systems to slow down
> – Just looking at run times of algorithms on their own is not a good measure of overall performance in the wild
> – Would caution NIST against putting too much emphasis on academic measures of performance of algorithms for this reason
I don't see any indication they're against the option of vectorization, but merely warn that systems performance is going to be what matters, and not just the algorithm.
After some fraction of a second it does revert to normal, if you haven't used any such instructions again.
It's not about temperature, some instructions lower the clock speed as soon as they're processed, and for about 1 millisecond, by design. CPUs from a few years ago do it for all the cores in the socket, more modern ones only for the affected core IIRC.
1ms is a lot of time, your core just needs to be processing 1000QPS to have a permanently degraded system.
https://stackoverflow.com/questions/35663635/why-do-processo...
The issue is that the AVX circuitry is actually powered down when not in use to save power and run cooler, so as soon as an instruction is used, the CPU starts to power up the circuits but this takes ~70 microseconds (and this reduces the base clock of the chip pretty much immediately), and after ~700 microseconds of not using the instructions it powers down the circuits again.
So if you know you have a batch of milliseconds (or more) of intensive work to do (eg crypto, rendering), it may be worth it. But I work on a maths library and while I have written SSE2 and AVX vectorised version of key routines, calling the AVX ones is for us generally a net slowdown as it slows down all the logic that occurs around those routines (eg most of our matrix operations are around 20x20 to 200x200 size... these are worth speeding up when we do lots of them, but we rarely do "batches")
Which freedom? If you are writing the code, you can do whatever you want.