Re: Execution time of code?
On Mar 7, 8:43 am, "Alf P. Steinbach" <al...@start.no> wrote:
* c...@mailvault.com:
On Mar 6, 10:00 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* c...@mailvault.com:
[...]
I was commenting on the "problem" with values like "10,000".
If you *really*, actually, have values like those you
exemplified, like "10,000", then that indicates with high
probability that somewhere in the testing code an integer
division is used where a floating point division should have
been used.
I've just done a few tests on my Linux machine here, and it does
seem to be an error in the library implementation under Linux.
For some reason, Posix requires that CLOCKS_PER_SEC be 1000000,
regardless of the actual accuracy available. So a machine whose
only timer source is the 50 Hz line frequency (I don't know of
any today, but that used to be a frequent case, many years ago)
will return the values 0, 20000, 40000, etc. (or 0, 10000,
20000, etc., if it triggers on each zero crossing). This sort
of defeats the purpose of CLOCKS_PER_SEC, as defined by the C
standard, but Posix does occasionally get confused. And of
course, on a machine which does support more precision (i.e. all
modern machines), you should get it, at least from a QoI point
of view.
But I assumed that was not the case, that it was just a case
of dramatizing the effect of low resolution.
If you really, actually have such values, then check out the
division of 'clock' result.
(I could document the results from clock, but for now I just
document the ratio.) I use semicolons within a shell to run
each version 3 times in a row. I execute that command
twice. The second group starts up right on the heels of the
first. So the test is run 6 times total. I ignore the
first 3 runs/times and do those just to get the machine
ready for the next 3. Anyway, my impression, and it seemed
like Victor has a similar impression, is the output from
clock isn't as precise as it could be. The range I got
earlier from clock, 1.4 - 4.5, leaves quite a bit of room
for manipulation if that is a person's goal.
Uh, the person doing the timing is presumably /not/ your
adversary, but yourself?
Anyways, if you have a range of 1.4 to 4.5 for the same code,
tested in *nix (indicated by your comment about semicolons),
using 'clock' which in *nix-land reports processor time, then
Something Is Wrong.
Yes. And that is probably true even if clock only has a
resolution of 10 ms. You don't bench a single run; you bench a
large number of runs, in a loop. For any significant
measurements, I would expect a total measured time of something
like 5 minutes, at least. Any decent benchmark harness should
be able to handle this sort of stuff.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34