Timing Block of GNAT code in milliseconds

Timing Block of GNAT code in milliseconds

[markp]

I am trying to time a block of code down to the millisecond level. Can
anyone help in this area?

Thanks.

Re: Timing Block of GNAT code in milliseconds

[tmoran]

>I am trying to time a block of code down to the millisecond level. Can
>anyone help in this area?
   The traditional way is
     T0 := Ada.Calendar.Clock;
     for i in 1 .. 1000 loop
       -- code to be timed
     end loop;
     Result := (Ada.Calendar.Clock - T0)/1000;
If the code to be timed is short so the loop overhead is significant, then
you time an empty loop (making sure the compiler doesn't optimize it away)
and subtract that.  On Windows machines it doesn't take long to call
Ada.Calendar.Clock, and that's accurate to better than one microsecond, so
if you want millisecond accuracy you could even dispense with the loop and
just do
     T0 := Ada.Calendar.Clock;
       -- code to be timed
     Result := (Ada.Calendar.Clock - T0)/1000;

Re: Timing Block of GNAT code in milliseconds

[markp]

Thanks for your response:

I tried this and got some errors. Hereis what my code looks like

   My_Time    : Ada.Calendar.Time;
   Result        : Ada.Calendar.Time;

  My_Time := Ada.Calendar.Clock;
  Result  := (Ada.Calendar.Clock - My_Time)/1000;

The error I get is :

Expected private type Ada.Calendar.Time
Expected type Standard Duration

on the piece of code (Ada.Calendar.Clock - My_Time).

Lastly,

How would I print out Result?

Thanks again

Re: Timing Block of GNAT code in milliseconds

[Marc A. Criley]

markp wrote:

> I tried this and got some errors. Hereis what my code looks like
> 
>    My_Time    : Ada.Calendar.Time;
>    Result        : Ada.Calendar.Time;

Result should by declared to be of type Duration, just like the error 
message said.

> 
>   My_Time := Ada.Calendar.Clock;
>   Result  := (Ada.Calendar.Clock - My_Time)/1000;
> 
> The error I get is :
> 
> Expected private type Ada.Calendar.Time
> Expected type Standard Duration
> 
> on the piece of code (Ada.Calendar.Clock - My_Time).
> 
> Lastly,
> 
> How would I print out Result?

Put_Line(Duration'Image(Result));

Marc A. Criley
www.mckae.com

Re: Timing Block of GNAT code in milliseconds

[Simon Wright]

"markp" <markwork66@yahoo.com> writes:

> Thanks for your response:
> 
> I tried this and got some errors. Hereis what my code looks like
> 
>    My_Time    : Ada.Calendar.Time;
>    Result        : Ada.Calendar.Time;
> 
>   My_Time := Ada.Calendar.Clock;
>   Result  := (Ada.Calendar.Clock - My_Time)/1000;
> 
> The error I get is :
> 
> Expected private type Ada.Calendar.Time
> Expected type Standard Duration
> 
> on the piece of code (Ada.Calendar.Clock - My_Time).

You need to say

   use type Ada.Calendar.Time;

in a declarative region (I usually put this just before the 'begin').

That gives you access to the operation "-" taking two parameters of
type Ada.Calendar.Time and returning a Duration; your Result should be
of type Duration (a Time corresponds to the wall-clock time, whereas
Duration is an interval).

The error message you got is reasonable; if you subtract "4 Jan 2004"
from "4 Jan 2005", you get "1 year" not "1 Jan 1971"!

> Lastly,
> 
> How would I print out Result?

Did you say what compiler/platform you're using?

On any platform you can say (eg)

  Ada.Text_IO.Put_Line ("Result is " & Duration'Image (Result));

GNAT has the non-portable extension 'Img so you can say

  Ada.Text_IO.Put_Line ("Result is " & Result'Img);

-- 
Simon Wright                               100% Ada, no bugs.

Re: Timing Block of GNAT code in milliseconds

[Steve]

Actually I think this is a better job for Ada.Real_Time than Ada.Calendar.

I usually do something like:

  start_time := Ada.Real_Time.Clock;
  .. do something
  end_time := Ada.Real_Time.Clock;
  elapsed_seconds := Float( To_Duration( end_time - start_time ) );

I tend to think of the Real_Time package as the one to use when you are 
timing events and the Calendar package as the one to use when you don't care 
about precise timing and want the time of day for reporting, etc.

Steve
(The Duck)


<tmoran@acm.org> wrote in message news:HI2dnf8gWoC-d_rfRVn-sQ@comcast.com...
> >I am trying to time a block of code down to the millisecond level. Can
>>anyone help in this area?
>   The traditional way is
>     T0 := Ada.Calendar.Clock;
>     for i in 1 .. 1000 loop
>       -- code to be timed
>     end loop;
>     Result := (Ada.Calendar.Clock - T0)/1000;
> If the code to be timed is short so the loop overhead is significant, then
> you time an empty loop (making sure the compiler doesn't optimize it away)
> and subtract that.  On Windows machines it doesn't take long to call
> Ada.Calendar.Clock, and that's accurate to better than one microsecond, so
> if you want millisecond accuracy you could even dispense with the loop and
> just do
>     T0 := Ada.Calendar.Clock;
>       -- code to be timed
>     Result := (Ada.Calendar.Clock - T0)/1000; 

Re: Timing Block of GNAT code in milliseconds

[Simon Wright]

"Steve" <nospam_steved94@comcast.net> writes:

> I tend to think of the Real_Time package as the one to use when you
> are timing events and the Calendar package as the one to use when
> you don't care about precise timing and want the time of day for
> reporting, etc.

It used to be the case with GNAT that there was an amazing similarity
between these two clocks! Looking on 5.02a1, on a first glance it
seems that Real_Time is derived as follows (the first two letters are
the encoding in the distribution, eg if building on NT the file
s-taprop.adb is copied from 5wtaprop.adb).

1s VxWorks/Cert taprop uses tickGet.

56 LynxOS taprop uses clock_gettime.

5a DEC Unix taprop uses clock_gettime.

5f IRIX pthread taprop uses clock_gettime.

5g IRIX athread taprop uses gettimeofday.

5h HP-UX DCE taprop uses clock_gettime.

5i GNU/LinuxThreads taprop uses getttimeofday.

5n Non-tasking taprop returns 0.0.

5o OS/2 taprop uses osprim which is the same as its Clock which is its
system clock.

5p OpenNT, Dec Unix, SCO taprop use osprim which is the same as its
Clock which uses gettimeofday.

5s Solaris taprop uses osprim which is the same as its Clock which
uses gettimeofday.

5v OpenVMS/Alpha taprop uses osprim which is the same as its clock
which uses the system clock.

5w NT taprop uses osprim which uses the performance counter.

5z VxWorks taprop uses clock_gettime.

7s 'POSIX-like' taprop uses clock_gettime.

-- 
Simon Wright                               100% Ada, no bugs.

Re: Timing Block of GNAT code in milliseconds

[Steve]

"Simon Wright" <simon@pushface.org> wrote in message 
news:x7vsm1i2gs7.fsf@smaug.pushface.org...
> "Steve" <nospam_steved94@comcast.net> writes:
>
>> I tend to think of the Real_Time package as the one to use when you
>> are timing events and the Calendar package as the one to use when
>> you don't care about precise timing and want the time of day for
>> reporting, etc.
>
> It used to be the case with GNAT that there was an amazing similarity
> between these two clocks! Looking on 5.02a1, on a first glance it
> seems that Real_Time is derived as follows (the first two letters are
> the encoding in the distribution, eg if building on NT the file
> s-taprop.adb is copied from 5wtaprop.adb).
>
[snip]

It would also be interesting to know whether there is a difference in the 
time base for Ada.Calendar and Ada.Real_Time for the different systems.

Steve
(The Duck)


>
> -- 
> Simon Wright                               100% Ada, no bugs. 

Re: Timing Block of GNAT code in milliseconds

[Simon Wright]

"Steve" <nospam_steved94@comcast.net> writes:

> "Simon Wright" <simon@pushface.org> wrote in message 
> news:x7vsm1i2gs7.fsf@smaug.pushface.org...
> > "Steve" <nospam_steved94@comcast.net> writes:
> >
> >> I tend to think of the Real_Time package as the one to use when
> >> you are timing events and the Calendar package as the one to use
> >> when you don't care about precise timing and want the time of day
> >> for reporting, etc.
> >
> > It used to be the case with GNAT that there was an amazing
> > similarity between these two clocks! Looking on 5.02a1, on a first
> > glance it seems that Real_Time is derived as follows (the first
> > two letters are the encoding in the distribution, eg if building
> > on NT the file s-taprop.adb is copied from 5wtaprop.adb).
> >
> [snip]
> 
> It would also be interesting to know whether there is a difference
> in the time base for Ada.Calendar and Ada.Real_Time for the
> different systems.

There are two things, the tick rate and the epoch. All the ones that
use the system clock or gettimeofday or clock_gettime are going to
have identical Calendar and Real_Time (and, incidentally, fail to meet
the ARM requirement in D.8(32), "There shall be no backward clock
jumps.", if the system's time-of-day changes; the only one that
obviously meets that is VxWorks/Cert).

I don't know about Windows NT.

-- 
Simon Wright                               100% Ada, no bugs.

Re: Timing Block of GNAT code in milliseconds

[Dmitry A. Kazakov]

On 24 Apr 2005 19:57:24 +0100, Simon Wright wrote:

> "Steve" <nospam_steved94@comcast.net> writes:
> 
>> "Simon Wright" <simon@pushface.org> wrote in message 
>> news:x7vsm1i2gs7.fsf@smaug.pushface.org...
>>> "Steve" <nospam_steved94@comcast.net> writes:
>>>
>>>> I tend to think of the Real_Time package as the one to use when
>>>> you are timing events and the Calendar package as the one to use
>>>> when you don't care about precise timing and want the time of day
>>>> for reporting, etc.
>>>
>>> It used to be the case with GNAT that there was an amazing
>>> similarity between these two clocks! Looking on 5.02a1, on a first
>>> glance it seems that Real_Time is derived as follows (the first
>>> two letters are the encoding in the distribution, eg if building
>>> on NT the file s-taprop.adb is copied from 5wtaprop.adb).
>>>
>> [snip]
>> 
>> It would also be interesting to know whether there is a difference
>> in the time base for Ada.Calendar and Ada.Real_Time for the
>> different systems.
> 
> There are two things, the tick rate and the epoch. All the ones that
> use the system clock or gettimeofday or clock_gettime are going to
> have identical Calendar and Real_Time (and, incidentally, fail to meet
> the ARM requirement in D.8(32), "There shall be no backward clock
> jumps.", if the system's time-of-day changes; the only one that
> obviously meets that is VxWorks/Cert).

Yes, but that shouldn't prevent them from using the same source. They could
run synchronized, experiencing rare and short periods when Calendar jumps
here and there.

> I don't know about Windows NT.

I presume Real_Time uses Windows' performance counter which never jumps.
But I have no idea how Calendar behaves, especially in presence of some
external time synchronization software like NTP.

Alas, both clock models are quite useless in a distributed environment.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Timing Block of GNAT code in milliseconds

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:ei2meksw8if6.11hcrgpc1osq5$.dlg@40tude.net...
> On 24 Apr 2005 19:57:24 +0100, Simon Wright wrote:
...
> > I don't know about Windows NT.
>
> I presume Real_Time uses Windows' performance counter which never jumps.
> But I have no idea how Calendar behaves, especially in presence of some
> external time synchronization software like NTP.

They both use the Window's performance counter; the code is shared as I
recall. The base time is determined from the usual Windows system calls, and
the performance counter is used to provide an offset.

But the performance counter can jump - just that it does so forward. GNAT
has a workaround for that, but of course you lose some accuracy if it has to
use the workaround.

                     Randy.

Re: Timing Block of GNAT code in milliseconds

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> I presume Real_Time uses Windows' performance counter which never
> jumps.  But I have no idea how Calendar behaves, especially in
> presence of some external time synchronization software like NTP.
> 
> Alas, both clock models are quite useless in a distributed
> environment.

I think that's going a bit far -- it has to depend what your
requirements are!

We are running on plain VxWorks and need millisecond sync over our
local network. If GNAT separated Real_Time from Calendar we could
probably have used Calendar; as it is we have our own similar package
which manages an offset from Calendar.

Any requirement much finer than millisecond sync is going to need
something more appropriate than plain old ethernet with a plain old
network stack (which takes about 150 us to traverse on this hardware
in the best of conditions!)

-- 
Simon Wright                               100% Ada, no bugs.

Re: Timing Block of GNAT code in milliseconds

[Dmitry A. Kazakov]

On 28 Apr 2005 21:26:00 +0100, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> I presume Real_Time uses Windows' performance counter which never
>> jumps.  But I have no idea how Calendar behaves, especially in
>> presence of some external time synchronization software like NTP.
>> 
>> Alas, both clock models are quite useless in a distributed
>> environment.
> 
> I think that's going a bit far -- it has to depend what your
> requirements are!
> 
> We are running on plain VxWorks and need millisecond sync over our
> local network. If GNAT separated Real_Time from Calendar we could
> probably have used Calendar; as it is we have our own similar package
> which manages an offset from Calendar.
> 
> Any requirement much finer than millisecond sync is going to need
> something more appropriate than plain old ethernet with a plain old
> network stack (which takes about 150 us to traverse on this hardware
> in the best of conditions!)

Neither clock is usable in a WAN.

We need time stamps synchronized across the network. The accuracy of
synchronization is the second problem. The first problem is that the very
idea of synchronized time stamps cannot be expressed in Ada terms. There is
no portable way to get say UTC from either Calendar or Real_Time, or to
convert UTC to them.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Timing Block of GNAT code in milliseconds

[tmoran]

>idea of synchronized time stamps cannot be expressed in Ada terms.
  I would argue your problem is due to using a Calendar (or Real_Time)
that thinks it's running on a single machine.  Can you replace the library
body with one that goes to a single time source for Ada.Calendar.Clock?
(There's no requirement in the language that a call on Clock be fast ;)

Re: Timing Block of GNAT code in milliseconds

[Dmitry A. Kazakov]

On Fri, 29 Apr 2005 13:25:23 -0500, tmoran@acm.org wrote:

>>idea of synchronized time stamps cannot be expressed in Ada terms.
> I would argue your problem is due to using a Calendar (or Real_Time)
> that thinks it's running on a single machine.

True

> Can you replace the library
> body with one that goes to a single time source for Ada.Calendar.Clock?
> (There's no requirement in the language that a call on Clock be fast ;)

The problem is with the scope of clock readings.

1. Calendar.Clock time is valid only within its time zone, further it
suffers jumps, and is unsuitable for evaluation of large time spans. To
start with, who can predict all new time jumps governments will prescribe
in coming 10 years?

2. Real_Time.Clock time is valid no longer next system boot.

I think that Annex E should mandate a third time source. It need not to be
synchronized with other two. 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Timing Block of GNAT code in milliseconds

[tmoran]

> 2. Real_Time.Clock time is valid no longer next system boot.
Why?  You could surely have a single black box located, say, in Greenwich
England, which could be queried for time over the internet.  Then you make
a body for Real_Time.Clock that does that query to provide a time.  All of
your programs on all of your distributed programs use the same library so
they query the same box and get the same time.  The duration of a call to
such a Real_Time.Clock might be long and might be variable, but that's
true to some extent just running on a single multi-tasking machine.  If
you want something faster and less variable, have each machine read from a
time continually transmitted over a fiber optic cable from a central
source.  There's no requirement that Ada.Real_Time use whatever low
quality clock is provided by the particular computer it's running on.
That just happens to be simpler, and adequate for most uses.

Re: Timing Block of GNAT code in milliseconds

[Dmitry A. Kazakov]

On Fri, 29 Apr 2005 15:24:27 -0500, tmoran@acm.org wrote:

>> 2. Real_Time.Clock time is valid no longer next system boot.
> Why?  You could surely have a single black box located, say, in Greenwich
> England, which could be queried for time over the internet.

So it will be until next black box boot. (:-))

> Then you make
> a body for Real_Time.Clock that does that query to provide a time.  All of
> your programs on all of your distributed programs use the same library so
> they query the same box and get the same time.  The duration of a call to
> such a Real_Time.Clock might be long and might be variable, but that's
> true to some extent just running on a single multi-tasking machine.  If
> you want something faster and less variable, have each machine read from a
> time continually transmitted over a fiber optic cable from a central
> source.  There's no requirement that Ada.Real_Time use whatever low
> quality clock is provided by the particular computer it's running on.
> That just happens to be simpler, and adequate for most uses.

There are enough time service departments all over the world to create a
new one (per each application.) Why not to follow international standards?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Timing Block of GNAT code in milliseconds

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:10m95m5yelieq$.kj1rktb792s3.dlg@40tude.net...
...
> We need time stamps synchronized across the network. The accuracy of
> synchronization is the second problem. The first problem is that the very
> idea of synchronized time stamps cannot be expressed in Ada terms. There
is
> no portable way to get say UTC from either Calendar or Real_Time, or to
> convert UTC to them.

Of course there is (assuming that you have a compiler that supports the Ada
2006 Ada.Calendar.Time_Zone and Ada.Calendar.Formatting.Split packages).

declare
     Now : Ada.Calendar.Time := Ada.Calendar.Clock;
     UTC_Offset : Ada.Calendar.Time_Zones.Time_Offset :=
           Ada.Calendar.Time_Zones.UTC_Time_Offset (Now);
begin
    Ada.Calendar.Formatting.Split (Now, Time_Zone => UTC_Offset, <other
parts of the UTC time>);
    ...
end;

It's a bit clunky, but that is the price of undoing daylight savings time.
If your time period is short enough (doesn't cross any hour boundaries in
the early morning), you can just get the offset once.

And you can use Time_Of with a Time_Zone parameter to construct a value.

                          Randy.

Re: Timing Block of GNAT code in milliseconds

[Dmitry A. Kazakov]

On Fri, 29 Apr 2005 15:52:55 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:10m95m5yelieq$.kj1rktb792s3.dlg@40tude.net...
> ...
>> We need time stamps synchronized across the network. The accuracy of
>> synchronization is the second problem. The first problem is that the very
>> idea of synchronized time stamps cannot be expressed in Ada terms. There is
>> no portable way to get say UTC from either Calendar or Real_Time, or to
>> convert UTC to them.
> 
> Of course there is (assuming that you have a compiler that supports the Ada
> 2006 Ada.Calendar.Time_Zone and Ada.Calendar.Formatting.Split packages).
> 
> declare
>      Now : Ada.Calendar.Time := Ada.Calendar.Clock;
>      UTC_Offset : Ada.Calendar.Time_Zones.Time_Offset :=
>            Ada.Calendar.Time_Zones.UTC_Time_Offset (Now);
> begin
>     Ada.Calendar.Formatting.Split (Now, Time_Zone => UTC_Offset, <other
> parts of the UTC time>);

I do hope that there is a Time_Zone which does mangle time!

>     ...
> end;
> 
> It's a bit clunky, but that is the price of undoing daylight savings time.
> If your time period is short enough (doesn't cross any hour boundaries in
> the early morning), you can just get the offset once.
> 
> And you can use Time_Of with a Time_Zone parameter to construct a value.

It is a perversion. It is local political time which is derived from UTC
not otherwise. Then the time span mandated by Ada.Calendar is too short,
precision is too low (for time stamping accuracy is not an issue.)

BTW I think we could safely replace Ada.Calendar.Clock with UTC clock, but
that would make some elder Ada library implementations illegal.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de