* Timing things.
@ 1999-06-16 0:00 Joel VanLaven
1999-06-16 0:00 ` Tom Moran
1999-06-17 0:00 ` Pascal Obry
0 siblings, 2 replies; 4+ messages in thread
From: Joel VanLaven @ 1999-06-16 0:00 UTC (permalink / raw)
I wrote a program as an assignment for an algorithms class in
Ada95 that builds and operates on a variety of double-ended priority
queues. I am supposed to time certain operations (the build then the
sum of the subsequent iterations of operations). I am trying to use
ada.real_time (rather than using some OS feature). Problem is on my
Windows98 PC using Gnat 3.11p I seem to be getting completely bogus and
useless times. (granularity of at best 1/100 of a second though it looks
more like 1/10 of a second)
So, does anyone know if I have to use a different OS / hardware system,
a different compiler, different code for the timing, or do I need to
modify my problem (least attractive because it was assigned this way).
To do the timing I am using:
start_time := ada.real_time.clock;
do operations ( e.g. build 10_000 element heap in at least 23_000
comparisons)
end_time := ada.real_time.clock;
num_micros := ada.real_time."/"(ada.real_time."-"(end_time,start_time),
ada.real_time.microseconds(1));
I am getting either end_time and start_time are the same or
num_micros is 110_000
PS. If anyone cares I will be happy to share my code
Thanks,
-- Joel VanLaven
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Timing things.
1999-06-16 0:00 Timing things Joel VanLaven
@ 1999-06-16 0:00 ` Tom Moran
1999-06-16 0:00 ` Joel VanLaven
1999-06-17 0:00 ` Pascal Obry
1 sibling, 1 reply; 4+ messages in thread
From: Tom Moran @ 1999-06-16 0:00 UTC (permalink / raw)
>Windows98 PC using Gnat 3.11p
>...
>I am getting either end_time and start_time are the same or
>num_micros is 110_000
Sounds like it's using the standard PC clock that tickes every 55
milliseconds. You can get a different compiler, or a different OS or
machine, or make a direct OS call to QueryPerformanceCounter (sp?)
or
> start_time := ada.real_time.clock;
for trial in 1 .. 100 loop
>do operations ( e.g. build 10_000 element heap in at least 23_000
> comparisons)
end loop;
>end_time := ada.real_time.clock;
>num_micros := ada.real_time."/"(ada.real_time."-"(end_time,start_time),
ada.real_time.microseconds(1))/100; ie, run the test long enough to
get multiple clock ticks, then divide the elapsed time by the number
of trials you used.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Timing things.
1999-06-16 0:00 ` Tom Moran
@ 1999-06-16 0:00 ` Joel VanLaven
0 siblings, 0 replies; 4+ messages in thread
From: Joel VanLaven @ 1999-06-16 0:00 UTC (permalink / raw)
Tom Moran wrote:
> Sounds like it's using the standard PC clock that tickes every 55
> milliseconds. You can get a different compiler, or a different OS or
> machine, or make a direct OS call to QueryPerformanceCounter (sp?)
Thanks alot. The OS call worked great, especially once I abandoned my
abstract data type instincts and did unchecked conversion from the wacky
win32 binding types to gnat's long_long_integer.
> ada.real_time.microseconds(1))/100; ie, run the test long enough to
> get multiple clock ticks, then divide the elapsed time by the number
> of trials you used.
A fine suggestion and the last resort I was avoiding. This is because
of my particular assignment. I was told to time the build and the
operations separately. And the number of operations wrt size of heap
was having an effect, so, I would either have to let my results be
skewed by higher operations to size ratio, swamp the operations runtime
with copying of a stored starting heap, or increase size and operations,
all of which either invalidate the results and/or modify the
assignment. Certianly possible, but not desired. Luckily the day has
been saved.
Thank you again,
-- Joel VanLaven
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Timing things.
1999-06-16 0:00 Timing things Joel VanLaven
1999-06-16 0:00 ` Tom Moran
@ 1999-06-17 0:00 ` Pascal Obry
1 sibling, 0 replies; 4+ messages in thread
From: Pascal Obry @ 1999-06-17 0:00 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 861 bytes --]
Joel VanLaven <jvanlaven@acm.org> a �crit dans le message :
3767E18A.1904F5AF@acm.org...
> I wrote a program as an assignment for an algorithms class in
> Ada95 that builds and operates on a variety of double-ended priority
> queues. I am supposed to time certain operations (the build then the
> sum of the subsequent iterations of operations). I am trying to use
> ada.real_time (rather than using some OS feature). Problem is on my
> Windows98 PC using Gnat 3.11p I seem to be getting completely bogus and
> useless times. (granularity of at best 1/100 of a second though it looks
> more like 1/10 of a second)
>
This is true in GNAT 3.11 where the clock is implemented with standard
Windows
timing function.
In GNAT 3.12 the clock is implemented using a high resolution counter, this
gives the clock a resolution of about 1 micro-sec.
Pascal.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1999-06-17 0:00 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-06-16 0:00 Timing things Joel VanLaven
1999-06-16 0:00 ` Tom Moran
1999-06-16 0:00 ` Joel VanLaven
1999-06-17 0:00 ` Pascal Obry
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox