On 8/19/05, guy keren <[EMAIL PROTECTED]> wrote:
>
> On Fri, 19 Aug 2005, Amos Shapira wrote:
>
> > > the fact is, that i kept getting very close values - closer then the
> >
> > That's the statement I was looking for (and didn't see) in your first
> > message - if they are identical then it could be that the call was simply
> > faster than system's the clock resolution. If they are "close" then it
> > means that the resolution is there.
>
> ok.
>
> > I've just ran the following on my desktop (dual pentium-4 2.8GHz, 2.6.12.2,
> > but an IBM ThinkCentre which is known to have clock issues so it might be
> > suspicious) and the fastest I got between two calls to gettimeofday was 2
> > microseconds.
>
> perhaps your machine is slower for this because it has SMP, and hence
> requires locking (i tested on single processor machines).
Maybe, I dunno.
I've just test on my home machine (a single CPU Athlon 2500+, debian Sarge,
kernel 2.6.8, g++ 3.3.5 with -O6) and got yet slower results:
66280 3
861173 4
68224 5
227 6
59 7
8 8
43 9
18 10
20 11
24 12
>
> > My conclusion from this excercise is that the resolution of the clock on
> > this
> > system can be practically regarded at around 2 microsecond. When
> > you received "identical" results your program was just fast enough to run
> > two system calls before the resolution bumped the clock.
>
> your assumption is faulty, since you do not know what is the resolution of
> the clock. if it runs an sub-micro-second resolution, and you use
> gettimeofday, you cannot tell if you got the same read because the clock
> was not advanced, or because it advanced by less then a micro-second
> (actually, by less then half a micro second on average).
But I didn't get such readings. Since you show that you can get such readings
with my program then I can join your conclusion for your system.
>
> > BTW - notice that there are no two identical values (no "0" line) - was your
> > code more efficient than this? ("g++-3.3 -O6" gave similar numbers, never
> > less than 3 microseconds).
>
> obviously my code was more efficient because:
>
> 1. it was written in C ;)
> 2. i didn't keep calling pairs of 'gettimeofday'. instead, i compaired
> every new call to the previous one (so the loop was structures
> differently).
Read my code again and see which part gets measured - only
two calls to gettimeofday(2), the rest is not measured, not even a loop
variable or a compare/jump.
>
> however...
>
> > #include <iostream>
> >
> > #include <sys/time.h>
> > #include <time.h>
> >
> > using namespace std;
>
> ouch! dave, don't do that...
My name is Amos... :^), and I did this not only because that's what
I'm used to (for the "std" namespace) but also for spite! :)
>
> > int main(int argc, char *argv[])
> > {
> > for (int i = 0; i < 1000000; ++i)
> > {
> > struct timeval before, after, diff;
> > gettimeofday(&before, 0);
> > gettimeofday(&after, 0);
> > timersub(&after, &before, &diff);
>
> i think i did the time diff calculation by hand, rather then by using a
> function call.
It's a macro which does just this, see the end of <sys/time.h>
>
> > if (diff.tv_sec) // cover my ass, never happened
> > cout << "Diff is more than a sec: " << diff.tv_sec << endl;
> > cout << diff.tv_usec << endl;
> > }
> > }
>
> it could be that cout is slower then printf.
Just tested this and you are right, cout is slower than printf by 50%
(printing an integer constant to /dev/null through cerr/stderr). Very
disappointing for me to notice this.
> compiled with:
> g++ checktime.c
> (i.e. no optimizations - they are quite meaningless in your test,
> since there's not much to optimize between two consecutive
> invocations of a system call).
So why does the rest of the code matters?
>
> [EMAIL PROTECTED] ~]$ g++ --version
> 2.96
>
> [EMAIL PROTECTED] ~]$ cat /etc/issue
>
> Red Hat Linux release 7.3 (Valhalla)
> Kernel 2.4.18-17.7.x on an i686
>
> cpu: model name : AMD Athlon(tm) XP 2200+
>
> can you load a non-SMP kernel on your machine and run the test under it,
> to test my SMP locking theory?
I don't have root access on the workplace machine. However I did test
this at home on a single-CPU AMD Athlon 2500+ (~110MHz according
to /proc/cpuinfo) and got very similar results to the ones at my
workplace, both with C++ and a C version.
Strange.
--Amos
================================================================To unsubscribe,
send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
