Investigate disappointing ARM64 results

[baentsch]

https://openquantumsafe.org/benchmarking/visualization/speed_kem.html doesn't show marked performance improvements for aarch64 Kyber as should be visible due to open-quantum-safe/liboqs#1117 now being part of profiling image -> config options not properly set?

@Martyrshot: What performance changes would you expect based on your local tests?

[baentsch]

One key reason found: The profiling images only contain gcc-8 which disables the ARM64 code -> Need to upgrade the ARM64 Dockerfile and the required ci-images

[baentsch]

When looking at a more recent run (log & visualization (filtering "All" dates, "aarch64" , "Kyber", "NIST L1", for example)), one can now see the good performance increase due to open-quantum-safe/liboqs#1117.

I still don't understand why

• the "90s"/AES versions didn't really budge -- actually are much slower than the "plain" versions... Is the ARM64 AES so bad?
• the worst performance figures are shown when the CPU config indicates "AES SHA2 NEON" active, best performance if only "NEON" active (??)

Tagging @dstebila @bhess @Martyrshot for insights.

[bhess]

The last time I used ARM aes instructions the performance was far better than with software implementations, so I assume one should see a speedup.

Would it make sense to add a benchmark for common crypto to be able to better explain the impact of their performance?

[bhess]

• the "90s"/AES versions didn't really budge -- actually are much slower than the "plain" versions... Is the ARM64 AES so bad?

As far as I can see there are no ARM-optimized "90s" available from pqclean, which explains why it falls back to the slower reference implementation.