Re: [commit: packages/integer-gmp] master: Allocate initial 1-limb mpz_t on the Stack and introduce MPZ# type (7bdcadd)
On 13/01/14 13:25, git@git.haskell.org wrote:
Repository : ssh://git@git.haskell.org/integer-gmp
On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/7bdcadda7e884edffb1427f0685493f3a2...
---------------------------------------------------------------
commit 7bdcadda7e884edffb1427f0685493f3a2e5c5fa Author: Herbert Valerio Riedel <hvr@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. Cheers, Simon
On 2014-01-13 at 21:57:03 +0100, Simon Marlow wrote:
On 13/01/14 13:25, git@git.haskell.org wrote:
Repository : ssh://git@git.haskell.org/integer-gmp
On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/7bdcadda7e884edffb1427f0685493f3a2...
---------------------------------------------------------------
commit 7bdcadda7e884edffb1427f0685493f3a2e5c5fa Author: Herbert Valerio Riedel <hvr@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
| 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@haskell.org] On Behalf Of | Herbert Valerio Riedel | Sent: 13 January 2014 21:50 | To: Simon Marlow | Cc: ghc-devs@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@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@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@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs
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@git.haskell.org wrote:
Repository : ssh://git@git.haskell.org/integer-gmp
On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/7bdcadda7e884edffb1427f0685493f3a2...
---------------------------------------------------------------
commit 7bdcadda7e884edffb1427f0685493f3a2e5c5fa Author: Herbert Valerio Riedel <hvr@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
participants (3)
-
Herbert Valerio Riedel -
Simon Marlow -
Simon Peyton Jones