[Haskell-cafe] Hugs faster and more reliable than GHC for large list monad 'do' block

Jason Dagit dagit at codersbase.com
Thu Aug 6 16:51:17 EDT 2009

On Thu, Aug 6, 2009 at 1:39 PM, Henning Thielemann <
lemming at henning-thielemann.de> wrote:

> Today a student has shown me a program that consists of a large 'do' block
> for the list monad. The program looks like
>   do x1 <- [0..3]
>      x2 <- [0..2]
>      ...
>      x600 <- [0..5]
>      guard (x1+x2+2*x3 >= 0)
>      ...
>      return (x1,x2,....,x600)
> It was actually generated by another program. The results were:
>  GHC-6.4 was not able to compile that program at all, because it stopped
> because of memory exhaustion.

Did you try playing with optimization options?  I think someone just
mentioned that compiling large amounts of static data in GHC is problematic
and recommended something like -O0 to prevent GHC from analyzing it.  Of
course, I wouldn't recommend having unoptimized code, but I'm curious how
that changes the results here.

>  GHC-6.8.2 finished compilation after two minutes but the program aborted
> quickly because of a corrupt thunk identifier.

Oh that's icky.

>  GHC-6.10 not yet tested.
>  Hugs-2006 executed the program without complaining and showed the first
> result after a few seconds: (0,0,0,0,0,...,0).
> Eventually the program must run on a Linux cluster with a not up-to-date
> Linux kernel, that is, I suspect newer GHC versions cannot be used due to
> the 'timer_create' problem. (At least, the 'cabal' executable that I
> generated with a GHC-6.8.2 had this problem when running on the cluster
> which reminded me on the problems with GHC-6.8 itself running on older Linux
> kernels.)

I just googled this and found this:
That was linked from this discussion:

The second link seems to indicate that it's not a problem of antiquity but
instead one related to what configure finds when building GHC for that
system.  In other words, it should be possible to make a version of GHC
locally that doesn't use timer_create and then your student should be good
to go.

Hope that helps,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090806/78f33441/attachment-0001.html

More information about the Haskell-Cafe mailing list