VAES support

[nazar-pc]

Vectorized AES can process more than one block at a time, greatly improving throughput, but it doesn't appear to be used by aes crate yet, which is unfortunate.

[tarcieri]

Note that AES-NI can already process more than one block-at-a-time by leveraging Instruction Level Parallelism (ILP).

We have separate benchmarks for serial aes*_block vs aes*_blocks where you can see the performance difference.

That said, it would probably be good to add VAES support for microarchitectures where it does provide performance benefits beyond what's possible with ILP.

[nazar-pc]

Absolutely, I am aware of that. Already using *_block and there is a difference indeed.

Those methods are the reason I looked inside wondering if it is also VAES-capable on top of instruction parallelism.

[newpavlov]

Unfortunately, currently I do not have access to a machine with AVX-512 so can not work on it myself.

If someone will work on this, it also could be worthwhile to also add support of VPCLMULQDQ to the polyvalcrate.

[nazar-pc]

Shouldn't be difficult to get server VM with AVX512 support, I can help with that if you'd like.

[tarcieri]

@newpavlov polyval is/was written in a way that LLVM will already use VPCLMULQDQ when the target supports it: RustCrypto/universal-hashes#44

...though perhaps we could be explicit about it.

[tarcieri]

Also I have several servers with AVX-512 support I can test on.

[newpavlov]

@tarcieri
I think it should be a relatively straightforward implementation? You would need to play with number of 512-bit blocks processed in parallel, because VAES instructions may have a different latency/throughput ratio and compiler can use 32 registers instead of 16. I think an optimal number will be bigger than the 8 blocks used in the AES-NI backend. IIUC VAES does not have instructions for key expansion, so you can adapt the existing AES-NI-based code.

The only annoying part should be plumbing in the autodetection module, but we can leave it for later, since VAES support will be gated either way (the relevant intrinsics are Nightly-only right now).

I may draft a PR on this weekend or during next week, if you will not get to it before that.

polyval is/was written in a way that LLVM will already use VPCLMULQDQ when the target supports it:

I thought about using parallelism (VPCLMULQDQ can process four 128-bit blocks at once). But I forgot that GHASH/POLYVAL is inherently sequential, so we can not utilize it while processing one text...

[tarcieri]

@newpavlov I opened a separate issue for VPCLMULQDQ here, I think that should be (potentially) fairly easy: RustCrypto/universal-hashes#184

POLYVAL/GHASH can be broken down into a parallelizable portion and a sequential portion... there's an accumulation of the output that is inherently sequential, but multiplication of the inputs can be performed in parallel.