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/