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

[Dan Weston]

I should clarify that this was done on an older kernel (bootstrapped 
from ghc 6.4 as Jeff Heard suggested), in case that makes any difference:

Main memory size: 7971 Mbytes
1 GenuineIntel Intel(R) Xeon(TM) CPU 3.40GHz processor
Swap Size: 2047 Mbytes
Num Processors: 1
Processor Type:                   Intel(R) Xeon(TM) CPU 3.40GHz x64
Clock Speed: 3400 MHZ
OS: Linux 2.6.9-42.0.3.EL.spi
OS-VERSION: CentOS release 4.4 (Final)
OS-HW: x86_64

Dan Weston wrote:
> 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
>>>
>>