----- Forwarded message from Dan Weston <[email protected]> -----
Date: Thu, 6 Aug 2009 13:59:45 -0700 From: Dan Weston <[email protected]> To: Henning Thielemann <[email protected]> Cc: Haskell Cafe <[email protected]> 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 > [email protected] > http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe ----- End forwarded message ----- _______________________________________________ Glasgow-haskell-bugs mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
