Closed baentsch closed 3 years ago
For item 1, I'd say the purpose is comparing algorithms, not comparing algorithm evolution. In fact many of the evolutions observed in our performance data are really consequences of us improving infrastructure, shared code, build options, etc. Useful for us to know that our changes are making things better, but not scientifically interesting.
For item 2, I'd lean towards "over a distribution of messages", but indeed it would be interesting to highlight algorithms with atypical dependency. It might be worth checking SUPERCOP's approach to message generation for signature benchmarking.
It might be worth checking SUPERCOP's approach to message generation for signature benchmarking.
SUPERCOP combines several variables in the signature benchmark: (1) message lengths up to 100000 bytes, (2) distinct message each time (randomly pre-generated for each iteration), (3) distinct key-pairs for each iteration. https://github.com/jedisct1/supercop/blob/master/crypto_sign/measure.c
We could use the same approach as SUPERCOP by default. For special additional tests, we could add command-line options to speed_sig
that allow to fix certain parameters.
We could use the same approach as SUPERCOP by default.
Silly question: What is missing in the SUPERCOP benchmarks? Or asked the other way: How can we avoid to replicate what's already been done? Do you have a link where they visualize their results? This is worse in terms of visualization than oqs-profiling's surely less-than-great visuals -- there must be something better for SUPERCOP. Also: Is there a way to compare across algorithms at one glance?
After this long silence, I tend to close this issue with the current code base without hearing what (else) we should do different. The purpose stated by @dstebila I think we fulfil. No response to my last question above further seems to indicate our visuals/comparison capabilities are better than SUPERCOPs, so I added a comment about that here. Please re-open if you see concrete things to change/amend.
Following up on discussions in https://github.com/open-quantum-safe/liboqs/pull/928 :
My personal initial attempt to answer:
Algorithm evolution may not be as interesting as a comparison across algorithms (and their variants) Runtime variations for any algorithm (or algorithm variant) with any kind of dependency would be interesting to highlight (possibly as a new set of tests and visualizations).