4 ms·
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 Int
by y7 7y ago
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.
- rwmj 7y agoDoes 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.
- jzwinck 7y agoIt 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.
- ot 7y ago> 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.
- schmerg 7y agoTo backup what others have said with a little more detail, see my stackoverflow reply https://stackoverflow.com/questions/35663635/why-do-processors-with-only-avx-out-perform-avx2-processors-for-many-simd-algori/44353690#44353690 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")
- fluffything 7y ago> who wants to take this freedom away Which freedom? If you are writing the code, you can do whatever you want.