Re: Ada.Execution_Time

[BrianG <briang000@gmail.com>]

Randy Brukardt wrote:
> "BrianG" <briang000@gmail.com> wrote in message 
> news:ie91co$cko$1@news.eternal-september.org...
> ...
>> My problem is that what is provided in the package in question does not 
>> provide any "values suitable for arithmetic" or provide "an object 
>> suitable for print" (unless all you care about is the number of whole 
>> seconds with no information about the (required) fraction, which seems 
>> rather limiting).
> 
> Having missed your original question, I'm confused as to where you are 
> finding the quoted text above. I don't see anything like that in the 
> Standard. Since it is not in the standard, there is no reason to expect 
> those statements to be true. (Even the standard is wrong occassionally, 
> other materials are wrong a whole lot more often.)
> 
The quoted text was from the post I responded to.  It was Georg's 
attempt to explain the package.  I agree that they are not in the RM; my 
original question was what is the intended purpose of the package - the 
content doesn't seem useful for any use I can think of.

>>  Time_Span is a private type, defined in another package.  If all I want 
>> is CPU_Time (in some form), why do I need Ada.Real_Time?  Also, why are 
>> "+" and "-" provided as they are defined? (And why Time_Span?  I thought 
>> that was the difference between two times, not the fractional part of 
>> time.)
> 
> I think you are missing the point of CPU_Time. It is an abstract 
> representation of some underlying counter. There is no requirement that this 
> counter have any particular value -- in particular it is not necessarily 
> zero when a task is created. So the only operations that are meaningful on a 
> value of type CPU_Time are comparisons and differences. Arguably, CPU_Time 
> is misnamed, because it is *not* some sort of time type.
Then the package is misnamed too - How is "Execution_Time" not a time? 
Wouldn't tying it explicitly to Real_Time imply some relation to "real 
time" (whether that makes sense or not)?  Using Duration could help 
that, since it's implementation-defined.

One of my problems is that difference (and sum) isn't provided between 
CPU_Time's, only with a Time_Span.  But you can only convert a portion 
of a CPU_Time to Time_Span.  When is that useful (as opposed to 
Splitting both CPU_Times)?

A function "-" (L, R : CPU_Time) return Time_Span (or better, Duration) 
would be required for what you describe above (actually, if what you say 
is true, then that and Clock are all that's required).

> 
> The package uses Ada.Real_Time because no one wanted to invent a new kind of 
> time. The only alternative would have been to use Calendar, which does not 
> have to be as accurate. (Of course, the real accuracy depends on the 
> underlying target; CPU_Time has to be fairly inaccurate on Windows simply 
> because the underlying counters are not very accurate, at least in the 
> default configuration.)
(I think that is inherent in anything of this type, but I'd think it's 
hard to specify that in the RM:)
> 
> My guess is that no one thought about the fact that Time_Span is only an 
> alias for Duration; it's definitely something that I didn't know until you 
> complained. (I know I've confused Time and Time_Span before, must have done 
> that here, too). So there probably was no good reason that Time_Span was 
> used instead of Duration in the package. But that seems to indicate a flaw 
> in Ada.Real_Time, not one for execution time.
I wasn't aware that it was an alias.  I had assumed it was there in case 
Duration didn't have the range or precision required for Time_Span (or 
something like that).

The other part of my problem is that I can only convert to another 
private type (for part of the value).  It seems to me equivalent to 
defining Sequential_IO and Direct_IO (etc) without File_Type - requiring 
the use of Text_IO any time you want to Open, Close, etc a file.  :-)

> 
> In any case, the presumption is that interesting CPU_Time differences are 
> relatively short, so that Time_Span is sufficient (as it will hold at least 
> one day).
But that is not provided - that would require a "-" between two 
CPU_Time's returning a Time_Span.  Unless all CPU_Time's are always less 
than a second, you can't get there easily.

> 
>> Given the rest of this thread, I would guess my answer is "No, no one 
>> actually uses Ada.Execution_Time".
> 
> Can't answer that. I intended to use it to replace some hacked debugging 
> code, but I've never gotten around to actually implementing it (I did do a 
> design, but there is of course a difference...).
> 
>                                   Randy.
>