Ada.Execution_Time

Ada.Execution_Time

[BrianG]

Has anyone actually used Ada.Execution_Time?  How is it supposed to be used?

I tried to use it for two (what I thought would be) simple uses: 
display the execution time of one task and sum the of execution time of 
a group of related tasks.

In both cases, I don't see anything in that package (or in 
Ada.Real_Time, which appears to be needed to use it) that provides any 
straightforward way to use the value reported.

For display, you can't use CPU_Time directly, since it's private.  You 
can Split it, but you get a Time_Span, which is also private.  So the 
best you can do is Split it, and then convert the parts to a type that 
can be used (like duration).

For summing, there is "+", but only between CPU_Time and Time_Span, so 
you can't add two CPU_Times.  Perhaps you can use Split, sum the 
seconds, and then use "+" to add the fractions to the next Clock (before 
repeating Split/add/"+" with it, then you need to figure out what to do 
with the last fractional second), but that seems an odd intended use.

The best I could come up with was to create my own function, like this 
(using the same definition for T as in Clock), which can be used for both:

function Task_CPU_Time return Duration (T : ...) is
    Sec      : Ada.Execution_Time.Seconds_Count;
    Fraction : Ada.Real_Time.Time_Span;
begin
    Ada.Execution_Time.Split(Ada.Execution_Time.Clock(T), Sec, Fraction);
    return To_Duration(Ada.Real_Time.Seconds(Integer(Sec)))
         + To_Duration(Fraction);
end Task_CPU_Time;

Wouldn't it make sense to put something like this into that package? 
Then, at least, there'd be something that's directly available to use - 
and you wouldn't need another package.  (I'm not sure about the 
definitions of CPU_Time and Duration, and whether the conversions would 
be guaranteed to work.)

--BrianG

Re: Ada.Execution_Time

[Jeffrey Carter]

On 12/11/2010 09:19 PM, BrianG wrote:
>
> function Task_CPU_Time return Duration (T : ...) is
> Sec : Ada.Execution_Time.Seconds_Count;
> Fraction : Ada.Real_Time.Time_Span;
> begin
> Ada.Execution_Time.Split(Ada.Execution_Time.Clock(T), Sec, Fraction);
> return To_Duration(Ada.Real_Time.Seconds(Integer(Sec)))
> + To_Duration(Fraction);
> end Task_CPU_Time;

I think you're over complicating things.

function To_Duration (Time : Ada.Execution_Time.CPU_Time) return Duration is
    Seconds  : Ada.Real_Time.Seconds_Count;
    Fraction : Ada.Real_Time.Time_Span;
begin -- To_Duration
    Ada.Execution_Time.Split (Time, Seconds, Fraction);

    return Duration (Seconds) + Ada.Real_Time.To_Duration (Fraction);
end To_Duration;

-- 
Jeff Carter
"This school was here before you came,
and it'll be here before you go."
Horse Feathers
48

Re: Ada.Execution_Time

[Jeffrey Carter]

On 12/11/2010 09:19 PM, BrianG wrote:
>
> function Task_CPU_Time return Duration (T : ...) is
> Sec : Ada.Execution_Time.Seconds_Count;
> Fraction : Ada.Real_Time.Time_Span;
> begin
> Ada.Execution_Time.Split(Ada.Execution_Time.Clock(T), Sec, Fraction);
> return To_Duration(Ada.Real_Time.Seconds(Integer(Sec)))
> + To_Duration(Fraction);
> end Task_CPU_Time;

I think you're over complicating things.

function To_Duration (Time : Ada.Execution_Time.CPU_Time) return Duration is
    Seconds  : Ada.Real_Time.Seconds_Count;
    Fraction : Ada.Real_Time.Time_Span;
begin -- To_Duration
    Ada.Execution_Time.Split (Time, Seconds, Fraction);

    return Duration (Seconds) + Ada.Real_Time.To_Duration (Fraction);
end To_Duration;

-- 
Jeff Carter
"This school was here before you came,
and it'll be here before you go."
Horse Feathers
48

Re: Ada.Execution_Time

[BrianG]

Jeffrey Carter wrote:
> On 12/11/2010 09:19 PM, BrianG wrote:
>>
...
> I think you're over complicating things.
> 
> function To_Duration (Time : Ada.Execution_Time.CPU_Time) return 
> Duration is
>    Seconds  : Ada.Real_Time.Seconds_Count;
>    Fraction : Ada.Real_Time.Time_Span;
> begin -- To_Duration
>    Ada.Execution_Time.Split (Time, Seconds, Fraction);
> 
>    return Duration (Seconds) + Ada.Real_Time.To_Duration (Fraction);
> end To_Duration;
> 
That's what I get for evolving thru several iterations before coming up 
with a function.  (BTW, where is To_Duration defined for integer types? 
  The only one in the Index is for Time_Span.)

But my question still remains:  What's the intended use of 
Ada.Execution_Time?  Is there an intended use where its content 
(CPU_Time, Seconds_Count and Time_Span, "+", "<", etc.) is useful?

--BrianG

Re: Ada.Execution_Time

[BrianG]

BrianG wrote:
> Jeffrey Carter wrote:
>> On 12/11/2010 09:19 PM, BrianG wrote:
> ...
>                   (BTW, where is To_Duration defined for integer types? 
>  The only one in the Index is for Time_Span.)
OOPS, forget that part.  I misread your code.

Re: Ada.Execution_Time

[Georg Bauhaus]

On 12/12/10 10:59 PM, BrianG wrote:


> But my question still remains: What's the intended use of Ada.Execution_Time? Is there an intended use where its content (CPU_Time, Seconds_Count and Time_Span, "+", "<", etc.) is useful?

I think that your original posting mentions a use that is quite
consistent with what the rationale says: each task has its own time.
Points in time objects can be split into values suitable for
arithmetic, using Time_Span objects.  Then, from the result of
arithmetic, produce an object suitable for print, as desired.


While this seems like having to write a bit much,
it makes things explicit, like Ada forces one to be
in many cases.   That' how I explain the series of
steps to myself.

Isn't it just like "null;" being required to express
the null statement?  It seems to me to be a logical
consequence of requiring that intents must be stated
explicitly.

<rant>
Some found the explicit null statement to be unusual,
bothersome, and confusing in the presence of a pragma.
Thus it was dropped by the language designers.

The little learning it took, the few words of explanation,
explicitness of intent dropped in favor of a special case in Ada
2012 which lets one use a pragma in place of a null statement.
(And re-introduce "null;" once rewriting / removing debug stuff
/ etc is taking place.)

Let's hope we can buy support tools in the future to
help us ensure the effects of language special casing can
be bridled per project.
</rant>

Re: Ada.Execution_Time

[Randy Brukardt]

"Georg Bauhaus" <rm-host.bauhaus@maps.futureapps.de> wrote in message 
news:4d05e737$0$6980$9b4e6d93@newsspool4.arcor-online.net...
...
> <rant>
> Some found the explicit null statement to be unusual,
> bothersome, and confusing in the presence of a pragma.
> Thus it was dropped by the language designers.

The logic is that you need a "null;" statement when there is nothing in some 
list of statements. A pragma (or label) is not "nothing", so the requirement 
for "null;" is illogical in those cases.

> The little learning it took, the few words of explanation,
> explicitness of intent dropped in favor of a special case in Ada
> 2012 which lets one use a pragma in place of a null statement.

Yes. This is primarily an issue for a pragma Assert.

> (And re-introduce "null;" once rewriting / removing debug stuff
> / etc is taking place.)

True, but that is always the case when removing debug stuff. The change here 
has no real effect on that. Most of mine is some sort of logging:

       if Something then
            <Lot of code>
       else
            Log_Item ("Something is False");
       end if;

If I remove the logging, I have to add a "null;" or remove the "else".

The situation for a pragma in Ada 2012 is no different:

       if Something then
            <Lot of code>
       else
            pragma Assert (not Something_Else);
       end if;

And it seems less likely that you would change this than the first form, and 
neither seems that likely.

(Note that this was not a change I cared about much in either direction. The 
use of pragmas for executable things is bad language design IMHO, and in any 
I simply don't use them for that sort of purpose, because they are much too 
limited to be of much use in a complex system.)

> Let's hope we can buy support tools in the future to
> help us ensure the effects of language special casing can
> be bridled per project.

I'd suggest you stick with Ada 2005. Ada 2012 is all about easier ways to 
write Ada code: not just these tweaks, but also conditional expressions, 
expression functions, iterator syntax, indexing of containers, the reference 
aspect (giving automatic dereferencing) are all "syntax sugar". That is, 
they're all about making it easier to write (and in most cases, read) Ada 
code in a style that is closer to the problem rather than the solution. (One 
could also put all of the contract stuff into this category, as you can 
write preconditions, postconditions, invariants, and predicates using pragma 
Assert -- it's just a lot more reliable for the compiler to decide where 
they need to go.)

                                               Randy.

Re: Ada.Execution_Time

[J-P. Rosen]

Le 13/12/2010 23:25, Randy Brukardt a �crit :
>> The little learning it took, the few words of explanation,
>> explicitness of intent dropped in favor of a special case in Ada
>> 2012 which lets one use a pragma in place of a null statement.
> 
> Yes. This is primarily an issue for a pragma Assert.
> 
[...]
> (Note that this was not a change I cared about much in either direction. The 
> use of pragmas for executable things is bad language design IMHO, and in any 
And to think that "assert" was a statement in (preliminary) Ada 1980...

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: Ada.Execution_Time

[Jeffrey Carter]

On 12/13/2010 03:25 PM, Randy Brukardt wrote:
>
> The logic is that you need a "null;" statement when there is nothing in some
> list of statements. A pragma (or label) is not "nothing", so the requirement
> for "null;" is illogical in those cases.

The logic I recall from watching videos of Ichbiah, Barnes, and Firth presenting 
Ada (80) at the Ada Launch was that a null statement indicates that the sequence 
of statements (SOS) was intentionally null; it was contrasted to the single 
semicolon used for the null statement in some other languages, which is easily 
missed when reading, easily accidentally deleted when editing, and generally 
considered a Bad Thing. Another justification is that it prevents the reader 
from wondering if something was accidentally deleted.

As such, a pragma might be "something" and as such not require a null statement, 
but I would disagree about a label. A label by itself would make me wonder what 
happened to the statement it labels.

Given the argument that the null statement is needed when there is no other SOS, 
that SOS refers to executable statements, and that neither a pragma nor a label 
are considered such, I would guess this is contrary to the intention of the 
original language designers.

I so like the idea that something explicit is required when a region 
deliberately contains nothing that I'd like to see "null;" as a declaration that 
is required when a declarative region contains nothing else.

-- 
Jeff Carter
"He didn't get that nose from playing ping-pong."
Never Give a Sucker an Even Break
110

Re: Ada.Execution_Time

[Vinzent Hoefler]

Randy Brukardt wrote:

> "Georg Bauhaus" <rm-host.bauhaus@maps.futureapps.de> wrote in message
> news:4d05e737$0$6980$9b4e6d93@newsspool4.arcor-online.net...
> ...
>> <rant>
>> Some found the explicit null statement to be unusual,
>> bothersome, and confusing in the presence of a pragma.
>> Thus it was dropped by the language designers.
>
> The logic is that you need a "null;" statement when there is nothing in some
> list of statements. A pragma (or label) is not "nothing", so the requirement
> for "null;" is illogical in those cases.

I believe, back in the old days, there was a requirement that the presence or
absence of a pragma shall have no effect on the legality of the program, wasn't
it?

Well, even if it just was that it "shall have no effect on a legal program", I
still wonder why it is so necessary to introduce the possibility to turn an
illegal program (without the null statement) into a legal one merely by adding
some random pragma where a "sequence of statements" was expected. A pragma is
/not/ a statement.

I agree with Georg here, this is an unnecessary change with no apparent use,
it doesn't support neither of the three pillars of the Ada language "safety",
"readability", or "maintainability".


Vinzent.

-- 
Beaten by the odds since 1974.

Re: Ada.Execution_Time

[Robert A Duff]

Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:

> The logic I recall from watching videos of Ichbiah, Barnes, and Firth
> presenting Ada (80) at the Ada Launch was that a null statement
> indicates that the sequence of statements (SOS) was intentionally null;
> it was contrasted to the single semicolon used for the null statement in
> some other languages, which is easily missed when reading, easily
> accidentally deleted when editing, and generally considered a Bad
> Thing.

It's kind of a "belt and suspenders" solution.

In C, you can say:

    for (<stuff-with-side-effects>)
        ;

and it's indeed easy to miss the empty statement,
especially if the ";" is on the same line as the "for",
and/or the following code is mis-indented.

Ada solves this two ways -- you have to write "end loop;"
and you also have to write "null;".  The "end loop;"
already solves the problem.

Similar issue with dangling "else" -- Ada doesn't have them
because of "end if".  (Amazingly, in 2010, people continue
to design programming languages with the dangling "else"
problem.  No excuse for it!)

> As such, a pragma might be "something" and as such not require a null
> statement, but I would disagree about a label. A label by itself would
> make me wonder what happened to the statement it labels.

Conceptually, a label does not label a statement -- it labels
a place in the code.  The Ada syntax rules are confused in
this regard.  I mean, when you say "goto L;" you don't mean
to execute the statement labeled <<L>> (and then come back here),
you mean to jump to the place marked <<L>>, and continue
on from there.

So if you want to jump to the end of a statement list, e.g.

    ...loop
        ...
        if ... then
            ...
            goto Continue;
        end if;
        ...
        <<Continue>>
    end loop;

it's just noise to put "null;" after <<Continue>>.

It's no big deal, of course, since gotos are rare.

> Given the argument that the null statement is needed when there is no
> other SOS, that SOS refers to executable statements, and that neither a
> pragma nor a label are considered such,...

Well, a pragma Assert is a lot like a statement.
I find it really annoying to have to write "null;"
before or after some Asserts.  Pure noise, IMHO.
(Again, no big deal.)

>... I would guess this is contrary
> to the intention of the original language designers.

Almost everything that changed in Ada 95, 2005, and 2012 is
contrary to the original intent.  Indeed, during the
Ada 9X project, Jean Ichbiah was quite angry that
we were scribbling graffiti all over his near-perfect
work of art.  So be it.

> I so like the idea that something explicit is required when a region
> deliberately contains nothing that I'd like to see "null;" as a
> declaration that is required when a declarative region contains nothing
> else.

I know.  I've seen your code with "-- null;" in empty declarative
parts.  I'm sure you realize that in this case, yours is a minority
opinion.

It's another belt and suspenders thing.  If you forgot to
declare anything in the declarative part, you'll likely
get errors when you refer to those missing declarations.
Unless, of course, you forgot the code as well.  When
we see:

    procedure P is
    begin
        null;
    end P;

how do we know the programmer didn't REALLY mean:

    procedure P is
        Message: constant String := "Hello, world.";
    begin
        Put_Line (Message);
    end P;

?

Should we write:

    procedure P is
        Message: constant String := "Hello, world.";
    begin
        Put_Line (Message);
        null;
    end P;

to indicate that we really did NOT want to do anything after
the Put_Line?

;-)

- Bob

Re: Ada.Execution_Time

[Adam Beneschan]

On Dec 14, 12:17 am, "Vinzent Hoefler"
<0439279208b62c95f1880bf0f8776...@t-domaingrabbing.de> wrote:

> > The logic is that you need a "null;" statement when there is nothing in some
> > list of statements. A pragma (or label) is not "nothing", so the requirement
> > for "null;" is illogical in those cases.
>
> I believe, back in the old days, there was a requirement that the presence or
> absence of a pragma shall have no effect on the legality of the program, wasn't
> it?

RM83 2.8(8): "An implementation is not allowed to define pragmas whose
presence or absence influences the legality of the text outside such
pragmas."  But note that this applied only to *implementation-defined*
pragmas; language-defined pragmas could influence legality (in
particular, the INTERFACE pragma could make an illegal program, i.e.
one in which a subprogram declaration didn't have a corresponding
body, legal).  I don't think this was intended to be a statement about
the *syntax* rules, since the syntax rules are defined by the language
and can't be changed by the implementation, although I suppose that
this rule could have been a reflection of an unstated principle that
was used when the syntax rules were designed.

The current version of this rule is in 2.8(16-19) and is only
Implementation Advice.

                                    -- Adam



>
> Well, even if it just was that it "shall have no effect on a legal program", I
> still wonder why it is so necessary to introduce the possibility to turn an
> illegal program (without the null statement) into a legal one merely by adding
> some random pragma where a "sequence of statements" was expected. A pragma is
> /not/ a statement.
>
> I agree with Georg here, this is an unnecessary change with no apparent use,
> it doesn't support neither of the three pillars of the Ada language "safety",
> "readability", or "maintainability".
>
> Vinzent.
>
> --
> Beaten by the odds since 1974.

Re: Ada.Execution_Time

[Robert A Duff]

"Vinzent Hoefler" <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de>
writes:

> I believe, back in the old days, there was a requirement that the presence or
> absence of a pragma shall have no effect on the legality of the program, wasn't
> it?

Yes, something like that.  It applied only to implementation-defined
pragmas, which smells fishy right there.

Anyway, it was a pretty silly rule.  So you can erase all the pragmas,
and your program is still legal.  But the program now does something
different (i.e. wrong) at run time.  How is this beneficial?

Try erasing all the pragmas Abort_Defer from your program!
Or for a language-defined one, try erasing all the pragmas
Elaborate_All.  Either way, your (still-legal) program
will be completely broken.

> Well, even if it just was that it "shall have no effect on a legal program", I
> still wonder why it is so necessary to introduce the possibility to turn an
> illegal program (without the null statement) into a legal one merely by adding
> some random pragma where a "sequence of statements" was expected.

People don't add "random" pragmas.  They add useful ones.

>...A pragma is
> /not/ a statement.

True, but a sequence_of_statements can contain pragmas.  Huh.
A pragma can act as a statement, but can't BE a statement.

> I agree with Georg here, this is an unnecessary change with no apparent use,
> it doesn't support neither of the three pillars of the Ada language "safety",
> "readability", or "maintainability".

It certainly supports readability.  I find this:

    if Debug_Mode then
        pragma Assert(Is_Good(X));
    end if;

slightly more readable than:

    if Debug_Mode then
        null;
        pragma Assert(Is_Good(X));
    end if;

- Bob

Re: Ada.Execution_Time

[Jeffrey Carter]

On 12/14/2010 08:42 AM, Robert A Duff wrote:
>
> Almost everything that changed in Ada 95, 2005, and 2012 is
> contrary to the original intent.  Indeed, during the
> Ada 9X project, Jean Ichbiah was quite angry that
> we were scribbling graffiti all over his near-perfect
> work of art.  So be it.

I know. Good thing he didn't see some of the current changes.

> I know.  I've seen your code with "-- null;" in empty declarative
> parts.  I'm sure you realize that in this case, yours is a minority
> opinion.

Of course.

-- 
Jeff Carter
"From this day on, the official language of San Marcos will be Swedish."
Bananas
28

Re: Ada.Execution_Time

[Dmitry A. Kazakov]

On Tue, 14 Dec 2010 10:53:40 -0500, Robert A Duff wrote:

> "Vinzent Hoefler" <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de>
> writes:
> 
>> I believe, back in the old days, there was a requirement that the presence or
>> absence of a pragma shall have no effect on the legality of the program, wasn't
>> it?
> 
> Or for a language-defined one, try erasing all the pragmas
> Elaborate_All.  Either way, your (still-legal) program
> will be completely broken.

Because Elaborate_All should never become a pragma. Two wrongs don't make
one right.

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

Re: Ada.Execution_Time

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Because Elaborate_All should never become a pragma. Two wrongs don't make
> one right.

Elaborate_All is a pragma because Elaborate is a pragma.  ;-)

- Bob

Re: Ada.Execution_Time

[Adam Beneschan]

On Dec 14, 9:45 am, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> writes:
>
> > Because Elaborate_All should never become a pragma. Two wrongs don't make
> > one right.
>
> Elaborate_All is a pragma because Elaborate is a pragma.  ;-)

And I guess Elaborate shouldn't have been a pragma, either, since it
affects the semantics; you can write a program that is not guaranteed
to work correctly unless you use this pragma.

When I was trying to look into whether such things really fit the
definition, I ran into trouble finding a clear non-language-specific
definition of what a "pragma" should be.  The Ada RM's have very clear
definitions.  In RM83: "A pragma is used to convey information to the
compiler".  That's crystal clear, except that in my view the entire
text of the program conveys information to the compiler, so it's not
really clear what distinguishes a "pragma" from any other line in the
source.  Ada 95 changed this to "A pragma is a compiler directive".
Which of course clears everything up.  Of course, my twisted mind
thinks an assignment statement is a compiler directive, since it
directs the compiler to generate code that assigns something to
something else, so I'm not sure that this is a useful definition.

Even in Ada 83, there were at least three different flavors of
pragmas.  Some (LIST, PAGE) had no effect on the operation of the
resulting code.  Some (OPTIMIZE, INLINE, PACK) could affect the
compiler's choice of what kind of code to generate, but the code would
produce the same results (unless the code explicitly did something to
create a dependency on the compiler's choice, such as relying on 'SIZE
of a record that may or may not be packed).  And others (ELABORATE,
PRIORITY, SHARED, INTERFACE) definitely affected the results---the
program's behavior would potentially be different (or, in the case of
INTERFACE, be illegal) if the pragma were missing.  I'm having trouble
figuring out a common thread that ties all these kinds of pragmas into
one unified concept---except, perhaps, that they are things that the
language designers found it PRAGMAtic to shove into the "pragma"
statement instead of inventing new syntax.  :) :) :)

And personally, I'm fine with that.  We can argue and discuss and
strive endlessly to come up with a flawless language; but during the
time it takes to perfect the language (and then for implementors to
implement it), everyone else is stuck using C++ and Java while they're
waiting for us, which cannot be good for the world.  So a bit of
artistic inelegance is, to me, a small price to pay.  I guess that's
because I'm too much of a ... well ... a pragma-tist?

                                   -- Adam

Re: Ada.Execution_Time

[Warren]

Robert A Duff expounded in
news:wccpqt4cqdr.fsf@shell01.TheWorld.com: 

> Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:
..
>> Given the argument that the null statement is needed when
>> there is no other SOS, that SOS refers to executable
>> statements, and that neither a pragma nor a label are
>> considered such,... 
> 
> Well, a pragma Assert is a lot like a statement.
> I find it really annoying to have to write "null;"
> before or after some Asserts.  Pure noise, IMHO.
> (Again, no big deal.)

Personally I think an Assert "statement" (non pragma) could be 
added. Then the assertion _is_ a "statement". I would further 
suggest that _that_ would be active unless explicitly defeated 
by compile option(s) or by pragma <grin>.

Warren

Re: Ada.Execution_Time

[anon]

In <op.vno2nwchlzeukk@jellix.jlfencey.com>, "Vinzent Hoefler" <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> writes:
>Randy Brukardt wrote:
>
>
>I believe, back in the old days, there was a requirement that the presence or
>absence of a pragma shall have no effect on the legality of the program, wasn't
>it?

Actually, it still does: Ada 83 thriough 2012 states in Chapter 2 

2.8 Pragmas

In Ada 83 it states:

    A pragma that is not language-defined has no effect if  its  identifier  is
    not  recognized  by  the  (current)  implementation.  Furthermore, a pragma
    (whether language-defined or implementation-defined) has no effect  if  its
    placement  or  its  arguments  do not correspond to what is allowed for the
    pragma.  The region of text over which a pragma has an  effect  depends  on
    the pragma. 

    Note: 

    It  is  recommended  (but not required) that implementations issue warnings
    for pragmas that are not recognized and therefore ignored. 


In Ada 95 .. 2012 states:


                         Implementation Requirements

13    The implementation shall give a warning message for an unrecognized
pragma name.

                         Implementation Permissions

15    An implementation may ignore an unrecognized pragma even if it violates
some of the Syntax Rules, if detecting the syntax error is too complex.

                            Implementation Advice

16    Normally, implementation-defined pragmas should have no semantic effect
for error-free programs; that is, if the implementation-defined pragmas are
removed from a working program, the program should still be legal, and should
still have the same semantics.




In Ada 83 the unrecognized pragmas was syntactically check and skipped
with an optional  simple warning that the compiler will skip that pragma.  
But in Ada 94 .. 2012 it is a question to what the Implementation will do.
It kinds of kills the Ada concept of "predictable" and that's a shame for all 
who controls the design of Ada.

Re: Ada.Execution_Time

[Adam Beneschan]

On Dec 14, 11:43 am, a...@att.net wrote:

> In Ada 95 .. 2012 states:
>
>                          Implementation Requirements
>
> 13    The implementation shall give a warning message for an unrecognized
> pragma name.
>
>                          Implementation Permissions
>
> 15    An implementation may ignore an unrecognized pragma even if it violates
> some of the Syntax Rules, if detecting the syntax error is too complex.
>
>                             Implementation Advice
>
> 16    Normally, implementation-defined pragmas should have no semantic effect
> for error-free programs; that is, if the implementation-defined pragmas are
> removed from a working program, the program should still be legal, and should
> still have the same semantics.
>
> In Ada 83 the unrecognized pragmas was syntactically check and skipped
> with an optional  simple warning that the compiler will skip that pragma.  
> But in Ada 94 .. 2012 it is a question to what the Implementation will do.
> It kinds of kills the Ada concept of "predictable" and that's a shame for all
> who controls the design of Ada.

They did add "pragma Restrictions(No_Implementation_Pragmas)".  So
those users who want that predictability back can have it.

                             -- Adam

Re: Ada.Execution_Time

[Dmitry A. Kazakov]

On Tue, 14 Dec 2010 19:10:44 +0000 (UTC), Warren wrote:

> Robert A Duff expounded in
> news:wccpqt4cqdr.fsf@shell01.TheWorld.com: 
> 
>> Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:
> ..
>>> Given the argument that the null statement is needed when
>>> there is no other SOS, that SOS refers to executable
>>> statements, and that neither a pragma nor a label are
>>> considered such,... 
>> 
>> Well, a pragma Assert is a lot like a statement.
>> I find it really annoying to have to write "null;"
>> before or after some Asserts.  Pure noise, IMHO.
>> (Again, no big deal.)
> 
> Personally I think an Assert "statement" (non pragma) could be 
> added. Then the assertion _is_ a "statement".

Once I suggested:

   raise <exception> when <condition>;

> I would further 
> suggest that _that_ would be active unless explicitly defeated 
> by compile option(s) or by pragma <grin>.

However implemented, the idea is bad.

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

Re: Ada.Execution_Time

[Jeffrey Carter]

On 12/14/2010 01:36 PM, Dmitry A. Kazakov wrote:
>
> Once I suggested:
>
>     raise <exception> when <condition>;

Yes, I suggested that, too. Also

return [<expression>] [when <condition>];

You could also argue for

goto <label> [when <condition>];

but I'd rather make goto as unattractive to use as possible.

-- 
Jeff Carter
"From this day on, the official language of San Marcos will be Swedish."
Bananas
28

Re: Ada.Execution_Time

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:10872143-12a2-4d25-bb08-e236b15d2c18@o14g2000prn.googlegroups.com...
...
>Even in Ada 83, there were at least three different flavors of
>pragmas.  Some (LIST, PAGE) had no effect on the operation of the
>resulting code.  Some (OPTIMIZE, INLINE, PACK) could affect the
>compiler's choice of what kind of code to generate, but the code would
>produce the same results (unless the code explicitly did something to
>create a dependency on the compiler's choice, such as relying on 'SIZE
>of a record that may or may not be packed).  And others (ELABORATE,
>PRIORITY, SHARED, INTERFACE) definitely affected the results---the
>program's behavior would potentially be different (or, in the case of
>INTERFACE, be illegal) if the pragma were missing.  I'm having trouble
>figuring out a common thread that ties all these kinds of pragmas into
>one unified concept---except, perhaps, that they are things that the
>language designers found it PRAGMAtic to shove into the "pragma"
>statement instead of inventing new syntax.  :) :) :)

I think you've got it. None of these things (in the last category) ought to 
have been pragmas in the first place.

Note that pragmas are one of the few ways that implementers have to 
represent implementation-defined information, so in practice, we have lots 
of things that ought to never have been pragmas.

At least Ada 2012 has finally come to grips with this, in that the aspect 
clause will be able to be used rather than almost all of the existing 
pragmas. (But not Elaborate, as the syntax doesn't work in a context clause, 
and no one has the energy to invent some other syntax solely for that 
purpose.) Note, however, that there will still be uses for the old pragmas 
(if you want to hide the aspects in the private part, for instance). But 
they should be used much less often.

                                      Randy.

Re: Ada.Execution_Time

[BrianG]

Georg Bauhaus wrote:
> On 12/12/10 10:59 PM, BrianG wrote:
> 
> 
>> But my question still remains: What's the intended use of 
>> Ada.Execution_Time? Is there an intended use where its content 
>> (CPU_Time, Seconds_Count and Time_Span, "+", "<", etc.) is useful?
> 
> I think that your original posting mentions a use that is quite
> consistent with what the rationale says: each task has its own time.
> Points in time objects can be split into values suitable for
> arithmetic, using Time_Span objects.  Then, from the result of
> arithmetic, produce an object suitable for print, as desired.
> 
> 
> While this seems like having to write a bit much,
> it makes things explicit, like Ada forces one to be
> in many cases.   That' how I explain the series of
> steps to myself.
> 
> Isn't it just like "null;" being required to express
> the null statement?  It seems to me to be a logical
> consequence of requiring that intents must be stated
> explicitly.
> 
I have no problem with verbosity or explicitness, and that's not what I 
was asking about.

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

Given the rest of this thread, I would guess my answer is "No, no one 
actually uses Ada.Execution_Time".

--BrianG

Re: Ada.Execution_Time

[jpwoodruff]

BrianG's discussion spurred my interest, so now I am able to
contradict his

