Re: Ada.Execution_Time

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

Randy Brukardt wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
> news:8o8ptdF35oU1@mid.individual.net...
>> Randy Brukardt wrote:
>>> I think we're actually in agreement on most points.
>> Good, and I agree. Nevertheless I again make a lot of comments, below, 
>> because I think your view, if true, means that Ada.Execution_Time is 
>> useless for real-time systems.
> 
> Much like "unmeasurable", "useless" is a little bit strong, but this is 
> definitely true in general.
> 
> That is, if you can afford megabucks to have a compiler runtime tailored to 
> your target hardware (and compiler vendors love such customers),

The cost will depend on the number of users/customers and the extent of 
tailoring needed; I admit I haven't asked for quotes.

At least the definition of a predefined, standard programmer interface 
in the form of Ada.Execution_Time and children should help make the 
tailoring more portable over targets, applications, and customers.

> then you probably could find a use for in a hard real-time system.

I think so.

> But the typical off-the-shelf implementation is not going to be useful for 
> anything beyond gross guidance.

Depends on which shelf you buy from :-)  You are probably right for GNAT 
GPL on Linux, but perhaps there is more hope for RAVEN and the like. 
Although I see that Ravenscar excludes Ada.Execution_Time.

> That's probably enough for soft real-time 
> systems anyway; and the facilities are useful for profiling and the like 
> even without any strong connection to reality.

I don't see how Ada.Execution_Time would be very useful for profiling. 
While it could show you which tasks are CPU hogs, it does not resolve 
the execution-time consumption to subprograms or subprogram parts, which 
I think would be the important information for code redesigns aiming at 
improving speed. Real profilers usually do give you subprogram-level or 
even statement-level information.

Of course, a profiler that collects subprogram-level execution time (per 
call, for example) but does not know about Ada task preemption will 
probably produce wildly wrong results.

> ... unless you have a very 
> controlled environment. And if you have that environment, a
> language-defined package doesn't buy you anything over
> roll-your-own.

I don't agree. I think a clean, standard, language-defined interface 
between the Ada RTS/kernel and the application will help an implementer, 
as I said above. Moreover, the scheduling algorithms published by Burns 
and Wellings and others are written to use Ada.Execution_Time. Rolling 
one's own interface would mean changing these algorithms.

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