comp.lang.ada
 help / color / mirror / Atom feed
* 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