An Example for Ada.Execution_Time

An Example for Ada.Execution_Time

[anon]

You ask for an example.

Here is an example for packages (Tested using MaRTE):
  Ada.Execution_Time         -- Defines Time type and main operations as
                             -- well as the primary Clock for this type

  Ada.Execution_Time.Timers  -- Links to Timers 


Altering this example one could use a number of timers to be set 
using different times. Or testing a number of algorithms using 
the timer.

Also, I do have a Real_Time non-Task version that this example was 
based on.


-------------------------------
-- Work.adb -- Main program

with Ada.Integer_Text_IO ;
with Ada.Text_IO ;
with Work_Algorithm ;         -- Contains worker algorithm
with Work_Execution_Time ;    -- Contains execution Timing routines

procedure Work is

  use Ada.Integer_Text_IO ;
  use Ada.Text_IO ;
  use Work_Execution_Time ; 

  Task_0 : Work_Task ;

begin -- Work
  Initialize ( Work_Algorithm'Access ) ;
  Task_0.Start ( False ) ;

  -- Prints results of Test

  New_Line ;
  Put ( "Event occured " ) ;
  Put ( Item => Counter, Width => 3 ) ;
  Put_Line ( " Times." ) ;
  New_Line ;

end Work ;

-------------------------------
-- Work_Algorithm.ads

procedure Work_Algorithm ;

-------------------------------
-- Work_Algorithm.adb

with Ada.Integer_Text_IO ;
with Ada.Text_IO ;

procedure Work_Algorithm is
    use Ada.Integer_Text_IO ;
    use Ada.Text_IO ;
  begin
    for Index in 0 .. 15 loop
      Put ( "Paused =>" ) ;
      Put ( Index ) ;
      New_Line ;
      delay 1.0 ;
    end loop ;
  end Work_Algorithm ;


-------------------------------
-- Work.Execution_Time.ads

with Ada.Execution_Time ;
with Ada.Real_Time ;

package Work_Execution_Time is

  type Algorithm_Type is access procedure ;

  task type Work_Task is
    entry Start ( Active : in Boolean ) ;
  end Work_Task ;


  Counter    : Natural ;

  procedure Initialize ( A : in Algorithm_Type ) ;

private 

  Algorithm  : Algorithm_Type ;

  Start_Time : Ada.Execution_Time.CPU_Time ;
  At_Time    : Ada.Execution_Time.CPU_Time ;
  In_Time    : Ada.Real_Time.Time_Span ;

end Work_Execution_Time ;

-------------------------------
-- Work_Execution_Time ;
with Ada.Integer_Text_IO ;
with Ada.Text_IO ;
with Ada.Execution_Time ;
with Ada.Execution_Time.Timers ;
with Ada.Real_Time ;
with Ada.Task_Identification ;

package body Work_Execution_Time is


    use Ada.Execution_Time ;
    use Ada.Real_Time ;
    use Timers ;

    package D_IO is new Ada.Text_IO.Fixed_IO ( Duration ) ;
    package S_IO is new Ada.Text_IO.Integer_IO
                                      ( Ada.Real_Time.Seconds_Count ) ;

  protected Handlers is
    -- Handler: Single Event
      procedure Handler_1 ( TM : in out Timer ) ;

    -- Handler: Multple Event
      procedure Handler_2 ( TM : in out Timer ) ;
  end Handlers ;



  task body Work_Task is

      use Ada.Task_Identification ;

    ID         : aliased Task_Id := Current_Task ;
    TM         : Timers.Timer ( ID'Access ) ;

    Cancelled  : Boolean := False ;

  begin
    Counter := 0 ;
    loop
      select
        Accept Start ( Active : in Boolean ) do
          if Active then
            Start_Time := Ada.Execution_Time.Clock ;
            At_Time := Start_Time + Milliseconds ( 5 ) ;
            Set_Handler ( TM, AT_Time, Handlers.Handler_2'Access ) ;
          else
            Start_Time := Ada.Execution_Time.Clock ;
            In_Time := Milliseconds ( 10 ) ;
            Set_Handler ( TM, In_Time, Handlers.Handler_2'Access ) ;
          end if ;

          Algorithm.all ;  -- Execute Test algorithm

          Timers.Cancel_Handler ( TM, Cancelled ) ;
        end Start ;
      or
        terminate ;
      end select ;
    end loop ;
  end Work_Task ;


  --
  -- Timer Event Routines
  --
  protected body Handlers is 

    -- Handler: Single Event

    procedure Handler_1 ( TM : in out Timer ) is

        Value     : Time_Span ;
        Cancelled : Boolean ;

      begin
        Value := Time_Remaining ( TM ) ;
        Ada.Text_IO.Put ( "Timing Event Occured at " ) ;
        D_IO.Put ( To_Duration ( Value ) ) ;
        Ada.Text_IO.New_Line ;
        Counter := Counter + 1 ;
        Cancel_Handler ( TM, Cancelled ) ;
      end Handler_1 ;

    -- Handler: Multple Event

    procedure Handler_2 ( TM : in out Timer ) is

        Value   : Time_Span ;

      begin
        Value := Time_Remaining ( TM ) ;
        Ada.Text_IO.Put ( "Timing Event Occured at " ) ;
        D_IO.Put ( To_Duration ( Value ) ) ;
        Ada.Text_IO.New_Line ;
        Counter := Counter + 1 ;

        Start_Time := Ada.Execution_Time.Clock ;
        In_Time := Ada.Real_Time.Milliseconds ( 10 ) ;
        Set_Handler ( TM, In_Time, Handlers.Handler_2'Access ) ;
      end Handler_2 ;

  end Handlers ;


  -- Initialize: Set Algorithm and Counter

  procedure Initialize ( A : in Algorithm_Type ) is
    begin
      Algorithm := A ;
      Counter := 0 ;
    end Initialize ;

end Work_Execution_Time ;

Re: An Example for Ada.Execution_Time

[BrianG]

anon@att.net wrote:
> You ask for an example.
I'll assume I am the "you".  (Since you don't specify and didn't relate 
it to the original thread.)

I asked for:
    >> An algorithm comparison program might look like:
    >>
    >> with Ada.Execution_Time ;
    >> with Ada.Execution_Time.Timers ;
    >Given the below program, please add some of the missing details to
    >show how this can be useful without also "with Ada.Real_Time".
    >Neither Execution_Time or Execution_Time.Timers provides any value
    >that can be used directly.
    >
    >>
    >> procedure Compare_Algorithm is
    >...]

You provided:
> 
> Here is an example for packages (Tested using MaRTE):
...
> with Ada.Execution_Time ;
> with Ada.Real_Time ;
...
> with Ada.Execution_Time ;
> with Ada.Execution_Time.Timers ;
> with Ada.Real_Time ;
...

As the extracts show, you could not do what I asked for.  You said in 
the original post you could do it with only the 2 Execution_Time 
'with's.  My entire point in this thread is that Execution_Time, as 
defined, is useless by itself.

--BrianG

Re: An Example for Ada.Execution_Time

[anon]

In <ifbi5c$rqt$1@news.eternal-september.org>, BrianG <briang000@gmail.com> writes:
>anon@att.net wrote:
>> You ask for an example.
>I'll assume I am the "you".  (Since you don't specify and didn't relate 
>it to the original thread.)
>
>I asked for:
>    >> An algorithm comparison program might look like:
>    >>
>    >> with Ada.Execution_Time ;
>    >> with Ada.Execution_Time.Timers ;
>    >Given the below program, please add some of the missing details to
>    >show how this can be useful without also "with Ada.Real_Time".
>    >Neither Execution_Time or Execution_Time.Timers provides any value
>    >that can be used directly.
>    >
>    >>
>    >> procedure Compare_Algorithm is
>    >...]
>
>You provided:
>> 
>> Here is an example for packages (Tested using MaRTE):
>....
>> with Ada.Execution_Time ;
>> with Ada.Real_Time ;
>....
>> with Ada.Execution_Time ;
>> with Ada.Execution_Time.Timers ;
>> with Ada.Real_Time ;
>....
>
>As the extracts show, you could not do what I asked for.  You said in 
>the original post you could do it with only the 2 Execution_Time 
>'with's.  My entire point in this thread is that Execution_Time, as 
>defined, is useless by itself.
>
>--BrianG

I changed the title so there was no need for reference lines

Since 2006, a number of people have ask about Ada.Execution_Time package 
and no one has given a true example that uses that package for what it was 
created for. Until now! I gave you a simple example that can be easily 
modified to a more complex program. Problem: may be whats the maximum 
number of timers that can be allocated.


and for your info (changes in work.adb)

  Task_0 : Work_Task ;
  Task_1 : Work_Task ;
  Task_2 : Work_Task ;
  Task_3 : Work_Task ;

begin
  Initialize ( Work_Algorithm'Access ) ;
  Task_0.Start ( False ) ;
  Task_1.Start ( False ) ;
  Task_2.Start ( True ) ;  -- just for a change
  Task_3.Start ( True ) ;
  ...

will gives four tasks with four different timers. 

     2 timers that have the same interval 
     2 timers that changes the interval

All that is needed is protect the Counter variable for each task and change the 
Counter print routine. And I will let others do that modification.

Re: An Example for Ada.Execution_Time

[Randy Brukardt]

"BrianG" <briang000@gmail.com> wrote in message 
news:ifbi5c$rqt$1@news.eternal-september.org...
...
> I asked for:
>    >> An algorithm comparison program might look like:
>    >>
>    >> with Ada.Execution_Time ;
>    >> with Ada.Execution_Time.Timers ;
>    >Given the below program, please add some of the missing details to
>    >show how this can be useful without also "with Ada.Real_Time".
>    >Neither Execution_Time or Execution_Time.Timers provides any value
>    >that can be used directly.

This seems like a totally silly question. There are a lot of well-designed 
packages in Ada that don't do anything useful without at least one or more 
other packages. Indeed, if you consider "Standard" to be a separate package 
(and it is), there are hardly any packages that *don't* require some other 
package to be useful.

More to the point, you probably need Ada.IO_Exceptions to use 
Ada.Directories effectively (use of any package without error handling is 
toy use); Ada.Streams.Stream_IO require use of Ada.Streams (a separate 
package, which you will need separate use clauses for even if you get it 
imported automatically); Ada.Strings.Maps aren't useful for anything unless 
you combine them with one of the string handling packages, and so on.

Perhaps you would have been happier if Ada.Execution_Time had been a child 
of Ada.Real_Time (exactly as in the string case), but this wouldn't change 
anything.

The odd thing is that Duration is defined in Standard, rather than some more 
appropriate package. Giving this some sort of religious importance is beyond 
silly...

                                   Randy.

Re: An Example for Ada.Execution_Time

[BrianG]

Randy Brukardt wrote:
> "BrianG" <briang000@gmail.com> wrote in message 
> news:ifbi5c$rqt$1@news.eternal-september.org...
> ...
>>    >Neither Execution_Time or Execution_Time.Timers provides any value
>>    >that can be used directly.
> 
> This seems like a totally silly question. 
> 
> Giving this some sort of religious importance is beyond 
> silly...
> 
>                                    Randy.


Apparently, asking how a package, defined in the standard, was intended 
to be used is now a silly question, and asking for an answer to the 
question I originally asked (which was to clarify a previous response, 
not to provide an example of use) is a religious debate.  I need to 
revise my definitions.

I won't claim to be an expert on the RM, but I don't recall any other 
package (I did look at the ones you mention) that define a private type 
but don't provide operations that make that type useful (for some 
definition of 'use').  Ada.Directories doesn't require Ada.IO_Exceptions 
to use Directory_Entry_Type or Search_Type; Ada.Streams.Stream_IO 
doesn't require Ada.Streams (or Ada.Text_IO) to Create/Open/Read/etc. a 
File_Type.  The only thing provided from a CPU_Time is a count in 
seconds, or another private type.

Since D.16 defines CPU_Time as if it were a numeric value, is it too 
much to ask why a conversion to some form of numeric value wasn't 
provided?  Perhaps either a "-" or To_Duration  (and before anyone 
mentions duplicating the existing function, look at all of the 
Open/Close/Create/etc. for all the *_IO File_Types)?  I wasn't asking 
for anything to be changed, merely "why" - because I originally thought 
there might be some use that I hadn't foreseen.  Apparently not.

(Give the RM definition, making it a child of Real_Time might make it 
seem more logical, I guess, but since CPU_Time is not really a time, and 
is not related to "real time" that doesn't seem to make any sense.  I 
would think that would be all the more reason not to relate it to 
Ada.Real_Time.)

--BrianG

-- don't ask me
-- I'm just improvising
--   my illusion of careless flight
-- can't you see
--   my temperature's rising
-- I radiate more heat than light

Re: An Example for Ada.Execution_Time

[Dmitry A. Kazakov]

On Thu, 30 Dec 2010 18:51:30 -0500, BrianG wrote:

> Since D.16 defines CPU_Time as if it were a numeric value, is it too 
> much to ask why a conversion to some form of numeric value wasn't 
> provided?

But time is not a number and was not defined as if it were. It is the time
differences which are numeric. RM D.14 defines differences of CPU_Time as
Time_Span. Time_Span is numeric.

I think this is the core of misunderstanding. The thing you have in mind is
"time interval since the task start according to the execution time clock."
It is not Ada.Execution_Time.Clock, it is:

   Ada.Execution_Time.Clock - CPU_Time_First

There is a direct correspondence between two, yet they are conceptually
different things.

Happy New Year,

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

Re: An Example for Ada.Execution_Time

[Niklas Holsti]

Dmitry A. Kazakov wrote:
> On Thu, 30 Dec 2010 18:51:30 -0500, BrianG wrote:
> 
>> Since D.16 defines CPU_Time as if it were a numeric value, is it too 
>> much to ask why a conversion to some form of numeric value wasn't 
>> provided?
> 
> But time is not a number and was not defined as if it were.

You keep saying that, Dmitri, but your only argument seems to be the 
absence of some operators like addition for CPU_Time. Since CPU_Time is 
private, we cannot tell if this absence means that the D.14 authors 
considered the type non-numeric, or just considered the operators 
unnecessary for the intended uses.

> It is the time
> differences which are numeric. RM D.14 defines differences of CPU_Time as
> Time_Span. Time_Span is numeric.

CPU_Time is logically numeric, since its "values correspond one-to-one 
with a .. range of mathematical integers" by RM D.14 (12/2). Moreover, 
RM D.14 (13/2) uses the symbol "I" to stand for a value of CPU_Time, and 
then uses "I" as a factor that multiplies a floating-point number. So 
"I" clearly stands for a number (one of the "mathematical integers").

> I think this is the core of misunderstanding. The thing you have in mind is
> "time interval since the task start according to the execution time clock."

I agree with that.

> It is not Ada.Execution_Time.Clock,

It is, since:

- by RM D.14 (17/2), Ada.Execution_Time.Clock returns the "current 
execution time" of the task, and

- by RM D.14 (13/2), "the execution time value is set to zero at the 
creation of the task".

Moreover, the range required of CPU_Time is "from the task start-up to 
50 years of execution time later" (RM D.14 (20/2)). This, too, indicates 
that CPU_Time is not an absolute time point like Ada.Calendar.Time, but 
represents accumulated execution time (duration) from the creation of 
the task.

However, the difference is irrelevant for the programmer, since the 
programmer can get visibly numeric values from CPU_Time only by 
computing the difference of two CPU_Time values as a Time_Span and then 
converting the Time_Span to a Duration.

> it is:
> 
>    Ada.Execution_Time.Clock - CPU_Time_First

No. There is no rule in D.14 that makes CPU_Time_First equal to the 
CPU_Time at the start of a task (which by D.14 (13/2) is "zero"). 
CPU_Time_First is just defined as the smallest value of CPU_Time, 
presumably according to the "<" operator. It might represent a negative 
execution time. The "range of mathematical integers" in D.14 (12/2) may 
include negative numbers -- at least nothing is said to exclude this 
possibility.

I don't know why Ada.Execution_Time does not define a constant called 
CPU_Time_Zero; I think it should. Perhaps CPU_Time_First is meant to 
stand for zero, but this is not stated in D.14.

Overall, I think there may be some confusion in D.14 regarding the 
interpretation of CPU_Time as absolute or relative to the task start. 
The fact that no CPU_Time_Zero is defined suggests that an "absolute" 
interpretation was meant, as does the absence of an operator that adds 
two CPU_Times to yield a CPU_Time sum. Other parts of D.14, such as the 
zero initialization at task creation, suggest the "relative to task 
start" meaning.

As far as I can tell, the only sure way to get the task's execution time 
as a Time_Span or Duration is to read and store the value of 
Ada.Execution_Time.Clock at the start of the task, and then use that in 
Dmitry's subtraction formula instead of CPU_Time_First.

> Happy New Year,

Also to all of you...

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: An Example for Ada.Execution_Time

[Simon Wright]

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

> On Thu, 30 Dec 2010 18:51:30 -0500, BrianG wrote:
>
>> Since D.16 defines CPU_Time as if it were a numeric value, is it too 
>> much to ask why a conversion to some form of numeric value wasn't 
>> provided?
>
> But time is not a number and was not defined as if it were. It is the time
> differences which are numeric. RM D.14 defines differences of CPU_Time as
> Time_Span. Time_Span is numeric.

This is certainly true. However, I remain surprised that .. even delving
back to v1.2 of the AI .. the proposer found it necessary to have this
type CPU_Time. The concept being looked for is the number of seconds
during which *this* task was executing, still sounds like a Duration
(OK, Time_Span if you must) to me.

> I think this is the core of misunderstanding. The thing you have in
> mind is "time interval since the task start according to the execution
> time clock."  It is not Ada.Execution_Time.Clock, it is:
>
>    Ada.Execution_Time.Clock - CPU_Time_First

I don't _think_ that CPU_Time_First is actually defined as the value of
Clock when the task starts (is initialized, put on the ready queue,
whatever).

D14(13/2) says "For each task, the execution time value is set to zero
at the creation of the task."; however, zero is clearly not a value of
CPU_Time, so I don't know what is meant.

> There is a direct correspondence between two, yet they are
> conceptually different things.

I have no idea what's meant by CPU_Time, then! Seems to me it's a giant
bug waiting to happen. It's clear that the CPU_Time of one task is
incommensurate with the CPU_Time of another. Given that, what's it
_for_?


Of course, I competely understand that the Standard is what it is, and
no one's going to change it at this point.

Re: An Example for Ada.Execution_Time

[Dmitry A. Kazakov]

On Fri, 31 Dec 2010 13:05:06 +0000, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Thu, 30 Dec 2010 18:51:30 -0500, BrianG wrote:
>>
>>> Since D.16 defines CPU_Time as if it were a numeric value, is it too 
>>> much to ask why a conversion to some form of numeric value wasn't 
>>> provided?
>>
>> But time is not a number and was not defined as if it were. It is the time
>> differences which are numeric. RM D.14 defines differences of CPU_Time as
>> Time_Span. Time_Span is numeric.
> 
> This is certainly true. However, I remain surprised that .. even delving
> back to v1.2 of the AI .. the proposer found it necessary to have this
> type CPU_Time. The concept being looked for is the number of seconds
> during which *this* task was executing, still sounds like a Duration
> (OK, Time_Span if you must) to me.

Yes, since the epoch is unambiguous: the task start. It does not make much
sense to introduce execution time. Maybe a reason was that introducing
clock returning time span or duration could be strange.

> D14(13/2) says "For each task, the execution time value is set to zero
> at the creation of the task."; however, zero is clearly not a value of
> CPU_Time, so I don't know what is meant.

Yes, Time_Of (0) seem to be the epoch.

>> There is a direct correspondence between two, yet they are
>> conceptually different things.
> 
> I have no idea what's meant by CPU_Time, then! Seems to me it's a giant
> bug waiting to happen. It's clear that the CPU_Time of one task is
> incommensurate with the CPU_Time of another. Given that, what's it
> _for_?

That does not manifest any bug. Except that each task should have had its
own CPU_Time type! Technically, it would be possible to inject an implicit
declaration of a CPU_Time type in the declaration scope of each task. We
could have a task-local "Standard/System" package encapsulating this and
similar stuff. Though, nobody would care to do this.

BTW, you could use CPU_Time as a simulation time within the task. E.g. you
could have subtasks scheduled by the task. The scheduler would use the
CPU_Time in order to activate/deactivate/re-schedule them, periodically
according to the CPU_Time, rather than the system time.

Happy New Year,

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

Re: An Example for Ada.Execution_Time

[Dmitry A. Kazakov]

On Fri, 31 Dec 2010 14:42:41 +0200, Niklas Holsti wrote:

> Dmitry A. Kazakov wrote:
>> On Thu, 30 Dec 2010 18:51:30 -0500, BrianG wrote:
>> 
>>> Since D.16 defines CPU_Time as if it were a numeric value, is it too 
>>> much to ask why a conversion to some form of numeric value wasn't 
>>> provided?
>> 
>> But time is not a number and was not defined as if it were.
> 
> You keep saying that, Dmitri, but your only argument seems to be the 
> absence of some operators like addition for CPU_Time. Since CPU_Time is 
> private, we cannot tell if this absence means that the D.14 authors 
> considered the type non-numeric, or just considered the operators 
> unnecessary for the intended uses.

No, the argument is that time is a state of some recurrent process, like
the position of an Earth's meridian relatively to the Sun. This state is
not numeric, it could be numeric though. That depends on the nature of the
process. 

>> It is the time
>> differences which are numeric. RM D.14 defines differences of CPU_Time as
>> Time_Span. Time_Span is numeric.
> 
> CPU_Time is logically numeric, since its "values correspond one-to-one 
> with a .. range of mathematical integers" by RM D.14 (12/2). Moreover, 
> RM D.14 (13/2) uses the symbol "I" to stand for a value of CPU_Time, and 
> then uses "I" as a factor that multiplies a floating-point number. So 
> "I" clearly stands for a number (one of the "mathematical integers").

No, this stands only for countability. Time is not a number, it can be
represented in the form Epoch + n * Interval, where n is a number.

> - by RM D.14 (13/2), "the execution time value is set to zero at the 
> creation of the task".

I agree that here RM is sloppy. They should rather talk about an "epoch"
rather than "zero," if they introduced CPU_Time as a time.
 
>>    Ada.Execution_Time.Clock - CPU_Time_First
> 
> No. There is no rule in D.14 that makes CPU_Time_First equal to the 
> CPU_Time at the start of a task (which by D.14 (13/2) is "zero"). 

OK, I agree with that. Correction:

   Ada.Execution_Time.Clock - Ada.Execution_Time.Time_Of (0)

> As far as I can tell, the only sure way to get the task's execution time 
> as a Time_Span or Duration is to read and store the value of 
> Ada.Execution_Time.Clock at the start of the task, and then use that in 
> Dmitry's subtraction formula instead of CPU_Time_First.

I suppose Time_Of (0) is the time when the task started because of D.14
(13/2).

Happy New Year,

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

Re: An Example for Ada.Execution_Time

[Robert A Duff]

Simon Wright <simon@pushface.org> writes:

> Of course, I competely understand that the Standard is what it is, and
> no one's going to change it at this point.

I haven't followed most of this (long!) discussion, but if
somebody reports a bug to ada-comment, and the ARG agrees
that it's sufficiently broken, then the standard will
get changed.  (Eventually.  ARG is just a bunch of
volunteers, who only meet for about 8 days per year.)

- Bob

Re: An Example for Ada.Execution_Time

[Niklas Holsti]

Dmitry A. Kazakov wrote:
> On Fri, 31 Dec 2010 14:42:41 +0200, Niklas Holsti wrote:
> 
>> Dmitry A. Kazakov wrote:
>>> On Thu, 30 Dec 2010 18:51:30 -0500, BrianG wrote:
>>>
>>>> Since D.16 defines CPU_Time as if it were a numeric value, is it too 
>>>> much to ask why a conversion to some form of numeric value wasn't 
>>>> provided?
>>> But time is not a number and was not defined as if it were.
>> You keep saying that, Dmitri, but your only argument seems to be the 
>> absence of some operators like addition for CPU_Time. Since CPU_Time is 
>> private, we cannot tell if this absence means that the D.14 authors 
>> considered the type non-numeric, or just considered the operators 
>> unnecessary for the intended uses.
> 
> No, the argument is that time is a state of some recurrent process, like
> the position of an Earth's meridian relatively to the Sun. This state is
> not numeric, it could be numeric though. That depends on the nature of the
> process.

This is your view of what the English word "time" means. It is not based 
on any text in the RM, as far as I can see. (And I don't see what 
"recurrent process" has to do with it. Time could also be measured by 
radioactive decay, for example, which is not recurrent. Or by water 
clocks, also not recurrent as long as the water lasts. Using recurrent 
processes like oscillators, rotators, or orbiters is just a good way to 
measure time accurately by counting periods.)

I have also tried to understand D.14 by interpreting its English words, 
like "time", but Randy says that this is "reading stuff that is not 
there". I don't entirely agree with him. For CPU_Time I think that D.14 
shows sufficiently clearly that it has a numeric meaning.

>> - by RM D.14 (13/2), "the execution time value is set to zero at the 
>> creation of the task".
> 
> I agree that here RM is sloppy. They should rather talk about an "epoch"
> rather than "zero," if they introduced CPU_Time as a time.

So, here the RM disagrees with your view that CPU_Time is not numeric, 
and your conclusion is that the RM is wrong? I am not convinced.

> I suppose Time_Of (0) is the time when the task started because of D.14
> (13/2).

Good point, I did not think of Time_Of (0) as a replacement for the 
(missing) CPU_Time_Zero constant.

So, even if we don't agree on the numeric or non-numeric nature of 
CPU_Time, we do agree on how to use Ada.Execution_Time.Clock to compute 
the execution time. Good!

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: An Example for Ada.Execution_Time

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

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

>> I think this is the core of misunderstanding. The thing you have in
>> mind is "time interval since the task start according to the
>> execution time clock."  It is not Ada.Execution_Time.Clock, it is:
>>
>>    Ada.Execution_Time.Clock - CPU_Time_First
>
> I don't _think_ that CPU_Time_First is actually defined as the value
> of Clock when the task starts (is initialized, put on the ready queue,
> whatever).

I think (from having had a look at GNAT GPL 2010's sources) that you are
right to suggest Time_Of (0) in place of CPU_Time_First (in GNAT's
implementation, the latter is Duration'First!).

Or Niklas's suggestion of the missing CPU_Time_Zero.

Re: An Example for Ada.Execution_Time

[Randy Brukardt]

"BrianG" <briang000@gmail.com> wrote in message 
news:ifj5u9$rr5$1@news.eternal-september.org...
> Randy Brukardt wrote:
>> "BrianG" <briang000@gmail.com> wrote in message 
>> news:ifbi5c$rqt$1@news.eternal-september.org...
>> ...
>>>    >Neither Execution_Time or Execution_Time.Timers provides any value
>>>    >that can be used directly.
>>
>> This seems like a totally silly question. Giving this some sort of 
>> religious importance is beyond silly...
>>
>>                                    Randy.
>
>
> Apparently, asking how a package, defined in the standard, was intended to 
> be used is now a silly question, and asking for an answer to the question 
> I originally asked (which was to clarify a previous response, not to 
> provide an example of use) is a religious debate.  I need to revise my 
> definitions.

But you didn't ask how a package defined in the standard was intended to be 
used. You asked why you have to use another package (Ada.Real_Time) in order 
for it to be useful. And you've repeated that over and over and over like it 
was meaningful in some way. But that is pretty much the definition of a 
silly question. It's just the way the package was defined, and it doesn't 
matter beyond having to add one additional "with" clause.

And that's pretty much irrelevant. In real Ada programs, there are many with 
clauses in the average compilation unit. In Janus/Ada, the number of withs 
averages 20 or so, and Claw programs are much higher than that. One could 
reduce those numbers by putting everything into a few massive packages, but 
those would be unweldy, poorly encapuslated, and close to unmaintainable.

The need to add one extra with to use a real-time package just falls into 
the noise. Probably it would have been better to offer the option of 
retrieving a value in terms of Duration, but it is just not a significant 
difference.

The answer to the "how do you use" question is simple and has been provided 
many times: use "-" to get a Time_Span, operate on that, and why that would 
be a problem to you or anyone else is beyond my comprehension.

> I won't claim to be an expert on the RM, but I don't recall any other 
> package (I did look at the ones you mention) that define a private type 
> but don't provide operations that make that type useful (for some 
> definition of 'use').  Ada.Directories doesn't require Ada.IO_Exceptions 
> to use Directory_Entry_Type or Search_Type; Ada.Streams.Stream_IO doesn't 
> require Ada.Streams (or Ada.Text_IO) to Create/Open/Read/etc. a File_Type. 
> The only thing provided from a CPU_Time is a count in seconds, or another 
> private type.

Here I completely disagree. If you plan to do anything *practical* with the 
Ada.Directories types, you'll have to use another package (at least 
Ada.Text_IO) to do something with the results. (Indeed, that is true of 
*all* Ada packages -- you have to do I/O somewhere or the results are 
irrelevant.  And you are wrong about Stream_IO.Read; you have to use a 
Stream_Element_Array in order to do that, and that is in Ada.Streams, not in 
Stream_IO.

In any case, I'm done wasting my time answering this question. It's obvious 
that you have lost you mind vis-a-vis this question, and there is no reason 
to waste any more time if/until you get it back. Do not feed the troll (even 
if the troll is someone that is otherwise reasonable).

                                                    Randy.

Re: An Example for Ada.Execution_Time

[Dmitry A. Kazakov]

On Fri, 31 Dec 2010 20:57:54 +0200, Niklas Holsti wrote:

> Dmitry A. Kazakov wrote:
>> On Fri, 31 Dec 2010 14:42:41 +0200, Niklas Holsti wrote:
>> 
>>> Dmitry A. Kazakov wrote:
>>>> On Thu, 30 Dec 2010 18:51:30 -0500, BrianG wrote:
>>>>
>>>>> Since D.16 defines CPU_Time as if it were a numeric value, is it too 
>>>>> much to ask why a conversion to some form of numeric value wasn't 
>>>>> provided?
>>>> But time is not a number and was not defined as if it were.
>>> You keep saying that, Dmitri, but your only argument seems to be the 
>>> absence of some operators like addition for CPU_Time. Since CPU_Time is 
>>> private, we cannot tell if this absence means that the D.14 authors 
>>> considered the type non-numeric, or just considered the operators 
>>> unnecessary for the intended uses.
>> 
>> No, the argument is that time is a state of some recurrent process, like
>> the position of an Earth's meridian relatively to the Sun. This state is
>> not numeric, it could be numeric though. That depends on the nature of the
>> process.
> 
> This is your view of what the English word "time" means.

The English word "time" it has many meanings.

> It is not based on any text in the RM, as far as I can see.

It is based on the fact that RM always introduces a distinct type, when it
means duration, time interval, period, e.g.: Duration, Time_Span. When RM
uses a type named "time," it does not mean duration. This why it does not
declare it numeric. It does not provide addition of times or multiplication
by a scalar, which were appropriate if time were numeric or had the meaning
duration. CPU_Time is handled accordingly. D.14 reuses Time_Span for
intervals of CPU_Time, which stresses the difference. If this is not clean,
then, not because CPU_Time is duration, it is because CPU_Time can be (and
is) unrelated to the source of Ada.Real_Time.Time. Thus reusing Time_Span
for its intervals questionable. It would be better to introduce a separate
type for this, e.g. CPU_Time_Interval. Furthermore, the CPU_Time type
should be local to the task, preventing its usage anywhere outside the
task, while CPU_Time_Interval could be same for all tasks.

>>> - by RM D.14 (13/2), "the execution time value is set to zero at the 
>>> creation of the task".
>> 
>> I agree that here RM is sloppy. They should rather talk about an "epoch"
>> rather than "zero," if they introduced CPU_Time as a time.
> 
> So, here the RM disagrees with your view that CPU_Time is not numeric,

No it does not. "Zero" is not a numeric term, it denotes a specific element
of a group (an additive identity element), zero object (an initial
element). The number named "zero" is a special case, when the group is
numeric.

RM is consistent here, but, as I said, sloppy, because the zero element of
a time system has a specific name: "epoch." RM uses this term in D.8, so
should it do here.

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

Re: An Example for Ada.Execution_Time

[Niklas Holsti]

Dmitry A. Kazakov wrote:
> On Fri, 31 Dec 2010 20:57:54 +0200, Niklas Holsti wrote:
> 
>> Dmitry A. Kazakov wrote:
>>> On Fri, 31 Dec 2010 14:42:41 +0200, Niklas Holsti wrote:
>>>
>>>> Dmitry A. Kazakov wrote:
>>>>> On Thu, 30 Dec 2010 18:51:30 -0500, BrianG wrote:
>>>>>
>>>>>> Since D.16 defines CPU_Time as if it were a numeric value, is it too 
>>>>>> much to ask why a conversion to some form of numeric value wasn't 
>>>>>> provided?
>>>>> But time is not a number and was not defined as if it were.
>>>> You keep saying that, Dmitri, but your only argument seems to be the 
>>>> absence of some operators like addition for CPU_Time. Since CPU_Time is 
>>>> private, we cannot tell if this absence means that the D.14 authors 
>>>> considered the type non-numeric, or just considered the operators 
>>>> unnecessary for the intended uses.
>>> No, the argument is that time is a state of some recurrent process, like
>>> the position of an Earth's meridian relatively to the Sun. This state is
>>> not numeric, it could be numeric though. That depends on the nature of the
>>> process.
>> This is your view of what the English word "time" means.
> 
> The English word "time" it has many meanings.

Yes indeed....

Dmitry, I think we are arguing this point -- whether 
Ada.Execution_Time.CPU_Time has "numeric" values -- from different 
personal definitions of what "numeric" means, so we are not going to 
agree, and should stop.

Meanwhile, I was reminded that the Ada RM actually defines "numeric 
type" as an integer or real type (RM 3.5(1)). Since CPU_Time and 
Time_Span etc. are all private types, and the RM does not say if they 
are implemented as integer or real types, we cannot know if they are 
"numeric types" using RM terms. Let's stop here, OK?

> It is based on the fact that RM always introduces a distinct type, when it
> means duration, time interval, period, e.g.: Duration, Time_Span. When RM
> uses a type named "time," it does not mean duration.

Yes, I agree that this is the RM principle, but I also think it is a 
different question. You may remember that Randy said that the ARG had 
discussions about type names for Ada.Execution_Time, and were not very 
happy with the name "CPU_Time" (as I understood Randy, at least).

Note that RM D.14 does not say that CPU_Time is a "time type" as "time 
types" are defined in RM 9.6. In contrast, Ada.Real_Time.Time is a "time 
type".

> D.14 reuses Time_Span for
> intervals of CPU_Time, which stresses the difference. If this is not clean,
> then, not because CPU_Time is duration, it is because CPU_Time can be (and
> is) unrelated to the source of Ada.Real_Time.Time.

I definitely don't agree that CPU_Time can be unrelated to the source of 
Ada.Real_Time.Time in an Ada system that is useful for real-time 
programming. Execution time may be measured with a different clock or 
timer than Ada.Real_Time.Time but the rates of the two times must be 
very closely the same while one task is executing. Otherwise 
Ada.Execution_Time would be useless.

Perhaps you mean that CPU_Time is unrelated to Ada.Real_Time.Time over 
longer periods during which the task is sometimes executing, sometimes 
not. Then I agree that the two times increase at different rates, of course.

> Thus reusing Time_Span for its intervals questionable. It would
> be better to introduce a separate type for this, e.g. CPU_Time_Interval.

I strongly disagree, because that would abandon the commensurability of 
CPU_Time (or its intervals) with real time and would destroy the 
usefulness of Ada.Execution_Time in real-time systems.

> Furthermore, the CPU_Time type should be local to the task,

It could be reasonable to have different CPU_Time types for each task. I 
can't immediately think of any reason for comparing or subtracting 
CPU_Time values across tasks. But I don't think this can be implemented 
in Ada.

> preventing its usage anywhere outside the task,

This would prevent or hamper the implementation of scheduling algorithms 
that monitor the execution times of several tasks. I object to it.

> while CPU_Time_Interval could be same for all tasks.

Definitely. And it must be the same as Ada.Real_Time.Time_Span or 
Duration for real-time scheduling purposes.

> RM is consistent here, but, as I said, sloppy, because the zero element of
> a time system has a specific name: "epoch."  RM uses this term in D.8, so
> should it do here.

Manfully resisting the strong temptation to continue to argue about the 
"numeric" issue, based on your statements about "zero", I want to 
comment on this "epoch" thing.

One of the differences between Ada.Real_Time.Time and 
Ada.Execution_Time.CPU_Time is that the epoch for the former is not 
specified in the RM. It follows that even if Ada.Real_Time.Time had a 
visibly numeric value, its meaning would be unknown to the program.

In contrast, the epoch for CPU_Time is specified in the RM: the creation 
of the task, a point in real time known to the program. This brings 
CPU_Time closer to the meaning of Duration or Time_Span. If CPU_Time had 
a visibly numeric value, its meaning would be known: the total execution 
time of the task since the program created the task.

I think the main reason why RM D.14 defines a specific type CPU_Time, 
instead of directly using Duration or Time_Span, is the large range 
required of CPU_Time: up to 50 years. Time_Span is required to hold only 
+- 1 hour, and Duration only +- 1 day.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: An Example for Ada.Execution_Time

[Dmitry A. Kazakov]

On Sat, 01 Jan 2011 22:25:30 +0200, Niklas Holsti wrote:

> Perhaps you mean that CPU_Time is unrelated to Ada.Real_Time.Time over 
> longer periods during which the task is sometimes executing, sometimes 
> not.

I mean that

1. The corresponding clocks can be different. Ada cannot influence this.

2. The clocks are not synchronized, i.e. T1 on the Ada.Real_Time.Clock
cannot be translated into T2 on the Ada.Execution_Time.Clock.

> One of the differences between Ada.Real_Time.Time and 
> Ada.Execution_Time.CPU_Time is that the epoch for the former is not 
> specified in the RM. It follows that even if Ada.Real_Time.Time had a 
> visibly numeric value, its meaning would be unknown to the program.
> 
> In contrast, the epoch for CPU_Time is specified in the RM: the creation 
> of the task, a point in real time known to the program.

That does not define it either. An epoch cannot be defined otherwise than
in terms of other clock. The task start time according to
Ada.Real_Time.Time or Ada.Calendar.Time is unknown.

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