What makes it arcane is that if you use the scalar form of gettimeofday rather than the list form, no division is required. Just a floating point substraction.

Perhaps when the underlying POSIX call was defined it was necessary to avoiding floating point math in order to achieve microsecond accuracy because maybe double precision floating point wasn't commonly available--though I'd question whether the timers of that era were good enough to render precision to a single microsecond accuracy?

Suffice it to say, it's been a while since computers have not been able to do a floating point subtraction to 6-decimal digits of precision accurately.

I did apologise for having misunderstood your math, and I'll do so again. I was expecting to see your code divide the iterations by the iteration count--beacuse it allows direct comparision of the affect of different numbers of iterations. I saw the discrepancy between the iterations and divisor and suspected a problem. Looked at the precedence and saw a further discrepancy to the math I thought you should be doing. I was wrong and I again apologise for that.

Once I realised that you were not trying to calculate a per iteration value, the purpose of the math became clear--but I didn't arrive at that realisation until I saw your second post.

If you are going to critic my posting publicly, I think I deserve the curtesy of you at least analysing some simple arithmetic a bit more closely.

Forget not that I was responding to your (incorrect) critique of my post. Incorrect because in the end, your benchmark method shows the same results as mine.

Also, it would be hard for me to respond to your post privately, with you being anonymous an'all.