MPS issue job003984

TitleCalling mps_clock frequently is bad for performance
Assigned userGareth Rees
DescriptionThe MPS calls ClockNow to measure the time it is taking, in particular to make the decision about when to return to the mutator in PolicyPollAgain. But this is a wrapper for mps_clock, which in the ANSI plinth calls clock(), which returns CPU time and is slow on some operating systems.

In profiles of benchmarks on macOS, getrusage() which is called by clock(), shows up at about 3% of runtime.

Do we really need CPU time or could we get away with something weaker?
AnalysisThe event clock implementation reads the Time Stamp Counter via the RDTSC instruction, which is very fast. But this is not likely be reliable enough for the use cases noted above.

Wikipedia says [1]: "With the advent of multi-core/hyper-threaded CPUs, systems with multiple CPUs, and hibernating operating systems, the TSC cannot be relied on to provide accurate results. ... There is no promise that the timestamp counters of multiple CPUs on a single motherboard will be synchronized. In such cases, programmers can only get reliable results by locking their code to a single CPU."

Windows documentation says [2]: "We strongly discourage using the RDTSC or RDTSCP processor instruction to directly query the TSC because you won't get reliable results on some versions of Windows, across live migrations of virtual machines, and on hardware systems without invariant or tightly synchronized TSCs."

It looks as if QueryPerformanceCounter [3] may be the right API on Windows, clock_gettime(CLOCK_MONOTONIC) [4] on POSIX systems with realtime extensions, and mach_absolute_time + mach_timebase_info [5] on OS X.

In any case, it seems that we need an abstract interface for monotonic realtime, and then we can try out implementations on different systems. On systems without fast realtime clocks, we may need some kind of proxy estimator, like the mutator allocation "clock" or the trace work "clock".
How foundmanual_test
Evidence[1] <>
[2] <>
[3] <>
[4] <>
[5] <>
Created byGareth Rees
Created on2016-03-12 22:37:28
Last modified byGareth Rees
Last modified on2018-07-05 09:41:12
History2016-03-12 GDR Created.