Measure time spent in SHA2, SHA3, and randombytes

[mkannwischer]

As in our recent paper, it would be nice to have some profiling information on how much time is spent in hashing and randombytes.
This should also give an intuition how the schemes sample randomness.

We implemented this by adding/subtracting the current cycle count to a global variable when entering/leaving the respective function. This should be done only for profiling, but not in the benchmarks since it can have a huge performance impact. It would be nice to port that to PQM4.

In case we want to use systick for this, then we will run into the problem that if the overflow occurs within one of the profiled functions the cycle counts are useless. In our paper experiments, we just detected this case and ran it several times until we had no overflow there - this won't work for SPHINCS.

[Ko-]

I don't really see why we couldn't account for that. We're already doing that for counting cycles in speed.c with systick, right? Every overflow triggers an interrupt and those are counted. Of course this logic has some overhead, but if it only happens every 2,400,000 cycles then that shouldn't be very significant.

There's also this approach to profiling applications with gprof. I looked into it at some point, but it's slightly more cumbersome. Definitely a downside is that it requires extra hardware, although I think we have that in the office. It's probably technically possible to do without, but that would require implementing some low-level I/O functions ourselves to make sure that gprof.out gets written to USART on exit.

[mkannwischer]

On Mon, Oct 22, 2018 at 03:10:41PM -0700, Ko- wrote: I don't really see why we couldn't account for that. We're already doing that for counting cycles in `speed.c` with `systick`, right? Every overflow triggers an interrupt and those are counted. Of course this logic has some overhead, but if it only happens every 2.400.000 cycles then that shouldn't be very significant.

You are absolutely right - we just need to check if there was an overflow at the end of each call.