GHCi timing statistics
Hi all - Is it my imagination, or are the statistics printed by GHCi when :set +s has been enabled entirely spurious when SMP parallelism is turned on? I'm trying to determine if I am actually getting any improvement, and - both by the wall clock and by the reported statistics I don't seem to be; however, the reported statistics don't seem to line up very well with the wall clock time. An additional oddity that I've noted is that my algorithm's reference implementation - which simply can't run in parallel due to a foolishly introduced data dependency - still seems to kick 16 CPUs well into the 90%+ utilization range when I have +RTS -N. This code has no parallelism primitives in it whatsoever. I realize that I'm not being terribly rigorous in my description here, but that is partly because I am not sure how to report on this yet. I think my next step is going to be to build a standalone executable to check using the Unix time command. For reference I am running Haskell platform from Debian Jessie on a 16- core amd64 system with 29GiB or RAM available. This would appear to be GHC 7.6.3 :( - d
I believe `:set +s` displays cpu time, not wall-clock time. On Thu, Mar 5, 2015, at 14:23, David Rush wrote:
Hi all -
Is it my imagination, or are the statistics printed by GHCi when :set +s has been enabled entirely spurious when SMP parallelism is turned on? I'm trying to determine if I am actually getting any improvement, and - both by the wall clock and by the reported statistics I don't seem to be; however, the reported statistics don't seem to line up very well with the wall clock time.
An additional oddity that I've noted is that my algorithm's reference implementation - which simply can't run in parallel due to a foolishly introduced data dependency - still seems to kick 16 CPUs well into the 90%+ utilization range when I have +RTS -N. This code has no parallelism primitives in it whatsoever.
I realize that I'm not being terribly rigorous in my description here, but that is partly because I am not sure how to report on this yet. I think my next step is going to be to build a standalone executable to check using the Unix time command.
For reference I am running Haskell platform from Debian Jessie on a 16- core amd64 system with 29GiB or RAM available. This would appear to be GHC 7.6.3 :(
- d
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
... still seems to kick 16 CPUs well into the 90%+ utilization range .... This code has no parallelism primitives in it whatsoever.
You're probably seeing the parallel garbage collector. This is known to
catch the unwary by surprise (see Bryan's comment):
http://www.reddit.com/r/haskell/comments/2m0pv6/force_criterion_to_benchmark...
As an aside: It really would be nice to have some criterion-like ability
from ghci. In fact that would be super cool because none of the other
languages have that.
This is well within the purview of a GSoC and whoever pulls it off bags
bragging rights easily convertible into job offers.
-- Kim-Ee
On Fri, Mar 6, 2015 at 5:23 AM, David Rush
Hi all -
Is it my imagination, or are the statistics printed by GHCi when :set +s has been enabled entirely spurious when SMP parallelism is turned on? I'm trying to determine if I am actually getting any improvement, and - both by the wall clock and by the reported statistics I don't seem to be; however, the reported statistics don't seem to line up very well with the wall clock time.
An additional oddity that I've noted is that my algorithm's reference implementation - which simply can't run in parallel due to a foolishly introduced data dependency - still seems to kick 16 CPUs well into the 90%+ utilization range when I have +RTS -N. This code has no parallelism primitives in it whatsoever.
I realize that I'm not being terribly rigorous in my description here, but that is partly because I am not sure how to report on this yet. I think my next step is going to be to build a standalone executable to check using the Unix time command.
For reference I am running Haskell platform from Debian Jessie on a 16- core amd64 system with 29GiB or RAM available. This would appear to be GHC 7.6.3 :(
- d
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
participants (3)
-
David Rush -
Eric Seidel -
Kim-Ee Yeoh