[Haskell-cafe] C-like Haskell
lennart at augustsson.net
Thu Jan 29 04:06:14 EST 2009
I had a quick look at the code for
loop :: Int64 -> Int64 -> Int64
loop i r = if i == 0 then r else loop (i-1) (r+1)
It's quite bad. It's full of C calls.
It would be much better to do what gcc does and treat Int64 as a
primitive type, and just insert C calls for the tricky operations,
On Thu, Jan 29, 2009 at 3:17 AM, Duncan Coutts
<duncan.coutts at worc.ox.ac.uk> wrote:
> On Wed, 2009-01-28 at 20:42 -0500, Ross Mellgren wrote:
>> Very possibly -- I'm on a mac so no prebuilt 64-bit binary. I'm not
>> good enough at reading core to tell, but I can tell from the core that
>> it's calling out to external C functions to do the 64-bit math.
> Right, that'll make it really slow but does not explain the allocations.
>> It could be that it's crossing over from machine register size to
>> managed heap object and so without additional help on 32-bit it wants
>> to allocate thunks.
> If it's using Int64 then there's no transition, that only happens with
> Integer (which is always heap allocated anyway).
> The sum parameter in the inner loop is an accumulating parameter that is
> not inspected until the final value is returned. In the case of the
> simple direct Int64 implementation the strictness analyser does notice
> that it really is strict so can be evaluated as we go along. I bet
> that's the source of the problem, that for the indirect Int64 impl used
> on 32bit machines the strictness analyser does not discover the same
> property. So that would explain the allocations.
> It's worth investigating the indirect Int64 implementation to see if
> this could be improved.
>> Does your core indicate that it's making a bunch of external __ccalls?
> No, it's all unboxed Int# types and primitive # operations. Lovely. In
> particular the inner loop is all unboxed types with no allocations.
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe