Hacker News Reader

Comment by magila | Hacker News Reader

One important aspect DJB ignores is power efficiency. ChaCha achieves its high speed by using the CPU's vector units, which consume huge amounts of power when running at peak load. Dedicated AES-GCM hardware can achieve the same performance at a fraction of the power consumption, which is an important consideration for both mobile and datacenter applications.

Gamers generally don't care about power consumption. When you've spent $1000 on the hardware an extra dollar or two on your electricity bill is no big deal.

View on HN

> CPU's vector units consume huge amounts of power when running at peak load. Dedicated AES-GCM hardware can achieve the same performance at a fraction of the power consumption

Citation needed. Where did you get that idea? Please show how djb's vector code spends more power vs the built-in AES "dedicated hardware" instruction when, as he measures:

"* Both ciphers are ~1.7 cycles/byte on Westmere (introduced 2010).

* Both ciphers are ~1.5 cycles/byte on Ivy Bridge (introduced 2012).

* Both ciphers are ~0.8 cycles/byte on Skylake (introduced 2015)."

"even though AES-192 has "hardware support", a smaller key, a smaller block size, and smaller data limits" (his code is 256 bits and 12 rounds).

The parts of the CPU that are not in use can be turned off, so making full use of the vector units can raise the temperature of the CPU a fair bit compared to less demanding code.

He's also comparing 12 rounds of ChaCha with 12-round AES, which may be fair, but realistically no one uses ChaCha12, they use ChaCha20.

AVX is so hot that Intel CPUs may have to clock down ~200 MHz when executing heavy AVX code to stay within their power/thermal limits. I have no idea if this hits DJB's code in reality.

http://www.intel.com/content/dam/www/public/us/en/documents/...

Thanks for the link, I can only find "when the processor detect AVX instruction additional voltage is applied, the processor can run hotter which can require the frequency to be reduced" but I don't see anywhere mentioned that the base frequency is 200 MHz. If you mean 200 MHz lower than TDP marked frequency, but processing twice as much data, it doesn't sound so bad, it's still 1.7 times more power efficient than the shorter instructions spending twice as much time at the marked TDP frequency. And I'd be surprised that AES is magically not needing serious processing too. Otherwise it would be already implemented to be much faster than it is now.

It really depends on your instruction mix. If only one in twenty instruction uses AVX, the rest of your instructions are running slower due to the lower clock and they aren't getting double the throughput. On top of that it could be some other thread using AVX, clocking down the entire core and harming the given thread that isn't using AVX.

Intel has done a lot of things to try to balance this. One of those things is they don't even bother turning half the vector unit on unless you use it a lot. If you seldom issue an op with 512-bit operands, the CPU will actually dispatch them as multiple 256-bit operations, in which case you won't incur the drop in clock, but you also don't get the supposed benefit of double throughput. Furthermore the performance may be much worse if the CPU decides to turn up the remaining vector bits, because the clock drops dramatically while those units are charging up.

So you can see that for someone trying to wring out every last bit of performance on a recent Intel CPU using all the advertised vector capabilities, optimization can become quite complicated.

AES uses the vector unit on Intel chips.

AES-NI uses the XMM register bank, but not necessarily any vector execution unit. Furthermore, it only uses the lower 128 bits of vector registers, whereas the linked document is referring to instructions that use the upper lanes as well, i.e. YMM or ZMM registers.

Reply on news.ycombinator.com