haskell array access
Derek Elkins
ddarius@hotpop.com
Fri, 27 Jun 2003 06:00:29 -0400
On Fri, 27 Jun 2003 09:36:36 +0100
"Simon Peyton-Jones" <simonpj@microsoft.com> wrote:
> Several comments
>
> 1. In Haskell "mod" is a lot more expensive than "rem", because it
> involves careful jiggery pokery with the sign of the result. That's
> why your boxed version was slower (nothing to do with boxing).
Ah. I guess I should've checked the core closer (or more than a quick
glimpse) before making wild assumptions. The (relatively) few other
times I've unboxed by hand, I've found GHC had already done it. I did
think mod might have been a problem, but I didn't expect it to be -that-
much of a difference, hence assuming it was boxing related (I didn't see
a modInt# so I figured remInt# was more or less it, it didn't know how
much less).
> 2. GHC does indeed optimise away the array access if you aren't
> careful, and does in Derek's code. Below is a version that avoids
> doing so, in the same way as the C version, by returning one of the
> values.
Yeah, I was having a very hard time believing it, as the code was
comparable to gcc optimising out the array access (which took ~.6
seconds on my computer).
> 3. Derek correctly points out that gcc does not do array-bound
> checks. GHC should eliminate them, but it's a non-trivial analysis and
> GHC does not currently attempt it. You can always use unsafeAt, as
> Derek does.
I was thinking that that would be nice, but was not surprised that it
wasn't there.
Are there any concoctions of flags/pragmas/techniques to coax GHC into
unrolling a function (or rather an IO computation in this case) a couple
of iterations. There was another (admittedly also noddy) program that I
could get to near gcc, but only by unrolling by hand (though Ian's TH
stuff likely could have done it).