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).
clock_gettime function? So still timestamping is the way to measure the number of cycles?
$\endgroup$
clock_gettime will wind up using RDTSC if that's the best way to measure elapsed time on the platform.
$\endgroup$
Commented
Oct 3, 2019 at 20:23