Re: Ada.Execution_Time

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

Dmitry A. Kazakov wrote:
> On Fri, 17 Dec 2010 13:50:26 +0200, Niklas Holsti wrote:
> 
>> Dmitry A. Kazakov wrote:
>>> On Fri, 17 Dec 2010 10:49:26 +0200, Niklas Holsti wrote:
>>>
>>>> Dmitry A. Kazakov wrote:
>>>>> CPU_Time has no physical meaning. 2s might be 2.5s
>>>>> real time or 1 year real time.
>>>> CPU_Time values have physical meaning after being summed over all tasks. 
>>>> The sum should be the real time, as closely as possible.
>>> 1. Not tasks, but threads + kernel services + kernel drivers + CPU
>>> frequency slowdowns => a) wrong; b) out of Ada scope => cannot be mandated
>> I believe we are talking about the intended meaning of 
>> Ada.Execution_Time.CPU_Time, not about how far it can be precisely 
>> "mandated" (standardized).
>>
>> Appendix D is about real-time systems, and I believe it is aimed in 
>> particular at systems built with Ada tasks and the Ada RTS. In such 
>> systems there may or may not be CPU time -- "overhead" -- that is not 
>> included in the CPU_Time of any task. See the last sentence in RM D.14 
>> 11/2: "It is implementation defined which task, if any, is charged the 
>> execution time that is consumed by interrupt handlers and run-time 
>> services on behalf of the system". In most systems there will be some 
>> such non-task overhead, but in a "pure Ada" system it should be small 
>> relative to the total CPU_Time of the tasks.
> 
> Yes, this is what I meant. CPU_Time does not have the meaning:
> 
> "CPU_Time values have physical meaning after being summed over all tasks. 
> The sum should be the real time, as closely as possible."

I said "as closely as possible", and I don't expect to find many systems 
in which they are exactly equal. But I still think that this (ideally 
exact, in practice approximate) relationship reflects the intended 
physical meaning of Ada.Execution_Time.CPU_Time: the elapsed real time 
(Time_Span) is divided into task execution times (CPU_Time) through task 
scheduling.

> Anyway, even if the sum of components has a physical meaning that does not
> imply that the components have it.

If you have only one task, the sum is identical to the term, so their 
physical meanings are the same. Generalize for the case of many tasks.

Next, we can argue if quarks have physical meaning, or if only hadrons 
do... :-)

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. 
Schedulability analysis in such systems is difficult since the 
"execution time" of a task depends on which other tasks are running at 
the same 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.  You would 
have to argue that a system with a lowered CPU clock frequency, running 
a single task with no interrupts, is only "executing the task" for a 
small part of each clock cycle, and the rest of each clock cycle is 
spent on some kind of system overhead. I don't think that is what the RM 
authors intended.

You may be right that the RM has no formal requirement that would 
prevent such an implementation. (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.) 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.

>>> 2. Not so anyway under many OSes => again, cannot be mandated
>> Whether or not all OSes support the concepts of Ada.Execution_Time is 
>> irrelevant to a discussion of the intended meaning of CPU_Time.
> 
> ARM usually does not intend what would be impossible to implement.

Not all OSes are designed for real-time systems. As I understand it, the 
ARM sensibly intends Annex D to be implemented in real-time OSes or in 
bare-Ada-RTS systems, not under Windows.

Even under Windows, as I understand earlier posts in this thread, 
problems arise only if task interruptions, suspensions, and preemptions 
are so frequent that the "quant" truncation is a significant part of the 
typical uninterrupted execution 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.

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