[commit: packages/integer-gmp] master: Allocate initial 1-limb mpz_t on the Stack and introduce MPZ# type (7bdcadd)
Simon Marlow
marlowsd at gmail.com
Thu Jan 16 09:26:35 UTC 2014
On 13/01/14 21:49, Herbert Valerio Riedel wrote:
> On 2014-01-13 at 21:57:03 +0100, Simon Marlow wrote:
>> On 13/01/14 13:25, git at git.haskell.org wrote:
>>> Repository : ssh://git@git.haskell.org/integer-gmp
>>>
>>> On branch : master
>>> Link : http://ghc.haskell.org/trac/ghc/changeset/7bdcadda7e884edffb1427f0685493f3a2e5c5fa/integer-gmp
>>>
>>>> ---------------------------------------------------------------
>>>
>>> commit 7bdcadda7e884edffb1427f0685493f3a2e5c5fa
>>> Author: Herbert Valerio Riedel <hvr at gnu.org>
>>> Date: Thu Jan 9 00:19:31 2014 +0100
>>>
>>> Allocate initial 1-limb mpz_t on the Stack and introduce MPZ# type
>>>
>>> We now allocate a 1-limb mpz_t on the stack instead of doing a more
>>> expensive heap-allocation (especially if the heap-allocated copy becomes
>>> garbage right away); this addresses #8647.
>>
>> While this is quite cool (turning some J# back into S#), I don't
>> understand why you've done it this way. Couldn't it be done in the
>> Haskell layer rather than modifying the primops? The ByteArray# has
>> already been allocated by GMP, so you don't lose anything by returning
>> it to Haskell and checking the size there. Then all the
>> DUMMY_BYTEARRAY stuff would go away.
>
> Actually there isn't always a ByteArray# allocated; the patch got rid of
> all mpz_init() calls for the result-mpz_t (which would have allocated
> 1-limb ByteArray#s);
>
> Now instead, the single word-sized limb that would have been
> heap-allocated via mpz_init() before calling the actual GMP operation,
> is allocated on the stack instead, and only if the GMP routines need to
> grow the passed in mpz_t's an actual ByteArray# is allocated.
>
> That's why I needed a way to return either a single stack-allocated limb
> (hence the word#), *or* an heap-allocated 'ByteArray#', which lead to
> the MPZ# 3-tuple.
Ok, I see now. Thanks for the explanation.
Cheers,
Simon
More information about the ghc-devs
mailing list