On Dec 14, 5:16 pm, BrianG <briang...@gmail.com> wrote:
>
> Given the rest of this thread, I would guess my answer is "No, no one
> actually uses Ada.Execution_Time".
>

Let me describe my experiment, which ends in a disappointing
observation about Ada.Execution_Time.

For some years I've had a package that defines a "Counter" object that
resembles a stop-watch.  Made curious by BrianG's question, I
re-implemented the abstraction over Ada.Execution_Time.

Unfortunately introduction of Ada.Real_Time can  cause an otherwise
successful program to raise STORAGE_ERROR :EXCEPTION_STACK_OVERFLOW.
This happens even if the program formerly ran only in an environment
task.


with Ada.Real_Time ;   -- This context leads to failure
Procedure Stack_Splat is
   Too_Big : array (1..1_000_000) of Float ;
begin
   null ;
end Stack_Splat ;


I haven't found the documentation that explains my observation, but
it's pretty clear that Ada.Real_Time in the context implies
substantially different run-time memory strategy.  I suppose there are
compile options to affect this; it can be an exercise for a later day.

Here is the package CPU, which is potentially useful in programs that
use stack gently.

-- PACKAGE FOR CPU TIME CALCULATIONS.
-----------------------------------------------------------------------
--
--              Author:         John P Woodruff
--                              jpwoodruff@gmail.com
--

-- This package owes a historic debt to the similarly named service
-- Created 19-SEP-1986 by Mats Weber.  This specification is largely
-- defined by that work.

--  15-apr-2004: However, Weber's package was implemented by unix
calls
--  (alternatively VMS calls).  JPW has adapted this package
--  specification twice: first to use the Ada.Calendar.Clock
--  functions, then later (when I discovered deMontmollin's WIN-PAQ)
--  to use windows32 low-level calls. Now only the thinnest of Mats
--  Weber's traces can be seen.

--  December 2010: the ultimate version is possible now that Ada2005
--  gives us Ada.Execution_Time.  The object CPU_Counter times a task
--  (presently limited to the current task), and a Report about a
--  CPU_Counter might make interesting reading. Unhappily when this
--  package is introduced, gnat allocates smaller space for the
--  environment task than in the absence of tasking.  Therefore
--  instrumented programs may blow stack in cases that uninstrumented
--  programs do not.

with Ada.Execution_Time ;

package CPU is

   -- Type of a CPU time counter.  Each object of this type is an
   --  independent stop-watch that times the task in which it is
   --  declared.  Possible enhancement: bind a CPU_Counter to a
   --  Task_ID different from Current_Task.

   type CPU_Counter is limited private;

   ------------------------------------------------------------------
   -- The operations for a counter are Start, Stop and Clear.
   -- A counter that is Stopped retains the time already accrued,
until
   -- it is Cleared.

   --  A stopped counter can be started and will add to the time
   --  already accrued - just as though it had run continuously.
   --  It is not necessary to stop a counter in order to read
   --  its value.

   procedure Start_Counter (The_Counter : in out CPU_Counter);
   procedure Stop_Counter  (The_Counter : in out CPU_Counter);
   procedure Clear_Counter (The_Counter : in out CPU_Counter);

   ------------------------------------------------------------------
   -- There are two groups of reporting functions:

   --  CPU_Time returns the time used during while the counter has
   --  been running.


   function CPU_Time (Of_Counter : CPU_Counter) return Duration ;

   -- Process_Lifespan returns the total CPU since the process
   --  started.  (Does not rely on any CPU_counter having been
   --  started.)

   function Process_Lifespan  return Duration ;


   Counter_Not_Started : exception;

   --------------------------------------------------------------
   --  The other reporting functions produce printable reports for
   --  a counter, or for the process as a whole (the procedure
   --  writes to standard output). Reports do not effect the
   --  counter.  Use a prefix string to label the output according
   --  to the activity being timed.

   procedure Report_Clock (Watch      : in CPU_Counter;
                           Prefix     : in String := "") ;

   function  Report_Clock (Watch      : in CPU_Counter) return
String ;


   procedure Report_Process_Lifespan ;

   function  Report_Process_Lifespan return String ;

private

   type CPU_Counter is
      record
         Identity       : Natural := 0 ;
         Accrued_Time   : Ada.Execution_Time.CPU_Time
                        := Ada.Execution_Time.CPU_Time_First ;
         Running        : Boolean := False;
         Start_CPU      : Ada.Execution_Time.Cpu_Time
                        := Ada.Execution_Time.Clock ;
      end record;

end CPU ;

---------------------------------
-- Creation : 19-SEP-1986 by Mats Weber.
-- Revision : 16-Jul-1992 by Mats Weber, enhanced portability by
adding
--                                       separate package
System_Interface.
-- JPW 23 Sep 00 use ada.calendar.clock (because it works on Windows)
-- jpw 14apr04 *found* the alternative.  Montmollin's win-paq product
--     defines win32_timing: the operating system function.
-- jpw 14dec10  reimplement and substantially simplify using
Ada.Execution_Time


with Ada.Text_Io;
with Ada.Real_Time ;

package body CPU is
   ----------------
   use type Ada.Execution_Time.Cpu_Time ;

   Next_Counter_Identity : Natural := 0 ;

   function To_Duration (Time : Ada.Execution_Time.CPU_Time) return
Duration is
      -- thanks to Jeff Carter comp.lang.ada 11dec10
      Seconds  : Ada.Real_Time.Seconds_Count;
      Fraction : Ada.Real_Time.Time_Span;
   begin     -- To_Duration
      Ada.Execution_Time.Split (Time, Seconds, Fraction);
      return Duration (Seconds) + Ada.Real_Time.To_Duration
(Fraction);
   end To_Duration;


   procedure Start_Counter (The_Counter : in out CPU_Counter) is
   begin
      if The_Counter.Identity > 0 then
         --  This is a restart:  identity and accrued times remain
         if not The_Counter.Running then
            The_Counter.Start_CPU := Ada.Execution_Time.Clock ;
         end if ;
         The_Counter.Running   := True ;
      else   -- this clock has never started before
         Next_Counter_Identity       := Next_Counter_Identity + 1;
         The_Counter.Identity        := Next_Counter_Identity ;
         The_Counter.Running         := True ;
         The_Counter.Start_CPU       := Ada.Execution_Time.Clock ;
      end if ;
   end Start_Counter;


   procedure Stop_Counter  (The_Counter : in out CPU_Counter)is
      Now : Ada.Execution_Time.Cpu_Time
          := Ada.Execution_Time.Clock ;
   begin
      if  The_Counter.Identity > 0 and The_Counter.Running then
         -- accrue time observed up to now
         The_Counter.Accrued_Time := The_Counter.Accrued_Time +
           (Now - The_Counter.Start_CPU) ;
         The_Counter.Running := False ;
      end if ;
   end Stop_Counter ;


   procedure Clear_Counter  (The_Counter : in out CPU_Counter) is
      -- the counter becomes "as new" ready to start.
   begin
      The_Counter.Running := False ;
      The_Counter.Accrued_Time := Ada.Execution_Time.CPU_Time_First ;
   end Clear_Counter ;


   function CPU_Time (Of_Counter  : CPU_Counter) return Duration is
      Now : Ada.Execution_Time.Cpu_Time
          := Ada.Execution_Time.Clock ;
   begin
      if Of_Counter.Identity <= 0 then
         raise Counter_Not_Started ;
      end if;
      if not Of_Counter.Running then
         return To_Duration (Of_Counter.Accrued_Time) ;
      else
         return To_Duration (Of_Counter.Accrued_Time +
                             (Now - Of_Counter.Start_CPU)) ;
      end if ;
   end CPU_Time;

   function Process_Lifespan return Duration is
   begin
      return To_Duration (Ada.Execution_Time.Clock) ;
   end Process_Lifespan ;

   function Report_Duration (D : in Duration) return String is
   begin
      if D < 1.0 then
         declare
            Millisec : String := Duration'Image (1_000.0 * D);
         begin
            return  MilliSec(MilliSec'First .. MilliSec'Last-6) & "
msec" ;
         end ;
      elsif D < 60.0 then
         declare Sec : String :=  Duration'Image (D);
         begin
            return Sec(Sec'First .. Sec'Last-6)  & " sec" ;  -- fewer
signficant figs
         end ;
      else
         declare
            Minutes : Integer := Integer(D) / 60 ;
            Seconds : Duration := D - Duration(Minutes) * 60.0 ;
            Sec : String := Duration'Image (Seconds) ;
         begin
            return Integer'Image (Minutes) & " min " &
              Sec(Sec'First .. Sec'Last-6) & " sec" ;
         end ;
      end if ;
   end Report_Duration ;


   procedure Report_Clock (Watch      : in CPU_Counter;
                           Prefix     : in String := "") is
      use Ada.Text_IO ;
   begin
      Put (Prefix & Report_Clock (Watch)) ;
      New_Line ;
   end Report_Clock;


   function Report_Clock (Watch      : in CPU_Counter) return String
is
   begin
      return
        " <" & Integer'Image(Watch.Identity) & "> " &
        Report_Duration (CPU_Time (Watch)) ;
   end Report_Clock ;


   procedure Report_Process_Lifespan is
      use Ada.Text_IO ;
   begin
      Put (Report_Process_Lifespan) ;
      New_Line ;
   end Report_Process_Lifespan ;


   function  Report_Process_Lifespan return String is
      use Ada.Text_IO ;
   begin
      return "Process Lifespan: " & Report_Duration
(Process_Lifespan) ;
   end Report_Process_Lifespan ;

end CPU ;

Re: Ada.Execution_Time

[Simon Wright]

BrianG <briang000@gmail.com> writes:

> Given the rest of this thread, I would guess my answer is "No, no one
> actually uses Ada.Execution_Time".

Certainly not if they're using Mac OS X:

   gcc -c cpu.adb
   Execution_Time is not supported in this configuration
   compilation abandoned

Re: Ada.Execution_Time

[Pascal Obry]

Le 15/12/2010 20:17, jpwoodruff a �crit :
> Unfortunately introduction of Ada.Real_Time can  cause an otherwise
> successful program to raise STORAGE_ERROR :EXCEPTION_STACK_OVERFLOW.
> This happens even if the program formerly ran only in an environment
> task.
> 
> 
> with Ada.Real_Time ;   -- This context leads to failure
> Procedure Stack_Splat is
>    Too_Big : array (1..1_000_000) of Float ;
> begin
>    null ;
> end Stack_Splat ;

Probably because the stack size is smaller in the context of tasking
runtime. Just increase the stack (see corresponding linker option) for
the environment task. Nothing really blocking or I did I miss your point?

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Ada.Execution_Time

[Randy Brukardt]

"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.)

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

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

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.

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

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

Re: Ada.Execution_Time

[Keith Thompson]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> "Vinzent Hoefler" <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de>
> writes:
[...]
>> I agree with Georg here, this is an unnecessary change with no apparent use,
>> it doesn't support neither of the three pillars of the Ada language "safety",
>> "readability", or "maintainability".
>
> It certainly supports readability.  I find this:
>
>     if Debug_Mode then
>         pragma Assert(Is_Good(X));
>     end if;
>
> slightly more readable than:
>
>     if Debug_Mode then
>         null;
>         pragma Assert(Is_Good(X));
>     end if;

So, um, why is Assert a pragma rather than a statement?

   if Debug_Mode then
      assert Is_Good(X);
   end if;

As somebody pointed out, it was defined that way in Ada 80.

Or am I opening a huge can of worms by asking that question?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: Ada.Execution_Time

[Adam Beneschan]

On Dec 15, 2:52 pm, Keith Thompson <ks...@mib.org> wrote:
> Robert A Duff <bobd...@shell01.TheWorld.com> writes:
>
>
>
>
>
> > "Vinzent Hoefler" <0439279208b62c95f1880bf0f8776...@t-domaingrabbing.de>
> > writes:
> [...]
> >> I agree with Georg here, this is an unnecessary change with no apparent use,
> >> it doesn't support neither of the three pillars of the Ada language "safety",
> >> "readability", or "maintainability".
>
> > It certainly supports readability.  I find this:
>
> >     if Debug_Mode then
> >         pragma Assert(Is_Good(X));
> >     end if;
>
> > slightly more readable than:
>
> >     if Debug_Mode then
> >         null;
> >         pragma Assert(Is_Good(X));
> >     end if;
>
> So, um, why is Assert a pragma rather than a statement?
>
>    if Debug_Mode then
>       assert Is_Good(X);
>    end if;
>
> As somebody pointed out, it was defined that way in Ada 80.
>
> Or am I opening a huge can of worms by asking that question?

Somebody on the ARG might have a more authoritative answer.  My
reading of AI95-286 is that a number of Ada compilers had already
implemented the Assert pragma and there was a lot of code using it.
Of course, those compilers couldn't have added "assert" as a statement
on their own, but adding an implementation-defined pragma is OK.

I'm guessing that there was probably code out there that used Assert
as a procedure, so adding this as a reserved word would have caused
problems.

                              -- Adam

Re: Ada.Execution_Time

[BrianG]

Simon Wright wrote:
> BrianG <briang000@gmail.com> writes:
> 
>> Given the rest of this thread, I would guess my answer is "No, no one
>> actually uses Ada.Execution_Time".
> 
> Certainly not if they're using Mac OS X:
> 
>    gcc -c cpu.adb
>    Execution_Time is not supported in this configuration
>    compilation abandoned
I get the same with the version of Linux I'm currently on (Ubuntu 9.04 I 
think); I had assumed it's because the version of gcc/gnat is rather old 
- 4.3.3.  (The later Ubuntu versions have problems with my eeepc - and 
introduce stupid interface changes with no easy way to revert.)

--Bg

Re: Ada.Execution_Time

[BrianG]

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

Re: Ada.Execution_Time

[jpwoodruff]

I learn that Ada.Execution_Time isn't widely implemented, so there
isn't a lot of point to pursue a portable abstraction.  I'm thinking I
might as well revert to Gautier's Windows implementation.  The draft I
posted y'day is probably no more portable than that one.


On Dec 15, 2:42 pm, Pascal Obry <pas...@obry.net> wrote:

>
> Probably because the stack size is smaller in the context of tasking
> runtime. Just increase the stack (see corresponding linker option) for
> the environment task. Nothing really blocking or I did I miss your point?
>

That is clearly the case.

Still, I'm non-plussed that I can't write a service - CPU.Counter in
the example - that can hide its implementation from the host program.

It occurs to me that the designers of the D.14 specification for
Ada.Execution_Time did not consider the prospect of measuring a single
environment task's performance.  Otherwise the package might be
factored so that function Clock did not presume multiple tasks.

Here's a flippant suggestion: maybe there should be a pragma to set
stack size.  I'd bury such a pragma inside package CPU so the
Ada.Execution_Time doesn't get linked into too-small an executable.

If I could do that, my user doesn't get a stack splat from an
instrument that worked correctly while running smaller tests.

John

Re: Ada.Execution_Time

[Jeffrey Carter]

On 12/15/2010 06:14 PM, BrianG wrote:
>
> 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).

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

 From ARM D.14:

function "-"  (Left : CPU_Time; Right : CPU_Time)  return Time_Span;

-- 
Jeff Carter
"Clear? Why, a 4-yr-old child could understand this
report. Run out and find me a 4-yr-old child. I can't
make head or tail out of it."
Duck Soup
94

Re: Ada.Execution_Time

[Dmitry A. Kazakov]

On Wed, 15 Dec 2010 16:05:16 -0600, Randy Brukardt wrote:

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

Any computer time is a representation of some counter. I think the point is
CPU_Time is not a real time, i.e. a time (actually the process driving the
corresponding counter) related to what people used to call "time" in the
external world. CPU_Time is what is usually called "simulation time." One
could use Duration or Time_Span in place of CPU_Time, but the concern is
that on some architectures, with multiple time sources, this would
introduce an additional inaccuracy. Another argument against it is that
there could be no fair translation from the CPU usage counter to
Duration/Time_Span (which is the case for Windows).

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

Re: Ada.Execution_Time

[Simon Wright]

BrianG <briang000@gmail.com> writes:

>> 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?

A 'time type'
[http://www.adaic.com/resources/add_content/standards/05rm/html/RM-9-6.html]
(6) can be used as the argument for a delay statement. Wouldn't make a
lot of sense for an execution time! (well, perhaps one could think of
some obscure use ...)

I see the standards have moved, time to update my bookmarks!

Re: Ada.Execution_Time

[Peter C. Chapin]

On 2010-12-15 20:14, BrianG wrote:

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

To me "execution time" sounds like a measure of how long a program has
run (in some sense). In other words it sounds like some kind of time
interval. "The execution time of this process was 10.102 seconds."

However, people often use "time" to refer to some sort of absolute
clock. "What time is it? It is now 8:07am on 2010-12-16." The basic
confusion is that the term "time" is extremely ambiguous in ordinary
usage. Not only is it used both for time intervals and absolute time
values, but there are several different kinds of time one might talk about.

Peter

Re: Ada.Execution_Time

[BrianG]

Jeffrey Carter wrote:
>  From ARM D.14:
> 
> function "-"  (Left : CPU_Time; Right : CPU_Time)  return Time_Span;
> 

Must be the "draft" I'm still using.  Time to find GNAT's adainclude on 
that computer.

Re: Ada.Execution_Time

[BrianG]

Dmitry A. Kazakov wrote:
> On Wed, 15 Dec 2010 16:05:16 -0600, Randy Brukardt wrote:
> 
>> 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.
> 
> Any computer time is a representation of some counter. I think the point is
> CPU_Time is not a real time, i.e. a time (actually the process driving the
> corresponding counter) related to what people used to call "time" in the
> external world. CPU_Time is what is usually called "simulation time." One
> could use Duration or Time_Span in place of CPU_Time, but the concern is
> that on some architectures, with multiple time sources, this would
> introduce an additional inaccuracy. Another argument against it is that
> there could be no fair translation from the CPU usage counter to
> Duration/Time_Span (which is the case for Windows).
> 
Isn't any "time" related to a computer nothing but a "simulation time"? 
  Yes, some times may be intended to emulate clock-on-the-wall-time, but 
that doesn't mean they're a very good emulation (ever measure the 
accuracy of a PC that's not synched to something?  You can get a watch 
free in a box of cereal that's orders of magnitude better.).  That's why 
we have Calendar, Real_Time, and CPU_Time - they're meant to be 
different things, but they are all "time" in some sense.  CPU_Time is 
obviously an approximation, dependent on the RTS, OS, task scheduler, etc.

What's so particularly bad about Windows (aside from the normal Windows 
things)?  Granted, I'm only doing simple prototyping (for non-Windows 
eventual use), but it seems a "fair" approximation.  When I added a 
1-second loop doing nonsense work (to get any measured value), it reads 
about 1 second, within about 5% (which is at least as good as I would 
have expected, given the 'normal' jitter on Delay).

--BrianG

Re: Ada.Execution_Time

[BrianG]

Simon Wright wrote:
> BrianG <briang000@gmail.com> writes:
> 
>>> 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?
> 
> A 'time type'
> [http://www.adaic.com/resources/add_content/standards/05rm/html/RM-9-6.html]
> (6) can be used as the argument for a delay statement. Wouldn't make a
> lot of sense for an execution time! (well, perhaps one could think of
> some obscure use ...)
(Actually for a delay_until.)  That paragraph seems to contradict the 
previous one which says "any nonlimited type".  Shouldn't (6) define 
Real_Time.Time since it's not Calendar.Time and isn't 
implementation-defined?  At least now Randy's comments make sense - I 
hadn't realized there was a language-defined concept of special 
"time-types" that had special uses (I hadn't realized the standard 
defines a use for certain private types that is not explicitly evident 
in the code - any other "magic" uses like this?)

> 
> I see the standards have moved, time to update my bookmarks!

Re: Ada.Execution_Time

[BrianG]

Peter C. Chapin wrote:
> On 2010-12-15 20:14, BrianG wrote:
> 
>> 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.
> 
> To me "execution time" sounds like a measure of how long a program has
> run (in some sense). In other words it sounds like some kind of time
> interval. "The execution time of this process was 10.102 seconds."
"CPU_Time" makes it more clear - it's not the execution time of the 
program, but the amount of CPU it has used.  If there's time-sharing, it 
can be less than the elapsed time used.  Or if there's multiple cores, 
it may be greater (although that may be unlikely as the task level).
> 
> However, people often use "time" to refer to some sort of absolute
> clock. "What time is it? It is now 8:07am on 2010-12-16." The basic
> confusion is that the term "time" is extremely ambiguous in ordinary
> usage. Not only is it used both for time intervals and absolute time
> values, but there are several different kinds of time one might talk about.
> 
> Peter

Re: Ada.Execution_Time

[Adam Beneschan]

On Dec 16, 9:24 am, BrianG <briang...@gmail.com> wrote:
> Simon Wright wrote:
> > BrianG <briang...@gmail.com> writes:
>
> >>> 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?
>
> > A 'time type'
> > [http://www.adaic.com/resources/add_content/standards/05rm/html/RM-9-6...]
> > (6) can be used as the argument for a delay statement. Wouldn't make a
> > lot of sense for an execution time! (well, perhaps one could think of
> > some obscure use ...)
>
> (Actually for a delay_until.)  That paragraph seems to contradict the
> previous one which says "any nonlimited type".

No, not really.  The rule that says "any nonlimited type" is a Name
Resolution Rule.  Those rules control how the language resolves
possibly ambiguous statements.  It's important to realize that Name
Resolution Rules are not legality rules, and it's possible for
something to be illegal and still satisfy the Name Resolution Rules,
which means that a "possible interpretation" can still cause an
ambiguity even if it's illegal.  Example:

   type Int is new Integer;
   function Overloaded (N : Integer) return Integer;
   function Overloaded (N : Integer) return Character;

   X : Int := Int (Overloaded (5));

This last call to Overloaded is ambiguous (and therefore illegal) even
though one definition of Overloaded returns a Character which cannot
legally be converted to Int.  The type conversion from a Character-
returning function to Int still satisfies the Name Resolution Rules
(4.6(6)).  Moral: Don't look at Name Resolution Rules if you're trying
to figure out whether something is legal.  (Other than when trying to
figure out whether something is unambiguous.)

> Shouldn't (6) define
> Real_Time.Time since it's not Calendar.Time and isn't
> implementation-defined?  

It should probably say "language-defined or implementation-defined".
D.8(18) does say that Real_Time.Time is one of those "time types".

                                 -- Adam

Re: Ada.Execution_Time

[Dmitry A. Kazakov]

On Thu, 16 Dec 2010 11:49:13 -0500, BrianG wrote:

> Dmitry A. Kazakov wrote:
>> On Wed, 15 Dec 2010 16:05:16 -0600, Randy Brukardt wrote:
>> 
>>> 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.
>> 
>> Any computer time is a representation of some counter. I think the point is
>> CPU_Time is not a real time, i.e. a time (actually the process driving the
>> corresponding counter) related to what people used to call "time" in the
>> external world. CPU_Time is what is usually called "simulation time." One
>> could use Duration or Time_Span in place of CPU_Time, but the concern is
>> that on some architectures, with multiple time sources, this would
>> introduce an additional inaccuracy. Another argument against it is that
>> there could be no fair translation from the CPU usage counter to
>> Duration/Time_Span (which is the case for Windows).
>> 
> Isn't any "time" related to a computer nothing but a "simulation time"? 

No, Ada.Calendar.Time and Ada.Real_Time.Time are derived from quartz
generators, which are physical devices. CPU_Time is derived from the time
the task owned a processor. This is a task time, the time in a simulated
Universe where nothing but the task exists. This Universe is not real, so
its time is not.

Or to put it otherwise, when Time has a value T, then under certain
conditions this has some meaning invariant to the program and the task
being run. For Ada.Real_Time.Time it is only the time differences T2 - T1,
which have this meaning. CPU_Time has no physical meaning. 2s might be 2.5s
real time or 1 year real time.

> Yes, some times may be intended to emulate clock-on-the-wall-time, but 
> that doesn't mean they're a very good emulation (ever measure the 
> accuracy of a PC that's not synched to something?

But the intent was to emulate the real time, whatever accuracy the result
night have.

> CPU_Time is 
> obviously an approximation, dependent on the RTS, OS, task scheduler, etc.

An approximation of what?

> What's so particularly bad about Windows (aside from the normal Windows 
> things)?

Windows counts full quants. It means that if the task (thread) enters a
non-busy waiting, e.g. for I/O or for other event, *before* it has spent
its quant, the quant is not counted (if I correctly remember). In effect,
you theoretically could have 0 CPU time with 99% processor load. Using the
task manager, you might frequently observe the effect of this: moderate CPU
load, but everything is frozen.

(I don't checked this behavior since Windows Server 2003, maybe they fixed
it in Vista, 7 etc).

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

Re: Ada.Execution_Time

[Jeffrey Carter]

On 12/15/2010 06:14 PM, BrianG wrote:
>
> 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).

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

 From ARM D.14:

function "-"  (Left : CPU_Time; Right : CPU_Time)  return Time_Span;

-- 
Jeff Carter
"Clear? Why, a 4-yr-old child could understand this
report. Run out and find me a 4-yr-old child. I can't
make head or tail out of it."
Duck Soup
94

Re: Ada.Execution_Time

[Jeffrey Carter]

On 12/16/2010 10:45 AM, Adam Beneschan wrote:
>
> It should probably say "language-defined or implementation-defined".
> D.8(18) does say that Real_Time.Time is one of those "time types".

That's a horrible way to phrase it. I would say, "some other time type".

-- 
Jeff Carter
"Have you gone berserk? Can't you see that that man is a ni?"
Blazing Saddles
38

Re: New AdaIC site (was: Ada.Execution_Time)

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:m24oaerlsi.fsf@pushface.org...
...
> I see the standards have moved, time to update my bookmarks!

I'd wait a day or two while we get the glitches out of these new sites. The 
domains are pointing a mix of old and new servers at the moment...

                                    Randy.

Re: Ada.Execution_Time

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:dfcf048b-bb6e-4993-b62a-9147bad3a6ff@j32g2000prh.googlegroups.com...
On Dec 15, 2:52 pm, Keith Thompson <ks...@mib.org> wrote:
...
>> So, um, why is Assert a pragma rather than a statement?
>>
>> if Debug_Mode then
>> assert Is_Good(X);
>> end if;
...
>Somebody on the ARG might have a more authoritative answer.  My
>reading of AI95-286 is that a number of Ada compilers had already
>implemented the Assert pragma and there was a lot of code using it.
>Of course, those compilers couldn't have added "assert" as a statement
>on their own, but adding an implementation-defined pragma is OK.

That's one reason. The other is that you can't put a statement into a 
declarative part (well, you can, but you need to use a helper generic and a 
helper procedure, along with an instantiation, which is insane -- although 
it is not that unusual to see that done in a program). A lot of asserts fit 
most naturally into the declarative part (precondition ones, for instance, 
although those will be better defined separately in Ada 2012).

                                                  Randy.

Re: Ada.Execution_Time

[Stephen Leake]

jpwoodruff <jpwoodruff@gmail.com> writes:

> Here's a flippant suggestion: maybe there should be a pragma to set
> stack size.  

If it set a _minimum_ stack size, that might be useful. It doesn't know
what else I have in my task, so it can't set the
_actual_ stack size!

-- 
-- Stephe

Re: Ada.Execution_Time

[Niklas Holsti]

>>> On Wed, 15 Dec 2010 16:05:16 -0600, Randy Brukardt wrote:
>>>
>>>> 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.

Are you sure, Randy? RM D.14 13/2 says "For each task, the execution 
time value is set to zero at the creation of the task."

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

Additions of CPU_Time values should also be meaningful. As I understand 
it, Ada.Execution_Time is meant for use in task scheduling, where it is 
essential that when several tasks start at the same time on one 
processor, the sum of their CPU_Time values at any later instant is 
close to the real elapsed time, Ada.Real_Time.Time_Span. Assuming that 
CPU_Time starts at zero for each task, see above.

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.

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

Re: Ada.Execution_Time

[anon]

In <ie91co$cko$1@news.eternal-september.org>, BrianG <briang000@gmail.com> writes:
>Georg Bauhaus wrote:
>> On 12/12/10 10:59 PM, BrianG wrote:
>> 
>> 
>>> But my question still remains: What's the intended use of 
>>> Ada.Execution_Time? Is there an intended use where its content 
>>> (CPU_Time, Seconds_Count and Time_Span, "+", "<", etc.) is useful?
>> 
>> I think that your original posting mentions a use that is quite
>> consistent with what the rationale says: each task has its own time.
>> Points in time objects can be split into values suitable for
>> arithmetic, using Time_Span objects.  Then, from the result of
>> arithmetic, produce an object suitable for print, as desired.
>> 
>> 
>> While this seems like having to write a bit much,
>> it makes things explicit, like Ada forces one to be
>> in many cases.   That' how I explain the series of
>> steps to myself.
>> 
>> Isn't it just like "null;" being required to express
>> the null statement?  It seems to me to be a logical
>> consequence of requiring that intents must be stated
>> explicitly.
>> 
>I have no problem with verbosity or explicitness, and that's not what I 
>was asking about.
>
>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).  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.)
>
>Given the rest of this thread, I would guess my answer is "No, no one 
>actually uses Ada.Execution_Time".
>
>--BrianG

Ada.Execution_Time is use for performance and reliability monitoring of the 
cpu resource aka a MCP (Tron). The control program can monitor the cpu 
usage of each task and decide which task needs to give up the CPU for the 
next task. 

With a shared server system it monitors which web site is over using the 
cpu and shutdown that web site temporality or permanent. One example too 
many Java Servlet on a web site.

For Ada 2012, it will mostly like will be use in the Ada runtime to balance 
the load for an Ada partition on multiple cores. Aka job scheduler for multiple 
tasks on multiple CPUs.

For the average Ada programmer, its another Ada package that most will 
never use because they will just use Ada.Real_Time.  The only problem 
is that Ada.Real_Time is an accumulation of times. A small list of these 
times includes VS swapping, IO processing, any cpu handled interrupts, 
as well as times for the task to execute as well as time the task sleeps 
while other tasks are executing. In some cases the Ada.Execution_Time
package can replace the Ada.Real_Time with only altering the with/use 
statements.

Some programmers might use this package to try to improve performance of 
an algorithm.

And a few might use this package for debugging like to prevent tasks from 
running away with the CPU resources. Such as stopping this type of 
logical condition from occurring at runtime:

  with x86 ; -- defines x86 instructions subset
  use  x86 ;

  task body run is

    begin
      Disable_Interrupts ;
      loop            -- Endless loop. 
        null ;        -- Which optimizes to one jump instruction
      end loop ;
    end run ;


Which when optimize can shutdown a cpu or computer system. And requires 
either a non-maskable reset or a full power cold restart without being able 
to save critical data or closing files.

Also, in history this package would be use to calculate the cpu usage charges 
for a customer.

Re: Ada.Execution_Time

[Dmitry A. Kazakov]

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

2. Not so anyway under many OSes => again, cannot be mandated

3. The intended purpose of CPU_Time has nothing to do with this constraint.
Nobody is interested in knowing if the actual sum is close or not to the
real time duration. It is a simulation time, which *could* be projected to
the real time in order to estimate potential CPU load. And the result
depends on the premises made.

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

Re: Ada.Execution_Time

[Niklas Holsti]

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.

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.

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

> 3. The intended purpose of CPU_Time has nothing to do with this constraint.
> Nobody is interested in knowing if the actual sum is close or not to the
> real time duration.

Real-time task scheduling and schedulability analysis is *all* about 
adding up task execution times (CPU_Time values, in principle) and 
comparing the sums to real-time deadlines (durations). I do believe 
there are some people, here and there, who are interested in such things...

In practice, since tasks in real-time Ada systems are usually created 
once at system start and are thereafter repeatedly activated (triggered) 
for each job (each deadline), the total CPU_Time of a task is less 
relevant for scheduling decisions than is the increase in CPU_Time since 
the last activation of the task. Using the services of 
Ada.Execution_Time, that increment is represented as a Time_Span. From 
this point of view, it is understandable that Ada.Execution_Time does 
not provide an addition operation "+" (Left, Right : CPU_Time) return 
CPU_Time.

> It is a simulation time, which *could* be projected to
> the real time in order to estimate potential CPU load.

"Simulation", "projection"... convey no meaning to me.

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

Re: Ada.Execution_Time

[Dmitry A. Kazakov]

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

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

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

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

> "Simulation", "projection"... convey no meaning to me.

http://en.wikipedia.org/wiki/Discrete_event_simulation

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

Re: Ada.Execution_Time

[Warren]

Randy Brukardt expounded in news:ieebpl$rt1$1@munin.nbi.dk:

> "Adam Beneschan" <adam@irvine.com> wrote in message 
> news:dfcf048b-bb6e-4993-b62a-9147bad3a6ff@j32g2000prh.google
> groups.com... On Dec 15, 2:52 pm, Keith Thompson
> <ks...@mib.org> wrote: ...
>>> So, um, why is Assert a pragma rather than a statement?
>>>
>>> if Debug_Mode then
>>> assert Is_Good(X);
>>> end if;
> ...
>>Somebody on the ARG might have a more authoritative answer.
>> My reading of AI95-286 is that a number of Ada compilers
>>had already implemented the Assert pragma and there was a
>>lot of code using it. Of course, those compilers couldn't
>>have added "assert" as a statement on their own, but adding
>>an implementation-defined pragma is OK. 
> 
> That's one reason. The other is that you can't put a
> statement into a declarative part (well, you can, but you
> need to use a helper generic and a helper procedure, along
> with an instantiation, which is insane -- although it is
> not that unusual to see that done in a program). A lot of
> asserts fit most naturally into the declarative part
> (precondition ones, for instance, although those will be
> better defined separately in Ada 2012). 
> 
>                                                   Randy.

I've never even thought to try that. I'll have to remember 
that.

Warren

Re: Ada.Execution_Time

[Niklas Holsti]

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

Re: Ada.Execution_Time

[BrianG]

anon@att.net wrote:
> In <ie91co$cko$1@news.eternal-september.org>, BrianG <briang000@gmail.com> writes:
>> Georg Bauhaus wrote:
>>> On 12/12/10 10:59 PM, BrianG wrote:
...
[Lots of meaningless comments deleted.]
> For the average Ada programmer, its another Ada package that most will 
> never use because they will just use Ada.Real_Time.  
[etc.]
>  In some cases the Ada.Execution_Time
> package can replace the Ada.Real_Time with only altering the with/use 
> statements.
If you mean that they both define a Clock and a Split, maybe.  If you mean
any program that actually does anything, that's not possible.  That was my
original comment:  Execution_Time does not provide any types/operations
useful, without also 'with'ing Real_Time.
> 
[etc.]
(Don't know why I bother w/ this msg.)

Re: Ada.Execution_Time

[Vinzent Hoefler]

BrianG wrote:

> If you mean that they both define a Clock and a Split, maybe.  If you mean
> any program that actually does anything, that's not possible.  That was my
> original comment:  Execution_Time does not provide any types/operations
> useful, without also 'with'ing Real_Time.

Yes, but so what? The intention of Ada.Execution_Time wasn't to provide the
user with means to instrument the software and to Text_IO some mostly
meaningless values (any decent profiler can do that for you), but rather a
way to implement user-defined schedulers based on actual CPU usage. You may
want to take a look at the child packages Timers and Group_Budget to see the
intended usage.

And well, if you're ranting about CPU_Time, Real_Time.Time_Span is not much
better. It's a pain in the ass to convert an Ada.Real.Time_Span to another
type to interface with OS-specific time types (like time_t) if you're opting
for speed, portability and accuracy.

BTW, has anyone any better ideas to convert TimeSpan into a record containing
seconds and nanoseconds than this:

    function To_Interval (TS : in Ada.Real_Time.Time_Span)
                          return ASAAC_Types.TimeInterval is
       Nanos_Per_Sec : constant                         := 1_000_000_000.0;
       One_Second    : constant Ada.Real_Time.Time_Span :=
                         Ada.Real_Time.Milliseconds (1000);
       Max_Interval  : constant Ada.Real_Time.Time_Span :=
                         Integer (ASAAC_Types.Second'Last) * One_Second;
       Seconds       : ASAAC_Types.Second;
       Nano_Seconds  : ASAAC_Types.Nanosec;
    begin
       declare
          Sub_Seconds : Ada.Real_Time.Time_Span;
       begin
          if TS >= Max_Interval then
             Seconds      := ASAAC_Types.Second'Last;
             Nano_Seconds := ASAAC_Types.Nanosec'Last;
          elsif TS < Ada.Real_Time.Time_Span_Zero then
             Seconds      := ASAAC_Types.Second'First;
             Nano_Seconds := ASAAC_Types.Nanosec'First;
          else
             Seconds      := ASAAC_Types.Second (TS / One_Second);
             Sub_Seconds  := TS - (Integer (Seconds) * One_Second);
             Nano_Seconds :=
               ASAAC_Types.Nanosec
                 (Nanos_Per_Sec * Ada.Real_Time.To_Duration (Sub_Seconds));
          end if;
       end;

       return
         ASAAC_Types.TimeInterval'(Sec  => Seconds,
                                   NSec => Nano_Seconds);
    end To_Interval;

The solution I came up with here generally works, but suffers some potential
overflow problems and doesn't look very efficient to me (although that'a minor
problem given the context it's usually used in).


Vinzent.

-- 
You know, we're sitting on four million pounds of fuel, one nuclear weapon,
and a thing that has 270,000 moving parts built by the lowest bidder.
Makes you feel good, doesn't it?
   --  Rockhound, "Armageddon"

Re: Ada.Execution_Time

[Dmitry A. Kazakov]

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

Re: Ada.Execution_Time

[Niklas Holsti]

Vinzent Hoefler wrote:
> BrianG wrote:
> 
>> If you mean that they both define a Clock and a Split, maybe.  If you 
>> meanany program that actually does anything, that's not possible.
>> That was my original comment:  Execution_Time does not provide any
>>types/operations useful, without also 'with'ing Real_Time.
> 
> Yes, but so what? The intention of Ada.Execution_Time wasn't to provide the
> user with means to instrument the software and to Text_IO some mostly
> meaningless values (any decent profiler can do that for you), but rather a
> way to implement user-defined schedulers based on actual CPU usage.

That is also my understanding of the intention. Moreover, since task 
scheduling for real-time systems unavoidably deals both with execution 
times and with real times, I think it is natural that both 
Ada.Execution_Time and Ada.Real_Time are required.

> And well, if you're ranting about CPU_Time, Real_Time.Time_Span is not much
> better. It's a pain in the ass to convert an Ada.Real.Time_Span to another
> type to interface with OS-specific time types (like time_t) if you're 
> opting for speed, portability and accuracy.

If your target type is OS-specific, it seems harsh to require full 
portability of the conversion.

> BTW, has anyone any better ideas to convert TimeSpan into a record 
> containing seconds and nanoseconds than this:

I may not have better ideas, but I do have some comments on your code.

>    function To_Interval (TS : in Ada.Real_Time.Time_Span)
>                          return ASAAC_Types.TimeInterval is

The following are constants independent of the parameters:

>       Nanos_Per_Sec : constant                         := 1_000_000_000.0;
>       One_Second    : constant Ada.Real_Time.Time_Span :=
>                         Ada.Real_Time.Milliseconds (1000);

(Why not ... := Ada.Real_Time.Seconds (1) ?)

>       Max_Interval  : constant Ada.Real_Time.Time_Span :=
>                         Integer (ASAAC_Types.Second'Last) * One_Second;

... so I would move the above declarations into the surrounding package, 
at least for One_Second and Max_Interval. Of course a compiler might do 
that optimization in the code, too. (By the way, Max_Interval is a bit 
less than the largest value of TimeInterval, since the above expression 
has no NSec part.)

>       Seconds       : ASAAC_Types.Second;
>       Nano_Seconds  : ASAAC_Types.Nanosec;
>    begin
>       declare
>          Sub_Seconds : Ada.Real_Time.Time_Span;
>       begin

The following tests for ranges seem unavoidable in any conversion 
between types defined by different sources. I don't see how 
Ada.Real_Time can be blamed for this.  Of course I cannot judge if the 
result (saturation at 'Last or 'First) is right for your application. As 
you say, there are potential overflow problems, already in the 
computation of Max_Interval above.

>          if TS >= Max_Interval then
>             Seconds      := ASAAC_Types.Second'Last;
>             Nano_Seconds := ASAAC_Types.Nanosec'Last;

An alternative approach to the over-range condition TS >= Max_Interval 
is to make the definition of the application-specific type 
ASAAC_Types.Second depend on the actual range of Ada.Real_Time.Time_Span 
so that over-range becomes impossible. Unfortunately I don't see how 
this could be done portably by static expressions in the declaration of 
ASAAC_Types.Second, so it would have to be a subtype declaration with an 
upper bound of To_Duration(Time_Span_Last)-1.0. This raises 
Constraint_Error at elaboration if the base type is too narrow.

>          elsif TS < Ada.Real_Time.Time_Span_Zero then
>             Seconds      := ASAAC_Types.Second'First;
>             Nano_Seconds := ASAAC_Types.Nanosec'First;

The above under-range test seems to be forced by the fact that 
ASAAC_Types.TimeInterval is unable to represent negative time intervals, 
  while Ada.Real_Time.Time_Span can do that. This problem is hardly a 
shortcoming in Ada.Real_Time.

>          else
>             Seconds      := ASAAC_Types.Second (TS / One_Second);
>             Sub_Seconds  := TS - (Integer (Seconds) * One_Second);
>             Nano_Seconds :=
>               ASAAC_Types.Nanosec
>                 (Nanos_Per_Sec * Ada.Real_Time.To_Duration (Sub_Seconds));

An alternative method converts the whole TS to Duration and then 
extracts the seconds and nanoseconds:

    TS_Dur : Duration;

    TS_Dur := To_Duration (TS);
    Seconds := ASAAC_Types.Second (TS_Dur - 0.5);
    Nano_Seconds := ASAAC_Types.Nanosec (
       Nanos_Per_Sec * (TS_Dur - Duration (Seconds)));

This, too, risks overflow in the multiplication, since the guaranteed 
range of Duration only extends to 86_400. Moreover, using Duration may 
lose precision (see below).

>          end if;
>       end;
> 
>       return
>         ASAAC_Types.TimeInterval'(Sec  => Seconds,
>                                   NSec => Nano_Seconds);
>    end To_Interval;
> 
> The solution I came up with here generally works, but suffers some 
> potential overflow problems

I think they are unavoidable unless you take care to make the range of 
the application-defined types (ASAAC_Types) depend on the range of the 
implementations of the standard types and also do the multiplication in 
some type with sufficient range, that you define.

> and doesn't look very efficient to me (although that'a minor
> problem given the context it's usually used in).

Apart from the definition of the constants (which can be moved out of 
the function), and the range checks (which depend on the application 
types in ASAAC_Types), the real conversion consists of a division, a 
subtraction, two multiplications and one call of To_Duration. This does 
not seem excessive to me, considering the nature of that target type. 
The alternative method that starts by converting all of TS to Duration 
avoids the division.

Still, this example suggests that Ada.Real_Time perhaps should provide a 
Split operation that divides a Time_Span into an integer number of 
Seconds and a sub-second Duration.

A problem that you don't mention is that the use of Duration may cause 
loss of precision. Duration'Small may be as large as 20 milliseconds (RM 
9.6(27)), although at most 100 microseconds are advised (RM 9.6(30)), 
while the Time_Span resolution must be 20 microseconds or better (RM 
D.8(30)). Perhaps Annex D should require better Duration resolution?

Loss of precision could be avoided by doing the multiplication in 
Time_Span instead of in Duration:

    Nano_Seconds := ASAAC_Types.Nanosec (
       To_Duration (Nanos_Per_Sec * Sub_Seconds));

but the overflow risk is perhaps larger, since Time_Span_Last may not be 
larger than 3600 (RM D.8(31)).

I have met with similar tricky problems in conversions between types of 
different origins in other contexts, too. I don't think that these 
problems mean that Ada.Real_Time is defective.

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

Re: Ada.Execution_Time

[Dmitry A. Kazakov]

On Sun, 19 Dec 2010 05:01:22 +0100, Vinzent Hoefler wrote:

> And well, if you're ranting about CPU_Time, Real_Time.Time_Span is not much
> better. It's a pain in the ass to convert an Ada.Real.Time_Span to another
> type to interface with OS-specific time types (like time_t) if you're opting
> for speed, portability and accuracy.

Well, speaking from my experience, the OS-specific time types are hardly
usable because of the OS services working with these types. The problem is
not conversion, but the implementations, which *do* use these [broken]
services. They might have a catastrophic accuracy. For example, under
VxWorks we had to replace the AdaCore implementation of Ada.Real_Time with
our own implementation. This stuff is inherently non-portable.

But the interface of Ada.Real_Time is portable, so I see absolutely no
point in replacing it with something OS-specific. It won't get either
portability or accuracy.

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

Re: Ada.Execution_Time

[anon]

In <iejsu9$lct$1@news.eternal-september.org>, BrianG <briang000@gmail.com> writes:
>anon@att.net wrote:
>> In <ie91co$cko$1@news.eternal-september.org>, BrianG <briang000@gmail.com> writes:
>>> Georg Bauhaus wrote:
>>>> On 12/12/10 10:59 PM, BrianG wrote:
>....
>[Lots of meaningless comments deleted.]
>> For the average Ada programmer, its another Ada package that most will 
>> never use because they will just use Ada.Real_Time.  
>[etc.]
>>  In some cases the Ada.Execution_Time
>> package can replace the Ada.Real_Time with only altering the with/use 
>> statements.
>If you mean that they both define a Clock and a Split, maybe.  If you mean
>any program that actually does anything, that's not possible.  That was my
>original comment:  Execution_Time does not provide any types/operations
>useful, without also 'with'ing Real_Time.
>> 
>[etc.]
>(Don't know why I bother w/ this msg.)


Kind of funny you cutting down "TOP" which can be found on most Linux 
boxes  Which allow anyone with the CPU options turn on to see both the 
Real_Time and CPU_Time.

An Example: Just use you your favorite music/video player and play a 2 
min song.  Real_Time will show the 2 min for the song and the 1 to 3 
seconds for the CPU_Time. 

And I know one professor that is now station in Poland that did enjoy 
giving his student assignment to decrease the amount of CPU execution 
time that an algorithm used. Which meant a student normally had to 
rewrite the algorithm. His student just loved him for that!


Note: Not sure of the name for the Windows version of Linux's top.


As for "Pragmas" that may effect the "CPU Execution Time. 
Three may pragmas that have been disabled in GNAT and they are:

    pragma Optimize     :  Gnat uses gcc command line -O(0,1,2,3.4).
                           Which does effect compiler language 
                           translation.

    pragma System_Name  :  Gnat uses default or gcc command line to 
    pragma Storage_Unit :  determine target. Target processor and its 
                           normal data size can effect CPU time.



And for web Servers:

Check with any main web hosting for the "Terms" or "Agreement".  In 
the document you will see a paragraph that states the web site excess 
from 10 to 25% of the resources will be shutdown.

Examples: 

    From Host: http://www.micfo.com/agreement

    6 SERVER RESOURCE USAGE


        The Client agrees to utilize "micfo's" Server Resources as set 
        out in clause 6.2.1, 6.2,2:

    6.2.1
        Shared Hosting; 7% of the CPU in any given twenty two (22) 
        Business Days.
    6.2.2
        Reseller Hosting; 10% of the CPU in any given twenty two 
        (22) Business Days.


        Also: from Host: http://www.hostgator.com/tos/tos.php

        User may not: 

        1) Use 25% or more of system resources for longer then 90 
           seconds. There are numerous activities that could cause 
           such problems; these include: CGI scripts, FTP, PHP, 
           HTTP, etc.

       12) Only use https protocol when necessary; encrypting and 
           decrypting communications is noticeably more CPU-intensive 
           than unencrypted communications.


How to you think these or any other web hosting company could measure the 
complete system resources without measuring the CPU Execution Time on a 
given user or application! In Ada, the routines can now use the package 
called "Ada.CPU_Execution_Time".

Re: Ada.Execution_Time

[BrianG]

anon@att.net wrote:
> In <iejsu9$lct$1@news.eternal-september.org>, BrianG <briang000@gmail.com> writes:
>> anon@att.net wrote:
>>> In <ie91co$cko$1@news.eternal-september.org>, BrianG <briang000@gmail.com> writes:
>>>> Georg Bauhaus wrote:
>>>>> On 12/12/10 10:59 PM, BrianG wrote:
>> ....
> 
> Kind of funny you cutting down "TOP" which can be found on most Linux 
> boxes  Which allow anyone with the CPU options turn on to see both the 
> Real_Time and CPU_Time.
Please provide any comment I made for/against "top".  Since my original 
question was based on Windows and I've stated that my (current) Linux 
doesn't support this package, that seems unlikely (even if I didn't 
trust my memory).
> 
...
> Note: Not sure of the name for the Windows version of Linux's top.
There is (that I know of) no real equiv to "top" - as in a command-line 
program.  The equiv to GNOME's "System Monitor" (for example - a gui 
program) would be Task Manager (and I made no comment about that either).
> 
...
> 
> How to you think these or any other web hosting company could measure the 
> complete system resources without measuring the CPU Execution Time on a 
> given user or application! In Ada, the routines can now use the package 
> called "Ada.CPU_Execution_Time".
> 
I have no problem with what Execution_Time does (as evidenced by the 
fact that I asked a question about its use) - it measures exactly what I 
want, an estimate of the CPU time used by a task.  My problem is with 
the way it is defined - it provides, by itself, no "value" of that that 
a using program can make use of to print or calculate (i.e. you also 
need Real_Time for that, which is silly - and I disagree that that is 
necessarily required in any case - my program didn't need it otherwise).
> 
--BrianG

Re: Ada.Execution_Time

[Keith Thompson]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> "Adam Beneschan" <adam@irvine.com> wrote in message 
> news:dfcf048b-bb6e-4993-b62a-9147bad3a6ff@j32g2000prh.googlegroups.com...
> On Dec 15, 2:52 pm, Keith Thompson <ks...@mib.org> wrote:
> ...
>>> So, um, why is Assert a pragma rather than a statement?
>>>
>>> if Debug_Mode then
>>> assert Is_Good(X);
>>> end if;
> ...
>>Somebody on the ARG might have a more authoritative answer.  My
>>reading of AI95-286 is that a number of Ada compilers had already
>>implemented the Assert pragma and there was a lot of code using it.
>>Of course, those compilers couldn't have added "assert" as a statement
>>on their own, but adding an implementation-defined pragma is OK.
>
> That's one reason. The other is that you can't put a statement into a 
> declarative part (well, you can, but you need to use a helper generic and a 
> helper procedure, along with an instantiation, which is insane -- although 
> it is not that unusual to see that done in a program). A lot of asserts fit 
> most naturally into the declarative part (precondition ones, for instance, 
> although those will be better defined separately in Ada 2012).

So add an assert operator that always yields True:

    declare
        Dummy: constant Boolean := assert some_expression; -- assert operator
    begin
        assert some_other_expression; -- assert statement
    end;

Though the use of "Assert" as an identifier in existing code is
certainly an issue.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: Ada.Execution_Time

[Randy Brukardt]

"Vinzent Hoefler" <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> 
wrote in message news:op.vnxz4kmplzeukk@jellix.jlfencey.com...
...
> Yes, but so what? The intention of Ada.Execution_Time wasn't to provide 
> the
> user with means to instrument the software and to Text_IO some mostly
> meaningless values (any decent profiler can do that for you), but rather a
> way to implement user-defined schedulers based on actual CPU usage. You 
> may
> want to take a look at the child packages Timers and Group_Budget to see 
> the
> intended usage.

Probably, but I wanted to use Ada.Execution_Time to *write* a "decent 
profiler" for our Ada programs. Since Janus/Ada doesn't use the system 
tasking facilities (mostly for historical reasons), existing profilers don't 
do a good job if the program includes any tasks. I've used various hacks 
based on Windows facilities to do part of the job, but Ada.Execution_Time 
would provide better information (especially for tasks).

Similarly, anyone that wanted portable profiling information probably would 
prefer to use Ada.Execution_Time rather than to invent something new (and 
neecessarily not as portable). I found this sort of usage at least as 
compelling as the real-time usages.

                                       Randy.

Re: Ada.Execution_Time

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:8n66ucFnavU1@mid.individual.net...
...
> A problem that you don't mention is that the use of Duration may cause 
> loss of precision. Duration'Small may be as large as 20 milliseconds (RM 
> 9.6(27)), although at most 100 microseconds are advised (RM 9.6(30)), 
> while the Time_Span resolution must be 20 microseconds or better (RM 
> D.8(30)). Perhaps Annex D should require better Duration resolution?

The rules for Duration were chosen so that it would not require more than a 
32-bit type. Not all embedded processors are set up to handle 64-bit numbers 
efficiently...

(As time moves on, this is less of a consideration than it used to be, but 
it still seems like a possible problem. Time_Span itself doesn't suffer from 
the problem since as a private type it can be represented as a record with 
several components. Duration is a visible fixed point type.) 

Re: Ada.Execution_Time

[Jeffrey Carter]

On 12/20/2010 05:37 PM, Randy Brukardt wrote:
>
> The rules for Duration were chosen so that it would not require more than a
> 32-bit type. Not all embedded processors are set up to handle 64-bit numbers
> efficiently...

Not much of a difference on an 8-bit processor, surely?

-- 
Jeff Carter
"Crucifixion's a doddle."
Monty Python's Life of Brian
82

Re: Ada.Execution_Time

[Robert A Duff]

Keith Thompson <kst-u@mib.org> writes:

> So add an assert operator that always yields True:
>
>     declare
>         Dummy: constant Boolean := assert some_expression; -- assert operator
>     begin
>         assert some_other_expression; -- assert statement
>     end;

If asserts had their own syntax, we could allow them wherever
we like -- "assert blah;" could be both a statement and
a declarative_item.

I really don't like having to declare dummy booleans.
It gets even more annoying when you have several.
What are you going to call them?  Dummy_1, Dummy_2,
and Dummy_3?  And then after some maintenance,
Dummy_1, Dummy_2_and_a_half, and Dummy_3?
Seems like an awful lot of noise -- assertions should
be easy!  (Of course, you might remember me complaining
that the declare/begin/end is just noise, too.)

Anyway, the strong syntactic separation between declarations
and statements makes no sense in a language where declarations
are executable code.  I think it's just wrong-headed thinking
inherited from Pascal.

> Though the use of "Assert" as an identifier in existing code is
> certainly an issue.

I've certainly written procedures called Assert that do
what you might expect.  This was quite common before
pragma Assert existed.

- Bob

Re: Ada.Execution_Time

[Dmitry A. Kazakov]

On Mon, 20 Dec 2010 22:23:12 -0500, Robert A Duff wrote:

> Anyway, the strong syntactic separation between declarations
> and statements makes no sense in a language where declarations
> are executable code.  I think it's just wrong-headed thinking
> inherited from Pascal.

It still does have sense in a language with lexical scopes. You need some
syntactically recognizable point where all things of the same scope become
usable.

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

Re: Ada.Execution_Time

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Mon, 20 Dec 2010 22:23:12 -0500, Robert A Duff wrote:
>
>> Anyway, the strong syntactic separation between declarations
>> and statements makes no sense in a language where declarations
>> are executable code.  I think it's just wrong-headed thinking
>> inherited from Pascal.
>
> It still does have sense in a language with lexical scopes. You need some
> syntactically recognizable point where all things of the same scope become
> usable.

Yes, you need such a "syntactically recognizable point".
But that doesn't require any separation of declarations
from statements.  If My_Assert is just a regular
user-defined procedure, then I see nothing wrong with:

    procedure P is
        X : T1 := ...;
        My_Assert(Is_Good(X)); -- Not Ada!
        Y : T2 := ...;
        My_Assert(not Is_Evil(Y));
        ...

without sprinkling "declares" and "begins" all over.

- Bob

Re: Ada.Execution_Time

[Dmitry A. Kazakov]

On Tue, 21 Dec 2010 12:19:47 -0500, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Mon, 20 Dec 2010 22:23:12 -0500, Robert A Duff wrote:
>>
>>> Anyway, the strong syntactic separation between declarations
>>> and statements makes no sense in a language where declarations
>>> are executable code.  I think it's just wrong-headed thinking
>>> inherited from Pascal.
>>
>> It still does have sense in a language with lexical scopes. You need some
>> syntactically recognizable point where all things of the same scope become
>> usable.
> 
> Yes, you need such a "syntactically recognizable point".
> But that doesn't require any separation of declarations
> from statements.  If My_Assert is just a regular
> user-defined procedure, then I see nothing wrong with:
> 
>     procedure P is
>         X : T1 := ...;
>         My_Assert(Is_Good(X)); -- Not Ada!
>         Y : T2 := ...;
>         My_Assert(not Is_Evil(Y));
>         ...
> 
> without sprinkling "declares" and "begins" all over.

There are too many issues which are wrong here.

1. The exceptions from My_Assert cannot be handled in P.

2. Checking an instance of T1 is not bound to the type. It is done upon
some arbitrary usage of T1 in an arbitrary procedure P.

3. Assuming that checking is really bound to the procedure P, then I want
to be sure that checking is not premature, that P has elaborated all stuff
belonging there, *before* I am starting to check things.

4. Ada *cannot* handle errors upon initialization and finalization. We have
to fix that first before even considering checks in such contexts.

etc.

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

Re: Ada.Execution_Time

[anon]

