Prev: Ada.Containers.Doubly_Linked_Lists
Next: Finding out minimal allocation unit
From: Dmitry A. Kazakov on 13 Mar 2007 05:33
On Mon, 12 Mar 2007 15:20:46 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message
> news:1lo7kf2cw2mog$.94hkrwmeyhqy.dlg(a)40tude.net...
>> On Sat, 10 Mar 2007 21:03:41 -0600, Randy Brukardt wrote:

> Janus/Ada certainly does this. It uses the performance counter, and only
> checks the real clock periodically to check for massive changes. Moreover,
> it only re-bases if the time has changed more then 5 minutes in either
> direction from the one determined by the performance counter (else we
> believe the performance counter).
>
> Tom Moran also designed code to fix the "clock leap" problem of the
> performance counter (he had a computer with that problem), and the is also
> part of our Calendar package.

I read somewhere that it is also possible to access the processor ticks
which have resolution of nanoseconds and are very lightweight to read. The
problem is that they fluctuate with the processor frequency. It would be
interesting to try to tie them to slower, but more reliable performance
counters in Ada.Real_Time.Clock, and the later to the system time in
Ada.Calendar.Clock:

ns ticks <-----> perf. counter <-----> sys time
(Ada.Real_Time.Clock) (Ada.Calendar.Clock)

So basically Ada.Real_Time.Clock would read ns ticks and adjust them
according to the accumulated statistics from performance counters. That
should be extremely fast comparing to a call QueryPerformanceCounter.
Ada.Calendar.Clock would do the same but adjust further to the system time.
The drawback is that the statistic would be accumulated in an extra task.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
First  |  Prev  | 
Pages: 1 2 3 4
Prev: Ada.Containers.Doubly_Linked_Lists
Next: Finding out minimal allocation unit