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

[Dan Weston]

No, I am using the latest released ghc:

 > ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.4

[ z.hs is attached ]

 > time ghc -O0 --make z.hs
[1 of 1] Compiling Main             ( z.hs, z.o )
Linking z ...
14.422u 0.630s 0:15.10 99.6%    0+0k 0+0io 0pf+0w

 > time ./z
z: internal error: scavenge: unimplemented/strange closure type -1 @ 
0x2a95a8e000
     (GHC version 6.10.4 for x86_64_unknown_linux)
     Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
Abort
0.007u 0.007s 0:00.02 0.0%      0+0k 0+0io 0pf+0w

Dan

Neil Mitchell wrote:
> 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
>>
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: z.hs
Type: text/x-haskell
Size: 19108 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090806/ce9fe8bc/z.bin