[Haskell-cafe] GHCi timing statistics
ky3 at atamo.com
Thu Mar 5 22:44:44 UTC 2015
> ... 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):
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.
On Fri, Mar 6, 2015 at 5:23 AM, David Rush <kumoyuki at gmail.com> 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 at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe