getCPUTime implementation incorrect?

Evan Laforge qdunkan at
Tue May 31 05:37:37 CEST 2011

I've just noticed that getCPUTime is returning erratic results for me:

GHCi, version 7.0.3:  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Loading package filepath- ... linking ... done.
Prelude> :m System.CPUTime
Prelude System.CPUTime> getCPUTime
Prelude System.CPUTime> getCPUTime
Prelude System.CPUTime> getCPUTime
Prelude System.CPUTime> getCPUTime
Prelude System.CPUTime> getCPUTime
Prelude System.CPUTime> getCPUTime

This is ghc 7.0.3, OS X 10.6.7, and it's the x86_64 version downloaded

So, I looked at the CPUTime.hsc source in the base library, and it
uses CTime to get tv_sec and tv_usec fields from the struct timeval.
Unfortunately, and I never knew this, tv_usec is not time_t, but is
suseconds_t.  On my OS X, these are different types: time_t is 64 bits
but suseconds_t is 32 bits.  After writing my own getCPUTime that uses
Int32 for tv_usec it's back to working again.

But the proper way to do this is probably to introduce CSUSeconds (I'm
guessing it stands for signed microseconds), which I guess means
editing the autoconfig to put a new define in HsBaseConfig.h.  I dont
know anything about autoconfig, but it's probably easy enough for
someone is :)

More information about the Glasgow-haskell-users mailing list