Nicolas George wrote:
> I made that benchmark in the first time to compare floating point arithmetic
> and 64 bits integer arithmetic, to select which one to use for a situation
> where both would be acceptable. At first, I just used "r += i * i", but I
> added the division to get a result that fits in 64 bits, and to be able to
> compare it to a trusted result. Adding it barely changed the timings at all.

You do realise that "unsigned" declares an "unsigned int", which will be 32
bit in both 32 and 64 bit modes of compilation? Thus, the only thing your
code as posted tests is how well the compiler handles the slowest operations
in there, which are the 32 bit integer division and the conversion of a 32
bit integer to a double. Neither of which tell you much about performance of
anything but those two specific operations, which are special cases in and
by themselves.

In fact, the integer division is slow due to the iterative algorithm (in
hardware!) needed to execute it. It would in fact be slower for most 64 bit
integers assuming the numbers you divide are sufficiently big (outside 32
bit range) because the time an integer division takes is not constant but
rather depends on the number of one- and zero-bits with any reasonable
processor released in the last three decades.

	Thorsten

Post a reply to this message