Re: An Example for Ada.Execution_Time

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

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
       .      @       .