timeGetTime

[marcus]

how come this snippet has got an output like:
12297359.000000
12297359.000000
12297375.000000
12297375.000000
12297390.000000
12297390.000000
12297406.000000

[Victor Bazarov]

Re: timeGetTime

marcus wrote:[color=blue]
> why does it sometimes claim that no time has passed and sometimes
> claim that about 16 milliseconds has past?[/color]

Because that's the *granularity* with which the system clock runs on
your machine.
[color=blue]
> It should be millisecond[/color]

Should? Who said that?
[color=blue]
> resolution on it (ok I know windows is not a realtime operating
> system, but anyway I think it should do better than this I was
> planning to do some profiling on my code)[/color]

Don't use it for profiling. Use something else (QueryPerforman ceCounter
for example). Many systems have better ways to keep time, you just need
to research your particular system, and for that you need to post to
a newsgroup that deals with your system, comp.os.ms-windows.program mer,
in your case.

[Karl Heinz Buchegger]

Re: timeGetTime

marcus wrote:[color=blue]
>
> how come this snippet has got an output like:
> 12297359.000000
> 12297359.000000
> 12297375.000000
> 12297375.000000
> 12297390.000000
> 12297390.000000
> 12297406.000000
> .
> .
>
> while (1)
> printf("%f\n", timeGetTime());
>
> why does it sometimes claim that no time has passed and sometimes
> claim that about 16 milliseconds has past?[/color]

Because the time couting chip in your computer has
a resolution of 16 milliseconds only?
[color=blue]
> It should be millisecond
> resolution on it[/color]

It has milliseconds resolution.
All the time values are in the unit 'milliseconds'.
But nowhere the documentation says that the value will
increase with 1 millisecond :-)
[color=blue]
> (ok I know windows is not a realtime operating
> system,[/color]

'realtime operating system' has nothing to do with it.
[color=blue]
> but anyway I think it should do better than this I was
> planning to do some profiling on my code)[/color]

You can do it.
Execute the code in question 16 times and divide the resulting
time by 16 and you get an accuracy of 1 millisecond. (Well
sort of, if the process didn't get swapped or interrupted
and nothing else is happening on your machine besides running
your program. You get the idea)

--
Karl Heinz Buchegger
kbuchegg@gascad .at

[Karl Heinz Buchegger]

Re: timeGetTime

marcus wrote:[color=blue]
>
> how come this snippet has got an output like:
> 12297359.000000
> 12297359.000000
> 12297375.000000
> 12297375.000000
> 12297390.000000
> 12297390.000000
> 12297406.000000
> .
> .
>
> while (1)
> printf("%f\n", timeGetTime());
>
> why does it sometimes claim that no time has passed and sometimes
> claim that about 16 milliseconds has past?[/color]

Because the time couting chip in your computer has
a resolution of 16 milliseconds only?
[color=blue]
> It should be millisecond
> resolution on it[/color]

It has milliseconds resolution.
All the time values are in the unit 'milliseconds'.
But nowhere the documentation says that the value will
increase with 1 millisecond :-)
[color=blue]
> (ok I know windows is not a realtime operating
> system,[/color]

'realtime operating system' has nothing to do with it.
[color=blue]
> but anyway I think it should do better than this I was
> planning to do some profiling on my code)[/color]

You can do it.
Execute the code in question 16 times and divide the resulting
time by 16 and you get an accuracy of 1 millisecond. (Well
sort of, if the process didn't get swapped or interrupted
and nothing else is happening on your machine besides running
your program. You get the idea)

--
Karl Heinz Buchegger
kbuchegg@gascad .at

[Maett]

Re: timeGetTime

Am 19 Apr 2005 10:03:32 -0700 schrieb marcus <marcus.silfver @koping.net>:
[color=blue]
> how come this snippet has got an output like:
> 12297359.000000
> 12297359.000000
> 12297375.000000
> 12297375.000000
> 12297390.000000
> 12297390.000000
> 12297406.000000
> .
> .
>
> while (1)
> printf("%f\n", timeGetTime());
>
> why does it sometimes claim that no time has passed and sometimes
> claim that about 16 milliseconds has past? It should be millisecond
> resolution on it (ok I know windows is not a realtime operating
> system, but anyway I think it should do better than this I was
> planning to do some profiling on my code)
>[/color]

