Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#42 Various bugs in perfcounter handling

Joseph Koshy

The bugs are:

1) Determination of CYCLES_PER_USEC is a configuration
time action. Thus a package built on one machine but
executed on another could end up with an incorrect
scaling factor.

2) gettimeofday(2) offers better precision compared
to times(3), at least on FreeBSD. The exact
frequency of the TSC is available using the
sysctl machdep.tsc_freq on FreeBSD and need not
be estimated as is being done in

3) The TSC's counting rate varies when the CPUs
speed changes (e.g., thermal throttling).
Using TSCs to determine "elapsed time" is

4) In current x86 implementations, TSCs on a
multi-processor system can get out of sync.
The values returned by two successive RDTSC
instructions are not guaranteed to be
monotonically increasing if there process switched
between CPUs in the interim.

See also: clocks(7).


  • Matt Harren
    Matt Harren

    Logged In: YES

    Hi Joseph,

    Yes, it's probably worth getting the CPU frequency from the
    OS instead of guessing. Can you send me a C command that
    will do this on FreeBSD? On Linux and Cygwin, cat
    /proc/cpuinfo should give what we want.

    For the others, there's not much we can do aside from
    turning off the use of hardware counters. Should we make
    software counters (with OCaml's Unix.times) the default in
    CIL? In all of our applications at Berkeley, hardware
    counters are better: we want to time many short operations
    with low overhead. Because the goal is only to compute the
    relative cost of each part of our algorithm, inaccuracy
    isn't so bad, and issue #3 is arguably a benefit of hardware

    -- Matt

  • Joseph Koshy
    Joseph Koshy

    Logged In: YES

    On FreeBSD, the TSC's nominal frequency is available
    via sysctl "machdep.tsc_freq". This can be read from
    the shell using sysctl(8).

    I have attached a C program that uses `sysctlbyname()`.

    FreeBSD 6.x onwards offers an SMP-safe API for accessing
    per-process (i.e., virtualized) hardware performance
    counters (libpmc(3) & hwpmc(4)). However, I feel the
    correct place for adding performance counter based
    measurements in inside O'Caml's runtime, i.e., make
    it a profiling option of some sort. I haven't yet
    looked at how to do this.

  • Joseph Koshy
    Joseph Koshy

    Retrieving TSC frequency in FreeBSD

  • Matt Harren
    Matt Harren

    Logged In: YES
    Originator: NO

    I changed Stats to get the CPU speed from the OS at runtime, so #1 and #2 are now fixed. (We still estimate the speed during configuration in case we can't get the speed at runtime, but this estimate will now usually be ignored). For the others, you'll have to disable hardware timers as specified in the documentation for "--stat" if these are a problem.

  • Matt Harren
    Matt Harren

    • status: open --> closed-fixed