Paul <
peps...@gmail.com> wrote:
> My aim is to compare times of various popcount algorithms.
> This raises another problem in that the times fluctuate wildly
> between runs.
This is not something that's trivial to measure, because it depends a
bit on what exactly you want to measure. For example, it's difficult
to measure exactly how fast it is to count the number of 1-bits in
a 32-bit unsigned integer (although if you can use inline asm,
many/most CPU architectures have a way to count the exact clock
cycle count, which would be the best possible way, but it's not
something trivial to implement).
On the other hand, if you want to measure how fast the algorithm
can count the number of 1-bits in a bitset of 10 billion bits,
that's much easier to measure, but that task is quite different
and tells little about how fast the algorithm is for that previous
case. (In this case you would be traversing a huge array, and thus
constantly running into cache misses, which slow down the process,
adding thus time overhead that's unrelated to the popcount algorithm
itself into the mix.)
However, if what you are doing is measuring if algorithm A is
faster than algorithm B, then you could do something more like
the second option. Have like an array of a million bits, and
calculate in a loop its number of 1-bits several times, so that
the total time spent is in the order of several seconds, and
then compare the times. (Make sure that the compiler isn't doing
some overly smart optimizations that bypass the subsequent loops
or something, or bypassing the whole thing because it sees that
the result isn't used for anything. One way to ensure this last
thing is to print the result, for example, even if you aren't
interested in what the actual value is.)