On Thu, Feb 25, 2010 at 01:48:50PM +0100, Henning Thielemann wrote:

I don't remember the details anymore, but JHC mail archive says: http://www.haskell.org/pipermail/jhc/2009-November/000670.html

I took a look at them. For the one that was crashing, it seems to be working fine now, so it may have been caused by a bug I have fixed in darcs. The one that gets mysteriously slower is trickier, doubling up the operation causes it not to be inlined which is inhibiting strictness analysis from finding and strictifying a single call, but that one just happens to be right in the middle of the critical loop, requiring a memory allocation whereas in the singular case, the escape analysis was able to move all allocation to the stack. I don't see a quick and dirty optimization that will fix this, but there are some more advanced general purpose optimizations that will catch this case so it will eventually get fixed (probably not in the next point release though). In particular, the loop inversion optimization[1] when at least one of the parameters passed through the loop is used strictly seems like it would be a worthwhile optimization in general and would be particularly good at fixing up this loop. while I am sure gcc is performing said optimization, gcc of course can't take advantage of the exposed strictness to rewrite the allocation, not knowing anything about haskell semantics. Adding some strictness annotations to the original source would also fix this, though I hope jhc itself will be able to catch things like this on its own in the future. John [1]http://en.wikipedia.org/wiki/Loop_inversion -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/