In <iemhm8$4up$1@news.eternal-september.org>, BrianG <briang000@gmail.com> writes:
>anon@att.net wrote:
>> In <iejsu9$lct$1@news.eternal-september.org>, BrianG <briang000@gmail.com> writes:
>>> anon@att.net wrote:
>>>> In <ie91co$cko$1@news.eternal-september.org>, BrianG <briang000@gmail.com> writes:
>>>>> Georg Bauhaus wrote:
>>>>>> On 12/12/10 10:59 PM, BrianG wrote:
>>> ....
>> 
>> Kind of funny you cutting down "TOP" which can be found on most Linux 
>> boxes  Which allow anyone with the CPU options turn on to see both the 
>> Real_Time and CPU_Time.
>Please provide any comment I made for/against "top".  Since my original 
>question was based on Windows and I've stated that my (current) Linux 
>doesn't support this package, that seems unlikely (even if I didn't 
>trust my memory).
>> 
>....
>> Note: Not sure of the name for the Windows version of Linux's top.
>There is (that I know of) no real equiv to "top" - as in a command-line 
>program.  The equiv to GNOME's "System Monitor" (for example - a gui 
>program) would be Task Manager (and I made no comment about that either).
>> 
>....
>> 
>> How to you think these or any other web hosting company could measure the 
>> complete system resources without measuring the CPU Execution Time on a 
>> given user or application! In Ada, the routines can now use the package 
>> called "Ada.CPU_Execution_Time".
>> 
>I have no problem with what Execution_Time does (as evidenced by the 
>fact that I asked a question about its use) - it measures exactly what I 
>want, an estimate of the CPU time used by a task.  My problem is with 
>the way it is defined - it provides, by itself, no "value" of that that 
>a using program can make use of to print or calculate (i.e. you also 
>need Real_Time for that, which is silly - and I disagree that that is 
>necessarily required in any case - my program didn't need it otherwise).
>> 
>--BrianG
There has been many third party versions of this package over the years 
and most of them included a Linux version. The Windows is specific to GNAT. 
And it just like GNAT the Windows version is not complete either.

For Execution_Time there are three package. GNAT has 
  Ada.Execution_Time                    for both Linux-MaRTE and Windows
  Ada.Execution_Time.Timers             only for Linux-MaRTE
  Ada.Execution_Time.Group_Budgets      Unimplemented Yet



In using the Linux-MaRTE version ( 2 packages ) 
  Ada.Execution_Time 
  Ada.Execution_Time.Timers 

Of course in this example you could use ( Note: they are fully implemented )
  Ada.Real_Time
  Ada.Real_Time.Timing_Events


An algorithm comparison program might look like:

with Ada.Execution_Time ;
with Ada.Execution_Time.Timers ;

procedure Compare_Algorithm is

    task type Algorithm_1 is
      use Ada.Execution_Time.Timers ;
    begin
      begin
        Set_Handler ( ... ) ; -- start timer
        Algorithm_1 ;
        Time_Remaining ( ... ) ; -- sample timer
      end ;
      Cancel_Handler ( ... ) ; release timer
    end ;    

    task type Algorithm_2 is
      use Ada.Execution_Time.Timers ;
    begin
      begin
        Set_Handler ( ... ) ; -- start timer
        Algorithm_2 ;
        Time_Remaining ( ... ) ; -- sample timer
      end ;
      Cancel_Handler ( ... ) ; release timer
    end ;    

  use Ada.Execution_Time ;

begin
  -- Start tasks
  -- wait until all tasks finish
  -- compare times using Execution_Time
  -- Print summary of comparison
end ;

Re: Ada.Execution_Time

[BrianG]

anon@att.net wrote:
> In <iemhm8$4up$1@news.eternal-september.org>, BrianG <briang000@gmail.com> writes:
>> anon@att.net wrote:
>> I have no problem with what Execution_Time does (as evidenced by the 
>> fact that I asked a question about its use) - it measures exactly what I 
>> want, an estimate of the CPU time used by a task.  My problem is with 
>> the way it is defined - it provides, by itself, no "value" of that that 
>> a using program can make use of to print or calculate (i.e. you also 
>> need Real_Time for that, which is silly - and I disagree that that is 
>> necessarily required in any case - my program didn't need it otherwise).
>> --BrianG
> There has been many third party versions of this package over the years 
> and most of them included a Linux version. The Windows is specific to GNAT. 
> And it just like GNAT the Windows version is not complete either.
My comments have been about the RM-defined package and its lack of 
usability (if that wasn't already clear).  What may or may not be 
provided by implementation-specific packages is irrelevant.

> 
> For Execution_Time there are three package. GNAT has 
>   Ada.Execution_Time                    for both Linux-MaRTE and Windows
>   Ada.Execution_Time.Timers             only for Linux-MaRTE
>   Ada.Execution_Time.Group_Budgets      Unimplemented Yet
> 
When you say "GNAT" here you should probably specify what version you 
mean.  I haven't looked in this area, but I was under the impression 
that GNAT has implemented all of Ada'05 for quite a while now (in Pro; 
maybe it has not yet all reached GCC or GPL releases?).

> 
> 
> In using the Linux-MaRTE version ( 2 packages ) 
>   Ada.Execution_Time 
>   Ada.Execution_Time.Timers 
See below.
> 
> Of course in this example you could use ( Note: they are fully implemented )
>   Ada.Real_Time
>   Ada.Real_Time.Timing_Events
So, instead of using a functionality already provided (with a slight 
kludgy issue), I should implement it entirely myself?  I still don't see 
how this could get me CPU_Time (even a "simulation" value).

> 
> 
> An algorithm comparison program might look like:
> 
> with Ada.Execution_Time ;
> with Ada.Execution_Time.Timers ;
Given the below program, please add some of the missing details to show 
how this can be useful without also "with Ada.Real_Time".  Neither 
Execution_Time or Execution_Time.Timers provides any value that can be 
used directly.

> 
> procedure Compare_Algorithm is
> 
>     task type Algorithm_1 is
>       use Ada.Execution_Time.Timers ;
>     begin
>       begin
>         Set_Handler ( ... ) ; -- start timer
>         Algorithm_1 ;
>         Time_Remaining ( ... ) ; -- sample timer
>       end ;
>       Cancel_Handler ( ... ) ; release timer
>     end ;    
> 
>     task type Algorithm_2 is
>       use Ada.Execution_Time.Timers ;
>     begin
>       begin
>         Set_Handler ( ... ) ; -- start timer
>         Algorithm_2 ;
>         Time_Remaining ( ... ) ; -- sample timer
>       end ;
>       Cancel_Handler ( ... ) ; release timer
>     end ;    
> 
>   use Ada.Execution_Time ;
> 
> begin
>   -- Start tasks
>   -- wait until all tasks finish
>   -- compare times using Execution_Time
Provide details here (line above and line below)- without relying on 
CPU_Time or Time_Span, which are both private.
>   -- Print summary of comparison
> end ;
> 
> 
--BrianG

Re: Ada.Execution_Time

[Niklas Holsti]

Dmitry A. Kazakov wrote:
> On Sat, 18 Dec 2010 23:20:20 +0200, Niklas Holsti wrote:
...
>> 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,

Fine for what? For schedulability analysis, fine for on-line scheduling,
... ?

However, this is a side issue, since we are (or at least I am)
discussing what the RM intends with Ada.Execution_Time, which must be
read in the context of D.2.1, which assumes that there is a clearly
defined set of "processors" and each processor executes exactly one
task at a time.

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

I still disagree, if we are talking about the intent of the RM. You have
not given any arguments, based on the RM text, to support your position.

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

The behaviour of some CPU/OS is irrelevant to the intent of the RM. As 
already said, an Ada implementation on such CPU/OS could use its own 
mechanisms for execution-time measurements.

> On a such platform the implementation would be as perverse as RM D.14
> is. But the perversion is only because of the interpretation.

Bah. I think that when RM D.14 says "time", it really means time. You
think it means something else, perhaps a CPU cycle count. I think the 
burden of proof is on you.

It seems evident to me that the text in D.14 must be interpreted using
the concepts in D.2.1, "The Task Dispatching Model", which clearly
specifies real-time points when a processor starts to execute a task and
stops executing a task. To me, and I believe to most readers of the RM,
the execution time of a task is the sum of these time slices, thus a
physical, real time.

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

I put my comment, above, in parentheses because it is a side issue.

And you still have not defined what you mean by "simulation time", and
how you come there from the RM text.

> It can be used for CPU load estimations,

How, if it has "no physical meaning", as you claim?

> while the "real time" implementation could not.

Why not? That is the way ordinary schedulability analysis works. And
again, it is irrevelant that some CPU/OS do not provide a good way to
measure the physical execution time of tasks.

> BTW, even for measurements people usually have in mind (e.g.
> comparing resources consumed by tasks), simulation time would be more
> fair.

What is "simulation time"?

> The problem is with I/O, because I/O is a "real" thing.

I assume by "I/O" you mean time consumed in waiting for some external
event. I agree that such I/O is a (solvable) problem in schedulability 
analysis, but it is not relevant for understanding the intent of RM D.14.

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

Re: Ada.Execution_Time

[Dmitry A. Kazakov]

On Sat, 25 Dec 2010 13:31:27 +0200, Niklas Holsti wrote:

> Dmitry A. Kazakov wrote:
>> On Sat, 18 Dec 2010 23:20:20 +0200, Niklas Holsti wrote:
> ...
>>> 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,
> 
> Fine for what? For schedulability analysis, fine for on-line scheduling,
> ... ?

Applicability of a concept is not what makes it wrong or right.

> However, this is a side issue, since we are (or at least I am)
> discussing what the RM intends with Ada.Execution_Time, which must be
> read in the context of D.2.1, which assumes that there is a clearly
> defined set of "processors" and each processor executes exactly one
> task at a time.

Why? Scheduling does not need Ada.Execution_Time, it is the
Ada.Execution_Time implementation, which needs some input from the
scheduler.

How do you explain that CPU_Time, a thing about time sharing, appears in
the real-time systems annex D?

> You have
> not given any arguments, based on the RM text, to support your position.

I am not a language lawyer to interpret the RM texts. My argument was to
common sense.

>>>> 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.
> 
> The behaviour of some CPU/OS is irrelevant to the intent of the RM.

Nope, one of the killer arguments ARG people deploy to reject most
reasonable AI's is: too difficult to implement on some obscure platform for
which Ada never existed and never will. (:-))

> As 
> already said, an Ada implementation on such CPU/OS could use its own 
> mechanisms for execution-time measurements.

Could or must? Does GNAT this?

>> On a such platform the implementation would be as perverse as RM D.14
>> is. But the perversion is only because of the interpretation.
> 
> Bah. I think that when RM D.14 says "time", it really means time. You
> think it means something else, perhaps a CPU cycle count. I think the 
> burden of proof is on you.
> 
> It seems evident to me that the text in D.14 must be interpreted using
> the concepts in D.2.1, "The Task Dispatching Model", which clearly
> specifies real-time points when a processor starts to execute a task and
> stops executing a task. To me, and I believe to most readers of the RM,
> the execution time of a task is the sum of these time slices, thus a
> physical, real time.

If that was the intent, then I really do not understand why CPU_Time was
introduced in addition to Ada.Real_Time.Time / Time_Span.

> And you still have not defined what you mean by "simulation time", and
> how you come there from the RM text.

Simulation time is a model of real time a physical process might have under
certain conditions.

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

Re: Ada.Execution_Time

[Niklas Holsti]

Dmitry A. Kazakov wrote:
> On Sat, 25 Dec 2010 13:31:27 +0200, Niklas Holsti wrote:
> 
>> Dmitry A. Kazakov wrote:
>>> On Sat, 18 Dec 2010 23:20:20 +0200, Niklas Holsti wrote:
>> ...
>>>> 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,
>> Fine for what? For schedulability analysis, fine for on-line scheduling,
>> ... ?
> 
> Applicability of a concept is not what makes it wrong or right.

I think it does. This concept, "the execution time of a task", stands 
for a number. A number is useless if it has no application in a 
calculation. I don't know of any other meaning of "wrongness" for a 
numerical concept.

>> However, this is a side issue, since we are (or at least I am)
>> discussing what the RM intends with Ada.Execution_Time, which must be
>> read in the context of D.2.1, which assumes that there is a clearly
>> defined set of "processors" and each processor executes exactly one
>> task at a time.
> 
> Why?

Because RM D.14 uses terms defined in RM D.2.1, for example "executing".

> Scheduling does not need Ada.Execution_Time,

The standard schedulers defined in the RM do no not need 
Ada.Execution_Time but, as remarked earlier in this thread, one of the 
purposes of Ada.Execution_Time is to support the implementation of 
non-standard scheduling algorithms that may make on-line scheduling 
decisions that depend on the actual execution times of tasks. For 
example, scheduling based on "slack time".

> it is the Ada.Execution_Time implementation, which needs some
> input from the scheduler.

We must be precise about our terms, here. Using terms as defined in 
http://en.wikipedia.org/wiki/Task_scheduling, Ada.Execution_Time needs 
input from the task *dispatcher* -- the part of the kernel that suspends 
and resumes tasks. It does not need input from the *scheduler*, which is 
the kernel part that selects the next task to be executed from among the 
ready tasks.

The term "dispatching" is defined differently in RM D.2.1 to mean the 
same as "scheduling" in the Wikipedia entry.

> How do you explain that CPU_Time, a thing about time sharing, appears in
> the real-time systems annex D?

You don't think that execution time is important for real-time systems?

In my view, CPU_Time is a measure of "real time", so its place in annex 
D is natural. In your view, CPU_Time is not "real time", which should 
make *you* surprised that it appears in annex D.

>> You have
>> not given any arguments, based on the RM text, to support your position.
> 
> I am not a language lawyer to interpret the RM texts. My argument was to
> common sense.

To me it seems that your argument is based on the difficulty (in your 
opinion) of implementing Ada.Execution_Time in some OSes such as MS 
Windows, if the RM word "time" is taken to mean real time.

It is common sense that some OSes are not designed (or not well 
designed) for real-time systems. Even a good real-time OS may not 
support all real-time methodologies, for example scheduling algorithms 
that depend on actual execution times.

>>>>> 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.
>> The behaviour of some CPU/OS is irrelevant to the intent of the RM.
> 
> Nope, one of the killer arguments ARG people deploy to reject most
> reasonable AI's is: too difficult to implement on some obscure platform for
> which Ada never existed and never will. (:-))

Apparently such arguments, if any were made in this case, were not valid 
enough to prevent the addition of Ada.Execution_Time to the RM.

Is your point that Ada.Execution_Time was accepted only because the ARG 
decided that the word "time" in RM D.14 should not be understood to mean 
real time? I doubt that very much... Surely such an unusual meaning of 
"time" should have been explained in the RM.

>> As already said, an Ada implementation on such CPU/OS could
>> use its own mechanisms for execution-time measurements.
> 
> Could or must? Does GNAT this?

I don't much care, it is irrelevant for understanding what the RM means. 
Perhaps the next version of MS Windows will have better support for 
measuring real task execution times; would that change the intent of the 
RM? Of course not.

>> It seems evident to me that the text in D.14 must be interpreted using
>> the concepts in D.2.1, "The Task Dispatching Model", which clearly
>> specifies real-time points when a processor starts to execute a task and
>> stops executing a task. To me, and I believe to most readers of the RM,
>> the execution time of a task is the sum of these time slices, thus a
>> physical, real time.
> 
> If that was the intent, then I really do not understand why CPU_Time was
> introduced in addition to Ada.Real_Time.Time / Time_Span.

Because (as I understand it) different processors/OSes have different 
mechanisms for measuring execution times and real times, and the 
mechanism most convenient for CPU_Time may use a different numerical 
type (range, scale, and precision) than the mechanisms and types used 
for Ada.Real_Time.Time, Time_Span, and Duration. This is evident in the 
different minimum ranges and precisions defined in the RM for these 
types. Randy remarked on this earlier in this thread.

>> And you still have not defined what you mean by "simulation time", and
>> how you come there from the RM text.
> 
> Simulation time is a model of real time a physical process might have under
> certain conditions.

Thank you. But I still do not see how your definition could be applied 
in this context, so we are back at the start of the post... :-)

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

Re: Ada.Execution_Time

[Dmitry A. Kazakov]

On Mon, 27 Dec 2010 14:44:53 +0200, Niklas Holsti wrote:

> Dmitry A. Kazakov wrote:
>> On Sat, 25 Dec 2010 13:31:27 +0200, Niklas Holsti wrote:
>> 
>>> Dmitry A. Kazakov wrote:
>>>> On Sat, 18 Dec 2010 23:20:20 +0200, Niklas Holsti wrote:
>>> ...
>>>>> 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,
>>> Fine for what? For schedulability analysis, fine for on-line scheduling,
>>> ... ?
>> 
>> Applicability of a concept is not what makes it wrong or right.
> 
> I think it does. This concept, "the execution time of a task", stands 
> for a number. A number is useless if it has no application in a 
> calculation.

Technically, CPU_Time is not a number in any sense. It is not a numeric Ada
type and it is not a model of a mathematical number (not even additive).

Anyway, the execution time can be used in calculations independently on
whether and how you could apply the results of such calculations.

You can add the height of your house to the distance to the Moon, the
interpretation is up to you.

>>> However, this is a side issue, since we are (or at least I am)
>>> discussing what the RM intends with Ada.Execution_Time, which must be
>>> read in the context of D.2.1, which assumes that there is a clearly
>>> defined set of "processors" and each processor executes exactly one
>>> task at a time.
>> 
>> Why?
> 
> Because RM D.14 uses terms defined in RM D.2.1, for example "executing".

These terms stay valid for non-real time systems.

>> Scheduling does not need Ada.Execution_Time,
> 
> The standard schedulers defined in the RM do no not need 
> Ada.Execution_Time but, as remarked earlier in this thread, one of the 
> purposes of Ada.Execution_Time is to support the implementation of 
> non-standard scheduling algorithms that may make on-line scheduling 
> decisions that depend on the actual execution times of tasks. For 
> example, scheduling based on "slack time".

Even if somebody liked to undergo such an adventure, he also could use
Elementary_Functions in the scheduler. That would not make the nature of
Elementary_Functions any different.

>> it is the Ada.Execution_Time implementation, which needs some
>> input from the scheduler.
> 
> We must be precise about our terms, here. Using terms as defined in 
> http://en.wikipedia.org/wiki/Task_scheduling, Ada.Execution_Time needs 
> input from the task *dispatcher* -- the part of the kernel that suspends 
> and resumes tasks.

Let's call it dispatcher. Time sharing needs some measure of consumed CPU
time. My points stand:

1. Time sharing has little to do with real-time systems.

2. It would be extremely ill-advised to use Ada.Execution_Time instead of
direct measures for an implementation of time sharing algorithms.

>> How do you explain that CPU_Time, a thing about time sharing, appears in
>> the real-time systems annex D?
> 
> You don't think that execution time is important for real-time systems?

Real-time systems work with the real-time, they real-time intervals
(durations) are of much minor interest. Execution time is of no interest,
because a real-time system does not care to balance the CPU load.

> In my view, CPU_Time is a measure of "real time", so its place in annex 
> D is natural. In your view, CPU_Time is not "real time", which should 
> make *you* surprised that it appears in annex D.

It does not surprise me, because there is no "time-sharing systems" annex,
or better it be "it is not what you think" or "if you think you need this,
your are wrong." There are some other Ada features we could move there.
(:-))

>>> You have
>>> not given any arguments, based on the RM text, to support your position.
>> 
>> I am not a language lawyer to interpret the RM texts. My argument was to
>> common sense.
> 
> To me it seems that your argument is based on the difficulty (in your 
> opinion) of implementing Ada.Execution_Time in some OSes such as MS 
> Windows, if the RM word "time" is taken to mean real time.
> 
> It is common sense that some OSes are not designed (or not well 
> designed) for real-time systems. Even a good real-time OS may not 
> support all real-time methodologies, for example scheduling algorithms 
> that depend on actual execution times.

I disagree with almost everything here. To start with, comparing real-time
clock services of Windows and of VxWorks, we would notice that Windows is
far superior in both accuracy and precision. Yet Windows is a half-baked
time-sharing OS, while VxWorks is one of the leading real-time OSes. Why is
it so? Because real-time applications do not need clock much. They are
real-time because their sources of time are *real*. These are hardware
interrupts, while timer interrupts are of a much lesser interest. I don't
care how much processor time my control loop takes so long it manages to
write the outputs when the actuators expect them. Measuring the CPU time
would bring me nothing. It is useless before the run, because it is not a
proof that the deadlines will be met. It useless at run-time because there
are easier and safer ways to detect faults.

>>>>>> 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.
>>> The behaviour of some CPU/OS is irrelevant to the intent of the RM.
>> 
>> Nope, one of the killer arguments ARG people deploy to reject most
>> reasonable AI's is: too difficult to implement on some obscure platform for
>> which Ada never existed and never will. (:-))
> 
> Apparently such arguments, if any were made in this case, were not valid 
> enough to prevent the addition of Ada.Execution_Time to the RM.

That is because ARG didn't intend to reject it! Somebody wanted it no
matter what (like interfaces, limited results, asserts, then, like, I am
afraid, if-operators now). The rest was minimizing the damage...

> Is your point that Ada.Execution_Time was accepted only because the ARG 
> decided that the word "time" in RM D.14 should not be understood to mean 
> real time? I doubt that very much... Surely such an unusual meaning of 
> "time" should have been explained in the RM.

It is explained by its name: "execution time." Execution means not real,
unreal time (:-)).

>>> As already said, an Ada implementation on such CPU/OS could
>>> use its own mechanisms for execution-time measurements.
>> 
>> Could or must? Does GNAT this?
> 
> I don't much care, it is irrelevant for understanding what the RM means. 
> Perhaps the next version of MS Windows will have better support for 
> measuring real task execution times; would that change the intent of the 
> RM? Of course not.

You suggested that Ada implementations would/could attempt to be consistent
with your interpretation of CPU_Time. But it seems that at least one of the
leading Ada vendors does not care. Is it a laziness on their side or maybe
you just expected too much?

>>> It seems evident to me that the text in D.14 must be interpreted using
>>> the concepts in D.2.1, "The Task Dispatching Model", which clearly
>>> specifies real-time points when a processor starts to execute a task and
>>> stops executing a task. To me, and I believe to most readers of the RM,
>>> the execution time of a task is the sum of these time slices, thus a
>>> physical, real time.
>> 
>> If that was the intent, then I really do not understand why CPU_Time was
>> introduced in addition to Ada.Real_Time.Time / Time_Span.
> 
> Because (as I understand it) different processors/OSes have different 
> mechanisms for measuring execution times and real times, and the 
> mechanism most convenient for CPU_Time may use a different numerical 
> type (range, scale, and precision) than the mechanisms and types used 
> for Ada.Real_Time.Time, Time_Span, and Duration.

I see no single reason why this could happen. Obviously, if talking about a
real-time system as you insist, the only possible choice for CPU_Time is
Time_Span, because to be consistent with the interpretation you propose it
must be derived from Ada.Real_Time clock.

My point is that RM intentionally leaves it up to the implementation to
choose a CPU_Time source independent on Ada.Real_Time.Clock. This why
different range and precision come into consideration.

>>> And you still have not defined what you mean by "simulation time", and
>>> how you come there from the RM text.
>> 
>> Simulation time is a model of real time a physical process might have under
>> certain conditions.
> 
> Thank you. But I still do not see how your definition could be applied 
> in this context, so we are back at the start of the post... :-)

Under some conditions (e.g. no task switching) an execution time interval
could be numerically equal to a real time interval.

But in my view the execution time is not even a simulation time of some
ideal (real) clock. It is a simulation time of some lax recurrent process,
e.g. scheduling activity, of which frequency is not even considered
constant. It can be any garbage, and it likely is.

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

Re: Ada.Execution_Time

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Nope, one of the killer arguments ARG people deploy to reject most
> reasonable AI's is: too difficult to implement on some obscure platform for
> which Ada never existed and never will. (:-))

The ARG and others have been guilty of that sort of argument in the
past, although I think "most reasonable AI's" is an exaggeration.
I think that line of reasoning is wrong -- I think it's just fine to have
things like Ada.Directories, even though many embedded systems don't
have directories.  It means that there's some standardization across
systems that DO have directories.  Those that don't can either
provide some minimal/useless implementation, or else appeal
to RM-1.1.3(6).

I think today's ARG is less inclined to follow that wrong line
of reasoning.

(I don't much like the design of Ada.Directories, and I think
you (Dmitry) agree with me about that, but it's beside the
point.)

- Bob

Re: Ada.Execution_Time

[Niklas Holsti]

Dmitry A. Kazakov wrote:
> On Mon, 27 Dec 2010 14:44:53 +0200, Niklas Holsti wrote:
> 
>> Dmitry A. Kazakov wrote:
>>> On Sat, 25 Dec 2010 13:31:27 +0200, Niklas Holsti wrote:
>>>
>>>> Dmitry A. Kazakov wrote:
>>>>> On Sat, 18 Dec 2010 23:20:20 +0200, Niklas Holsti wrote:
>>>> ...
>>>>>> 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,
>>>> Fine for what? For schedulability analysis, fine for on-line scheduling,
>>>> ... ?
>>> Applicability of a concept is not what makes it wrong or right.
>> I think it does. This concept, "the execution time of a task", stands 
>> for a number. A number is useless if it has no application in a 
>> calculation.
> 
> Technically, CPU_Time is not a number in any sense. It is not a numeric Ada
> type and it is not a model of a mathematical number (not even additive).

RM D.14(12/2): "The type CPU_Time represents the execution time of a 
task. The set of values of this type corresponds one-to-one with an 
implementation-defined range of mathematical integers". Thus, a number.

However, the sub-thread above was not about CPU_Time in 
Ada.Execution_Time, but about the general concept "the execution time of 
a task". (Serves me right for introducing side issues, although my 
intentions were good, I think.)

> Anyway, the execution time can be used in calculations independently on
> whether and how you could apply the results of such calculations.
> 
> You can add the height of your house to the distance to the Moon, the
> interpretation is up to you.

You are being absurd.

Dmitri, your arguments are becoming so weird that I am starting to think 
that you are just trolling or goading me.

>>> it is the Ada.Execution_Time implementation, which needs some
>>> input from the scheduler.
>> We must be precise about our terms, here. Using terms as defined in 
>> http://en.wikipedia.org/wiki/Task_scheduling, Ada.Execution_Time needs 
>> input from the task *dispatcher* -- the part of the kernel that suspends 
>> and resumes tasks.
> 
> Let's call it dispatcher. Time sharing needs some measure of consumed CPU
> time. My points stand:
> 
> 1. Time sharing has little to do with real-time systems.

What do you mean by "time sharing"? The classical mainframe system used 
interactively by many terminals? What on earth does that have to do with 
our discussion? Such a system of course must have concurrent tasks or 
processes in some form, but so what?

If by "time sharing algorithms" (below in your point 2) you mean what is 
usually called "task scheduling algorithms", where several tasks 
time-share the same processor by a task-switching (dispatching) 
mechanism, your point 1 is bizarre. Priority-scheduled task switching is 
the canonical architecture for real-time systems.

> 2. It would be extremely ill-advised to use Ada.Execution_Time instead of
> direct measures for an implementation of time sharing algorithms.

If by "direct measures" you mean the use of some external measuring 
device such as an oscilloscope or logic analyzer, such measures are 
available only externally, to the developers, not within the Ada program 
itself. The whole point of Ada.Execution_Time is that it is available to 
the Ada program itself, enabling run-time decisions based on the actual 
execution times of tasks.

> Real-time systems work with the real-time, they real-time intervals
> (durations) are of much minor interest. Execution time is of no interest,
> because a real-time system does not care to balance the CPU load.

I am made speechless (or should I say "typing-less"). If that is your 
view, there is no point in continuing this discussion because we do not 
agree on what a real-time program is.

>>>> You have
>>>> not given any arguments, based on the RM text, to support your position.
>>> I am not a language lawyer to interpret the RM texts. My argument was to
>>> common sense.
>> To me it seems that your argument is based on the difficulty (in your 
>> opinion) of implementing Ada.Execution_Time in some OSes such as MS 
>> Windows, if the RM word "time" is taken to mean real time.
>>
>> It is common sense that some OSes are not designed (or not well 
>> designed) for real-time systems. Even a good real-time OS may not 
>> support all real-time methodologies, for example scheduling algorithms 
>> that depend on actual execution times.
> 
> I disagree with almost everything here. To start with, comparing real-time
> clock services of Windows and of VxWorks, we would notice that Windows is
> far superior in both accuracy and precision.

So what? Real-time systems need determinism. The clock only has to be 
accurate enough.

If your tasks suffer arbitrary millisecond-scale suspensions or 
dispatching delays (as is rumored for Windows) a microsecond-level clock 
accuracy is no help.

> Yet Windows is a half-baked
> time-sharing OS, while VxWorks is one of the leading real-time OSes. Why is
> it so? Because real-time applications do not need clock much. They are
> real-time because their sources of time are *real*. These are hardware
> interrupts, while timer interrupts are of a much lesser interest.

Both are important. Many control systems are driven by timers that 
trigger periodic tasks. In my experience (admittedly limited), it is 
rare for sensors to generate periodic input streams on their own, they 
must usually be sampled by periodic reads. You are right, however, that 
some systems, such as automobile engine control units, have external 
triggers, such as shaft-rotation interrupts.

Anyway, your point has do to with the "time" that *activates* tasks, not 
with the measurement of task-specific execution times. So this is 
irrelevant.

> I don't
> care how much processor time my control loop takes so long it manages to
> write the outputs when the actuators expect them.

You should care, if the processor must also have time for some other 
tasks of lower priority, which are preempted by the control-loop task.

> Measuring the CPU time
> would bring me nothing. It is useless before the run, because it is not a
> proof that the deadlines will be met.

In some cases (simple code or extensive tests, deterministic processor) 
CPU-time measurements can be used to prove that deadlines are met. But 
of course static analysis of the worst-case execution time is better.

> It useless at run-time because there
> are easier and safer ways to detect faults.

If you mean "deadline missed" or "task overrun" faults, you are right 
that there are other detection methods. Still, Ada.Execution_Time may 
help to *anticipate*, and thus mitigate, such faults.

For example, assume that the computation in a control algorithm consists 
of two consecutive stages where the first stage processes the inputs 
into a state model and the second stage computes the control outputs 
from the state model. Using Ada.Execution_Time or 
Ada.Execution_Time.Timers the program could detect an unexpectedly high 
CPU usage in the first stage, and fall back to a simpler, faster 
algorithm in the second stage, to ensure that some control outputs are 
computed before the deadline.

But you are again ignoring other run-time uses of execution-time 
measurements, such as advanced scheduling algorithms.

>> Is your point that Ada.Execution_Time was accepted only because the ARG 
>> decided that the word "time" in RM D.14 should not be understood to mean 
>> real time? I doubt that very much... Surely such an unusual meaning of 
>> "time" should have been explained in the RM.
> 
> It is explained by its name: "execution time." Execution means not real,
> unreal time (:-)).

Nonsense. I spend some part of my time asleep, some time awake. Both 
"sleeping time" and "awake time" are (pieces of) real time. A task 
spends some of its time being executed, some of its time not being 
executed (waiting or ready).

>>> If that was the intent, then I really do not understand why CPU_Time was
>>> introduced in addition to Ada.Real_Time.Time / Time_Span.
>> Because (as I understand it) different processors/OSes have different 
>> mechanisms for measuring execution times and real times, and the 
>> mechanism most convenient for CPU_Time may use a different numerical 
>> type (range, scale, and precision) than the mechanisms and types used 
>> for Ada.Real_Time.Time, Time_Span, and Duration.
> 
> I see no single reason why this could happen. Obviously, if talking about a
> real-time system as you insist, the only possible choice for CPU_Time is
> Time_Span, because to be consistent with the interpretation you propose it
> must be derived from Ada.Real_Time clock.

I have only said that the sum of the CPU_Times of all tasks executing on 
the same processor should be close to the real elapsed time, since the 
CPU's time is shared between the tasks. This does not mean that 
Ada.Execution_Time.CPU_Time and Ada.Real_Time.Time must have a common 
time source, only that both time sources must approximate physical, real 
time.

> My point is that RM intentionally leaves it up to the implementation to
> choose a CPU_Time source independent on Ada.Real_Time.Clock. This why
> different range and precision come into consideration.

I agree. But in both cases the intent is to approximate physical, real 
time, not some "simulation time" where one "simulation second" could be 
one year of real time.

> Under some conditions (e.g. no task switching) an execution time interval
> could be numerically equal to a real time interval.

Yes! Therefore, under these conditions, CPU_Time (when converted to a 
Time_Span or Duration) does have a physical meaning. So we agree. At last.

And under the task dispatching model in RM D.2.1, these conditions can 
be extended to task switching scenarios with the result that the sum of 
the CPU_Times of the tasks (for one processor) will be numerically close 
to the elapsed real time interval.

> But in my view the execution time is not even a simulation time of some
> ideal (real) clock. It is a simulation time of some lax recurrent process,
> e.g. scheduling activity, of which frequency is not even considered
> constant.

You may well have this view, but I don't see that your view has anything 
to do with Ada.Execution_Time as defined in the Ada RM.

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

Re: Ada.Execution_Time

[Simon Wright]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> Nonsense. I spend some part of my time asleep, some time awake. Both
> "sleeping time" and "awake time" are (pieces of) real time. A task
> spends some of its time being executed, some of its time not being
> executed (waiting or ready).

And, just to be clear, CPU_Time corresponds to the "awake time"?

I thought I understood pretty much what was intended in the execution
time annex, even if it didn't seem to have much relevance to my work,
but this discussion has managed to confuse me thoroughly.

A minor aside -- as a user, I find the use of Time_Span here and in
Ada.Real_Time very annoying. It's perfectly clear that what's meant is
Duration.

Re: Ada.Execution_Time

[Dmitry A. Kazakov]

On Mon, 27 Dec 2010 22:11:18 +0200, Niklas Holsti wrote:

> Dmitry A. Kazakov wrote:
>> Technically, CPU_Time is not a number in any sense. It is not a numeric Ada
>> type and it is not a model of a mathematical number (not even additive).
> 
> RM D.14(12/2): "The type CPU_Time represents the execution time of a 
> task. The set of values of this type corresponds one-to-one with an 
> implementation-defined range of mathematical integers". Thus, a number.

This is true for any value of any type due to finiteness. I think
D.14(12/2) refers to an ability to implement Split. But that is irrelevant.
CPU_Time is not declared numeric, it does not have +.

>>>> it is the Ada.Execution_Time implementation, which needs some
>>>> input from the scheduler.
>>> We must be precise about our terms, here. Using terms as defined in 
>>> http://en.wikipedia.org/wiki/Task_scheduling, Ada.Execution_Time needs 
>>> input from the task *dispatcher* -- the part of the kernel that suspends 
>>> and resumes tasks.
>> 
>> Let's call it dispatcher. Time sharing needs some measure of consumed CPU
>> time. My points stand:
>> 
>> 1. Time sharing has little to do with real-time systems.
> 
> What do you mean by "time sharing"? The classical mainframe system used 
> interactively by many terminals? What on earth does that have to do with 
> our discussion? Such a system of course must have concurrent tasks or 
> processes in some form, but so what?

Because this is the only case where execution time might be any relevant to
the algorithm of task switching.

> If by "time sharing algorithms" (below in your point 2) you mean what is 
> usually called "task scheduling algorithms", where several tasks 
> time-share the same processor by a task-switching (dispatching) 
> mechanism, your point 1 is bizarre. Priority-scheduled task switching is 
> the canonical architecture for real-time systems.

, which architecture makes execution time irrelevant to switching
decisions.

>> 2. It would be extremely ill-advised to use Ada.Execution_Time instead of
>> direct measures for an implementation of time sharing algorithms.
> 
> If by "direct measures" you mean the use of some external measuring 
> device such as an oscilloscope or logic analyzer, such measures are 
> available only externally, to the developers, not within the Ada program 
> itself.

You forgot one external device called real time clock.

> The whole point of Ada.Execution_Time is that it is available to 
> the Ada program itself, enabling run-time decisions based on the actual 
> execution times of tasks.

, which would be ill-advised to do.

>>>>> You have
>>>>> not given any arguments, based on the RM text, to support your position.
>>>> I am not a language lawyer to interpret the RM texts. My argument was to
>>>> common sense.
>>> To me it seems that your argument is based on the difficulty (in your 
>>> opinion) of implementing Ada.Execution_Time in some OSes such as MS 
>>> Windows, if the RM word "time" is taken to mean real time.
>>>
>>> It is common sense that some OSes are not designed (or not well 
>>> designed) for real-time systems. Even a good real-time OS may not 
>>> support all real-time methodologies, for example scheduling algorithms 
>>> that depend on actual execution times.
>> 
>> I disagree with almost everything here. To start with, comparing real-time
>> clock services of Windows and of VxWorks, we would notice that Windows is
>> far superior in both accuracy and precision.
> 
> So what? Real-time systems need determinism. The clock only has to be 
> accurate enough.

Sorry, are you saying that lesser accuracy of real-time clock is a way to
achieve determinism?
 
> If your tasks suffer arbitrary millisecond-scale suspensions or 
> dispatching delays (as is rumored for Windows) a microsecond-level clock 
> accuracy is no help.

And conversely, the catastrophic accuracy of the VxWorks real-time clock
service does not hinder its usability for real-time application. Which is
my point. You don't need good real-time clock in so many real-time
applications, and you never need execution time there.

> Anyway, your point has do to with the "time" that *activates* tasks, not 
> with the measurement of task-specific execution times.

Exactly

> So this is irrelevant.

No, it is the execution time which is irrelevant for real-time systems,
because of the way tasks are activated there.

>> I don't
>> care how much processor time my control loop takes so long it manages to
>> write the outputs when the actuators expect them.
> 
> You should care, if the processor must also have time for some other 
> tasks of lower priority, which are preempted by the control-loop task.

Why? It is straightforward: the task of higher priority level owns the
processor.

>> Measuring the CPU time
>> would bring me nothing. It is useless before the run, because it is not a
>> proof that the deadlines will be met.
> 
> In some cases (simple code or extensive tests, deterministic processor) 
> CPU-time measurements can be used to prove that deadlines are met.

It is difficult to imagine. This is done either statically or else by
running tests. Execution time has drawbacks of both approaches and
advantages of none.

> For example, assume that the computation in a control algorithm consists 
> of two consecutive stages where the first stage processes the inputs 
> into a state model and the second stage computes the control outputs 
> from the state model. Using Ada.Execution_Time or 
> Ada.Execution_Time.Timers the program could detect an unexpectedly high 
> CPU usage in the first stage, and fall back to a simpler, faster 
> algorithm in the second stage, to ensure that some control outputs are 
> computed before the deadline.

No, in our systems we use a different schema. The "fall back" values are
always evaluated first. They must become ready at the end of each cycle. A
finer estimation is evaluated in background and used when ready. Actually,
according to your schema, the finer estimation always "fail" because it is
guaranteed too complex for one cycle. It takes 10-100 cycles to compute at
least. So your schema would not work. In general, real-time systems are
usually designed for the worst case scenario, because when something
unanticipated indeed happens you could have no time to do anything else.
 
>>> Is your point that Ada.Execution_Time was accepted only because the ARG 
>>> decided that the word "time" in RM D.14 should not be understood to mean 
>>> real time? I doubt that very much... Surely such an unusual meaning of 
>>> "time" should have been explained in the RM.
>> 
>> It is explained by its name: "execution time." Execution means not real,
>> unreal time (:-)).
> 
> Nonsense. I spend some part of my time asleep, some time awake. Both 
> "sleeping time" and "awake time" are (pieces of) real time. A task 
> spends some of its time being executed, some of its time not being 
> executed (waiting or ready).

A very good example. Now consider your perception of time. Does it
correspond to the real time? No it does not. The time spent in sleep can be
sensed from very short to very long. This felt time is an analogue of the
task execution time. You better do not use this subjective time to decide
when to have next meal. That could end in obesity.

>>>> If that was the intent, then I really do not understand why CPU_Time was
>>>> introduced in addition to Ada.Real_Time.Time / Time_Span.
>>> Because (as I understand it) different processors/OSes have different 
>>> mechanisms for measuring execution times and real times, and the 
>>> mechanism most convenient for CPU_Time may use a different numerical 
>>> type (range, scale, and precision) than the mechanisms and types used 
>>> for Ada.Real_Time.Time, Time_Span, and Duration.
>> 
>> I see no single reason why this could happen. Obviously, if talking about a
>> real-time system as you insist, the only possible choice for CPU_Time is
>> Time_Span, because to be consistent with the interpretation you propose it
>> must be derived from Ada.Real_Time clock.
> 
> I have only said that the sum of the CPU_Times of all tasks executing on 
> the same processor should be close to the real elapsed time, since the 
> CPU's time is shared between the tasks. This does not mean that 
> Ada.Execution_Time.CPU_Time and Ada.Real_Time.Time must have a common 
> time source, only that both time sources must approximate physical, real 
> time.

What is the reason to use different sources?

>> My point is that RM intentionally leaves it up to the implementation to
>> choose a CPU_Time source independent on Ada.Real_Time.Clock. This why
>> different range and precision come into consideration.
> 
> I agree. But in both cases the intent is to approximate physical, real 
> time, not some "simulation time" where one "simulation second" could be 
> one year of real time.

Certainly the latter. Consider a system with n-processors. The execution
time second will be 1/n of the real time second. With shared memory it will
be f*1/n, where f is some unknown factor. That works in both directions, on
a single processor board with memory connected over some bus system, it
could be f<1, because some external devices might block CPU (and thus your
task) while accessing the memory. Note that the error is systematic. It is
not an approximation of real time.

>> Under some conditions (e.g. no task switching) an execution time interval
>> could be numerically equal to a real time interval.
> 
> Yes! Therefore, under these conditions, CPU_Time (when converted to a 
> Time_Span or Duration) does have a physical meaning. So we agree. At last.

Since these conditions are never met, the model you have in mind is
inadequate (wrong).

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

Re: Ada.Execution_Time

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcc39pj86y4.fsf@shell01.TheWorld.com...
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> Nope, one of the killer arguments ARG people deploy to reject most
>> reasonable AI's is: too difficult to implement on some obscure platform 
>> for
>> which Ada never existed and never will. (:-))
>
> The ARG and others have been guilty of that sort of argument in the
> past, although I think "most reasonable AI's" is an exaggeration.
> I think that line of reasoning is wrong -- I think it's just fine to have
> things like Ada.Directories, even though many embedded systems don't
> have directories.  It means that there's some standardization across
> systems that DO have directories.  Those that don't can either
> provide some minimal/useless implementation, or else appeal
> to RM-1.1.3(6).

They're supposed to provide a useless implementation that raises Use_Error 
for most of the operations. There are a pair of Notes to that effect 
(A.16(129-130)). I don't think features should ever be designed so that 
implementations have to appeal to 1.1.3(6) - my preference would be that 
that paragraph not exist with the language itself sufficiently flexible 
where it matters. (Otherwise, implementations could leave out anything that 
they want and appeal to 1.1.3(6). I think that both interfaces and 
coextensions are "impractical" to implement for the benefit gained, so does 
that mean I can ignore them and still have a complete Ada compiler??)

                                 Randy.

Re: Ada.Execution_Time

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:8nm30fF7r9U1@mid.individual.net...
> Dmitry A. Kazakov wrote:
>> On Sat, 18 Dec 2010 23:20:20 +0200, Niklas Holsti wrote:
...
>> On a such platform the implementation would be as perverse as RM D.14
>> is. But the perversion is only because of the interpretation.
>
> Bah. I think that when RM D.14 says "time", it really means time. You
> think it means something else, perhaps a CPU cycle count. I think the 
> burden of proof is on you.
>
> It seems evident to me that the text in D.14 must be interpreted using
> the concepts in D.2.1, "The Task Dispatching Model", which clearly
> specifies real-time points when a processor starts to execute a task and
> stops executing a task. To me, and I believe to most readers of the RM,
> the execution time of a task is the sum of these time slices, thus a
> physical, real time.

For the record, I agree more with Dmitry than Niklas here. At least the 
interpretation *I* had when this package was proposed was that it had only a 
slight relationship to real-time. My understanding was that it was intended 
to provide a window into whatever facilities the underlying system had for 
execution "time" counting. That had no defined relationship with what Ada 
calls "time". As usch, I think the name "execution time" is misleading, (and 
I recall some discussions about that in the ARG), but no one had a better 
name that made any sense at all.

In particular, there is no requirement in the RM or anywhere else that these 
"times" sum to any particular answer. I don't quite see how there could be, 
unless you were going to require a tailored Ada target system (which is 
definitely not going to be a requirement).

Perhaps the proposers (from the IRTAW meetings) had something else in mind, 
but if so, they communicated it very poorly.

                             Randy.

Re: Ada.Execution_Time

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> They're supposed to provide a useless implementation that raises Use_Error 
> for most of the operations. There are a pair of Notes to that effect 
> (A.16(129-130)).

OK, good enough.

>... I don't think features should ever be designed so that 
> implementations have to appeal to 1.1.3(6) - my preference would be that 
> that paragraph not exist with the language itself sufficiently flexible 
> where it matters.

But something like 1.1.3(6) has to exist in every language definition,
at least implicitly.  Computers are finite machines, so there will
always be things that are "impossible or impractical", and it is
impossible for any language designer to predict what that means
in all cases.

>...(Otherwise, implementations could leave out anything that 
> they want and appeal to 1.1.3(6).

Well, not really.  That para says "given the execution environment", not
"given the compiler-writer's whim, or laziness, or lack of interest".
One could claim that "if X = 0..." is impractical to implement, but of
course people would laugh at that claim.

>... I think that both interfaces and 
> coextensions are "impractical" to implement for the benefit gained, so does 
> that mean I can ignore them and still have a complete Ada compiler??)

I definitely disagree about interfaces.  I might agree about
coextensions, depending on my mood on any particular day of the week.
But yeah, you can implement what you like, and claim it's an Ada
compiler.  Whether people buy it is a question that lies outside any ISO
standard.

Standards are optional!  The Ada standard doesn't require anybody to do
anything.  Still, there's a community that can decide, informally, that
so-and-so compiler is an implementation of Ada 2005 (despite a few minor
bugs), and such-and-such compiler is not.

- Bob

Re: Ada.Execution_Time

[Niklas Holsti]

Simon Wright wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> 
>> Nonsense. I spend some part of my time asleep, some time awake. Both
>> "sleeping time" and "awake time" are (pieces of) real time. A task
>> spends some of its time being executed, some of its time not being
>> executed (waiting or ready).
> 
> And, just to be clear, CPU_Time corresponds to the "awake time"?

Perhaps that is the natural choice, but I did not mean the choice to be 
significant. Dmitry was saying that "execution time" is not "time", just 
because it uses the prefix or qualification "execution". By that 
reasoning, "awake time" would not be "time", "chicken soup" would not be 
"soup", etc.

> I thought I understood pretty much what was intended in the execution
> time annex, even if it didn't seem to have much relevance to my work,
> but this discussion has managed to confuse me thoroughly.

Randy's last post in this thread, in which he agrees with Dmitry, has 
the same effect on me. I hope that further discussion with Randy will 
converge to something.

Did your earlier understanding resemble Dmitry's, or mine? Or neither?

> A minor aside -- as a user, I find the use of Time_Span here and in
> Ada.Real_Time very annoying. It's perfectly clear that what's meant is
> Duration.

I think Time_Span and Duration are different representations of the same 
physical thing, a span of time that can be physically measured in 
seconds. The reasons for having two (possibly) different representations 
(two types) have been discussed before: different requirements on range 
and precision. Still, the differences are important only for processors 
that are very small and weak, in today's scale, so perhaps this 
distinction is no longer needed and the types could be merged.

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

Re: Ada.Execution_Time

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> And conversely, the catastrophic accuracy of the VxWorks real-time
> clock service does not hinder its usability for real-time application.

Catastrophic?

The Radstone PPC7A cards (to take one example) have two facilities: (a)
the PowerPC decrementer, run off a crystal with some not-too-good quoted
accuracy (50 ppm, I think), and (b) a "real time clock".

The RTC would be much better termed a time-of-day clock, since what it
provides is the date and time to 1 second precision. It also needs
battery backup, not easy to justify on naval systems (partly because it
adversely affects the shelf life of the boards, partly because navies
don't like noxious chemicals in their equipment).

We never used the RTC.

The decrementer is the facility used by VxWorks, and hence by GNAT under
VxWorks, to support time; both Ada.Calendar and Ada.Real_Time (we are
still at Ada 95 so I have no idea about Ada.Execution_Time). We run with
clock interrupts at 1 ms and (so far as we can tell from using bus
analysers) the interrupts behave perfectly reliably.

For a higher-resolution view of time we've extended Ada.Calendar, using
the PowerPC's mftb (Move From Time Base) instruction to measure sub-tick
intervals (down to 40 ns).

Re: Ada.Execution_Time

[Simon Wright]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> Randy's last post in this thread, in which he agrees with Dmitry, has
> the same effect on me. I hope that further discussion with Randy will
> converge to something.
>
> Did your earlier understanding resemble Dmitry's, or mine? Or neither?

Yours, I think.

It seems strange to have CPU_Time bearing only a tenuous relationship
to what we might normally call "time", and then to have the difference
between two CPU_Times turn out to be a Time_Span!

Re: Ada.Execution_Time

[Niklas Holsti]

Dmitry, from now on I am going to respond only to those of your comments 
that to me seem to make some kind of sense and have not been discussed 
before. From my omissions you may deduce my opinion of the remainder.

Dmitry A. Kazakov wrote:
>>> 2. It would be extremely ill-advised to use Ada.Execution_Time instead of
>>> direct measures for an implementation of time sharing algorithms.
Niklas Holsti replied:
>> If by "direct measures" you mean the use of some external measuring 
>> device such as an oscilloscope or logic analyzer, such measures are 
>> available only externally, to the developers, not within the Ada program 
>> itself.
Dmitry:
> You forgot one external device called real time clock.

And you seem to forget that Ada.Execution_Time may be implemented by 
reading a real-time clock. As has been said before.

Dmitry:
>>> I don't
>>> care how much processor time my control loop takes so long it manages to
>>> write the outputs when the actuators expect them.
Niklas:
>> You should care, if the processor must also have time for some other 
>> tasks of lower priority, which are preempted by the control-loop task.
Dmitry:
> Why? It is straightforward: the task of higher priority level owns the
> processor.

Do you mean that your system has only one task with real-time deadlines, 
and no CPU time has to be left for lower-priority tasks, and no CPU time 
is taken by higher-priority tasks? Then scheduling is trivial for your 
system and your system is a poor example for a discussion about scheduling.

Niklas:
>> For example, assume that the computation in a control algorithm consists 
>> of two consecutive stages where the first stage processes the inputs 
>> into a state model and the second stage computes the control outputs 
>> from the state model. Using Ada.Execution_Time or 
>> Ada.Execution_Time.Timers the program could detect an unexpectedly high 
>> CPU usage in the first stage, and fall back to a simpler, faster 
>> algorithm in the second stage, to ensure that some control outputs are 
>> computed before the deadline.
Dmitry:
> No, in our systems we use a different schema.

So what? I said nothing (and know nothing) about your system, any 
resemblance is coincidental. And there can be several valid schemas.

> The "fall back" values are
> always evaluated first. They must become ready at the end of each cycle. A
> finer estimation is evaluated in background and used when ready.

So your problem is different (the coarse values are the rule). Different 
problem, different solution.

> In general, real-time systems are
> usually designed for the worst case scenario,

Yes, but this is often criticized as inefficient, and there are 
scheduling methods that make good use of the difference (slack) between 
actual and worst-case execution times. These methods need something like 
Ada.Execution_Time. As has been said before.

> Consider a system with n-processors. The execution
> time second will be 1/n of the real time second.

No. If you have n workers digging a ditch, you must pay each of them the 
same amount of money each hour as if you had one worker. So the "digging 
hour" is still one hour, although the total amount of work that can be 
done in one hour is n digging-hours. You are confusing the total amount 
of work with the amount of work per worker.

With n processors the system can do n seconds worth of execution in one 
real-time second. But each processor still executes for one second. And 
as I understand the Ada task dispatching/scheduling model, one task 
cannot execute at the same time on more than one processor, so one task 
cannot accumulate more than one second of execution time in one second 
of real time.

(At the risk of introducing another side issue, I note that an 
automatically parallelizing compiler might make a task use several 
processors in parallel, at least for some of the time. But I don't think 
that RM D2.1 considers this possibility.)

> With shared memory it will
> be f*1/n, where f is some unknown factor.

I agree that variable memory access times, and other dynamic timing that 
may depend on the number of processors and on how they share resources, 
is a complicating factor in the analysis of CPU loads and 
schedulability. Indeed this is why I fear that the concept of "the 
execution time of task" is becoming fearsomely context-dependent and 
therefore problematic -- something that you disagreed with.

For the definition of Ada.Execution_Time, memory access latency is 
relevant only if the Ada RTS suspends tasks that are waiting for memory 
access, so that they are "not executing" until the memory access is 
completed. Most RTOSes do not suspend tasks in that way, I believe.

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

Re: Ada.Execution_Time

[Dmitry A. Kazakov]

On Tue, 28 Dec 2010 14:14:57 +0000, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> And conversely, the catastrophic accuracy of the VxWorks real-time
>> clock service does not hinder its usability for real-time application.
> 
> Catastrophic?
>
> The Radstone PPC7A cards (to take one example) have two facilities: (a)
> the PowerPC decrementer, run off a crystal with some not-too-good quoted
> accuracy (50 ppm, I think), and (b) a "real time clock".
> 
> The RTC would be much better termed a time-of-day clock, since what it
> provides is the date and time to 1 second precision. It also needs
> battery backup, not easy to justify on naval systems (partly because it
> adversely affects the shelf life of the boards, partly because navies
> don't like noxious chemicals in their equipment).
> 
> We never used the RTC.
>
> The decrementer is the facility used by VxWorks, and hence by GNAT under
> VxWorks, to support time; both Ada.Calendar and Ada.Real_Time (we are
> still at Ada 95 so I have no idea about Ada.Execution_Time). We run with
> clock interrupts at 1 ms and (so far as we can tell from using bus
> analysers) the interrupts behave perfectly reliably.

Yes, this thing. In our case it was Pentium VxWorks 6.x. (The PPC we used
prior to it had poor performance) The problem was that Ada.Real_Time.Clock
had the accuracy of the clock interrupts, i.e. 1ms, which is by all
accounts catastrophic for a 1.7GHz processor. You can switch some tasks
forth and back between two clock changes.
 
> For a higher-resolution view of time we've extended Ada.Calendar, using
> the PowerPC's mftb (Move From Time Base) instruction to measure sub-tick
> intervals (down to 40 ns).

So did we in our case. VxWorks has means to access the Pentium high
resolution counter. We took Ada.Real_Time and replaced the Clock function
with one that used the counter multiplied by its frequency.

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

Re: Ada.Execution_Time

[Dmitry A. Kazakov]

On Tue, 28 Dec 2010 16:46:20 +0200, Niklas Holsti wrote:

> And you seem to forget that Ada.Execution_Time may be implemented by 
> reading a real-time clock. As has been said before.

Only if you have control over the OS or else can hook on task switches. I
think it is doable under VxWorks. But I doubt that AdaCore would do this.

> Dmitry:
>>>> I don't
>>>> care how much processor time my control loop takes so long it manages to
>>>> write the outputs when the actuators expect them.
> Niklas:
>>> You should care, if the processor must also have time for some other 
>>> tasks of lower priority, which are preempted by the control-loop task.
> Dmitry:
>> Why? It is straightforward: the task of higher priority level owns the
>> processor.
> 
> Do you mean that your system has only one task with real-time deadlines, 
> and no CPU time has to be left for lower-priority tasks, and no CPU time 
> is taken by higher-priority tasks? Then scheduling is trivial for your 
> system and your system is a poor example for a discussion about scheduling.

Right, a real-time system is usually a bunch of tasks activated according
to their priority levels. This is why I doubted that Ada.Execution_Time
might be useful there.

> Niklas:
>>> For example, assume that the computation in a control algorithm consists 
>>> of two consecutive stages where the first stage processes the inputs 
>>> into a state model and the second stage computes the control outputs 
>>> from the state model. Using Ada.Execution_Time or 
>>> Ada.Execution_Time.Timers the program could detect an unexpectedly high 
>>> CPU usage in the first stage, and fall back to a simpler, faster 
>>> algorithm in the second stage, to ensure that some control outputs are 
>>> computed before the deadline.
> Dmitry:
>> No, in our systems we use a different schema.
> 
> So what? I said nothing (and know nothing) about your system, any 
> resemblance is coincidental. And there can be several valid schemas.

No, the point was rather that your schema is not typical for a real-time
system.

>> Consider a system with n-processors. The execution
>> time second will be 1/n of the real time second.
> 
> No. If you have n workers digging a ditch, you must pay each of them the 
> same amount of money each hour as if you had one worker. So the "digging 
> hour" is still one hour, although the total amount of work that can be 
> done in one hour is n digging-hours. You are confusing the total amount 
> of work with the amount of work per worker.

The ditch has 10 digging hours, this is a virtual time, which can be 1 real
hour if I had 10 workers or 26 hours if I have only one (26 = 24(8) + 2, 8
hours per day). With one worker it can even be 26 + 48 if he starts Friday,
or even more if she takes a leave for child rearing (:-)).

The sum of working hours is a measure of work. It is not a measure of time.

   Time = Work / Power

You can use it to estimate the real time required to complete the work ...
or just re-read the The Mythical Man-Month... (:-))

> With n processors the system can do n seconds worth of execution in one 
> real-time second. But each processor still executes for one second. And 
> as I understand the Ada task dispatching/scheduling model, one task 
> cannot execute at the same time on more than one processor, so one task 
> cannot accumulate more than one second of execution time in one second 
> of real time.

Yes.

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

Re: Ada.Execution_Time

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Yes, this thing. In our case it was Pentium VxWorks 6.x. (The PPC we
> used prior to it had poor performance) The problem was that
> Ada.Real_Time.Clock had the accuracy of the clock interrupts,
> i.e. 1ms, which is by all accounts catastrophic for a 1.7GHz
> processor. You can switch some tasks forth and back between two clock
> changes.

Our experience was that where there are timing constraints to be met, or
cyclic timing behaviours to implement, a milliscond is OK.

We did consider running the VxWorks tick at 100 us but this was quite
unnecessary!

Re: Ada.Execution_Time

[(see below)]

At least part of this discussion is motivated by the abysmal facilities for
the measurement of elapsed time on some (all?) modern architectures.

My current Ada project is the emulation of the KDF9, a computer introduced
50 years ago. It had a hardware clock register that was incremented by 1
every 32 logic clock cycles and could be read by a single instruction taking
4 logic clock cycles (the CPU ran on a 1MHz logic clock).

Using this feature, the OS could keep track of the CPU time used by a
process to within 32 logic clock cycles per time slice (typically better
than 1 part in 1_000). Summing many such slices gives a total with much
better relative error than that of the individual slices, of course.

Dmitri reports a modern computer with a timer having a resolution that is
thousands or millions of times worse than the CPU's logic clock.

Why has this aspect of computer architecture degenerated so much, I wonder?
And why have software people not made more of a push for improvements?

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Ada.Execution_Time

[Dmitry A. Kazakov]

On Tue, 28 Dec 2010 16:18:11 +0000, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Yes, this thing. In our case it was Pentium VxWorks 6.x. (The PPC we
>> used prior to it had poor performance) The problem was that
>> Ada.Real_Time.Clock had the accuracy of the clock interrupts,
>> i.e. 1ms, which is by all accounts catastrophic for a 1.7GHz
>> processor. You can switch some tasks forth and back between two clock
>> changes.
> 
> Our experience was that where there are timing constraints to be met, or
> cyclic timing behaviours to implement, a milliscond is OK.
> 
> We did consider running the VxWorks tick at 100 us but this was quite
> unnecessary!

We actually have it set at 100 us, I believe.

But we need high accuracy clock not for switching tasks. It is for time
stamping and frequency measurements.

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

Re: Ada.Execution_Time

[Dmitry A. Kazakov]

On Tue, 28 Dec 2010 16:27:18 +0000, (see below) wrote:

> Dmitri reports a modern computer with a timer having a resolution that is
> thousands or millions of times worse than the CPU's logic clock.

You get me wrong, the timer resolution is OK, it is the system service
which does not use it properly. In the case of VxWorks the system time is
incremented from the timer interrupts, e.g. by 1ms. You can set interrupts
to each 1um spending all processor time handling interrupts. It is an OS
architecture problem. System time should have been taken from the real time
counter.

> Why has this aspect of computer architecture degenerated so much, I wonder?
> And why have software people not made more of a push for improvements?

The computer architecture did not degenerate. Modern processor and
motherboard have multiple time sources 3-4. Some of them have a very high
resolution and reliable, e.g. keep on counting in the sleep mode etc. It is
usually the standard OS services to blame for not using these clocks.
Practically in any OS there is a backdoor to get a decent real-time clock.
Then the journey begins. You need to synchronize readings from that clock
(usually a 64-bit counter) with the system time (of miserable accuracy) in
order to get a decent UTC stamp. This is doable using some statistical
method, depending on your needs (monotonic, or not, etc). Shame that the OS
does not do this.

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

Re: Ada.Execution_Time

[(see below)]

On 28/12/2010 16:55, in article 1oq6oggi7rtzj.4u4yyq6m8r74$.dlg@40tude.net,
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:

> On Tue, 28 Dec 2010 16:27:18 +0000, (see below) wrote:
> 
>> Dmitri reports a modern computer with a timer having a resolution that is
>> thousands or millions of times worse than the CPU's logic clock.
> 
> You get me wrong, the timer resolution is OK, it is the system service
> which does not use it properly. In the case of VxWorks the system time is
> incremented from the timer interrupts, e.g. by 1ms. You can set interrupts
> to each 1um spending all processor time handling interrupts. It is an OS
> architecture problem. System time should have been taken from the real time
> counter.

