Benchmark results unrealistic?

[Hans Mull]

Hi!
I've created a benchmark tool which uses Agner Fog's asmlib to count the
clockcycles a function takes. I 'm using it to measure the
MersenneTwister.h speed.
Sourcecode is here:
http://code.google.com/p/multirng/so...s/benchmarks.h
(the main function just calls this functions)
When I run on a P4 Prescott (MinGW with GCC4, Win XP MediaCenter) with
-O3 -fexpensive-optimizations and Prescott-specific optimizations, it
shows me that e.g. mtr.rand() takes ~1200 clockcycles. I think this is
realistic.
But when I write something like

time[0] = ReadTSC();
for(int i = 0;i < NUMTESTS;i++) rand();
time[1] = ReadTSC();

and

cout << "rand() time:" << (time[1]-time[0])/NUMTESTS << endl;

it shows me that it (and the other functions too) takes only 20
clockcycles. Is this realistic? I think it's OK that when you call the
function it takes more clockcycles than in the average, but 20
clockcycles for creating a random number? However, even if I set
NUMTESTS to higher or lower values, the result remains the same (except
of a difference of about 3 or 4 clockcycles)

Thanks in advance, Hans

[James Kanze]

On Feb 11, 3:30 pm, Hans Mull <[e-mail]:

I've created a benchmark tool which uses Agner Fog's asmlib to count the
clockcycles a function takes. I 'm using it to measure the
MersenneTwister.h speed.
Sourcecode is here:http://code.google.com/p/multirng/so...enchmarks/benc...
(the main function just calls this functions)
When I run on a P4 Prescott (MinGW with GCC4, Win XP MediaCenter) with
-O3 -fexpensive-optimizations and Prescott-specific optimizations, it
shows me that e.g. mtr.rand() takes ~1200 clockcycles. I think this is
realistic.
But when I write something like

time[0] = ReadTSC();
for(int i = 0;i < NUMTESTS;i++) rand();
time[1] = ReadTSC();

and

cout << "rand() time:" << (time[1]-time[0])/NUMTESTS << endl;

it shows me that it (and the other functions too) takes only
20 clockcycles. Is this realistic? I think it's OK that when
you call the function it takes more clockcycles than in the
average, but 20 clockcycles for creating a random number?

That sounds a bit high for the usual implementations of rand(),
yes. But maybe your platform uses something better than the
usual implementations. Which aren't always that good, although
on a 64 bit machine, you can implement a reasonable good RGN
with only 2 cycles of computation. And of course, since it is a
function, you have the overhead of a function call in there. On
some machines, that can be several clock cycles in itself. Plus
the stores to memory, etc.

Of course, clock cycles don't really mean much on a modern
machine anyway. Most modern machines are capable of executing
several instructions in parallel, in a single clock, if there
are no dependencies, where as a rapid sequence of memory
accesses may lead to the memory pipeline staturating, and
several clocks in which no instructions can be executed. The
time it takes to execute rand() in a loop like this is probably
not typical of the time it would take to execute it in normal
program flow.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]