Eric Hughes <eric.eh9@[EMAIL PROTECTED]
> writes:
> On Mar 30, 12:59 pm, Robert A Duff <bobd...@[EMAIL PROTECTED]
>
> wrote:
>> The only thing that's guaranteed is I/O behavior, so you have to do
some
>> I/O.
>
> Only? You can also count on task termination, no?
Insofar as it affects I/O, yes. And I suppose you can count on
termination of the program as a whole (that is, if all tasks
terminate, then so should the program).
>...Example code
> below.
>
> Eric
>
>
> with Ada.Real_Time ;
> with Ada.Text_IO ;
> procedure Foo
> is
> Val : Natural := 0 ;
Better make that modular, or this conversion gets confused by the
overflow issue. Oh, never mind, I see you reduced the counts,
and (if I can do that in my head correctly) it won't overflow. ;-)
> Start_T, End_T : Ada.Real_Time.Time ;
> use Ada.Real_Time ;
> begin
> declare
> task Start_Timer ;
> task body Start_Timer is begin
> Start_T := Ada.Real_Time.Clock ;
> end ;
> begin
> null ;
> end ;
>
> declare
> task Compute ;
> task body Compute is begin
> for K in 1 .. 10 loop
> for I in 1 .. 10_000 loop
> Val := Val + I * I ;
> end loop;
> end loop;
> end ;
> begin
> null ;
> end ;
>
> declare
> task End_Timer ;
> task body End_Timer is begin
> End_T := Ada.Real_Time.Clock ;
> end ;
> begin
> null ;
> end ;
>
> Ada.Text_IO.Put_Line( Natural'Image( Val ) ) ;
> Ada.Text_IO.Put_Line( Duration'Image( To_Duration( End_T -
> Start_T ) ) ) ;
>
> end Foo ;
I don't see any language rule that would prevent moving the calculation
of Val before or after the Start_Timer or End_Timer tasks, since they
don't use that value. Or in parallel with them. Or at compile time.
I'm not claiming that real compilers do these transformations
in practise, nor implying that they "should".
I suppose you could reasonably argue that the Clock in Start_Timer must
happen before the one in End_Timer (since a calculation based on those
values is printed out). So I guess it would be wrong to print
a negative time span.
Meaningful benchmarking is hard! ;-)
- Bob
|