Surely the interrupt rate does not matter. The KDF9 clock interrupted once
every 2^20 us, but could be read to the nearest 32 us. Can the clock you
speak of not be interrogated between interrupts?

> 
>> Why has this aspect of computer architecture degenerated so much, I wonder?
>> And why have software people not made more of a push for improvements?
> 
> The computer architecture did not degenerate. [...] It is
> usually the standard OS services to blame for not using these clocks.

I guess the second part of my question stands. 8-)

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Ada.Execution_Time

[Dmitry A. Kazakov]

On Tue, 28 Dec 2010 19:41:40 +0000, (see below) wrote:

> On 28/12/2010 16:55, in article 1oq6oggi7rtzj.4u4yyq6m8r74$.dlg@40tude.net,
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
> 
>> On Tue, 28 Dec 2010 16:27:18 +0000, (see below) wrote:
>> 
>>> Dmitri reports a modern computer with a timer having a resolution that is
>>> thousands or millions of times worse than the CPU's logic clock.
>> 
>> You get me wrong, the timer resolution is OK, it is the system service
>> which does not use it properly. In the case of VxWorks the system time is
>> incremented from the timer interrupts, e.g. by 1ms. You can set interrupts
>> to each 1um spending all processor time handling interrupts. It is an OS
>> architecture problem. System time should have been taken from the real time
>> counter.
> 
> Surely the interrupt rate does not matter. The KDF9 clock interrupted once
> every 2^20 us, but could be read to the nearest 32 us. Can the clock you
> speak of not be interrogated between interrupts?

Yes, the TSC can be read any time, and, if I correctly remember, each
reading will give a new value. PPC RT clock is also reliable.

There could be certain issues for multi-core processors, you should take
care that the task synchronizing the counter with UTC would not jump from
core to core. Alternatively you should synchronize clocks of individual
cores.

>>> Why has this aspect of computer architecture degenerated so much, I wonder?
>>> And why have software people not made more of a push for improvements?
>> 
>> The computer architecture did not degenerate. [...] It is
>> usually the standard OS services to blame for not using these clocks.
> 
> I guess the second part of my question stands. 8-)

The OSes did not become degenerate it always were. (:-))

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

Re: Ada.Execution_Time

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Yes, the TSC can be read any time, and, if I correctly remember, each
> reading will give a new value. PPC RT clock is also reliable.
>
> There could be certain issues for multi-core processors, you should
> take care that the task synchronizing the counter with UTC would not
> jump from core to core. Alternatively you should synchronize clocks of
> individual cores.

Using the TSC on a MacBook Pro gives very unreliable results (I rather
think the core you're using goes to sleep and you may or may not wake
up using the same core!). However, the system clock (Ada.Calendar) is
precise to a microsecond.

Re: Ada.Execution_Time

[Dmitry A. Kazakov]

On Tue, 28 Dec 2010 22:39:31 +0000, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Yes, the TSC can be read any time, and, if I correctly remember, each
>> reading will give a new value. PPC RT clock is also reliable.
>>
>> There could be certain issues for multi-core processors, you should
>> take care that the task synchronizing the counter with UTC would not
>> jump from core to core. Alternatively you should synchronize clocks of
>> individual cores.
> 
> Using the TSC on a MacBook Pro gives very unreliable results (I rather
> think the core you're using goes to sleep and you may or may not wake
> up using the same core!).

Can it be because the processor changes the TSC frequency when it goes into
the sleep mode? I thought Intel has fixed that bug.

I cannot think out a good time service for a multi-core with unsynchronized
TSC's. Intel should simply fix that mess.

> However, the system clock (Ada.Calendar) is precise to a microsecond.

It likely uses a programmable timer. TSC gives fraction of nanosecond.

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

Re: Ada.Execution_Time

[Niklas Holsti]

Randy, I'm glad that you are participating in this thread. My duologue 
with Dmitry is becoming repetitive and our views entrenched.

We have been discussing several things, although the focus is on the 
intended meaning and properties of Ada.Execution_Time. As I am not an 
ARG member I have based my understanding on the (A)RM text. If the text 
does not reflect the intent of the ARG, I will be glad to know it, but 
perhaps the ARG should then consider resolving the conflict by 
confirming or changing the text.

Randy Brukardt wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
> news:8nm30fF7r9U1@mid.individual.net...
>> Dmitry A. Kazakov wrote:
>>> On Sat, 18 Dec 2010 23:20:20 +0200, Niklas Holsti wrote:
> ...
>>> On a such platform the implementation would be as perverse as RM D.14
>>> is. But the perversion is only because of the interpretation.
>> Bah. I think that when RM D.14 says "time", it really means time. You
>> think it means something else, perhaps a CPU cycle count. I think the 
>> burden of proof is on you.
>>
>> It seems evident to me that the text in D.14 must be interpreted using
>> the concepts in D.2.1, "The Task Dispatching Model", which clearly
>> specifies real-time points when a processor starts to execute a task and
>> stops executing a task. To me, and I believe to most readers of the RM,
>> the execution time of a task is the sum of these time slices, thus a
>> physical, real time.
> 
> For the record, I agree more with Dmitry than Niklas here. At least the 
> interpretation *I* had when this package was proposed was that it had only a 
> slight relationship to real-time.

Oh. What would that slight relationship be? Or was it left unspecified?

> My understanding was that it was intended 
> to provide a window into whatever facilities the underlying system had for 
> execution "time" counting.

Of course, as long as those facilities are good enough for the RM 
requirements and for the users; otherwise, the implementor might improve 
on the underlying system as required. The same holds for Ada.Real_Time. 
If the underlying system is a bare-board Ada RTS, the Ada 95 form of the 
RTS probably had to be extended to support Ada.Execution_Time.

I'm sure that the proposers of the package Ada.Execution_Time expected 
the implementation to use the facilities of the underlying system. But I 
am also confident that they had in mind some specific uses of the 
package and that these uses require that the values provided by 
Ada.Execution_Time have certain properties that can reasonably be 
expected of "execution time", whether or not these properties are 
expressly written as requirements in the RM.

Examples of these uses are given in the paper by A. Burns and A.J. 
Wellings, "Programming Execution-Time Servers in Ada 2005," pp.47-56, 
27th IEEE International Real-Time Systems Symposium (RTSS'06), 2006. 
http://doi.ieeecomputersociety.org/10.1109/RTSS.2006.39.

You put "time" in quotes, Randy. Don't you agree that there *is* a 
valid, physical concept of "the execution time of a task" that can be 
measured in units of physical time, seconds say? At least for processors 
that only execute one task at a time, and whether or not the system 
provides facilities for measuring this time?

I think that the concept exists and that it matches the description in 
RM D.14 (11/2), using the background from D.2.1, whether or not the ARG 
intended this match.

If you agree that such "execution time" values are conceptually well 
defined, do you not think that the "execution time counting facilities" 
of real-time OSes are meant to measure these values, to some practical 
level of accuracy?

If so, then even if Ada.Execution_Time is intended as only a window into 
these facilities, it is still intended to provide measures of the 
physical execution time of tasks, to some practical level of accuracy.

> That had no defined relationship with what Ada calls "time".
> As usch, I think the name "execution time" is misleading, (and 
> I recall some discussions about that in the ARG), but no one had a better 
> name that made any sense at all.

Do you remember if these discussions concerned the name of the package, 
the name of the type CPU_Time, or the very concept "execution time"? If 
the question was of the terms "time" versus "duration", I think 
"duration" would have been more consistent with earlier Ada usage, but 
"execution time" is more common outside Ada, for example in the acronym 
WCET for Worst-Case Execution Time.

The fact that Ada.Execution_Time provides a subtraction operator for 
CPU_Time that yields Time_Span, which can be further converted to 
Duration, leads the RM reader to assume some relationship, at least that 
spans of real time and spans of execution time can be measured in the 
same physical units (seconds).

It has already been said, and not only by me, that Ada.Execution_Time is 
intended (among other things, perhaps) to be used for implementing task 
scheduling algorithms that depend on the accumulated execution time of 
the tasks. This is supported by the Burns and Wellings paper referenced 
above. In such algorithms I believe it is essential that the execution 
times are physical times because they are used in formulae that relate 
(sums of) execution-time spans to spans of real time.

Dmitry has agreed with some of my statements on this point, for example:

- A task cannot accumulate execution time at a higher rate than real 
time. For example, in one real-time second the CPU_Time of a task cannot 
increase by more than one second.

- If only one task is executing on a processor, the execution time of 
that task increases (or "could increase") at the same rate as real time.

Do you agree that we can expect these statements to be true? (On the 
second point, system overhead should of course be taken into account, on 
which more below.)

> In particular, there is no requirement in the RM or anywhere else that these 
> "times" sum to any particular answer.

I agree that the RM has no such explicit requirement. I made this claim 
to counter Dmitry's assertion that CPU_Time has no physical meaning, and 
of course I accept that the sum will usually be less than real elapsed 
time because the processor spends some time on non-task activities.

The last sentence of RM D.14 (11/2) says "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". This 
sentence strongly suggests to me that the author of this paragraph had 
in mind that the total available execution time (span) equals the real 
time (span), that some of this total is charged to the tasks, but that 
some of the time spent in interrupt handlers etc. need not be charged to 
tasks.

The question is how much meaning should be read into ordinary words like 
"time" when used in the RM without a formal definition.

If the RM were to say that L is the length of a piece of string S, 
measured in meters, and that some parts of S are colored red, some blue, 
and some parts may not be colored at all, surely we could conclude that 
the sum of the lengths in meters of the red, blue, and uncolored parts 
equals L? And that the sum of the lengths of the red and blue parts is 
at most L? And that, since we like colorful things, we hope that the 
length of the uncolored part is small?

I think the case of summing task execution time spans is analogous.

> I don't quite see how there could be, 
> unless you were going to require a tailored Ada target system (which is 
> definitely not going to be a requirement).

I don't want such a requirement. The acceptable overhead (fraction of 
execution time not charged to tasks) depends on the application.

Moreover, on a multi-process systems (an Ada program running under 
Windows or Linux, for example) some of the CPU time is spent on other 
processes, all of which would be "overhead" from the point of view of 
the Ada program. I don't think that the authors of D.14 had such systems 
in mind.

> Perhaps the proposers (from the IRTAW meetings) had something else in mind, 
> but if so, they communicated it very poorly.

Do you remember who they were? Are the IRTAW minutes or proposals 
accessible on the web?

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

Re: Ada.Execution_Time

[Dmitry A. Kazakov]

On Wed, 29 Dec 2010 14:48:20 +0200, Niklas Holsti wrote:

> Dmitry has agreed with some of my statements on this point, for example:
> 
> - A task cannot accumulate execution time at a higher rate than real 
> time. For example, in one real-time second the CPU_Time of a task cannot 
> increase by more than one second.

Hold on, that is only true if a certain model of CPU_Time measurement used.
There are many potential models. The one we discussed was the model A:

Model A. Get an RTC reading upon activation. Each time CPU_Time is
requested by Clock get another RTC reading, build the difference, add the
accumulator to the result. Upon task deactivation, get the difference and
update the accumulator.

This is a very strong model. Weaker models:

Model A.1. Get RTC upon activation and deactivation. Update the accumulator
upon deactivation. When the task is active CPU_Time does not change.

Model B. Use a time source different from RTC. This what Windows actually
doest.

Model B.1. Like A.1, CPU_Time freezes when the task is active.

Model C. Asynchronous task monitoring process

...

Note that in either model the counter readings are rounded. Windows rounds
toward zero, which why you never get more load than 100%. But it is
thinkable and expectable that some systems would round away from zero or to
the nearest bound. So the statement holds only if you have A (maybe C) + a
corresponding rounding.

> - If only one task is executing on a processor, the execution time of 
> that task increases (or "could increase") at the same rate as real time.

This also may be wrong if a B model is used. In particular, task switching
may be (and I think is) driven by the programmable timer interrupts. The
real-time clock may be driven by the TSC. Since these two are physically
different, unsynchronized time sources, the effect can be any. It is to
expect a systematic error accumulated with the time.

> The question is how much meaning should be read into ordinary words like 
> "time" when used in the RM without a formal definition.

Time as physical concept is not absolute. There is no *the* real time, but
many real times and even more unreal ones. I don't think RM can go into
this. Not only because it would be not Ada's business, but because
otherwise it would have to use some reference time. Ada does not have this,
it intentionally refused to have it when introduced Ada.Real_Time.Time. The
same arguments which were used then apply now. CPU_Time is a third time by
default absolutely independent on the other two.

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

Re: Ada.Execution_Time

[(see below)]

On 29/12/2010 14:30, in article aooml6t0ezs4.4srxtfm9z00r.dlg@40tude.net,
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:

> On Wed, 29 Dec 2010 14:48:20 +0200, Niklas Holsti wrote:
> 
>> Dmitry has agreed with some of my statements on this point, for example:
>> 
>> - A task cannot accumulate execution time at a higher rate than real
>> time. For example, in one real-time second the CPU_Time of a task cannot
>> increase by more than one second.
> 
> Hold on, that is only true if a certain model of CPU_Time measurement used.
> There are many potential models. The one we discussed was the model A:
> 
> Model A. Get an RTC reading upon activation. Each time CPU_Time is
> requested by Clock get another RTC reading, build the difference, add the
> accumulator to the result. Upon task deactivation, get the difference and
> update the accumulator.
> 
> This is a very strong model. Weaker models:
> 
> Model A.1. Get RTC upon activation and deactivation. Update the accumulator
> upon deactivation. When the task is active CPU_Time does not change.
> 
> Model B. Use a time source different from RTC. This what Windows actually
> doest.
> 
> Model B.1. Like A.1, CPU_Time freezes when the task is active.
> 
> Model C. Asynchronous task monitoring process
> 
> ...
> Note that in either model the counter readings are rounded. ...
> 
>> - If only one task is executing on a processor, the execution time of
>> that task increases (or "could increase") at the same rate as real time.
> 
> This also may be wrong if a B model is used. ...
> 
>> The question is how much meaning should be read into ordinary words like
>> "time" when used in the RM without a formal definition.
> 
> Time as physical concept is not absolute. There is no *the* real time, but
> many real times and even more unreal ones.  ...

I hope we can agree that Ada is defined "sensibly".

From this I deduce that the intent for CPU_Time is that it be a useful
approximation to the sum of the durations (small "d") of the intervals of
local inertial-frame physical time in which the task is in the running
state.

It seems to me that the only grey area is the degree of approximation that
is acceptable for the result to be "useful".

Dmitri raises some devils-advocate issues around that. Some of them might be
considered to be dismissed by the assumption of sensible definition. Others
might not be so clear. Perhaps the ARG consider these to be issues of
implementation quality rather than semantics.

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Ada.Execution_Time

[Dmitry A. Kazakov]

On Wed, 29 Dec 2010 16:19:13 +0000, (see below) wrote:

> From this I deduce that the intent for CPU_Time is that it be a useful
> approximation to the sum of the durations (small "d") of the intervals of
> local inertial-frame physical time in which the task is in the running
> state.

There exist more pragmatic considerations than the relativity theory. The
duration you refer above is according to which clock?

- Real time CPU counter
- Programmable timer
- BIOS clock
- OS system clock
- Ada.Real_Time.Clock
- Ada.Calendar.Clock
- an NTP server from the given list ...
  ...

> It seems to me that the only grey area is the degree of approximation that
> is acceptable for the result to be "useful".

That is the next can of worms to open. Once you decided which clock you
take, you would have to define the sum of *which* durations according to
this clock you are going to approximate. This would be way more difficult
and IMO impossible. What is the "CPU" is presence of many cores? What does
it mean for the task to be "active" keeping in mind the cases it could get
blocked without losing the "CPU" (defined above)?

In my humble opinion, ARG defined Ada.Execution_Time in the most
*reasonable* way, in particular, allowing to deliver whatever garbage the
underlying OS service spits.

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

Re: Ada.Execution_Time

[(see below)]

On 29/12/2010 16:51, in article jw9ocxiajasa.142oku2z0e6rx$.dlg@40tude.net,
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:

> On Wed, 29 Dec 2010 16:19:13 +0000, (see below) wrote:
> 
>> From this I deduce that the intent for CPU_Time is that it be a useful
>> approximation to the sum of the durations (small "d") of the intervals of
>> local inertial-frame physical time in which the task is in the running
>> state.
> 
> There exist more pragmatic considerations than the relativity theory. The
> duration you refer above is according to which clock?

I referred to time dilation to preempt your bringing it up. 8-)

> - Real time CPU counter
> - Programmable timer
> - BIOS clock
> - OS system clock
> - Ada.Real_Time.Clock
> - Ada.Calendar.Clock
> - an NTP server from the given list ...
>   ...

Quite so, but these issues, and rounding, and so on, are all subsumed under
"useful approximation".  They are implementation dependent in the best of
circumstances, and so need to be specified by the implementer.

>> It seems to me that the only grey area is the degree of approximation that
>> is acceptable for the result to be "useful".
> 
> That is the next can of worms to open. Once you decided which clock you
> take, you would have to define the sum of *which* durations according to
> this clock you are going to approximate. This would be way more difficult
> and IMO impossible. What is the "CPU" is presence of many cores? What does
> it mean for the task to be "active" keeping in mind the cases it could get
> blocked without losing the "CPU" (defined above)?

I think you are are creating unnecessary difficulties. Note that I said
nothing about CPUs, only about process states. The elapsed time between
dispatching a task/process and pre-empting or blocking it is a well defined
physical quantity. It has nothing to do with cores, and I've no idea what
"blocked without losing the CPU" means. In my dictionary that is simply
self-contradictory. But if it does mean something in some implementation,
all that is necessary is to inform of the approximation it gives rise to.

> In my humble opinion,

!-)

> ARG defined Ada.Execution_Time in the most
> *reasonable* way, in particular, allowing to deliver whatever garbage the
> underlying OS service spits.

I agree. What else could they do?
And if the implementation documents that, where is the harm?

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Ada.Execution_Time

[Niklas Holsti]

Dmitry A. Kazakov wrote:
> On Wed, 29 Dec 2010 14:48:20 +0200, Niklas Holsti wrote:
> 
>> Dmitry has agreed with some of my statements on this point, for example:
>>
>> - A task cannot accumulate execution time at a higher rate than real 
>> time. For example, in one real-time second the CPU_Time of a task cannot 
>> increase by more than one second.
> 
> Hold on, that is only true if a certain model of CPU_Time measurement used.

In my view, it is true within the accuracy of the execution-time 
measurement method.

> There are many potential models. The one we discussed was the model A:
> 
> Model A. Get an RTC reading upon activation. Each time CPU_Time is
> requested by Clock get another RTC reading, build the difference, add the
> accumulator to the result. Upon task deactivation, get the difference and
> update the accumulator.

OK. This is, I think, the most natural model, perhaps with some 
processor performance counter or CPU-clock-cycle counter replacing the RTC.

> This is a very strong model. Weaker models:
> 
> Model A.1. Get RTC upon activation and deactivation. Update the accumulator
> upon deactivation. When the task is active CPU_Time does not change.

That model is not permitted, because the value of 
Ada.Execution_Time.Clock must change at every "CPU tick". The duration 
of a CPU tick is Ada.Execution_Time.CPU_Tick, which is at most one 
millisecond (RM D.14(20/2)).

It is true that CPU_Tick is only the "average length" of the 
constant-Clock intervals, but the implementation is also required to 
document an upper bound, which also forbids your model A.1.

(I think that this "average" definition caters for implementations where 
the execution time counter is incremented by an RTC interrrupt handler 
that may suffer some timing jitter.)

> Model B. Use a time source different from RTC. This what Windows actually
> doest.

I don't think that this is a different "model". No time source provides 
ideal, exact real time. If the time source for Ada.Execution_Time.Clock 
differs much from real time, the accuracy of the implementation is poor 
to that extent. It does not surprise me that this happens on Windows.

I admit that the RM does not specify any required accuracy for 
Ada.Execution_Time.Clock. The accuracy required for 
execution-time-dependent scheduling algorithms is generally low, I believe.

Analogously, there are no accuracy requirements on Ada.Real_Time.Clock.

> Model B.1. Like A.1, CPU_Time freezes when the task is active.

Forbidden like A.1 above.

> Model C. Asynchronous task monitoring process

That sounds weird. Please clarify.

> Note that in either model the counter readings are rounded. Windows rounds
> toward zero, which why you never get more load than 100%. But it is
> thinkable and expectable that some systems would round away from zero or to
> the nearest bound. So the statement holds only if you have A (maybe C) + a
> corresponding rounding.

So it holds within the accuracy of the measurement method, which often 
involves some sampling or rounding error. In my view.

>> - If only one task is executing on a processor, the execution time of 
>> that task increases (or "could increase") at the same rate as real time.
> 
> This also may be wrong if a B model is used. In particular, task switching
> may be (and I think is) driven by the programmable timer interrupts. The
> real-time clock may be driven by the TSC. Since these two are physically
> different, unsynchronized time sources, the effect can be any. It is to
> expect a systematic error accumulated with the time.

Again, it holds within the accuracy of the measurement method and the 
time source, which is all that one can expect.

The points I made were meant to show how CPU_Time is related, in 
principle, to real time. I entirely accept that in practice the 
relationships will be affected by measurement inaccuracies.

For the task scheduling methods that depend on actual execution times, I 
believe that long-term drifts or accumulations of errors in CPU_Time are 
unimportant. The execution time (span) measurements need to be 
reasonably accurate only over time spans similar to the period of the 
longest-period task. The overhead (execution time not charged to tasks) 
will probably be much larger, both in mean value and in variability, 
than the time-source errors.

As discussed earlier, the time source for Ada.Real_Time.Clock that 
determines when time-driven tasks are activated may need higher fidelity 
to real time.

>> The question is how much meaning should be read into ordinary words like 
>> "time" when used in the RM without a formal definition.
> 
> Time as physical concept is not absolute. There is no *the* real time, but
> many real times and even more unreal ones.

When RM D.14(11/2) defines "the execution time of a given task" as "the 
time spent by the system executing that task", the only reasonable 
reading of the second "time" is as the common-sense physical time, as 
measured by your wrist-watch or by some more precise clock.

Let's not go into relativity and quantum mechanics for this.

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

Re: Ada.Execution_Time

[Dmitry A. Kazakov]

On Wed, 29 Dec 2010 19:57:19 +0000, (see below) wrote:

> They are implementation dependent in the best of
> circumstances, and so need to be specified by the implementer.

But Niklas seems to want more than merely documentation.

> I've no idea what "blocked without losing the CPU" means.

That is when you access something over the system bus from the task and
have to wait for the bus to become free.

There are also kernel times spend on some OS book keeping and for I/O
initiated by other task. It is impossible to tell what is done on task's
behalf and what is not. D 14(11/2) leaves everything to the implementation.

>> ARG defined Ada.Execution_Time in the most
>> *reasonable* way, in particular, allowing to deliver whatever garbage the
>> underlying OS service spits.
> 
> I agree. What else could they do?
> And if the implementation documents that, where is the harm?

To me no harm.

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

Re: Ada.Execution_Time

[Dmitry A. Kazakov]

On Wed, 29 Dec 2010 22:32:30 +0200, Niklas Holsti wrote:

> Dmitry A. Kazakov wrote:
>> 
>> Model C. Asynchronous task monitoring process
> 
> That sounds weird. Please clarify.

For example, in the kernel you have a timer interrupt each n us. Within the
handler you get the current TCB and increment the CPU usage counter there
by 1. CPU_Time returned by Clock yields Counter * n us. This is a quite
lightweight schema, which can be used for small and real-time systems. The
overhead is constant.

> Again, it holds within the accuracy of the measurement method and the 
> time source, which is all that one can expect.

The error is not bound. Only its deviation is bound, e.g. x seconds per
second of measurement.

>> Time as physical concept is not absolute. There is no *the* real time, but
>> many real times and even more unreal ones.
> 
> When RM D.14(11/2) defines "the execution time of a given task" as "the 
> time spent by the system executing that task", the only reasonable 
> reading of the second "time" is as the common-sense physical time, as 
> measured by your wrist-watch or by some more precise clock.

Which physical experiment could prove or disprove that a given
implementation is in agreement with this definition? Execution time is not
observable.

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

Re: Ada.Execution_Time

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:8o0p0lF94rU1@mid.individual.net...
> Randy, I'm glad that you are participating in this thread. My duologue 
> with Dmitry is becoming repetitive and our views entrenched.
>
> We have been discussing several things, although the focus is on the 
> intended meaning and properties of Ada.Execution_Time. As I am not an ARG 
> member I have based my understanding on the (A)RM text. If the text does 
> not reflect the intent of the ARG, I will be glad to know it, but perhaps 
> the ARG should then consider resolving the conflict by confirming or 
> changing the text.

Perhaps, but that presumes there is something wrong with the text. A lot is 
purposely left unspecified in the ARM; what causes problems is when people 
start reading stuff that is not there.

...

>> My understanding was that it was intended to provide a window into 
>> whatever facilities the underlying system had for execution "time" 
>> counting.
>
> Of course, as long as those facilities are good enough for the RM 
> requirements and for the users; otherwise, the implementor might improve 
> on the underlying system as required. The same holds for Ada.Real_Time. If 
> the underlying system is a bare-board Ada RTS, the Ada 95 form of the RTS 
> probably had to be extended to support Ada.Execution_Time.
>
> I'm sure that the proposers of the package Ada.Execution_Time expected the 
> implementation to use the facilities of the underlying system. But I am 
> also confident that they had in mind some specific uses of the package and 
> that these uses require that the values provided by Ada.Execution_Time 
> have certain properties that can reasonably be expected of "execution 
> time", whether or not these properties are expressly written as 
> requirements in the RM.

Probably, but quality of implementation is rarely specified in the Ada 
Standard. When it is, it generally is in the form of Implementation Advice 
(as opposed to hard requirements). The expectation is that implementers are 
going to provide the best implementation that they can -- implementers don't 
purposely build crippled or useless implementations. Moreover, that is 
*more* likely when the Standard is overspecified, simply because of the need 
to provide something that meets the standard.

> Examples of these uses are given in the paper by A. Burns and A.J. 
> Wellings, "Programming Execution-Time Servers in Ada 2005," pp.47-56, 27th 
> IEEE International Real-Time Systems Symposium (RTSS'06), 2006. 
> http://doi.ieeecomputersociety.org/10.1109/RTSS.2006.39.
>
> You put "time" in quotes, Randy. Don't you agree that there *is* a valid, 
> physical concept of "the execution time of a task" that can be measured in 
> units of physical time, seconds say? At least for processors that only 
> execute one task at a time, and whether or not the system provides 
> facilities for measuring this time?

I'm honestly not sure. The problem is that while such a concept might 
logicially exist, as a practical matter it cannot be measured outside of the 
most controlled circumstances. Thus, that might make sense in a bare-board 
Ada implementation, but not in any implementation running on top of any OS 
or kernel. As such, whether the concept exists is more of an "angels on the 
head of a pin" question than anything of practical importance.

> I think that the concept exists and that it matches the description in RM 
> D.14 (11/2), using the background from D.2.1, whether or not the ARG 
> intended this match.
>
> If you agree that such "execution time" values are conceptually well 
> defined, do you not think that the "execution time counting facilities" of 
> real-time OSes are meant to measure these values, to some practical level 
> of accuracy?
>
> If so, then even if Ada.Execution_Time is intended as only a window into 
> these facilities, it is still intended to provide measures of the physical 
> execution time of tasks, to some practical level of accuracy.

The problem is that that "practical level of accuracy" isn't realistic. 
Moreover, I've always viewed such facilities as "profiling" ones -- it's the 
relative magnitudes of the values that matter, not the absolute values. In 
that case, the scale of the values is not particularly relevant.

Specifically, I mean that what is important is which task is taking a lot of 
CPU. In that case, it simply is the task that has a large "execution time" 
(whatever that means) compared to the others. Typically, that's more than 
100 times the usage of the other tasks, so the units involved are hardly 
relevant.

>> That had no defined relationship with what Ada calls "time".
>> As usch, I think the name "execution time" is misleading, (and I recall 
>> some discussions about that in the ARG), but no one had a better name 
>> that made any sense at all.
>
> Do you remember if these discussions concerned the name of the package, 
> the name of the type CPU_Time, or the very concept "execution time"? If 
> the question was of the terms "time" versus "duration", I think "duration" 
> would have been more consistent with earlier Ada usage, but "execution 
> time" is more common outside Ada, for example in the acronym WCET for 
> Worst-Case Execution Time.
>
> The fact that Ada.Execution_Time provides a subtraction operator for 
> CPU_Time that yields Time_Span, which can be further converted to 
> Duration, leads the RM reader to assume some relationship, at least that 
> spans of real time and spans of execution time can be measured in the same 
> physical units (seconds).
>
> It has already been said, and not only by me, that Ada.Execution_Time is 
> intended (among other things, perhaps) to be used for implementing task 
> scheduling algorithms that depend on the accumulated execution time of the 
> tasks. This is supported by the Burns and Wellings paper referenced above. 
> In such algorithms I believe it is essential that the execution times are 
> physical times because they are used in formulae that relate (sums of) 
> execution-time spans to spans of real time.

That would be a wrong interpretation of a algorithms, I think. (Either that, 
or the algorithms themselves are heavily flawed!). The important property is 
that all of the execution times have a reasonably proportional relationship 
to the actual time spent executing each task (that hypothetical concept); 
the absolute values shouldn't matter much (just as the exact priority values 
are mostly irrelevant to scheduling decisions). Moreover, when the values 
are close, one would hope that the algorithms don't change behavior much.

The values would be trouble if they bore no relationship at all to the 
"actual time spent executing the task", but it's hard to imagine any 
real-world facility in which that was the case.

...
...
>> In particular, there is no requirement in the RM or anywhere else that 
>> these "times" sum to any particular answer.
>
> I agree that the RM has no such explicit requirement. I made this claim to 
> counter Dmitry's assertion that CPU_Time has no physical meaning, and of 
> course I accept that the sum will usually be less than real elapsed time 
> because the processor spends some time on non-task activities.
>
> The last sentence of RM D.14 (11/2) says "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". This 
> sentence strongly suggests to me that the author of this paragraph had in 
> mind that the total available execution time (span) equals the real time 
> (span), that some of this total is charged to the tasks, but that some of 
> the time spent in interrupt handlers etc. need not be charged to tasks.
>
> The question is how much meaning should be read into ordinary words like 
> "time" when used in the RM without a formal definition.
>
> If the RM were to say that L is the length of a piece of string S, 
> measured in meters, and that some parts of S are colored red, some blue, 
> and some parts may not be colored at all, surely we could conclude that 
> the sum of the lengths in meters of the red, blue, and uncolored parts 
> equals L? And that the sum of the lengths of the red and blue parts is at 
> most L? And that, since we like colorful things, we hope that the length 
> of the uncolored part is small?
>
> I think the case of summing task execution time spans is analogous.

I think you are inventing things. There is no such requirement in the 
standard, and that's good: I've never seen a real system in which this has 
been true.

Even the various profilers I wrote for MS-DOS (the closest system to a bare 
machine that will ever be in wide use) never had this property. I used to 
think that it was some sort of bug in my methods, but even using completely 
different ways of measuring time (counting ticks at subprogram heads vs. 
statistical probes -- I tried both) the effects still showed up. I've pretty 
much concluded that is is simply part of the nature of computer time -- much 
like floating point, it is an incomplete abstraction of the "real" time, and 
expecting too much out of it is going to lead immediately to disappointment.

>> I don't quite see how there could be, unless you were going to require a 
>> tailored Ada target system (which is definitely not going to be a 
>> requirement).
>
> I don't want such a requirement. The acceptable overhead (fraction of 
> execution time not charged to tasks) depends on the application.
>
> Moreover, on a multi-process systems (an Ada program running under Windows 
> or Linux, for example) some of the CPU time is spent on other processes, 
> all of which would be "overhead" from the point of view of the Ada 
> program. I don't think that the authors of D.14 had such systems in mind.

I disagree, in the sense that the ARG as a whole certainly considered the 
use of this facility in all environments. (I find that it would be very 
valuable for profiling on Windows, for instance, even if the results only 
have a weak relationship to reality).

It's possible that the people who proposed it originally were thinking as 
you are, but the ARG modified those proposals quite a bit; the result is 
definitely a team effort and not the work on any particular individual.

                               Randy.

Re: Ada.Execution_Time

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:xdzib16pw12u$.v5dybjo9t1sb.dlg@40tude.net...
> On Wed, 29 Dec 2010 19:57:19 +0000, (see below) wrote:
>...
>>> ARG defined Ada.Execution_Time in the most
>>> *reasonable* way, in particular, allowing to deliver whatever garbage 
>>> the
>>> underlying OS service spits.
>>
>> I agree. What else could they do?
>> And if the implementation documents that, where is the harm?
>
> To me no harm.

Exactly. The issue is if you think that there is something more than that; 
for whatever reason Niklas seems to think there are requirements intended 
beyond that, and that simply isn't true. It's clear that he'd never be happy 
with a Windows implementation of Ada.Execution_Time -- too bad, because it 
still can be useful.

                              Randy.

Re: Ada.Execution_Time

[Niklas Holsti]

Dmitry A. Kazakov wrote:
> On Wed, 29 Dec 2010 22:32:30 +0200, Niklas Holsti wrote:
> 
>> Dmitry A. Kazakov wrote:
>>> Model C. Asynchronous task monitoring process
>> That sounds weird. Please clarify.
> 
> For example, in the kernel you have a timer interrupt each n us. Within the
> handler you get the current TCB and increment the CPU usage counter there
> by 1. CPU_Time returned by Clock yields Counter * n us. This is a quite
> lightweight schema, which can be used for small and real-time systems. The
> overhead is constant.

Yes, that is one possible implementation, and not a bad one, although 
the CPU_Tick will probably be relatively large, and may have some 
jitter. The definition of Ada.Execution_Time.CPU_Tick as the *average* 
constant-Clock duration would come into play.

In principle this implementation is not much different from the simple, 
hardware-driven, directly readable counter of nanoseconds or CPU clock 
cycles. The only difference is that here the "counter" is driven by a 
timer-generated interrupt, not by a hardware clock generator, and it is 
easier to make task-specific counters.

>> Again, it holds within the accuracy of the measurement method and the 
>> time source, which is all that one can expect.
> 
> The error is not bound. Only its deviation is bound, e.g. x seconds per
> second of measurement.

Yes, as for different unsynchronized clocks in general. I don't think 
this is a problem for the intended uses of Ada.Execution_Time, as I 
understand them.

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

Re: Ada.Execution_Time

[Niklas Holsti]

Dmitry A. Kazakov wrote:
> On Wed, 29 Dec 2010 19:57:19 +0000, (see below) wrote:
> 
>> They are implementation dependent in the best of
>> circumstances, and so need to be specified by the implementer.
> 
> But Niklas seems to want more than merely documentation.

I'll answer that in a soon-to-appear answer to Randy.

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

Re: Ada.Execution_Time

[Niklas Holsti]

Dmitry A. Kazakov wrote:
> On Wed, 29 Dec 2010 14:48:20 +0200, Niklas Holsti wrote:
> 
>> Dmitry has agreed with some of my statements on this point, for example:
>>
>> - A task cannot accumulate execution time at a higher rate than real 
>> time. For example, in one real-time second the CPU_Time of a task cannot 
>> increase by more than one second.
> 
> Hold on, that is only true if a certain model of CPU_Time measurement used.
> There are many potential models. The one we discussed was the model A:
> 
> Model A. Get an RTC reading upon activation. Each time CPU_Time is
> requested by Clock get another RTC reading, build the difference, add the
> accumulator to the result. Upon task deactivation, get the difference and
> update the accumulator.

[ cut ]

> Note that in either model the counter readings are rounded. Windows rounds
> toward zero, which why you never get more load than 100%. But it is
> thinkable and expectable that some systems would round away from zero or to
> the nearest bound.

The RTEMS CPU Usage Statistics function in fact rounds up: "RTEMS keeps 
track of how many clock ticks have occurred which [should be "while"] 
the task being switched out has been executing. If the task has been 
running less than 1 clock tick, then for the purposes of the statistics, 
it is assumed to have executed 1 clock tick. This results in some 
inaccuracy but the alternative is for the task to have appeared to 
execute 0 clock ticks." (Quoted from 
http://www.rtems.org/onlinedocs/releases/rtemsdocs-4.9.4/share/rtems/pdf/c_user.pdf, 
page 285).

I think that rounding up may indeed be better (safer) for real-time 
scheduling and monitoring purposes. But of course this is just changing 
the direction of the inaccuracy, the principle stands.

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

Re: Ada.Execution_Time

[Niklas Holsti]

Before I answer Randy's points, below, I will try to summarise my 
position in this discussion. It seems that my convoluted dialog with 
Dmitry has not made it clear. I'm sorry that this makes for a longish post.

I am not proposing or asking for new requirements on Ada.Execution_Time 
in RM D.14. I accept that the accuracy and other qualities of the 
implementation are (mostly) not specified in the RM, so Randy is right 
that the implementors can (mostly) just provide an interface to whatever 
services exist, and Dmitry is also (mostly) right when he says that 
Ada.Execution_Time can deliver garbage results and still satisfy the RM 
requirements.

However, I think we all hope that, as Randy said, implementers are going 
to provide the best implementation that they can. Speaking of a "best" 
implementation implies that there is some ideal solution, perhaps not 
practically realizable, against which the quality of an implementation 
can be judged. Moreover, since the RM defines the language and is the 
basis on which implementors work, I would expect that the RM tries to 
describe this ideal solution, perhaps only through informal definitions, 
rationale, implementation advice, or annotations. This is what I have 
called the "intent of Ada.Execution_Time" and it includes such questions 
as the intended meaning of a CPU_Time value and what is meant by 
"execution time of a task".

My background for this discussion and for understanding 
Ada.Execution_Time is real-time programming and analysis, and in 
particular the various forms of schedulability analysis. In this domain 
the theory and practice depend crucially on the execution times of 
tasks, usually on the worst-case execution time (WCET) but sometimes on 
the whole range or distribution of execution times. Moreover, the theory 
and practice assume that "the execution time of a task" has a physical 
meaning and a strong relationship to real time.

For example, it is assumed (usually implicitly) that when a task is 
executing uninterrupted on a processor, the execution time of the task 
and the real time increase at the same rate -- this is more or less the 
definition of "execution time". Another (implicitly) assumed property is 
that if a processor first runs task A for X seconds of execution time, 
then switches to task B for Y seconds of execution time, the elapsed 
real time equals X + Y plus some "overhead" time for the task switch. 
(As a side comment, I admit that some of these assumptions are becoming 
dubious for complex processors where tasks can have strong interactions, 
for example through the cache.)

I have assumed, and still mostly believe, that this concept of 
"execution time of a task" is the ideal or intent behind 
Ada.Execution_Time, and that approaching this ideal is an implementer's 
goal.

My participation in this thread started with my objection to Dmitry's 
assertion that "CPU_Time has no physical meaning". I may have 
misunderstood Dmitry's thought, leading to a comedy of 
misunderstandings. Perhaps Dmitry only meant that in the absence of any 
accuracy requirements, CPU_Time may not have a useful physical meaning 
in a poor implementation of Ada.Execution_Time. I accept that, but I 
think that a good implementation should try to give CPU_Time the 
physical meaning that "execution time" has in the theory and practice of 
real-time systems, as closely as is practical and desired by the users 
of the implementation.

My comments in this thread therefore show the properties that I think a 
good implementation of Ada.Execution_Time should have, and are not 
proposed as new requirements. At most they could appear as additions to 
the rationale, advice, or annotations for RM D.14. I measure the 
"goodness" of an implementation as "usefulness for implementing 
real-time programs". Others, perhaps Randy or Dmitry, may have other 
goodness measures.

This thread started by a question about how Ada.Execution_Time is meant 
to be used. I think it is useful to discuss the properties and uses that 
can be expected of a good implementation, even if the RM also allows 
poor implementations.

Randy Brukardt wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
> news:8o0p0lF94rU1@mid.individual.net...
>> I'm sure that the proposers of the package Ada.Execution_Time expected the 
>> implementation to use the facilities of the underlying system. But I am 
>> also confident that they had in mind some specific uses of the package and 
>> that these uses require that the values provided by Ada.Execution_Time 
>> have certain properties that can reasonably be expected of "execution 
>> time", whether or not these properties are expressly written as 
>> requirements in the RM.
> 
> Probably, but quality of implementation is rarely specified in the Ada 
> Standard. When it is, it generally is in the form of Implementation Advice 
> (as opposed to hard requirements). The expectation is that implementers are 
> going to provide the best implementation that they can -- implementers don't 
> purposely build crippled or useless implementations. Moreover, that is 
> *more* likely when the Standard is overspecified, simply because of the need 
> to provide something that meets the standard.

I agree.

>> You put "time" in quotes, Randy. Don't you agree that there *is* a valid, 
>> physical concept of "the execution time of a task" that can be measured in 
>> units of physical time, seconds say? At least for processors that only 
>> execute one task at a time, and whether or not the system provides 
>> facilities for measuring this time?
> 
> I'm honestly not sure. The problem is that while such a concept might 
> logicially exist, as a practical matter it cannot be measured outside of the 
> most controlled circumstances.

I don't think that measurement is so difficult or that the circumstances 
must be so very controlled.

Let's assume a single-processor system and a measurement mechanism like 
the "Model A" that Dmitry described. That is, we have a HW counter that 
is driven by a fixed frequency. For simplicity and accuracy, let's 
assume that the counter is driven by the CPU clock so that the counter 
changes are synchronized with instruction executions. I think such 
counters are not uncommon in current computers used in real-time 
systems, although they may be provided by the board and not the 
processor. We implement Ada.Execution_Time by making the task-switching 
routines and the Clock function in Ada.Execution_Time read the value of 
the counter to keep track of how much the counter increases while the 
processor is running a given task. The accumulated increase is stored in 
the TCB of the task when the task is not running.

Randy, why do you think that this mechanism does not measure the 
execution time of the tasks, or a good approximation of the ideal? There 
are of course nice questions about exactly when in the task-switching 
code the counter is read and stored, and what to do with interrupts, but 
I think these are details that can be dismissed as in RM D.14 (11/2) by 
considering them implementation defined.

It is true that execution times measured in that way are not exactly 
repeatable on today's processors, even when the task follows exactly the 
same execution path in each measurement, because of external 
perturbations (such as memory access delays due to DRAM refresh) and 
inter-task interferences (such as cache evictions due to interrupts or 
preempting tasks). But this non-repeatability is present in the ideal 
concept, too, and I don't expect Ada.Execution_Time.Clock to give 
exactly repeatable results. It should show the execution time in the 
current execution of the task.

> Thus, that might make sense in a bare-board 
> Ada implementation, but not in any implementation running on top of any OS 
> or kernel.

The task concept is not so Ada-specific. For example, I would call RTEMS 
a "kernel", and it has a general (not Ada-specific) service for 
measuring per-task execution times, implemented much as Dmitry's Model A 
except that the "RTC counter" may be the RTEMS interrupt-driven "clock 
tick" counter, not a HW counter.

And what is an OS but a kernel with a large set of services, and usually 
running several unrelated applications / processes, not just several 
tasks in one application? Task-specific execution times for an OS-based 
application are probably less repeatable, and less useful, but that does 
not detract from the principle.

> As such, whether the concept exists is more of an "angels on the 
> head of a pin" question than anything of practical importance.

It is highly important for all practical uses of real-time scheduling 
theories and algorithms, since it is their basic assumption. Of course, 
some real-time programmers are of the opinion that real-time scheduling 
theories are of no practical importance. I am not one of them :-)

>> If so, then even if Ada.Execution_Time is intended as only a window into 
>> these facilities, it is still intended to provide measures of the physical 
>> execution time of tasks, to some practical level of accuracy.
> 
> The problem is that that "practical level of accuracy" isn't realistic. 

I disagree. I think execution-time measurements using Dmitry's Model A 
are practical and can be sufficiently accurate, especially if they use a 
hardware counter or RTC.

> Moreover, I've always viewed such facilities as "profiling" ones -- it's the 
> relative magnitudes of the values that matter, not the absolute values. In 
> that case, the scale of the values is not particularly relevant.

When profiling is used merely to identify the CPU hogs or bottlenecks, 
with the aim of speeding up a program, I agree that the scale is not 
relevant. Profiling is often used in this way for non-real-time systems. 
It can be done also for real-time systems, but would not help in the 
analysis of schedulability if the time-scale is arbitrary.

If profiling is used to measure task execution times for use in 
schedulability analysis or even crude CPU load computations, the scale 
must be real time, because the reference values (deadlines, load 
measurement intervals) are expressed in real time.

>> It has already been said, and not only by me, that Ada.Execution_Time is 
>> intended (among other things, perhaps) to be used for implementing task 
>> scheduling algorithms that depend on the accumulated execution time of the 
>> tasks. This is supported by the Burns and Wellings paper referenced above. 
>> In such algorithms I believe it is essential that the execution times are 
>> physical times because they are used in formulae that relate (sums of) 
>> execution-time spans to spans of real time.
> 
> That would be a wrong interpretation of a algorithms, I think. (Either that, 
> or the algorithms themselves are heavily flawed!). The important property is 
> that all of the execution times have a reasonably proportional relationship 
> to the actual time spent executing each task (that hypothetical concept); 
> the absolute values shouldn't matter much

I think you are wrong. The algorithms presented in the Burns and 
Wellings paper that I referred to implement "execution-time servers" 
which, as I understand them, are meant to limit the fraction of the CPU 
power that is given to certain groups of tasks and work as follows in 
outline. The CPU fraction is defined by an execution-time budget, say B 
seconds, that the tasks in the group jointly consume. When the budget is 
exhausted, the tasks in the group are either suspended or demoted to a 
background priority. The budget is periodically replenished (increased 
up to B seconds) every R seconds, with B < R for a one-processor system. 
The goal is thus to let this task group use at most B/R of the CPU time. 
In other words, that the CPU load fraction from this task group should 
be no more than B/R.

The B part is measured in execution time (CPU_Time differences as 
Time_Spans) and the R part in real time. If execution time is not scaled 
properly, the load fraction B/R is wrong in proprtion, and the CPU time 
(1-B/R) left for other, perhaps more critical tasks could be too small, 
causing deadline misses and failures. It is essential that execution 
time (B) is commensurate with real time (R). The examples in the paper 
also show this assumption.

As usual for academic papers in real-time scheduling, Burns and Wellings 
make no explicit assumptions about the meaning of execution time. They 
do mention measurement inaccuracies, but a systematic difference in 
scale is not considered.

> (just as the exact priority values 
> are mostly irrelevant to scheduling decisions).

The case of priority values is entirely different. I don't know of any 
real-time scheduling methods or analyses in which the quantitative 
values of priorities are important; only their relative order is 
important. In contrast, all real-time scheduling methods and analyses 
that I know of depend on the quantitative, metric, values of task 
execution times. Perhaps some heuristic scheduling methods like 
"shortest task first" are exceptions to this rule, but I don't think 
they are suitable for real-time systems.

> Moreover, when the values 
> are close, one would hope that the algorithms don't change behavior much.

Yes, I don't think the on-line execution-time dependent scheduling 
algorithms need very accurate measures of execution time. But if the 
time-scale is wrong by a factor of 2, say, I'm sure the algorithms will 
not perform as expected.

Burns and Wellings say that one of the "servers" they describe may have 
problems with cumulative drift due to measurement errors -- similar to 
round-off or truncation errors -- and they propose methods to correct 
that. But they do not discuss scale errors, which should lead to a much 
larger drift.

> The values would be trouble if they bore no relationship at all to the 
> "actual time spent executing the task", but it's hard to imagine any 
> real-world facility in which that was the case.

I agree, but Dmitry claimed the opposite ("CPU_Time has no physical 
meaning") to which I objected. And indeed it seems that under some 
conditions the execution times measured with the Windows "quants" 
mechanism are zero, which would certainly inconvenience scheduling 
algorithms.

>> The question is how much meaning should be read into ordinary words like 
>> "time" when used in the RM without a formal definition.
>>
>> If the RM were to say that L is the length of a piece of string S, 
>> measured in meters, and that some parts of S are colored red, some blue, 
>> and some parts may not be colored at all, surely we could conclude that 
>> the sum of the lengths in meters of the red, blue, and uncolored parts 
>> equals L? And that the sum of the lengths of the red and blue parts is at 
>> most L? And that, since we like colorful things, we hope that the length 
>> of the uncolored part is small?
>>
>> I think the case of summing task execution time spans is analogous.
> 
> I think you are inventing things.

Possibly so. RM D.14 (11/2) tries to define "the execution time of a 
task" by using an English phrase "... is the time spent by the system 
...". I am trying to understand what this definition might mean, as a 
description of the ideal or intent in the minds of the authors, who 
certainly intended the definition to have *some* meaning for the reader.

I strongly suspect that the proposers of D.14 meant "execution time" as 
understood in the real-time scheduling theory domain, and that they felt 
it unnecessary to define it or its properties more formally, partly out 
of habit, as those properties are implicitly assumed in academic papers, 
partly because any definition would have had to include messy text about 
measurement errors, and they did not want to specify accuracy requirements.

> There is no such requirement in the standard, and that's good:

I agree and I don't want to add such a requirement.

> I've never seen a real system in which this has been true.

I don't think it will be exactly true in a real system. I continue to 
think that it will be approximately true in a good implementation of 
Ada.Execution_Time (modulo the provision on interrupt handlers etc), and 
that this is necessary if Ada.Execution_Time is to be used as Burns and 
Wellings propose.

> Even the various profilers I wrote for MS-DOS (the closest system to a bare 
> machine that will ever be in wide use) never had this property.

I can't comment on that now, but I would be interested to hear what you 
tried, and what happened.

>> Moreover, on a multi-process systems (an Ada program running under Windows 
>> or Linux, for example) some of the CPU time is spent on other processes, 
>> all of which would be "overhead" from the point of view of the Ada 
>> program. I don't think that the authors of D.14 had such systems in mind.
> 
> I disagree, in the sense that the ARG as a whole certainly considered the 
> use of this facility in all environments.

Aha. Well, as I said above on the question of Ada vs kernel vs OS, the 
package should be implementable under and OS like Windows or Linux, too. 
I don't think D.14 makes any attempt to exclude that, and why should it.

> (I find that it would be very 
> valuable for profiling on Windows, for instance, even if the results only 
> have a weak relationship to reality).

Yes, if all you want are the relative execution-time consumptions of the 
tasks in order to find the CPU hogs. And the quant-truncation problem 
may distort even the relative execution times considerably.

Randy wrote in another post:
 > It's clear that he [Niklas] would never be happy
 > with a Windows implementation of Ada.Execution_Time -- too bad,
 > because it still can be useful.

I probably would not be happy to use Windows at all for a real-time 
system, so my happiness with Ada.Execution_Time is perhaps moot.

But it is all a question of what accuracy is required and can be 
provided. If I understand the description of Windows quants correctly, 
an implementation of Ada.Execution_Time under Windows may have tolerable 
accuracy if the average span of non-interrupted, non-preempted, and 
non-suspended execution of task is much larger than a quant, as the 
truncation of partially used quants then causes a relatively small error.

I don't know if the scheduling methods of Windows would let one make 
good use the measured execution times. I have no experience of Windows 
programming on that level, unfortunately.

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

Re: Ada.Execution_Time

[BrianG]

Dmitry A. Kazakov wrote:
> On Tue, 28 Dec 2010 14:14:57 +0000, Simon Wright wrote:
> 
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>
>>> And conversely, the catastrophic accuracy of the VxWorks real-time
>>> clock service does not hinder its usability for real-time application.
>> Catastrophic?
>>
...
> 
> Yes, this thing. In our case it was Pentium VxWorks 6.x. (The PPC we used
> prior to it had poor performance) The problem was that Ada.Real_Time.Clock
> had the accuracy of the clock interrupts, i.e. 1ms, which is by all
> accounts catastrophic for a 1.7GHz processor. You can switch some tasks
> forth and back between two clock changes.
>  

So, we're talking about GNAT's use of VxWorks' features as
"catastrophic"?  That's not how I read the original statement.

(We use GNAT on VxWorks, but since we don't (yet) really use tasks, and 
have our own "delay" equivalent to match external hardware, I don't see 
its performance - but since I'm used to GNAT on DOS/Windows, I don't 
have very high expectations.  It sounds like I should keep that opinion.)

--BrianG

Re: Ada.Execution_Time

[Dmitry A. Kazakov]

On Thu, 30 Dec 2010 19:40:08 -0500, BrianG wrote:

> Dmitry A. Kazakov wrote:
>> On Tue, 28 Dec 2010 14:14:57 +0000, Simon Wright wrote:
>> 
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>
>>>> And conversely, the catastrophic accuracy of the VxWorks real-time
>>>> clock service does not hinder its usability for real-time application.
>>> Catastrophic?
>> 
>> Yes, this thing. In our case it was Pentium VxWorks 6.x. (The PPC we used
>> prior to it had poor performance) The problem was that Ada.Real_Time.Clock
>> had the accuracy of the clock interrupts, i.e. 1ms, which is by all
>> accounts catastrophic for a 1.7GHz processor. You can switch some tasks
>> forth and back between two clock changes.  
> 
> So, we're talking about GNAT's use of VxWorks' features as
> "catastrophic"?  That's not how I read the original statement.

No, GNAT just uses the standard OS clock. It is the OS design flaw. They
should have used the CPU's real time clock, or provide a configurable
clock, so that you could choose its source. Why should AdaCore clean up
Wind River's mess?

Happy New Year,

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

Re: Ada.Execution_Time

[Randy Brukardt]

I think we're actually in agreement on most points. The main difference is 
that I contend that the theoretical "execution time" is, in actual practice, 
unmeasurable. ("Unmeasurable" is a bit strong, but I mean that you can only 
get a gross estimation of it.)

You have argued that there exist cases where it is possible to do better (a 
hardware clock, a single processor, a kernel that doesn't get in the way of 
using the hardware clock, no contention with other devices on the bus, 
etc.), and I wouldn't disagree. The problem is that those cases aren't 
realistic, particularly if you are talking about a language-defined package. 
(Even if there is a hardware clock available on a particular target, an 
off-the-shelf compiler isn't going to be able to use it. It can only use the 
facilities of the kernel or OS.)

This shows up when you talk about the inability to reproduce the results. In 
practice, I think you'll find that the values vary a lot from run to run; 
the net effect is that the error is a large percentage of the results for 
many values.

Your discussion of real-time scheduling using this still seems to me to be 
more in the realm of academic exercise than something practical. I'm sure 
that it works in very limited circumstances, but those circumstances are 
getting less and less likely by the year. Techniques that assume a strong 
correspondence between these values and real-time are simply fantasy -- I 
would hope no one depend on these for anything of importance. (With the 
possible exception of an all-Ada kernel, but even then you would be 
*writing* Ada.Execution_Time, not using it.) A weak correspondence (for 
choosing between otherwise similar tasks, for one instance) might make 
sense, but that is about it.

                       Randy.


"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:8o4k3tFko2U1@mid.individual.net...
> Before I answer Randy's points, below, I will try to summarise my position 
> in this discussion. It seems that my convoluted dialog with Dmitry has not 
> made it clear. I'm sorry that this makes for a longish post.
>
> I am not proposing or asking for new requirements on Ada.Execution_Time in 
> RM D.14. I accept that the accuracy and other qualities of the 
> implementation are (mostly) not specified in the RM, so Randy is right 
> that the implementors can (mostly) just provide an interface to whatever 
> services exist, and Dmitry is also (mostly) right when he says that 
> Ada.Execution_Time can deliver garbage results and still satisfy the RM 
> requirements.
>
> However, I think we all hope that, as Randy said, implementers are going 
> to provide the best implementation that they can. Speaking of a "best" 
> implementation implies that there is some ideal solution, perhaps not 
> practically realizable, against which the quality of an implementation can 
> be judged. Moreover, since the RM defines the language and is the basis on 
> which implementors work, I would expect that the RM tries to describe this 
> ideal solution, perhaps only through informal definitions, rationale, 
> implementation advice, or annotations. This is what I have called the 
> "intent of Ada.Execution_Time" and it includes such questions as the 
> intended meaning of a CPU_Time value and what is meant by "execution time 
> of a task".
>
> My background for this discussion and for understanding Ada.Execution_Time 
> is real-time programming and analysis, and in particular the various forms 
> of schedulability analysis. In this domain the theory and practice depend 
> crucially on the execution times of tasks, usually on the worst-case 
> execution time (WCET) but sometimes on the whole range or distribution of 
> execution times. Moreover, the theory and practice assume that "the 
> execution time of a task" has a physical meaning and a strong relationship 
> to real time.
>
> For example, it is assumed (usually implicitly) that when a task is 
> executing uninterrupted on a processor, the execution time of the task and 
> the real time increase at the same rate -- this is more or less the 
> definition of "execution time". Another (implicitly) assumed property is 
> that if a processor first runs task A for X seconds of execution time, 
> then switches to task B for Y seconds of execution time, the elapsed real 
> time equals X + Y plus some "overhead" time for the task switch. (As a 
> side comment, I admit that some of these assumptions are becoming dubious 
> for complex processors where tasks can have strong interactions, for 
> example through the cache.)
>
> I have assumed, and still mostly believe, that this concept of "execution 
> time of a task" is the ideal or intent behind Ada.Execution_Time, and that 
> approaching this ideal is an implementer's goal.
>
> My participation in this thread started with my objection to Dmitry's 
> assertion that "CPU_Time has no physical meaning". I may have 
> misunderstood Dmitry's thought, leading to a comedy of misunderstandings. 
> Perhaps Dmitry only meant that in the absence of any accuracy 
> requirements, CPU_Time may not have a useful physical meaning in a poor 
> implementation of Ada.Execution_Time. I accept that, but I think that a 
> good implementation should try to give CPU_Time the physical meaning that 
> "execution time" has in the theory and practice of real-time systems, as 
> closely as is practical and desired by the users of the implementation.
>
> My comments in this thread therefore show the properties that I think a 
> good implementation of Ada.Execution_Time should have, and are not 
> proposed as new requirements. At most they could appear as additions to 
> the rationale, advice, or annotations for RM D.14. I measure the 
> "goodness" of an implementation as "usefulness for implementing real-time 
> programs". Others, perhaps Randy or Dmitry, may have other goodness 
> measures.
>
> This thread started by a question about how Ada.Execution_Time is meant to 
> be used. I think it is useful to discuss the properties and uses that can 
> be expected of a good implementation, even if the RM also allows poor 
> implementations.
>
> Randy Brukardt wrote:
>> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
>> news:8o0p0lF94rU1@mid.individual.net...
>>> I'm sure that the proposers of the package Ada.Execution_Time expected 
>>> the implementation to use the facilities of the underlying system. But I 
>>> am also confident that they had in mind some specific uses of the 
>>> package and that these uses require that the values provided by 
>>> Ada.Execution_Time have certain properties that can reasonably be 
>>> expected of "execution time", whether or not these properties are 
>>> expressly written as requirements in the RM.
>>
>> Probably, but quality of implementation is rarely specified in the Ada 
>> Standard. When it is, it generally is in the form of Implementation 
>> Advice (as opposed to hard requirements). The expectation is that 
>> implementers are going to provide the best implementation that they 
>> can -- implementers don't purposely build crippled or useless 
>> implementations. Moreover, that is *more* likely when the Standard is 
>> overspecified, simply because of the need to provide something that meets 
>> the standard.
>
> I agree.
>
>>> You put "time" in quotes, Randy. Don't you agree that there *is* a 
>>> valid, physical concept of "the execution time of a task" that can be 
>>> measured in units of physical time, seconds say? At least for processors 
>>> that only execute one task at a time, and whether or not the system 
>>> provides facilities for measuring this time?
>>
>> I'm honestly not sure. The problem is that while such a concept might 
>> logicially exist, as a practical matter it cannot be measured outside of 
>> the most controlled circumstances.
>
> I don't think that measurement is so difficult or that the circumstances 
> must be so very controlled.
>
> Let's assume a single-processor system and a measurement mechanism like 
> the "Model A" that Dmitry described. That is, we have a HW counter that is 
> driven by a fixed frequency. For simplicity and accuracy, let's assume 
> that the counter is driven by the CPU clock so that the counter changes 
> are synchronized with instruction executions. I think such counters are 
> not uncommon in current computers used in real-time systems, although they 
> may be provided by the board and not the processor. We implement 
> Ada.Execution_Time by making the task-switching routines and the Clock 
> function in Ada.Execution_Time read the value of the counter to keep track 
> of how much the counter increases while the processor is running a given 
> task. The accumulated increase is stored in the TCB of the task when the 
> task is not running.
>
> Randy, why do you think that this mechanism does not measure the execution 
> time of the tasks, or a good approximation of the ideal? There are of 
> course nice questions about exactly when in the task-switching code the 
> counter is read and stored, and what to do with interrupts, but I think 
> these are details that can be dismissed as in RM D.14 (11/2) by 
> considering them implementation defined.
>
> It is true that execution times measured in that way are not exactly 
> repeatable on today's processors, even when the task follows exactly the 
> same execution path in each measurement, because of external perturbations 
> (such as memory access delays due to DRAM refresh) and inter-task 
> interferences (such as cache evictions due to interrupts or preempting 
> tasks). But this non-repeatability is present in the ideal concept, too, 
> and I don't expect Ada.Execution_Time.Clock to give exactly repeatable 
> results. It should show the execution time in the current execution of the 
> task.
>
>> Thus, that might make sense in a bare-board Ada implementation, but not 
>> in any implementation running on top of any OS or kernel.
>
> The task concept is not so Ada-specific. For example, I would call RTEMS a 
> "kernel", and it has a general (not Ada-specific) service for measuring 
> per-task execution times, implemented much as Dmitry's Model A except that 
> the "RTC counter" may be the RTEMS interrupt-driven "clock tick" counter, 
> not a HW counter.
>
> And what is an OS but a kernel with a large set of services, and usually 
> running several unrelated applications / processes, not just several tasks 
> in one application? Task-specific execution times for an OS-based 
> application are probably less repeatable, and less useful, but that does 
> not detract from the principle.
>
>> As such, whether the concept exists is more of an "angels on the head of 
>> a pin" question than anything of practical importance.
>
> It is highly important for all practical uses of real-time scheduling 
> theories and algorithms, since it is their basic assumption. Of course, 
> some real-time programmers are of the opinion that real-time scheduling 
> theories are of no practical importance. I am not one of them :-)
>
>>> If so, then even if Ada.Execution_Time is intended as only a window into 
>>> these facilities, it is still intended to provide measures of the 
>>> physical execution time of tasks, to some practical level of accuracy.
>>
>> The problem is that that "practical level of accuracy" isn't realistic.
>
> I disagree. I think execution-time measurements using Dmitry's Model A are 
> practical and can be sufficiently accurate, especially if they use a 
> hardware counter or RTC.
>
>> Moreover, I've always viewed such facilities as "profiling" ones -- it's 
>> the relative magnitudes of the values that matter, not the absolute 
>> values. In that case, the scale of the values is not particularly 
>> relevant.
>
> When profiling is used merely to identify the CPU hogs or bottlenecks, 
> with the aim of speeding up a program, I agree that the scale is not 
> relevant. Profiling is often used in this way for non-real-time systems. 
> It can be done also for real-time systems, but would not help in the 
> analysis of schedulability if the time-scale is arbitrary.
>
> If profiling is used to measure task execution times for use in 
> schedulability analysis or even crude CPU load computations, the scale 
> must be real time, because the reference values (deadlines, load 
> measurement intervals) are expressed in real time.
>
>>> It has already been said, and not only by me, that Ada.Execution_Time is 
>>> intended (among other things, perhaps) to be used for implementing task 
>>> scheduling algorithms that depend on the accumulated execution time of 
>>> the tasks. This is supported by the Burns and Wellings paper referenced 
>>> above. In such algorithms I believe it is essential that the execution 
>>> times are physical times because they are used in formulae that relate 
>>> (sums of) execution-time spans to spans of real time.
>>
>> That would be a wrong interpretation of a algorithms, I think. (Either 
>> that, or the algorithms themselves are heavily flawed!). The important 
>> property is that all of the execution times have a reasonably 
>> proportional relationship to the actual time spent executing each task 
>> (that hypothetical concept); the absolute values shouldn't matter much
>
> I think you are wrong. The algorithms presented in the Burns and Wellings 
> paper that I referred to implement "execution-time servers" which, as I 
> understand them, are meant to limit the fraction of the CPU power that is 
> given to certain groups of tasks and work as follows in outline. The CPU 
> fraction is defined by an execution-time budget, say B seconds, that the 
> tasks in the group jointly consume. When the budget is exhausted, the 
> tasks in the group are either suspended or demoted to a background 
> priority. The budget is periodically replenished (increased up to B 
> seconds) every R seconds, with B < R for a one-processor system. The goal 
> is thus to let this task group use at most B/R of the CPU time. In other 
> words, that the CPU load fraction from this task group should be no more 
> than B/R.
>
> The B part is measured in execution time (CPU_Time differences as 
> Time_Spans) and the R part in real time. If execution time is not scaled 
> properly, the load fraction B/R is wrong in proprtion, and the CPU time 
> (1-B/R) left for other, perhaps more critical tasks could be too small, 
> causing deadline misses and failures. It is essential that execution time 
> (B) is commensurate with real time (R). The examples in the paper also 
> show this assumption.
>
> As usual for academic papers in real-time scheduling, Burns and Wellings 
> make no explicit assumptions about the meaning of execution time. They do 
> mention measurement inaccuracies, but a systematic difference in scale is 
> not considered.
>
>> (just as the exact priority values are mostly irrelevant to scheduling 
>> decisions).
>
> The case of priority values is entirely different. I don't know of any 
> real-time scheduling methods or analyses in which the quantitative values 
> of priorities are important; only their relative order is important. In 
> contrast, all real-time scheduling methods and analyses that I know of 
> depend on the quantitative, metric, values of task execution times. 
> Perhaps some heuristic scheduling methods like "shortest task first" are 
> exceptions to this rule, but I don't think they are suitable for real-time 
> systems.
>
>> Moreover, when the values are close, one would hope that the algorithms 
>> don't change behavior much.
>
> Yes, I don't think the on-line execution-time dependent scheduling 
> algorithms need very accurate measures of execution time. But if the 
> time-scale is wrong by a factor of 2, say, I'm sure the algorithms will 
> not perform as expected.
>
> Burns and Wellings say that one of the "servers" they describe may have 
> problems with cumulative drift due to measurement errors -- similar to 
> round-off or truncation errors -- and they propose methods to correct 
> that. But they do not discuss scale errors, which should lead to a much 
> larger drift.
>
>> The values would be trouble if they bore no relationship at all to the 
>> "actual time spent executing the task", but it's hard to imagine any 
>> real-world facility in which that was the case.
>
> I agree, but Dmitry claimed the opposite ("CPU_Time has no physical 
> meaning") to which I objected. And indeed it seems that under some 
> conditions the execution times measured with the Windows "quants" 
> mechanism are zero, which would certainly inconvenience scheduling 
> algorithms.
>
>>> The question is how much meaning should be read into ordinary words like 
>>> "time" when used in the RM without a formal definition.
>>>
>>> If the RM were to say that L is the length of a piece of string S, 
>>> measured in meters, and that some parts of S are colored red, some blue, 
>>> and some parts may not be colored at all, surely we could conclude that 
>>> the sum of the lengths in meters of the red, blue, and uncolored parts 
>>> equals L? And that the sum of the lengths of the red and blue parts is 
>>> at most L? And that, since we like colorful things, we hope that the 
>>> length of the uncolored part is small?
>>>
>>> I think the case of summing task execution time spans is analogous.
>>
>> I think you are inventing things.
>
> Possibly so. RM D.14 (11/2) tries to define "the execution time of a task" 
> by using an English phrase "... is the time spent by the system ...". I am 
> trying to understand what this definition might mean, as a description of 
> the ideal or intent in the minds of the authors, who certainly intended 
> the definition to have *some* meaning for the reader.
>
> I strongly suspect that the proposers of D.14 meant "execution time" as 
> understood in the real-time scheduling theory domain, and that they felt 
> it unnecessary to define it or its properties more formally, partly out of 
> habit, as those properties are implicitly assumed in academic papers, 
> partly because any definition would have had to include messy text about 
> measurement errors, and they did not want to specify accuracy 
> requirements.
>
>> There is no such requirement in the standard, and that's good:
>
> I agree and I don't want to add such a requirement.
>
>> I've never seen a real system in which this has been true.
>
> I don't think it will be exactly true in a real system. I continue to 
> think that it will be approximately true in a good implementation of 
> Ada.Execution_Time (modulo the provision on interrupt handlers etc), and 
> that this is necessary if Ada.Execution_Time is to be used as Burns and 
> Wellings propose.
>
>> Even the various profilers I wrote for MS-DOS (the closest system to a 
>> bare machine that will ever be in wide use) never had this property.
>
> I can't comment on that now, but I would be interested to hear what you 
> tried, and what happened.
>
>>> Moreover, on a multi-process systems (an Ada program running under 
>>> Windows or Linux, for example) some of the CPU time is spent on other 
>>> processes, all of which would be "overhead" from the point of view of 
>>> the Ada program. I don't think that the authors of D.14 had such systems 
>>> in mind.
>>
>> I disagree, in the sense that the ARG as a whole certainly considered the 
>> use of this facility in all environments.
>
> Aha. Well, as I said above on the question of Ada vs kernel vs OS, the 
> package should be implementable under and OS like Windows or Linux, too. I 
> don't think D.14 makes any attempt to exclude that, and why should it.
>
>> (I find that it would be very valuable for profiling on Windows, for 
>> instance, even if the results only have a weak relationship to reality).
>
> Yes, if all you want are the relative execution-time consumptions of the 
> tasks in order to find the CPU hogs. And the quant-truncation problem may 
> distort even the relative execution times considerably.
>
> Randy wrote in another post:
> > It's clear that he [Niklas] would never be happy
> > with a Windows implementation of Ada.Execution_Time -- too bad,
> > because it still can be useful.
>
> I probably would not be happy to use Windows at all for a real-time 
> system, so my happiness with Ada.Execution_Time is perhaps moot.
>
> But it is all a question of what accuracy is required and can be provided. 
> If I understand the description of Windows quants correctly, an 
> implementation of Ada.Execution_Time under Windows may have tolerable 
> accuracy if the average span of non-interrupted, non-preempted, and 
> non-suspended execution of task is much larger than a quant, as the 
> truncation of partially used quants then causes a relatively small error.
>
> I don't know if the scheduling methods of Windows would let one make good 
> use the measured execution times. I have no experience of Windows 
> programming on that level, unfortunately.
>
> -- 
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
>       .      @       . 

Re: Ada.Execution_Time

[Niklas Holsti]

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.

> The main difference is 
> that I contend that the theoretical "execution time" is, in actual practice, 
> unmeasurable. ("Unmeasurable" is a bit strong, but I mean that you can only 
> get a gross estimation of it.)

You are right, we disagree on this.

> You have argued that there exist cases where it is possible to do better (a 
> hardware clock, a single processor, a kernel that doesn't get in the way of 
> using the hardware clock,

Yes.

> no contention with other devices on the bus, etc.),

I may have been fuzzy on that. Such real but variable or unpredictable 
delays or speed-ups are, in my view, just normal parts of the execution 
time of the affected task, and do not harm the ideal concept of "the 
execution time of a task" nor the usefulness of Ada.Execution_Time and 
its child packages. They only mean that the measured execution time of 
one particular execution of a task is less predictive of the execution 
times of future executions of that task. More on this below.

> and I wouldn't disagree. The problem is that those cases aren't 
> realistic, particularly if you are talking about a language-defined package. 

I am not proposing new general requirements on timing accuracy for the RM.

> (Even if there is a hardware clock available on a particular target, an 
> off-the-shelf compiler isn't going to be able to use it. It can only use the 
> facilities of the kernel or OS.)

For critical, embedded, hard-real-time systems I think it is not 
uncommon to use dedicated real-time computers with kernels such as 
VxWorks or RTEMS or bare-board Ada run-time systems. I have worked on 
such computers in the past, and I see such computers being advertised 
and used today.

In such systems, the kernel or Ada RTS is usually customised by a "board 
support package" (BSP) that, among other things, handles the interfaces 
to clocks and timers on the target computer (the "board"). Such systems 
can provide high-accuracy timers and mechanisms for execution-time 
monitoring without having to change the compiler; it should be enough to 
change the implementation of Ada.Execution_Time. In effect, 
Ada.Execution_Time would be a part of the BSP, or depend on types and 
services defined in the BSP.

The question is then if the compiler/system vendors will take the 
trouble and cost to customise Ada.Execution_Time for a particular 
board/computer, or if they will just use the general, lowest-denominator 
but portable service provided by the kernel. Dmitry indicates that GNAT 
on VxWorks takes the latter, easy way out. That's a matter of cost vs 
demand; if the users want it, the vendors can provide it.

For example, the "CPU Usage Statistics" section of the "RTEMS C User's 
Guide" says: "RTEMS versions newer than the 4.7 release series, support 
the ability to obtain timestamps with nanosecond granularity if the BSP 
provides support. It is a desirable enhancement to change the way the 
usage data is gathered to take advantage of this recently added 
capability. Please consider sponsoring the core RTEMS development team 
to add this capability." Thus, in March 2010 the RTEMS developers wanted 
and could implement accurate execution-time measurement, but no customer 
had yet paid for its implementation.

> This shows up when you talk about the inability to reproduce the results. In 
> practice, I think you'll find that the values vary a lot from run to run; 
> the net effect is that the error is a large percentage of the results for 
> many values.

Again, I may have not have been clear on my view of the reproducibility 
and variability of execution-time measurements. The variability in the 
measured execution time of a task has three components or sources:

1. Variable execution paths due to data-dependent conditional 
control-flow (if-then-else, case, loop). In other words, on different 
executions of the task, different sequences of instructions are 
executed, leading to different execution times.

2. Variable execution times of indivual instructions, for example due to 
variable cache contents and variable bus contention.

3. Variable measurement errors, for example truncations or roundings in 
the count of CPU_Time clock cycles, variable amount of interrupt 
handling included in the task execution time, etc.

Components 1 and 2 are big problems for worst-case analysis but in my 
view are not problems for Ada.Execution_Time. In fact, I think that one 
of the intended uses of Ada.Execution_Time is to help systems make good 
use of this execution-time variability by letting the system do other 
useful things when some task happens to execute quicker than its 
worst-case execution time and leaves some slack in the schedule.

Only component 3 is an "error" in the measured value. This component, 
and also constant measurement errors if any, are problems for users of 
Ada.Execution_Time.

> Your discussion of real-time scheduling using this still seems to me to be 
> more in the realm of academic exercise than something practical. I'm sure 
> that it works in very limited circumstances,

I think these circumstances have some correlation with the domain for 
which Ada is or was intended: reliable, embedded, possibly real-time 
systems. Well, this is a limited niche.

> but those circumstances are 
> getting less and less likely by the year. Techniques that assume a strong 
> correspondence between these values and real-time are simply fantasy -- I 
> would hope no one depend on these for anything of importance.

If this is true, Ada.Execution_Time is useless for real-time systems. 
Since it was added to the RM for 2005, and is still in the draft for RM 
2012, I suppose the ARG majority does not share your view.

Thanks for a frank discussion, and best wishes for 2011!

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

Re: Ada.Execution_Time

[Simon Wright]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> The question is then if the compiler/system vendors will take the
> trouble and cost to customise Ada.Execution_Time for a particular
> board/computer, or if they will just use the general,
> lowest-denominator but portable service provided by the kernel. Dmitry
> indicates that GNAT on VxWorks takes the latter, easy way out.

The latest supported GNAT on VxWorks (5.5) actually doesn't implement
Ada.Execution_Time at all (well, the source of the package spec is
there, adorned with "pragma Unimplemented_Unit", just like the FSF 4.5.0
sources and the GNAT GPL sources -- unless you're running on Cygwin or
MaRTE).

Re: Ada.Execution_Time

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Your discussion of real-time scheduling using this still seems to me
> to be more in the realm of academic exercise than something
> practical. I'm sure that it works in very limited circumstances, but
> those circumstances are getting less and less likely by the year.

Sounds as if you don't agree with the !problem section of AI-00307?

The first paragraph says that measurement/estimation is important, and
that measurement is difficult [actually, I don't see this; _estimation_
is hard, sure, what with pipelining, caches etc, but _measurement_?]

The second paragraph says that in a hard real time system you ought to
be able to monitor execution times in order to tell whether things have
gone wrong. Hence Ada.Execution_Time.Timers.

The third paragraph talks about fancy scheduling algorithms. This is the
point at which I too start to wonder whether things are getting a bit
academic; but I have no practical experience of the sort of real-time
systems under discussion. We merely have to produce the required output
within 2 ms of a program interrupt; but the world won't end if we miss
occasionally (not that we ever do), because of the rest of the system
design, which has to cope with data loss over noisy radio channels.

The last paragraphs call up the Real-Time extensions to POSIX (IEEE
1003.1d, after a lot of googling) as an indication of the intention.

Re: Ada.Execution_Time

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>
>> The question is then if the compiler/system vendors will take the
>> trouble and cost to customise Ada.Execution_Time for a particular
>> board/computer, or if they will just use the general,
>> lowest-denominator but portable service provided by the kernel. Dmitry
>> indicates that GNAT on VxWorks takes the latter, easy way out.
>
> The latest supported GNAT on VxWorks (5.5) actually doesn't implement
> Ada.Execution_Time at all (well, the source of the package spec is
> there, adorned with "pragma Unimplemented_Unit", just like the FSF
> 4.5.0 sources and the GNAT GPL sources -- unless you're running on
> Cygwin or MaRTE).

Actually, Dmitry's complaint was that time (either from
Ada.Calendar.Clock, or Ada.Real_Time.Clock, I forget) wasn't as precise
as it can easily be on modern hardware, being incremented at each timer
interrupt; so if your timer ticks every millisecond, that's your
granularity.

This could easily be changed (at any rate for Real_Time), but doesn't I
believe necessarily affect what's to be expected from delay/delay until,
or Execution_Time come to that.

Re: Ada.Execution_Time

[Niklas Holsti]

Simon Wright wrote:
> Simon Wright <simon@pushface.org> writes:
> 
>> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>>
>>> The question is then if the compiler/system vendors will take the
>>> trouble and cost to customise Ada.Execution_Time for a particular
>>> board/computer, or if they will just use the general,
>>> lowest-denominator but portable service provided by the kernel. Dmitry
>>> indicates that GNAT on VxWorks takes the latter, easy way out.
>> The latest supported GNAT on VxWorks (5.5) actually doesn't implement
>> Ada.Execution_Time at all (well, the source of the package spec is
>> there, adorned with "pragma Unimplemented_Unit", just like the FSF
>> 4.5.0 sources and the GNAT GPL sources -- unless you're running on
>> Cygwin or MaRTE).
> 
> Actually, Dmitry's complaint was that time (either from
> Ada.Calendar.Clock, or Ada.Real_Time.Clock, I forget) wasn't as precise
> as it can easily be on modern hardware, being incremented at each timer
> interrupt; so if your timer ticks every millisecond, that's your
> granularity.

Thanks for correcting me, Simon, I mis-remembered or misunderstood Dmitry.

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

Re: Ada.Execution_Time

[Randy Brukardt]

"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), then you 
probably could find a use for in a hard real-time system.

But the typical off-the-shelf implementation is not going to be useful for 
anything beyond gross guidance. 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.

But it doesn't make sense to assume tight matches 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. So I would agree that 
the existence Ada.Execution_Time really doesn't buy anything for a hard 
real-time system.

I suppose there are others that disagree (starting with Alan Burns). I think 
they're wrong.

                                   Randy.





>> The main difference is that I contend that the theoretical "execution 
>> time" is, in actual practice, unmeasurable. ("Unmeasurable" is a bit 
>> strong, but I mean that you can only get a gross estimation of it.)
>
> You are right, we disagree on this.
>
>> You have argued that there exist cases where it is possible to do better 
>> (a hardware clock, a single processor, a kernel that doesn't get in the 
>> way of using the hardware clock,
>
> Yes.
>
>> no contention with other devices on the bus, etc.),
>
> I may have been fuzzy on that. Such real but variable or unpredictable 
> delays or speed-ups are, in my view, just normal parts of the execution 
> time of the affected task, and do not harm the ideal concept of "the 
> execution time of a task" nor the usefulness of Ada.Execution_Time and its 
> child packages. They only mean that the measured execution time of one 
> particular execution of a task is less predictive of the execution times 
> of future executions of that task. More on this below.
>
>> and I wouldn't disagree. The problem is that those cases aren't 
>> realistic, particularly if you are talking about a language-defined 
>> package.
>
> I am not proposing new general requirements on timing accuracy for the RM.
>
>> (Even if there is a hardware clock available on a particular target, an 
>> off-the-shelf compiler isn't going to be able to use it. It can only use 
>> the facilities of the kernel or OS.)
>
> For critical, embedded, hard-real-time systems I think it is not uncommon 
> to use dedicated real-time computers with kernels such as VxWorks or RTEMS 
> or bare-board Ada run-time systems. I have worked on such computers in the 
> past, and I see such computers being advertised and used today.
>
> In such systems, the kernel or Ada RTS is usually customised by a "board 
> support package" (BSP) that, among other things, handles the interfaces to 
> clocks and timers on the target computer (the "board"). Such systems can 
> provide high-accuracy timers and mechanisms for execution-time monitoring 
> without having to change the compiler; it should be enough to change the 
> implementation of Ada.Execution_Time. In effect, Ada.Execution_Time would 
> be a part of the BSP, or depend on types and services defined in the BSP.
>
> The question is then if the compiler/system vendors will take the trouble 
> and cost to customise Ada.Execution_Time for a particular board/computer, 
> or if they will just use the general, lowest-denominator but portable 
> service provided by the kernel. Dmitry indicates that GNAT on VxWorks 
> takes the latter, easy way out. That's a matter of cost vs demand; if the 
> users want it, the vendors can provide it.
>
> For example, the "CPU Usage Statistics" section of the "RTEMS C User's 
> Guide" says: "RTEMS versions newer than the 4.7 release series, support 
> the ability to obtain timestamps with nanosecond granularity if the BSP 
> provides support. It is a desirable enhancement to change the way the 
> usage data is gathered to take advantage of this recently added 
> capability. Please consider sponsoring the core RTEMS development team to 
> add this capability." Thus, in March 2010 the RTEMS developers wanted and 
> could implement accurate execution-time measurement, but no customer had 
> yet paid for its implementation.
>
>> This shows up when you talk about the inability to reproduce the results. 
>> In practice, I think you'll find that the values vary a lot from run to 
>> run; the net effect is that the error is a large percentage of the 
>> results for many values.
>
> Again, I may have not have been clear on my view of the reproducibility 
> and variability of execution-time measurements. The variability in the 
> measured execution time of a task has three components or sources:
>
> 1. Variable execution paths due to data-dependent conditional control-flow 
> (if-then-else, case, loop). In other words, on different executions of the 
> task, different sequences of instructions are executed, leading to 
> different execution times.
>
> 2. Variable execution times of indivual instructions, for example due to 
> variable cache contents and variable bus contention.
>
> 3. Variable measurement errors, for example truncations or roundings in 
> the count of CPU_Time clock cycles, variable amount of interrupt handling 
> included in the task execution time, etc.
>
> Components 1 and 2 are big problems for worst-case analysis but in my view 
> are not problems for Ada.Execution_Time. In fact, I think that one of the 
> intended uses of Ada.Execution_Time is to help systems make good use of 
> this execution-time variability by letting the system do other useful 
> things when some task happens to execute quicker than its worst-case 
> execution time and leaves some slack in the schedule.
>
> Only component 3 is an "error" in the measured value. This component, and 
> also constant measurement errors if any, are problems for users of 
> Ada.Execution_Time.
>
>> Your discussion of real-time scheduling using this still seems to me to 
>> be more in the realm of academic exercise than something practical. I'm 
>> sure that it works in very limited circumstances,
>
> I think these circumstances have some correlation with the domain for 
> which Ada is or was intended: reliable, embedded, possibly real-time 
> systems. Well, this is a limited niche.
>
>> but those circumstances are getting less and less likely by the year. 
>> Techniques that assume a strong correspondence between these values and 
>> real-time are simply fantasy -- I would hope no one depend on these for 
>> anything of importance.
>
> If this is true, Ada.Execution_Time is useless for real-time systems. 
> Since it was added to the RM for 2005, and is still in the draft for RM 
> 2012, I suppose the ARG majority does not share your view.
>
> Thanks for a frank discussion, and best wishes for 2011!
>
> -- 
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
>       .      @       . 

Re: Ada.Execution_Time

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:m2zkrk62ms.fsf@pushface.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> Your discussion of real-time scheduling using this still seems to me
>> to be more in the realm of academic exercise than something
>> practical. I'm sure that it works in very limited circumstances, but
>> those circumstances are getting less and less likely by the year.
>
> Sounds as if you don't agree with the !problem section of AI-00307?

Pretty much.

Keep in mind that the IRTAW proposals tend to get put into the language 
without much resistance from the majority of the ARG. Most of us don't have 
a enough real-time experience to really be able to have a strong opinion on 
a topic. So we don't generally oppose the basic reason for a proposal.

We simply spend time on polishing the proposals into acceptable RM language 
(which is usually a large job by itself; the proposals tend to be very 
sloppy). Rarely do we object to the proposal itself, in large part because 
we simply don't have enough energy to think in great detail about every 
proposal.

It's best to think of the Annex D stuff as designed and proposed separately 
by a small subgroup. (There's a similar dynamic for some other areas as 
well, numerics coming to mind.) That small subgroup may have a different 
world-view than the rest of us.

                                   Randy.

Re: Ada.Execution_Time

[Brad Moore]

On 03/01/2011 2:33 PM, Randy Brukardt wrote:

 > if you can afford megabucks to have a compiler runtime tailored to
> your target hardware (and compiler vendors love such customers), then you
> probably could find a use for in a hard real-time system.
>
> But the typical off-the-shelf implementation is not going to be useful for
> anything beyond gross guidance. 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.
>
> But it doesn't make sense to assume tight matches 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. So I would agree that
> the existence Ada.Execution_Time really doesn't buy anything for a hard
> real-time system.
>
> I suppose there are others that disagree (starting with Alan Burns). I think
> they're wrong.

> Keep in mind that the IRTAW proposals tend to get put into the language
> without much resistance from the majority of the ARG. Most of us don't have
> a enough real-time experience to really be able to have a strong opinion on
> a topic. So we don't generally oppose the basic reason for a proposal.
>
> We simply spend time on polishing the proposals into acceptable RM language
> (which is usually a large job by itself; the proposals tend to be very
> sloppy). Rarely do we object to the proposal itself, in large part because
> we simply don't have enough energy to think in great detail about every
> proposal.
>
> It's best to think of the Annex D stuff as designed and proposed separately
> by a small subgroup. (There's a similar dynamic for some other areas as
> well, numerics coming to mind.) That small subgroup may have a different
> world-view than the rest of us.

To get a perspective on some of the IRTAW thinking with respect to 
execution time, one might want to have a look at the paper;

"Execution-Time Control For Interrupt Handling", a proposal from the 
most recent IRTAW.

http://www.sigada.org/ada_letters/apr2010/paper3.pdf

The paper expresses an interest in accounting for the time spent
during the handling of interrupts, and tracking this separately
rather than charge the execution time to the current running task,
as is currently the case for most current implementations of 
Ada.Execution_Time.

The intent is to improve the accuracy of execution time measurement
and computing WCET so that task budgets can be tighter allowing for 
higher CPU utilization.


--BradM

Re: Ada.Execution_Time

[Niklas Holsti]

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

Re: Ada.Execution_Time

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:8omvicFgm0U1@mid.individual.net...
...
>> 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.

I was thinking of "profiling" by hand, essentially by adding profiler calls 
to "interesting" points in the code. I have a number of packages which are 
designed for this purpose.

My experience with subprogram level profiling is that it often changes the 
results too much, as the overhead of profiling can be a lot more than the 
overhead of calling small subprograms (like the classic Getters/Setters). 
Perhaps it is just the way that we do it in Janus/Ada (by adding it to 
Enter_Walkback/Exit_Walkback calls that occur at the entrance and exit of 
every subprogram [unless turned off by compiler switch or pragma], which 
mean you don't have to recompile anything other than the main subprogram).

Instruction level profiling (which is used to provide statement profiling) 
is a statistical method, and that has its own problems (its possible to get 
into a situation where the program and profiler operate in sync, such that 
the profiler never sees the execution of some of the code). It's also 
impractical unless you have a very fast timer interrupt or a long time to 
run (machines have gotten too fast for the one I used to use -- it only gets 
a few hits before the compilations are finished...).

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

Right, and that is a problem with both my profiling packages and the 
Janus/Ada subprogram profiler. They both use Calendar.Clock, which is 
obviously oblivious to task switching. Ada.Execution_Time would be a major 
improvement in that respect.

                              Randy.

P.S. I think I owe you a compiler update. Did you read on our mailing list 
about the latest beta of Janus/Ada?