Memory consumption

[baentsch]

Looking at the latest runs, it seems liboqs improved significantly all memory consumption on x64 and aarch64 -- but not on m1.

e.g., for SIG-gens (heap usage):

e.g., for KEM-encaps (heap usage):

Only two algorithms don't show marked improvements: Frodo-1344-AES and HQC-256.

The change occurred between liboqs commits 179c95cf382bfcccb37e05d2801183f55f9a64e8 (0.8.0-dev) and 93e784725e3be0aaa2691a557456ff786155a7b2 (0.8.1-dev).

Does anyone have an idea why this is so? Worthwhile further investigation? @SWilson4 @dstebila ?

[SWilson4]

I'm not sure this makes the picture any clearer (if anything, it leaves me more confused), but it is interesting, and maybe it will give you some insight @baentsch:

This is the SIG heap usage for Dilithium3 (keygen) on aarch64...

... and this is the SIG heap usage for Dilithium3 (keygen) on m1.

In the latter picture, there are two lines: the upper line is Dilithium3-AES, and the lower line is Dilithium3-SHA. The memory consumption of Dilithium3-SHA on m1 is exactly the same as the new, lower number for Dilithium3 on aarch64. (The same is true for both sign and verify as well.) The older, higher number is close, but not identical to the Dilithium3-AES heap usage.

This leaves me with even more questions...

1. Why was m1 (and only m1) consistently collecting data for Dilithium3-AES throughout June? It seems like we purged that algorithm from liboqs on May 16: Remove remaining references to SPHINCS+-Haraka, Kyber 90s, Dilithium-AES liboqs#1465
2. Why would the aarch64 machine suddenly drop to exactly the same heap usage as the m1 machine had been reporting for the previous month?
3. Even if this points to an explanation for Dilithium (say, somehow accidentally running the AES version or mislabelling data), how does it translate to the other algorithms which exhibited similar behaviour at the same time?

[baentsch]

Why was m1 (and only m1) consistently collecting data for Dilithium3-AES throughout June?

This simply may be because the cronjob on m1 didn't properly pull the latest profiling image and kept running with old code.

Why would the aarch64 machine suddenly drop to exactly the same heap usage as the m1 machine had been reporting for the previous month?

That is weird indeed and warrants a closer look (best in the original results JSON files on S3 -- maybe there's something wrong in the "data collation" (?)

how does it translate to the other algorithms which exhibited similar behaviour at the same time?

No clue, I'm afraid. Maybe worthwhile "manually" going back to those commits, just building liboqs and equally "manually" checking KEM and SIG performance as output by speed_kem/sig -- bypassing all the shenanigans done in the profiling image?