[commit: packages/integer-gmp] master: Allocate initial 1-limb mpz_t on the Stack and introduce MPZ# type (7bdcadd)

[Simon Peyton Jones]

| 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.

Interesting!  To risk becoming like a broken record, have you described this overall strategy somewhere?  And linked to that explanation from suitable places?   This "big picture" information is invaluable.

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
| Herbert Valerio Riedel
| Sent: 13 January 2014 21:50
| To: Simon Marlow
| Cc: ghc-devs at haskell.org
| Subject: Re: [commit: packages/integer-gmp] master: Allocate initial 1-
| limb mpz_t on the Stack and introduce MPZ# type (7bdcadd)
| 
| 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/7bdcadda7e884edffb1427f0685493
| f3a2e5c5fa/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.
| 
| Greetings,
|   hvr
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs