Hugs faster and more reliable than GHC for large list monad 'do' block

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Hugs faster and more reliable than GHC for large list monad 'do' block

Henning Thielemann

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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hugs faster and more reliable than GHC for large list monad 'do' block

Jason Dagit-2


On Thu, Aug 6, 2009 at 1:39 PM, Henning Thielemann <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hugs faster and more reliable than GHC for large list monad 'do' block

Dan Weston
In reply to this post by Henning Thielemann
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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hugs faster and more reliable than GHC for large list monad 'do' block

Neil Mitchell
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<[hidden email]> 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
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hugs faster and more reliable than GHC for large list monad 'do' block

Henning Thielemann
In reply to this post by Dan Weston

On Thu, 6 Aug 2009, 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.

Maybe that it was a list.

> 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

Indeed, this is also what we got from the executable built by GHC-6.8.2.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hugs faster and more reliable than GHC for large list monad 'do' block

Henning Thielemann
In reply to this post by Jason Dagit-2

On Thu, 6 Aug 2009, Jason Dagit wrote:

>       '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.
Thanks for the pointer. But it means building GHC myself, which I have no
experience with. :-(
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hugs faster and more reliable than GHC for large list monad 'do' block

Dan Weston
In reply to this post by Neil Mitchell
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<[hidden email]> 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
>>> [hidden email]
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>

import Control.Monad(guard)

main = print z

z :: [[Int]]
z    =   do x1  <- [0..3]
            x2  <- [0..3]
            x3  <- [0..3]
            x4  <- [0..3]
            x5  <- [0..3]
            x6  <- [0..3]
            x7  <- [0..3]
            x8  <- [0..3]
            x9  <- [0..3]
            x10 <- [0..3]
            x11 <- [0..3]
            x12 <- [0..3]
            x13 <- [0..3]
            x14 <- [0..3]
            x15 <- [0..3]
            x16 <- [0..3]
            x17 <- [0..3]
            x18 <- [0..3]
            x19 <- [0..3]
            x20 <- [0..3]
            x21 <- [0..3]
            x22 <- [0..3]
            x23 <- [0..3]
            x24 <- [0..3]
            x25 <- [0..3]
            x26 <- [0..3]
            x27 <- [0..3]
            x28 <- [0..3]
            x29 <- [0..3]
            x30 <- [0..3]
            x31 <- [0..3]
            x32 <- [0..3]
            x33 <- [0..3]
            x34 <- [0..3]
            x35 <- [0..3]
            x36 <- [0..3]
            x37 <- [0..3]
            x38 <- [0..3]
            x39 <- [0..3]
            x40 <- [0..3]
            x41 <- [0..3]
            x42 <- [0..3]
            x43 <- [0..3]
            x44 <- [0..3]
            x45 <- [0..3]
            x46 <- [0..3]
            x47 <- [0..3]
            x48 <- [0..3]
            x49 <- [0..3]
            x50 <- [0..3]
            x51 <- [0..3]
            x52 <- [0..3]
            x53 <- [0..3]
            x54 <- [0..3]
            x55 <- [0..3]
            x56 <- [0..3]
            x57 <- [0..3]
            x58 <- [0..3]
            x59 <- [0..3]
            x60 <- [0..3]
            x61 <- [0..3]
            x62 <- [0..3]
            x63 <- [0..3]
            x64 <- [0..3]
            x65 <- [0..3]
            x66 <- [0..3]
            x67 <- [0..3]
            x68 <- [0..3]
            x69 <- [0..3]
            x70 <- [0..3]
            x71 <- [0..3]
            x72 <- [0..3]
            x73 <- [0..3]
            x74 <- [0..3]
            x75 <- [0..3]
            x76 <- [0..3]
            x77 <- [0..3]
            x78 <- [0..3]
            x79 <- [0..3]
            x80 <- [0..3]
            x81 <- [0..3]
            x82 <- [0..3]
            x83 <- [0..3]
            x84 <- [0..3]
            x85 <- [0..3]
            x86 <- [0..3]
            x87 <- [0..3]
            x88 <- [0..3]
            x89 <- [0..3]
            x90 <- [0..3]
            x91 <- [0..3]
            x92 <- [0..3]
            x93 <- [0..3]
            x94 <- [0..3]
            x95 <- [0..3]
            x96 <- [0..3]
            x97 <- [0..3]
            x98 <- [0..3]
            x99 <- [0..3]
            x100 <- [0..3]
            x101 <- [0..3]
            x102 <- [0..3]
            x103 <- [0..3]
            x104 <- [0..3]
            x105 <- [0..3]
            x106 <- [0..3]
            x107 <- [0..3]
            x108 <- [0..3]
            x109 <- [0..3]
            x110 <- [0..3]
            x111 <- [0..3]
            x112 <- [0..3]
            x113 <- [0..3]
            x114 <- [0..3]
            x115 <- [0..3]
            x116 <- [0..3]
            x117 <- [0..3]
            x118 <- [0..3]
            x119 <- [0..3]
            x120 <- [0..3]
            x121 <- [0..3]
            x122 <- [0..3]
            x123 <- [0..3]
            x124 <- [0..3]
            x125 <- [0..3]
            x126 <- [0..3]
            x127 <- [0..3]
            x128 <- [0..3]
            x129 <- [0..3]
            x130 <- [0..3]
            x131 <- [0..3]
            x132 <- [0..3]
            x133 <- [0..3]
            x134 <- [0..3]
            x135 <- [0..3]
            x136 <- [0..3]
            x137 <- [0..3]
            x138 <- [0..3]
            x139 <- [0..3]
            x140 <- [0..3]
            x141 <- [0..3]
            x142 <- [0..3]
            x143 <- [0..3]
            x144 <- [0..3]
            x145 <- [0..3]
            x146 <- [0..3]
            x147 <- [0..3]
            x148 <- [0..3]
            x149 <- [0..3]
            x150 <- [0..3]
            x151 <- [0..3]
            x152 <- [0..3]
            x153 <- [0..3]
            x154 <- [0..3]
            x155 <- [0..3]
            x156 <- [0..3]
            x157 <- [0..3]
            x158 <- [0..3]
            x159 <- [0..3]
            x160 <- [0..3]
            x161 <- [0..3]
            x162 <- [0..3]
            x163 <- [0..3]
            x164 <- [0..3]
            x165 <- [0..3]
            x166 <- [0..3]
            x167 <- [0..3]
            x168 <- [0..3]
            x169 <- [0..3]
            x170 <- [0..3]
            x171 <- [0..3]
            x172 <- [0..3]
            x173 <- [0..3]
            x174 <- [0..3]
            x175 <- [0..3]
            x176 <- [0..3]
            x177 <- [0..3]
            x178 <- [0..3]
            x179 <- [0..3]
            x180 <- [0..3]
            x181 <- [0..3]
            x182 <- [0..3]
            x183 <- [0..3]
            x184 <- [0..3]
            x185 <- [0..3]
            x186 <- [0..3]
            x187 <- [0..3]
            x188 <- [0..3]
            x189 <- [0..3]
            x190 <- [0..3]
            x191 <- [0..3]
            x192 <- [0..3]
            x193 <- [0..3]
            x194 <- [0..3]
            x195 <- [0..3]
            x196 <- [0..3]
            x197 <- [0..3]
            x198 <- [0..3]
            x199 <- [0..3]
            x200 <- [0..3]
            x201 <- [0..3]
            x202 <- [0..3]
            x203 <- [0..3]
            x204 <- [0..3]
            x205 <- [0..3]
            x206 <- [0..3]
            x207 <- [0..3]
            x208 <- [0..3]
            x209 <- [0..3]
            x210 <- [0..3]
            x211 <- [0..3]
            x212 <- [0..3]
            x213 <- [0..3]
            x214 <- [0..3]
            x215 <- [0..3]
            x216 <- [0..3]
            x217 <- [0..3]
            x218 <- [0..3]
            x219 <- [0..3]
            x220 <- [0..3]
            x221 <- [0..3]
            x222 <- [0..3]
            x223 <- [0..3]
            x224 <- [0..3]
            x225 <- [0..3]
            x226 <- [0..3]
            x227 <- [0..3]
            x228 <- [0..3]
            x229 <- [0..3]
            x230 <- [0..3]
            x231 <- [0..3]
            x232 <- [0..3]
            x233 <- [0..3]
            x234 <- [0..3]
            x235 <- [0..3]
            x236 <- [0..3]
            x237 <- [0..3]
            x238 <- [0..3]
            x239 <- [0..3]
            x240 <- [0..3]
            x241 <- [0..3]
            x242 <- [0..3]
            x243 <- [0..3]
            x244 <- [0..3]
            x245 <- [0..3]
            x246 <- [0..3]
            x247 <- [0..3]
            x248 <- [0..3]
            x249 <- [0..3]
            x250 <- [0..3]
            x251 <- [0..3]
            x252 <- [0..3]
            x253 <- [0..3]
            x254 <- [0..3]
            x255 <- [0..3]
            x256 <- [0..3]
            x257 <- [0..3]
            x258 <- [0..3]
            x259 <- [0..3]
            x260 <- [0..3]
            x261 <- [0..3]
            x262 <- [0..3]
            x263 <- [0..3]
            x264 <- [0..3]
            x265 <- [0..3]
            x266 <- [0..3]
            x267 <- [0..3]
            x268 <- [0..3]
            x269 <- [0..3]
            x270 <- [0..3]
            x271 <- [0..3]
            x272 <- [0..3]
            x273 <- [0..3]
            x274 <- [0..3]
            x275 <- [0..3]
            x276 <- [0..3]
            x277 <- [0..3]
            x278 <- [0..3]
            x279 <- [0..3]
            x280 <- [0..3]
            x281 <- [0..3]
            x282 <- [0..3]
            x283 <- [0..3]
            x284 <- [0..3]
            x285 <- [0..3]
            x286 <- [0..3]
            x287 <- [0..3]
            x288 <- [0..3]
            x289 <- [0..3]
            x290 <- [0..3]
            x291 <- [0..3]
            x292 <- [0..3]
            x293 <- [0..3]
            x294 <- [0..3]
            x295 <- [0..3]
            x296 <- [0..3]
            x297 <- [0..3]
            x298 <- [0..3]
            x299 <- [0..3]
            x300 <- [0..3]
            x301 <- [0..3]
            x302 <- [0..3]
            x303 <- [0..3]
            x304 <- [0..3]
            x305 <- [0..3]
            x306 <- [0..3]
            x307 <- [0..3]
            x308 <- [0..3]
            x309 <- [0..3]
            x310 <- [0..3]
            x311 <- [0..3]
            x312 <- [0..3]
            x313 <- [0..3]
            x314 <- [0..3]
            x315 <- [0..3]
            x316 <- [0..3]
            x317 <- [0..3]
            x318 <- [0..3]
            x319 <- [0..3]
            x320 <- [0..3]
            x321 <- [0..3]
            x322 <- [0..3]
            x323 <- [0..3]
            x324 <- [0..3]
            x325 <- [0..3]
            x326 <- [0..3]
            x327 <- [0..3]
            x328 <- [0..3]
            x329 <- [0..3]
            x330 <- [0..3]
            x331 <- [0..3]
            x332 <- [0..3]
            x333 <- [0..3]
            x334 <- [0..3]
            x335 <- [0..3]
            x336 <- [0..3]
            x337 <- [0..3]
            x338 <- [0..3]
            x339 <- [0..3]
            x340 <- [0..3]
            x341 <- [0..3]
            x342 <- [0..3]
            x343 <- [0..3]
            x344 <- [0..3]
            x345 <- [0..3]
            x346 <- [0..3]
            x347 <- [0..3]
            x348 <- [0..3]
            x349 <- [0..3]
            x350 <- [0..3]
            x351 <- [0..3]
            x352 <- [0..3]
            x353 <- [0..3]
            x354 <- [0..3]
            x355 <- [0..3]
            x356 <- [0..3]
            x357 <- [0..3]
            x358 <- [0..3]
            x359 <- [0..3]
            x360 <- [0..3]
            x361 <- [0..3]
            x362 <- [0..3]
            x363 <- [0..3]
            x364 <- [0..3]
            x365 <- [0..3]
            x366 <- [0..3]
            x367 <- [0..3]
            x368 <- [0..3]
            x369 <- [0..3]
            x370 <- [0..3]
            x371 <- [0..3]
            x372 <- [0..3]
            x373 <- [0..3]
            x374 <- [0..3]
            x375 <- [0..3]
            x376 <- [0..3]
            x377 <- [0..3]
            x378 <- [0..3]
            x379 <- [0..3]
            x380 <- [0..3]
            x381 <- [0..3]
            x382 <- [0..3]
            x383 <- [0..3]
            x384 <- [0..3]
            x385 <- [0..3]
            x386 <- [0..3]
            x387 <- [0..3]
            x388 <- [0..3]
            x389 <- [0..3]
            x390 <- [0..3]
            x391 <- [0..3]
            x392 <- [0..3]
            x393 <- [0..3]
            x394 <- [0..3]
            x395 <- [0..3]
            x396 <- [0..3]
            x397 <- [0..3]
            x398 <- [0..3]
            x399 <- [0..3]
            x400 <- [0..3]
            x401 <- [0..3]
            x402 <- [0..3]
            x403 <- [0..3]
            x404 <- [0..3]
            x405 <- [0..3]
            x406 <- [0..3]
            x407 <- [0..3]
            x408 <- [0..3]
            x409 <- [0..3]
            x410 <- [0..3]
            x411 <- [0..3]
            x412 <- [0..3]
            x413 <- [0..3]
            x414 <- [0..3]
            x415 <- [0..3]
            x416 <- [0..3]
            x417 <- [0..3]
            x418 <- [0..3]
            x419 <- [0..3]
            x420 <- [0..3]
            x421 <- [0..3]
            x422 <- [0..3]
            x423 <- [0..3]
            x424 <- [0..3]
            x425 <- [0..3]
            x426 <- [0..3]
            x427 <- [0..3]
            x428 <- [0..3]
            x429 <- [0..3]
            x430 <- [0..3]
            x431 <- [0..3]
            x432 <- [0..3]
            x433 <- [0..3]
            x434 <- [0..3]
            x435 <- [0..3]
            x436 <- [0..3]
            x437 <- [0..3]
            x438 <- [0..3]
            x439 <- [0..3]
            x440 <- [0..3]
            x441 <- [0..3]
            x442 <- [0..3]
            x443 <- [0..3]
            x444 <- [0..3]
            x445 <- [0..3]
            x446 <- [0..3]
            x447 <- [0..3]
            x448 <- [0..3]
            x449 <- [0..3]
            x450 <- [0..3]
            x451 <- [0..3]
            x452 <- [0..3]
            x453 <- [0..3]
            x454 <- [0..3]
            x455 <- [0..3]
            x456 <- [0..3]
            x457 <- [0..3]
            x458 <- [0..3]
            x459 <- [0..3]
            x460 <- [0..3]
            x461 <- [0..3]
            x462 <- [0..3]
            x463 <- [0..3]
            x464 <- [0..3]
            x465 <- [0..3]
            x466 <- [0..3]
            x467 <- [0..3]
            x468 <- [0..3]
            x469 <- [0..3]
            x470 <- [0..3]
            x471 <- [0..3]
            x472 <- [0..3]
            x473 <- [0..3]
            x474 <- [0..3]
            x475 <- [0..3]
            x476 <- [0..3]
            x477 <- [0..3]
            x478 <- [0..3]
            x479 <- [0..3]
            x480 <- [0..3]
            x481 <- [0..3]
            x482 <- [0..3]
            x483 <- [0..3]
            x484 <- [0..3]
            x485 <- [0..3]
            x486 <- [0..3]
            x487 <- [0..3]
            x488 <- [0..3]
            x489 <- [0..3]
            x490 <- [0..3]
            x491 <- [0..3]
            x492 <- [0..3]
            x493 <- [0..3]
            x494 <- [0..3]
            x495 <- [0..3]
            x496 <- [0..3]
            x497 <- [0..3]
            x498 <- [0..3]
            x499 <- [0..3]
            x500 <- [0..3]
            x501 <- [0..3]
            x502 <- [0..3]
            x503 <- [0..3]
            x504 <- [0..3]
            x505 <- [0..3]
            x506 <- [0..3]
            x507 <- [0..3]
            x508 <- [0..3]
            x509 <- [0..3]
            x510 <- [0..3]
            x511 <- [0..3]
            x512 <- [0..3]
            x513 <- [0..3]
            x514 <- [0..3]
            x515 <- [0..3]
            x516 <- [0..3]
            x517 <- [0..3]
            x518 <- [0..3]
            x519 <- [0..3]
            x520 <- [0..3]
            x521 <- [0..3]
            x522 <- [0..3]
            x523 <- [0..3]
            x524 <- [0..3]
            x525 <- [0..3]
            x526 <- [0..3]
            x527 <- [0..3]
            x528 <- [0..3]
            x529 <- [0..3]
            x530 <- [0..3]
            x531 <- [0..3]
            x532 <- [0..3]
            x533 <- [0..3]
            x534 <- [0..3]
            x535 <- [0..3]
            x536 <- [0..3]
            x537 <- [0..3]
            x538 <- [0..3]
            x539 <- [0..3]
            x540 <- [0..3]
            x541 <- [0..3]
            x542 <- [0..3]
            x543 <- [0..3]
            x544 <- [0..3]
            x545 <- [0..3]
            x546 <- [0..3]
            x547 <- [0..3]
            x548 <- [0..3]
            x549 <- [0..3]
            x550 <- [0..3]
            x551 <- [0..3]
            x552 <- [0..3]
            x553 <- [0..3]
            x554 <- [0..3]
            x555 <- [0..3]
            x556 <- [0..3]
            x557 <- [0..3]
            x558 <- [0..3]
            x559 <- [0..3]
            x560 <- [0..3]
            x561 <- [0..3]
            x562 <- [0..3]
            x563 <- [0..3]
            x564 <- [0..3]
            x565 <- [0..3]
            x566 <- [0..3]
            x567 <- [0..3]
            x568 <- [0..3]
            x569 <- [0..3]
            x570 <- [0..3]
            x571 <- [0..3]
            x572 <- [0..3]
            x573 <- [0..3]
            x574 <- [0..3]
            x575 <- [0..3]
            x576 <- [0..3]
            x577 <- [0..3]
            x578 <- [0..3]
            x579 <- [0..3]
            x580 <- [0..3]
            x581 <- [0..3]
            x582 <- [0..3]
            x583 <- [0..3]
            x584 <- [0..3]
            x585 <- [0..3]
            x586 <- [0..3]
            x587 <- [0..3]
            x588 <- [0..3]
            x589 <- [0..3]
            x590 <- [0..3]
            x591 <- [0..3]
            x592 <- [0..3]
            x593 <- [0..3]
            x594 <- [0..3]
            x595 <- [0..3]
            x596 <- [0..3]
            x597 <- [0..3]
            x598 <- [0..3]
            x599 <- [0..3]
            x600 <- [0..3]
            guard (x1+x2+2*x3 >= 0)
            return [x1,x2,x3,x4,x5,x6,x7,x8,x9,x10,x11,x12,x13,x14,x15,x16,x17,x18,x19,x20,x21,x22,x23,x24,x25,x26,x27,x28,x29,x30,x31,x32,x33,x34,x35,x36,x37,x38,x39,x40,x41,x42,x43,x44,x45,x46,x47,x48,x49,x50,x51,x52,x53,x54,x55,x56,x57,x58,x59,x60,x61,x62,x63,x64,x65,x66,x67,x68,x69,x70,x71,x72,x73,x74,x75,x76,x77,x78,x79,x80,x81,x82,x83,x84,x85,x86,x87,x88,x89,x90,x91,x92,x93,x94,x95,x96,x97,x98,x99,x100,x101,x102,x103,x104,x105,x106,x107,x108,x109,x110,x111,x112,x113,x114,x115,x116,x117,x118,x119,x120,x121,x122,x123,x124,x125,x126,x127,x128,x129,x130,x131,x132,x133,x134,x135,x136,x137,x138,x139,x140,x141,x142,x143,x144,x145,x146,x147,x148,x149,x150,x151,x152,x153,x154,x155,x156,x157,x158,x159,x160,x161,x162,x163,x164,x165,x166,x167,x168,x169,x170,x171,x172,x173,x174,x175,x176,x177,x178,x179,x180,x181,x182,x183,x184,x185,x186,x187,x188,x189,x190,x191,x192,x193,x194,x195,x196,x197,x198,x199,x200,x201,x202,x203,x204,x205,x206,x207,x208,x209,x210,x211,x212,x213,x214,x215,x216,x217,x218,x219,x220,x221,x222,x223,x224,x225,x226,x227,x228,x229,x230,x231,x232,x233,x234,x235,x236,x237,x238,x239,x240,x241,x242,x243,x244,x245,x246,x247,x248,x249,x250,x251,x252,x253,x254,x255,x256,x257,x258,x259,x260,x261,x262,x263,x264,x265,x266,x267,x268,x269,x270,x271,x272,x273,x274,x275,x276,x277,x278,x279,x280,x281,x282,x283,x284,x285,x286,x287,x288,x289,x290,x291,x292,x293,x294,x295,x296,x297,x298,x299,x300,x301,x302,x303,x304,x305,x306,x307,x308,x309,x310,x311,x312,x313,x314,x315,x316,x317,x318,x319,x320,x321,x322,x323,x324,x325,x326,x327,x328,x329,x330,x331,x332,x333,x334,x335,x336,x337,x338,x339,x340,x341,x342,x343,x344,x345,x346,x347,x348,x349,x350,x351,x352,x353,x354,x355,x356,x357,x358,x359,x360,x361,x362,x363,x364,x365,x366,x367,x368,x369,x370,x371,x372,x373,x374,x375,x376,x377,x378,x379,x380,x381,x382,x383,x384,x385,x386,x387,x388,x389,x390,x391,x392,x393,x394,x395,x396,x397,x398,x399,x400,x401,x402,x403,x404,x405,x406,x407,x408,x409,x410,x411,x412,x413,x414,x415,x416,x417,x418,x419,x420,x421,x422,x423,x424,x425,x426,x427,x428,x429,x430,x431,x432,x433,x434,x435,x436,x437,x438,x439,x440,x441,x442,x443,x444,x445,x446,x447,x448,x449,x450,x451,x452,x453,x454,x455,x456,x457,x458,x459,x460,x461,x462,x463,x464,x465,x466,x467,x468,x469,x470,x471,x472,x473,x474,x475,x476,x477,x478,x479,x480,x481,x482,x483,x484,x485,x486,x487,x488,x489,x490,x491,x492,x493,x494,x495,x496,x497,x498,x499,x500,x501,x502,x503,x504,x505,x506,x507,x508,x509,x510,x511,x512,x513,x514,x515,x516,x517,x518,x519,x520,x521,x522,x523,x524,x525,x526,x527,x528,x529,x530,x531,x532,x533,x534,x535,x536,x537,x538,x539,x540,x541,x542,x543,x544,x545,x546,x547,x548,x549,x550,x551,x552,x553,x554,x555,x556,x557,x558,x559,x560,x561,x562,x563,x564,x565,x566,x567,x568,x569,x570,x571,x572,x573,x574,x575,x576,x577,x578,x579,x580,x581,x582,x583,x584,x585,x586,x587,x588,x589,x590,x591,x592,x593,x594,x595,x596,x597,x598,x599,x600]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hugs faster and more reliable than GHC for large list monad 'do' block

Jeff Heard
In reply to this post by Jason Dagit-2
Yes, the GHC compiler will work on older kernels and CentOS kernels if
you bootstrap it with 6.4

On Thu, Aug 6, 2009 at 4:51 PM, Jason Dagit<[hidden email]> wrote:

>
>
> On Thu, Aug 6, 2009 at 1:39 PM, Henning Thielemann
> <[hidden email]> 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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hugs faster and more reliable than GHC for large list monad 'do' block

Dan Weston
In reply to this post by 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<[hidden email]> 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
>>>> [hidden email]
>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>>
>>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> [hidden email]
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hugs faster and more reliable than GHC for large list monad 'do' block

Felipe Lessa
In reply to this post by Dan Weston
On Thu, Aug 06, 2009 at 04:25:07PM -0700, Dan Weston wrote:
> > ghc --version
> The Glorious Glasgow Haskell Compilation System, version 6.10.4

Confirmed on Gento amd64 with custom-built GHC from Haskell overlay:

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.4

$ uname -a
Linux kira 2.6.30-tuxonice-r4 #1 SMP Sat Jul 25 15:28:05 BRT 2009 x86_64 Intel(R) Core(TM)2 Duo CPU T5450 @ 1.66GHz GenuineIntel GNU/Linux

--
Felipe.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hugs faster and more reliable than GHC for large list monad 'do' block

Don Stewart-2
felipe.lessa:

> On Thu, Aug 06, 2009 at 04:25:07PM -0700, Dan Weston wrote:
> > > ghc --version
> > The Glorious Glasgow Haskell Compilation System, version 6.10.4
>
> Confirmed on Gento amd64 with custom-built GHC from Haskell overlay:
>
> $ ghc --version
> The Glorious Glasgow Haskell Compilation System, version 6.10.4
>
> $ uname -a
> Linux kira 2.6.30-tuxonice-r4 #1 SMP Sat Jul 25 15:28:05 BRT 2009 x86_64 Intel(R) Core(TM)2 Duo CPU T5450 @ 1.66GHz GenuineIntel GNU/Linux


Someone please file a bug report,

    http://hackage.haskell.org/trac/ghc/newticket?type=bug
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hugs faster and more reliable than GHC for large list monad 'do' block

Henning Thielemann
In reply to this post by Dan Weston

On Thu, 6 Aug 2009, Dan Weston wrote:

> 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.
>>
> No, I am using the latest released ghc:

I think Neil refered to my experiences with GHC-6.4, namely that the 'do'
block could not be compiled, at all.

Neil, thanks for pointing to the ticket. I think it is the problem we
encountered.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hugs faster and more reliable than GHC for large list monad 'do' block

Henning Thielemann
In reply to this post by Don Stewart-2

On Thu, 6 Aug 2009, Don Stewart wrote:

> Someone please file a bug report,
>
>    http://hackage.haskell.org/trac/ghc/newticket?type=bug

Done, Don!

http://hackage.haskell.org/trac/ghc/ticket/3424
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe