Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Sometimes, websites and scientific papers that introduce and/or handle cryptographic algorithms also provide speed-analysis and tables comparing the individual performance of cryptographic implementations. I would like to do the same, but I'm not sure how to calculate the “cycles”.

I have this data:

  • processor clock frequency: 2,1 ghz
  • message length: 16 byte
  • Speed: 4,3 Mbytes/s

How can I calculate “cycles” and “cycles per byte” from that data?

share|improve this question
2  
Welcome to Crypto.SE! Please note that this question is off-topic, and in general the community expects someone to do some research before asking a question. –  rath May 18 '13 at 21:21
    
I'm voting to leave closed since whilst this is now a clear and well-worded question I think it's still off-topic for this site: its about measuring computational speed, albeit the speed of a cryptographic algorithm. –  figlesquidge Mar 25 at 10:59
add comment

closed as off topic by Hendrik Brummermann May 19 '13 at 8:32

Questions on Cryptography Stack Exchange are expected to relate to cryptography within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

1 Answer

up vote 2 down vote accepted

$\displaystyle \text{cycles per byte} = \frac{\text{cycles per second}}{\text{bytes per second}} = \frac{2.1 ~ \text{GHz}}{4.3 ~ \text{MiB}} = \frac{2.1 \times 10^9}{4.3 \times 1024^2} \approx 466 ~ \text{cpb}$


Of course this may be way off because processors are complex beasts these days, and may not work at their full potential all the time, and the calculations may very well be reordered, optimized, or vectorized.

So it's a little better than raw speed in that it is not dependent of processor clock speed but it is still quite dependent on the underlying hardware details. It is a decent measure of cryptographic performance.

share|improve this answer
    
thanks for the reply, I do not understand why data i see are very different ... for example this report fastcrypto.org/umac/2004/perf04.html cycles per byte are much less, why? –  Luca Del Giudice May 18 '13 at 17:56
    
@LucaDelGiudice Maybe the algorithm you are using has not been optimized during compilation, which would explain the slow speeds you see. But without additional details it's hard to tell. –  Thomas May 18 '13 at 18:40
1  
@Thomas captain to the resque! –  Smit Johnth May 18 '13 at 18:49
1  
@LucaDelGiudice Just noticed the "hash" tag. If you are measuring the performance of a hash function, you want to use messages longer than 16 bytes, otherwise most of the time will be spend doing initialization/finalization work (which do take up a lot of clock cycles for most hash functions). Try a 32MB buffer, you should see better results. –  Thomas May 19 '13 at 7:34
add comment

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