I've just noticed that getCPUTime is returning erratic results for me: GHCi, version 7.0.3: http://www.haskell.org/ghc/ :? 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-1.2.0.0 ... linking ... done. Prelude> :m System.CPUTime Prelude System.CPUTime> getCPUTime 9696631700340362000000 Prelude System.CPUTime> getCPUTime 1333572622260398592000000 Prelude System.CPUTime> getCPUTime 21577331579851694000000 Prelude System.CPUTime> getCPUTime 21577331579861838000000 Prelude System.CPUTime> getCPUTime 1061231477620269514000000 Prelude System.CPUTime> getCPUTime 9965140170836829000000 This is ghc 7.0.3, OS X 10.6.7, and it's the x86_64 version downloaded from http://www.haskell.org/ghc/download_ghc_7_0_3 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 :)