On Thu, Aug 6, 2009 at 1:39 PM, Henning Thielemann < lemm...@henning-thielemann.de> 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. Did you try playing with optimization options? I think someone just mentioned that compiling large amounts of static data in GHC is problematic and recommended something like -O0 to prevent GHC from analyzing it. Of course, I wouldn't recommend having unoptimized code, but I'm curious how that changes the results here. > > GHC-6.8.2 finished compilation after two minutes but the program aborted > quickly because of a corrupt thunk identifier. Oh that's icky. > > 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.) I just googled this and found this: http://www.haskell.org/pipermail/glasgow-haskell-users/2008-March/014498.html That was linked from this discussion: http://www.nabble.com/ghc-6.8.2-and-timer_create-error-td16160635.html The second link seems to indicate that it's not a problem of antiquity but instead one related to what configure finds when building GHC for that system. In other words, it should be possible to make a version of GHC locally that doesn't use timer_create and then your student should be good to go. Hope that helps, Jason
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe