RFC: Time Library 0.2

[Simon Marlow]

On 03 November 2005 04:24, John Meacham wrote:

> On Wed, Nov 02, 2005 at 08:19:56PM -0800, John Meacham wrote:
>> On Wed, Nov 02, 2005 at 11:43:16AM +0100, Sebastian Sylvan wrote:
>>> On 11/2/05, Ashley Yakeley <ashley at semantic.org> wrote:
>>>> In article
>>>> <3d96ac180511010738h1e3c5206vba7318e724e3cb48 at mail.gmail.com>,
>>>>  Sebastian Sylvan <sebastian.sylvan at gmail.com> wrote:
>>>> 
>>>>> Which is why I requested a separate function which just gives the
>>>>> picosecs since startup (or something).
>>>> 
>>>> That's what getCPUTime in System.CPUTime does.
>>> 
>>> No it isnt'. getCPUTime gives the.. uh.. CPU-time :-)
>>> 
>>> If all my program does is sleep, waiting for other programs to
>>> release some resource, then getCPUTime will return zero.
>>> 
>>> What I'm requesting is a function which gives the number of
>>> wall-clock picos seconds since startup, which could be used for all
>>> sorts of real-time simulations etc.
>> 
>> is this true? I always thought that is what getCPUTime was supposed
>> to mean, a reading from the tsc on x86 machines for instance and
>> distinct from the unix notion of 'cputime'.
> 
> hmm.. looking at the report, you are correct. hmm.. perhaps we need
> another function to read the tsc-equivalent on various CPUs.

Reading the TSC doesn't work well on SMP machines, because the
individual CPU counters probably aren't synchronised.  As it happens,
I've just been struggling with exactly this - I need to get the
per-thread CPU time, and the implementation in glibc (clock_gettime())
uses the TSC, which gives bogus results.  I hope they'll fix this at
some point.

Cheers,
	Simon