[westondan@imageworks.com: Re: [Haskell-cafe] Hugs faster and more reliable than GHC for large list monad 'do' block]

[Don Stewart]

----- Forwarded message from Dan Weston <westondan at imageworks.com> -----

Date: Thu, 6 Aug 2009 13:59:45 -0700
From: Dan Weston <westondan at imageworks.com>
To: Henning Thielemann <lemming at henning-thielemann.de>
Cc: Haskell Cafe <haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] Hugs faster and more reliable than GHC for large
	list monad 'do' block

I assume for the return line, you meant to return a list, not a tuple. ghc 
doesn't support a 600-tuple.
In any case, returning a list, I have verified that this problem exists in 
ghc 6.10.3, for -O0 and -O2.

For -O0, it compiles and links fine, but gives this runtime message:

z: internal error: scavenge: unimplemented/strange closure type -1 @  
0x2a95a8e000
    (GHC version 6.10.3 for x86_64_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
Abort

Maybe it is attempting to unroll these loops, even with -O0?

Dan

Henning Thielemann 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.
>   GHC-6.8.2 finished compilation after two minutes but the program 
> aborted quickly because of a corrupt thunk identifier.
>   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.)
>
> Since the list monad sorts the variable values in lexicographic order  
> which is inappropriate for the considered problem, I recommended the use 
> of control-monad-omega. Luke, I hope this monad can cope with 600  
> variables. :-)
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

----- End forwarded message -----