[Haskell-cafe] Re: C-like Haskell

Simon Marlow marlowsd at gmail.com
Fri Jan 30 07:25:26 EST 2009


Lennart Augustsson wrote:
> 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,
> like division.

Yeah, somebody should fix that.

Cheers,
	Simon


> 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.
>>
>> Duncan
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>



More information about the Haskell-Cafe mailing list