Re: Ada.Execution_Time

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sat, 18 Dec 2010 23:20:20 +0200, Niklas Holsti wrote:

> Dmitry A. Kazakov wrote:
>> On Fri, 17 Dec 2010 13:50:26 +0200, Niklas Holsti wrote:
>> 
> Next, we can argue if quarks have physical meaning, or if only hadrons 
> do... :-)

I thought about it! (:-)) But the example of a "half of a car" might be
better.

> The concept and measurement of "the execution time of a task" does 
> become problematic in complex processors that have hardware 
> multi-threading and can run several tasks in more or less parallel 
> fashion, without completely isolating the tasks from each other. 

No, the concept is just fine, it is the interpretation of the measured
values in the way you wanted, which causes problems. That is the core of my
point. The measure is not real time.

>>> By "CPU frequency slowdowns" I assume you mean a system that varies the 
>>> CPU clock frequency, for example to reduce energy consumption when load 
>>> is low. This do not necessarily conflict with Ada.Execution_Time and the 
>>> physical meaning of CPU_Time, although it may make implementation 
>>> harder. One implementation could be to drive the CPU-time counter by a 
>>> fixed clock (a timer clock), not by the CPU clock.
>> 
>> I am not a language lawyer, but I bet that an implementation of
>> Ada.Execution_Time.Split that ignores any CPU frequency changes when
>> summing up processor ticks consumed by the task would be legal.
> 
> Whether or not such an implementation is formally legal, that would 
> require very perverse interpretations of the text in RM D.14.

RM D.14 defines CPU_Tick constant, of which physical equivalent (if we
tried to enforce your interpretation) is not constant for many CPU/OS
combinations. On a such platform the implementation would be as perverse as
RM D.14 is. But the perversion is only because of the interpretation.

> (In fact, some variable-frequency 
> scheduling methods may prefer to measure task "execution times" in units 
> of processor ticks, not in real-time units like seconds.)

Exactly. As a simulation time RM D.14 is perfectly OK. It can be used for
CPU load estimations, while the "real time" implementation could not. BTW,
even for measurements people usually have in mind (e.g. comparing resources
consumed by tasks), simulation time would be more fair. The problem is with
I/O, because I/O is a "real" thing.

> But the 
> implementation could not implement the function "-" (Left, Right : 
> CPU_Time) return Time_Span to give a meaningful result, with the normal 
> meaning of Time_Span, since the result would be the same Time_Span for a 
> high CPU frequency and for a low one.

The result is not meaningful as real time, but it is as simulation time.

> Moreover, an Ada RTS running on 
> Windows could of course use another clock or timer to measure execution 
> time, if the Windows functionality is unsuitable.

I read one study of Java RTS, unfortunately I lost the link. They faced
this problem. In order to measure the real (statistically unbiased etc) CPU
time, they implemented a Windows driver or service (I don't remember if
they also had some hardware), which monitored, frequently enough, the
thread occupying the processor. Ada RTS could use a similar technique.
However even this were not enough, one should really hook on the OS
scheduler to get fair real CPU time.

BTW, I never checked Linux or VxWorks for that. Anybody knows if it were
possible to implement RM D.14 in this interpretation under these OSes?

The requirement is that the OS scheduler accumulated the differences
between the RT clock readings when the task lost and gained the processor.
From what I know about VxWorks, I doubt it much.

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