Re: Ada.Execution_Time

[BrianG <briang000@gmail.com>]

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