Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
Cycles per byte seems to be a critical concern in designing and choosing stream ciphers. For example, from Wikipedia, RC4 has 7 cycles/byte on original Pentium chips.
How is this calculated? Do they just time the encryption of multiple megabytes and then divide by the CPU's clock speed? Do they look at the assembly code and lookup cycle per instruction in some table, figuring in pipelining, branch prediction, etc.?
Predicting speed by looking at the assembly is hard, especially since processors do all sorts of tricks which have memory (e.g. branch prediction). So yes, this is all about measuring.
There is an art to it; for instance, you would rather repeatedly encrypt the same relatively small buffer (4 or 8 kB) so as to avoid cache effects. One method is to do the repeated encryption sufficiently many times so as to smooth out random effects like IRQ due to external activity (e.g. you adjust the loop count so that the running time is at least 5 seconds). Another is to use the platform cycle counter to get precise measures. Either way, you need to do a bit of "warm-up" to ensure that the code is all in L1 cache and that the branch prediction has reached its permanent state; this is especially important when benchmarking an implementation for a virtual machine subject to JIT compilation (e.g. a Java or .NET implementation).
See sphlib for an example on how it is done on hash functions, with the "repeated processing" method. eBACS is a huge benchmarking effort which prefers to use cycle counters.
They measure it.
Once upon a time, CPUs were simple enough that you really code compute the amount of time for a stretch of code by looking up the clocks per instruction in the manual, add them all together, and that'd be the total time.
However, CPU manufacturers have added more and more optimizations and parallelism; this makes the CPUs run faster (for example; using memory caches, executing instructions in a pipeline, executing instructions out of order), however it becomes increasingly difficult for someone to look at some code and generate an estimate.
So, instead of trying to deal with the complexity, we just measure it.
