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

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 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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