> ... 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_sequentially_for/

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 <kumoyuki@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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe