Re: Ada.Execution_Time

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

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