The basic windows clock tick usually is 10 ms (on a PC without intel hyperthreading) or 15.625 ms (on a PC with intel hyperthreading) . But since the time value you used increments in multiples of 1ms, you observe increments of 15 or 16 ms.

[Keith Thompson]

Re: timeGetTime

marcus.silfver@ koping.net (marcus) writes:[color=blue]
> how come this snippet has got an output like:
> 12297359.000000
> 12297359.000000
> 12297375.000000
> 12297375.000000
> 12297390.000000
> 12297390.000000
> 12297406.000000
> .
> .
>
> while (1)
> printf("%f\n", timeGetTime());[/color]

There is no standard C (or C++, as far as I know) function called
timeGetTime. You should ask in a newsgroup dedicated to whatever
system you're using (assuming the documentation doesn't answer your
question).

(It's probably an issue involving the underlying resolution of
whatever time information timeGetTime() accesses.)

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[marbac]

Re: timeGetTime

marcus wrote:
[color=blue]
>
> why does it sometimes claim that no time has passed and sometimes
> claim that about 16 milliseconds has past? It should be millisecond
> resolution on it (ok I know windows is not a realtime operating
> system, but anyway I think it should do better than this I was
> planning to do some profiling on my code)[/color]

If you plan to measure the speed of one algorithm compared to another:

http://www.math.uwaterloo.ca/~jamuir/rdtscpm1.pdf

In my environment (Linux/gcc) the function rdtscll is located in <asm/msr.h>
I can imagine that there is something equivalent in your system.

regards marbac

[Randy Howard]

Re: timeGetTime

In article <6Ze9e.11779$0z 2.3603@news.che llo.at>, marbac@chello.a t
says...[color=blue]
>
> If you plan to measure the speed of one algorithm compared to another:
>
> http://www.math.uwaterloo.ca/~jamuir/rdtscpm1.pdf
>
> In my environment (Linux/gcc) the function rdtscll is located in <asm/msr.h>
> I can imagine that there is something equivalent in your system.[/color]

Fundamentally broken on SMP systems, and perhaps dual-core as well.
This is also OT for both of these groups you have posted it to.

--
Randy Howard (2reply remove FOOBAR)
"Making it hard to do stupid things often makes it hard
to do smart ones too." -- Andrew Koenig

[Dag-Erling Smørgrav]

Re: timeGetTime

Randy Howard <randyhoward@FO OverizonBAR.net > writes:[color=blue]
> [RDTSC is f]undamentally broken on SMP systems, and perhaps
> dual-core as well.[/color]

Not necessarily; some SMP motherboards synchronize the TSCs of all
CPUs. I would expect that multi-core CPUs would have a single shared
TSC, or individual but synchronized TSCs for each core.

DES
--
Dag-Erling Smørgrav - des@des.no

[Randy Howard]

Re: timeGetTime

In article <86k6mxtrde.fsf @xps.des.no>, des@des.no says...[color=blue]
> Randy Howard <randyhoward@FO OverizonBAR.net > writes:[color=green]
> > [RDTSC is f]undamentally broken on SMP systems, and perhaps
> > dual-core as well.[/color]
>
> Not necessarily; some SMP motherboards synchronize the TSCs of all
> CPUs.[/color]

Since not all of them do (most I've seen do not, and I've worked on
dozens of different IA32 SMP platforms), then that is worthless
information since you can not rely upon it.
[color=blue]
> I would expect that multi-core CPUs would have a single shared
> TSC, or individual but synchronized TSCs for each core.[/color]

I haven't tried it on a dual-core system yet, but hopefully they
will do so. Even so, it doesn't do much good to those that
intend to rely on rdtsc for timing, as not all platforms will
work as expected.

--
Randy Howard (2reply remove FOOBAR)
"Making it hard to do stupid things often makes it hard
to do smart ones too." -- Andrew Koenig