[Haskell-cafe] Hugs faster and more reliable than GHC for large
list monad 'do' block
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
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
Hope that helps,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe