cpuTimePrecision is wrong

changed weight to 5

added Tbug Trac import core libraries labels

changed milestone to %6.10 branch

Can I ask what you're using this value for?

Does anyone happen to know where we can get real values for this for any platforms?

I use getCPUTime to measure the start and end times of some code I want to benchmark and need to know cpuTimePrecision to ensure that time quantisation is not a significant source of error and to normalise the times to some grokable number of "ticks". I don't know what part of windows API should be used for this, but 15.625 mS seems too coarse resolution (at least 4 orders of magnitude too coarse assuming a non-brain dead OS) and the figure given by cpuTimePrecision is in any case wrong.

If it can't be made right then it would be better not to have it at all, or have some function which determines it empirically (you could use unsafePerformIO to keep the existing API I guess).

Unfortunately the mess that is MSDN doesn't make it at all easy to figure out what can or should be done about this. I can't figure it out but perhaps someone else knows.

The queryPerformanceFrequency and queryPerformanceCounter functions seem to offer better resolution, but AFAICT measure "wall clock" time rather than CPU time and may not be available on all windows systems (according to MSDN).

changed milestone to %6.12 branch

changed milestone to %6.12.3

removed milestone

changed weight to 3

Trac metadata

Trac field	Value
Priority	normal → low

changed milestone to %7.0.2

changed milestone to %7.2.1

changed milestone to %7.4.1

changed milestone to %7.6.1

changed weight to 0

Trac metadata

Trac field	Value
Priority	low → lowest

changed milestone to %7.6.2

changed milestone to %7.10.1

Moving to 7.10.1.

assigned to @trac-ekmett

Moving over to new owning component 'Core Libraries'.

Trac metadata

Trac field	Value
Component	libraries/base → Core Libraries

removed milestone

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

changed milestone to %8.0.1

Milestone renamed

changed title from cpuTimePrecision is wrong for me on Windows (XP) to cpuTimePrecision is wrong

The module CPUTime is part of the Haskell 98 report (but not the Haskell 2010 report).

Computation getCPUTime returns the number of picoseconds of CPU time used by the current program. The precision of this result is given by cpuTimePrecision. This is the smallest measurable difference in CPU time that the implementation can record, and is given as an integral number of picoseconds.

getCPUTime

getCPUTime always returns a multiple of 15625000000

http://stackoverflow.com/a/29164665 explains this as follows:

the clock is updated 64 times per second, at the clock tick interrupt. Or in other words 1 / 64 = 0.015625 between ticks

And 0.015625 seconds = 15625000000 picoseconds.

Edit: on my Linux system, the precision of getCPUTime seems to be one microsecond. This makes sence, given that the implementation calls getrusage, which returns a timeval structure containing seconds and microseconds as longs.

/usr/include/x86_64-linux-gnu/bits/time.h:

struct timeval
  {
    __time_t tv_sec;		/* Seconds.  */
    __suseconds_t tv_usec;	/* Microseconds.  */
  };

/usr/include/x86_64-linux-gnu/bits/types.h:

__STD_TYPE __TIME_T_TYPE __time_t;      /* Seconds since the Epoch.  */
__STD_TYPE __SUSECONDS_T_TYPE __suseconds_t; /* Signed count of microseconds.  */

/usr/include/x86_64-linux-gnu/bits/typesizes.h:

#define __TIME_T_TYPE           __SYSCALL_SLONG_TYPE
#define __SUSECONDS_T_TYPE      __SYSCALL_SLONG_TYPE

(to be sure this is really this is really a long:)

/usr/include/x86_64-linux-gnu/bits/typesizes.h:

#if defined __x86_64__ && defined __ILP32__
# define __SYSCALL_SLONG_TYPE   __SQUAD_TYPE
# define __SYSCALL_ULONG_TYPE   __UQUAD_TYPE
#else
# define __SYSCALL_SLONG_TYPE   __SLONGWORD_TYPE
# define __SYSCALL_ULONG_TYPE   __ULONGWORD_TYPE
#endif

/usr/include/x86_64-linux-gnu/bits/types.h:

#define __SLONGWORD_TYPE        long int

(why does it alway have to be this complicated)

cpuTimePrecision

The current implementation of cpuTimePrecision looks at the value of clockTicks = clk_tck() (see #7519 (closed)), converted to picoseconds.

On my Linux system, clk_tck calls sysconf(_SC_CLK_TCK) and always returns 100 (see libraries/base/cbits/sysconf.c, and note that CLK_TCK is only defined when #undef __USE_XOPEN2K, see /usr/include/time.h and /usr/include/x86_64-linux-gnu/bits/time.h).

On Windows, clk_tck seems to always return CLK_TCK = 1000 (see ./opt/ghc-7.10.3/mingw/x86_64-w64-mingw32/include/time.h).

These values don't seem related in any way to the precision of getCPUTime.

From man sysconf:

clock ticks - _SC_CLK_TCK

The number of clock ticks per second. The corresponding vari‐

able is obsolete. It was of course called CLK_TCK. (Note:

the macro CLOCKS_PER_SEC does not give information: it must

equal 1000000.)

According to this stackoverflow comment:

it's the number of times the timer interrupts the CPU for scheduling and other tasks, 100Hz is a common value, higher frequency equals higher timer resolution and more overhead.

Solution ?

Does anyone happen to know where we can get real values for this for any platforms?

I don't know, but on Windows, you can supposedly use GetSystemTimeAdjustment. Some more discussion here: http://lists.ntp.org/pipermail/questions/2011-September/030583.html.

But maybe we should just give up, since CPUTime is not part of the Haskell report anymore. Keep the function cpuTimePrecision for backward compatibility, but change the docstring to say what it really does: return the number of picoseconds between clock ticks.

This issue was also discussed in this thread: https://mail.haskell.org/pipermail/libraries/2008-February/009305.html

Trac metadata

Trac field	Value
TypeOfFailure	- → OtherFailure
CC	- → ekmett
Operating system	Windows → Unknown/Multiple
Architecture	x86_64 (amd64) → Unknown/Multiple

Trac metadata

Trac field	Value
TypeOfFailure	OtherFailure → DocumentationBug

But maybe we should just give up, since CPUTime is not part of the Haskell report anymore. Keep the function cpuTimePrecision for backward compatibility, but change the docstring to say what it really does: return the number of picoseconds between clock ticks.

This sounds reasonable to me.

For the record, I believe the relevant Linux interface here is clock_getres (which itself only has nanosecond resolution at best).

added Plow label

cpuTimePrecision is wrong

Child items 0

Activity

getCPUTime

cpuTimePrecision

Solution ?