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

[Neil Mitchell]

Hi

I think the issue you're running in to with 6.4 is this one:
http://hackage.haskell.org/trac/ghc/ticket/830 - known and fixed a
while back.

Thanks

Neil

On Thu, Aug 6, 2009 at 9:59 PM, Dan Weston<westondan at imageworks.com> wrote:
> 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
>