On Thu, Aug 6, 2009 at 1:39 PM, Henning Thielemann
<lemming@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.)