4
$\begingroup$

I am trying to measure the cycles per byte for $\mathop{SHA-3}$ reference implementation. I am using recommendations from Microsoft querying the performance counter. As you can see in the first snippet, cycles are measured before converting into microseconds. My code looks like the following: 

QueryPerformanceCounter(&StartingTime);
SHA3_256(K_OUT, K_IN, length);
QueryPerformanceCounter(&EndingTime);

ElapsedMicroseconds.QuadPart = EndingTime.QuadPart - StartingTime.QuadPart;
printf("Elapsed ticks: %.20f \n", ElapsedMicroseconds.QuadPart / (float)(length));

But the results are definitively wrong. It is mostly something smaller than $0.9$. I would guess a value around $30$ Cycles per Byte. What am I doing wrong?

|improve this question
$\endgroup$
  • $\begingroup$ This is borderline Off Topic (implementations details). I tried to edit it to make it inside the crypto.se scope. If you feel like it doesn't reflect what you want to ask, feel free to revert. $\endgroup$ – Biv Oct 30 '16 at 11:50
  • $\begingroup$ Also note that QueryPerformanceFrequency(&Frequency); is useless in your case. $\endgroup$ – Biv Oct 30 '16 at 11:52
8
$\begingroup$

To perform a good check, please use a large number of iterations (i.e. a for loop) of calls to the cryptographic primitive with your specific data size. Then average these out.

To avoid compiler optimizations, be sure to print out the result after the clock has been stopped. For instance, you could XOR all the outputs together and print that out. Otherwise the compiler may determine that your call has no side effects and simply remove the entire call to SHA-3.

Note that internal operations are usually performed on 64-bit or larger registers, i.e. 8 bytes at a time. It is perfectly possible to have sub-one scores - although I admit that for SHA-3 the value of 0.9 cycle/byte does not seem likely.

|improve this answer
$\endgroup$
  • 1
    $\begingroup$ Don't just dodge the compiler optimizer. It's telling you something important- your test case is too trivial and doesn't reflect real-world usage. You may get a number this way, but it's not going to be useful. $\endgroup$ – Puppy Oct 30 '16 at 16:05
  • 1
    $\begingroup$ @Puppy Too trivial or useful for who? Why is this comment below the answer instead of the question? Are you saying that it isn't useful to test cryptographic primitives, ever? $\endgroup$ – Maarten Bodewes♦ Oct 30 '16 at 16:12
  • 2
    $\begingroup$ I guess that testing the primitive in a cryptosystem of some kind is indeed more useful, if that's the goal. I guess above is useful when comparing different implementations of SHA-3 (or indeed other hash algorithms). In that case I don't see too much wrong with it, even with the trick of avoiding the compiler issue. Unfortunately I can only work with what was in the question and I think it's a bridge too far to call testing just the primitive "too trivial". $\endgroup$ – Maarten Bodewes♦ Oct 30 '16 at 17:01
  • 1
    $\begingroup$ @EllaRose: I also would like a good answer to the original question "How to measure Cycles per Byte of an Algorithm?". For my own benefit (and the benefit of others who obviously don't know the valid way of doing it), please post an answer briefly describing a valid test and perhaps linking to an example of how "everyone else tests". $\endgroup$ – David Cary Oct 30 '16 at 17:42
  • 3
    $\begingroup$ @DavidCary There are actually a few answers related to the subject here on crypto.se already. Here's a few of them: Calculating cycles per byte, What does a cycle mean in cryptography benchmarks, How to calculate cycles per byte, Ideal way to profile/performance-measure cipher implementations. Theres also eBACS and Crypto++ benchmarks $\endgroup$ – Ella Rose♦ Oct 30 '16 at 18:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.