[GHC] #14714: RTS Timings on windows are somewhat unreliable

#14714: RTS Timings on windows are somewhat unreliable
-------------------------------------+-------------------------------------
Reporter: AndreasK | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 8.2.2
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: None/Unknown
Unknown/Multiple |
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
Times given by the RTS are very unreliable on small scales.
Part of that is I assume simply the lack of precision.
But CPU Time often is reported higher than wall clock time (using the
single threaded RTS) as well.
Examples:
{{{
$ ./binary-trees 12 +RTS -t
stretch tree of depth 13 check: -1
...
long lived tree of depth 12 check: -1
<

#14714: RTS Timings on windows are somewhat unreliable -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: Component: Runtime System | Version: 8.2.2 Resolution: wontfix | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * status: new => closed * component: Compiler => Runtime System * resolution: => wontfix * os: Unknown/Multiple => Windows * priority: normal => low Comment: There seems to be no way around this. The windows cpuTime information comes from `GetProcessTimes` while the elapsed time uses `QueryPerformanceCounter`. GetProcessTimes has a lower accuracy which leads to these result for cpuTime. QueryProcessCycleTime would have better resolution but measures cycles not time. This works fine for benchmarking where one would disable frequency scaling anyway. But It would lead to confusing results otherwise. Marking this as wontfix for now as I don't think there is a better solution available currently. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14714#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC