# What does a “cycle” mean in cryptography benchmarks?

In this table of the "Crypto++ 5.6.0 Benchmarks", for example, cryptographic algorithm performance is measured in cycles per byte for symmetric ciphers, and in cycles per operation for asymmetric ciphers.

What does "cycle" here mean, exactly? And does one AES or RSA decryption always need the same amount of cycles, or can it be different every time? (If it's always the same number of cycles for a cipher, then the time needed to decrypt must always be the same for different ciphertexts.)

"Cycles" are CPU instruction cycles. Cycles per byte roughly measures how many instructions, in a given instruction set, are needed to produce each byte of output. They're a reasonably-good relative measure of the performance of different algorithms.

Generally, when you measure an algorithm's cycles per byte, you use carefully controlled conditions. You ensure the system isn't doing anything else, you ensure the code cache is populated, you try to avoid measuring memory speed, and so on.

Some ciphers are dependent on their data. To help control for this, you try to use a large data set and average it out.

You can't measure asymmetric ciphers this way, because they don't operate on bulk data. For them, it makes more sense to talk about cycles per operation, operations per second, or the like.

I noticed on that data set, they have a lower cycles per byte for SHA256 than SHA512. If they had used their CPU's 64-bit instruction set, the results would have been the other way around. So the results are heavily dependent on how the code is compiled (instruction set, optimizations, and so on).

• But how do you get the number of cycles? Is it like timestamping, where you take a timestamp, run the code, take a timestamp again, and the difference in timestamps give you the elapsed time of the code? How do you get the number of cycles for a piece of code? – xkcd Oct 2 '19 at 10:42
• @xkcd You used to have to do it that way, but modern CPUs actually provide instruction cycle counters. – David Schwartz Oct 2 '19 at 12:22
• Thanks for the Wikipedia link, it was very informative. But even in that article, it recommends using clock_gettime function? So still timestamping is the way to measure the number of cycles? – xkcd Oct 2 '19 at 17:04
• @xkcd Functions like clock_gettime will wind up using RDTSC if that's the best way to measure elapsed time on the platform. – David Schwartz Oct 3 '19 at 20:23