* gmp issues (long)
@ 2003-02-24 22:29 Rob Browning
2003-02-25 20:54 ` Marius Vollmer
0 siblings, 1 reply; 10+ messages in thread
From: Rob Browning @ 2003-02-24 22:29 UTC (permalink / raw)
I have a version of guile working now using gmp for bignums, and now
that I can test it, there are some issues worth discussing.
Now that I've fixed some bugs confusing the issue (though there may
well be others) it appears that at least in some fairly trivial
testing (and I emphasize *trivial*), gmp doesn't appear faster than
our old implementation.
Given this code:
(define (bench-random-int-op op)
(let loop ((x-vals random-x-values)
(y-vals random-y-values))
(if (pair? x-vals)
(begin
(op (car x-vals)
(car y-vals))
(loop (cdr x-vals)
(cdr y-vals))))))
and a set of 4000000 pre-generated random pairs of bignums, via
(random 1000000000000000000), which all turned out to be bignums, I
get the following results:
$ ./run-benchmark guile-1.6 ./guile-1.7 ./guile-gmp foo.scm
starting trials
("bench-random-op +" "guile-1.6" ((user . 201) (sys . 0) (gc . 90)))
("bench-random-op -" "guile-1.6" ((user . 179) (sys . 1) (gc . 57)))
("bench-random-op *" "guile-1.6" ((user . 219) (sys . 0) (gc . 99)))
("bench-random-op /" "guile-1.6" ((user . 262) (sys . 0) (gc . 114)))
("bench-random-op gcd" "guile-1.6" ((user . 121) (sys . 2) (gc . 44)))
("bench-random-op lcm" "guile-1.6" ((user . 275) (sys . 0) (gc . 116)))
starting trials
("bench-random-op +" "./guile-1.7" ((user . 342) (sys . 1) (gc . 60)))
("bench-random-op -" "./guile-1.7" ((user . 315) (sys . 0) (gc . 59)))
("bench-random-op *" "./guile-1.7" ((user . 352) (sys . 0) (gc . 56)))
("bench-random-op /" "./guile-1.7" ((user . 380) (sys . 0) (gc . 55)))
("bench-random-op gcd" "./guile-1.7" ((user . 266) (sys . 1) (gc . 56)))
("bench-random-op lcm" "./guile-1.7" ((user . 381) (sys . 0) (gc . 55)))
starting trials
("bench-random-op +" "./guile-gmp" ((user . 402) (sys . 1) (gc . 67)))
("bench-random-op -" "./guile-gmp" ((user . 386) (sys . 0) (gc . 63)))
("bench-random-op *" "./guile-gmp" ((user . 436) (sys . 0) (gc . 65)))
("bench-random-op /" "./guile-gmp" ((user . 422) (sys . 0) (gc . 65)))
("bench-random-op gcd" "./guile-gmp" ((user . 387) (sys . 0) (gc . 62)))
("bench-random-op lcm" "./guile-gmp" ((user . 463) (sys . 0) (gc . 64)))
Bear in mind that there may well be mistakes in my code affecting this
result.
The second (perhaps related) issue involves memory use. It turns out
that an mpz_t, which is the GMP integer type, takes up a minimum of 12
bytes (when an int is 4 bytes), and will always be more than that
because that 12 bytes doesn't include any space for the actual digits.
To make this clear, here is what an mpz_t looks like:
typedef struct
{
int _mp_alloc; /* Number of *limbs* allocated and pointed
to by the _mp_d field. */
int _mp_size; /* abs(_mp_size) is the number of limbs the
last field points to. If _mp_size is
negative this is a negative number. */
mp_limb_t *_mp_d; /* Pointer to the limbs. */
} __mpz_struct;
Right now, in the new code a guile gmp bignum is a smob whose data
pointer is an mpz_t*. Including the smob mpz_t pointer itself, this
gives us a minimum size of 24-bytes for an 8-byte bignum on many 32-bit
machines, and 40-bytes on many 64-bit machines :<
It's also worth noting that GMP never shrinks its allocations for a
given mpz_t, even if you change a giant integer to a much smaller
integer via subtraction or similar. However, this may not really
matter much to us since we essentially always create a new value for
the result of an operation.
Our old implementation, on the other hand, if I understand it
correctly, would usually use a minimum of 4 bytes for a bignum,
actually probably 6, and so would require 10 bytes for it's smallest
bignum, including the smob pointer, and could grow in 2 byte
increments (the increment size usually depended on sizeof (unsigned
short)). So with the old implementation, an 8-byte bignum would
probably require about 13-14 bytes, including the smob ptr. Perhaps
more importantly, I believe the old implementation allowed bignums as
small as 6-bytes (10 with ptr). With respect to storage use, this is
a much nicer jump from a 4-byte fixnum than GMP's 20-byte likely
minimum -- which would only get you a 4-byte integer.
So the first question is "Is GMP's minimum usage unacceptable?". If
so, then there are a variety of things we could consider (thanks to
Dale for discussing this with me on irc at some length):
1) possibly scrap GMP altogether.
2) possibly try to use long-longs to provide an intermediate-sized
rep where available, which could use "native" ops. This
intermediate value would require 12-bytes including smob ptr and
provide an 8-byte int (presuming long long == 64-bit).
3) possibly use mpz_t values only for computation, allocating them
on the stack, and use the old "array of shorts" format in the
heap. The big cost here would be conversions to/from mpz_t and
the array of shorts, but we would be able to allocate in 2-byte
increments, with the same minimum sizes we used to have. With
respect to the costs, we'd have to know how much of the cost of
(+ big-x big-y) is currently comprised of non-math operations
i.e. how much would the conversion cost relative to the current
interpretation overhead, etc.
4) possibly use GMP's lower-level ops, and manage the storage of the
GMP mp_limb_t array ourselves. This should allow us to ditch
mpz_t's _mp_alloc int field, and it would probably be safe to
replace the _mp_size field with a short, since I doubt that we'd
ever be likely to overflow long data[MAX_SHORT] digits. (What was
the size limit, if any, on our old bignums?).
The disadvantage here is that there would be much more code to
write by hand -- we'd have to implement bignum
addition/subtraction etc. ourselves from the GMP primitives,
since these primitives only operate on individual _mp_limb_t
values (i.e. digits). We'd have to handle carry, borrow etc.,
ourselves.
The advantage is that these primitives are supposed to be very
fast, since the common ops are likely to be coded in assembly on
most platforms. This approach would get us a minimum bignum
size, including the smob ptr, of 18-bytes for an 8-byte bignum
(10-bytes of overhead), presuming 32-bit arch and 32-bit longs.
The smallest bignum we could represent would be (still presuming
32-bit longs) 4-bytes, which including the smob ptr, would
require 14-bytes of storage.
5) use more than one smob to represent bignums. While there are a
variety of ways this could work, one would be to have something
like:
big-2: mp_limb_t data[2] (12-bytes incl smob ptr on 32-bit)
big-4: mp_limb_t data[4] (16-bytes incl smob ptr on 32-bit)
big-n: mp_limb_t data* (8-bytes + data, incl smob ptr on 32-bit)
This would probably be the best use of space if using GMP, but
it may well complicate the implementation of numbers.c too much
and still has the same drawbacks as (4).
6) try a super-ugly-hack (super-ugly, presuming the GMP people
consider it not-kosher to touch mpz_t internals) where we perform
all our operations as mpz_t values, but then convert them to a
representation like this:
struct _our_mpz { mp_limb_t *data; short size; }
in the heap, after just copying the _mp_d data pointer out of the
result mpz_t, dropping the _mp_alloc value (after checking to be
sure alloc == size -- if not, we'd have to mpz_realloc2), and
then putting their _mp_size into our size (after checking to be
sure it will fit). Then later, when we needed to perform
computations with our representation, we'd copy this data back
into a new mpz_t (mpz_t's are actually 1-element arrays of the
_mpz_struct):
mpz_t tmp;
tmp[0]._mp_alloc = our_mpz->size;
tmp[0]._mp_size = our_mpz->size;
tmp[0]._mp_d = our_mpz->data;
Though this mucks around in the gmp internals, it does have the
distinct advantage of letting us continue to use the high-level
mpz_ interface and still reduce the mpz_t storage overhead from
12-bytes minimum overhead (excluding the smob ptr) to 6 bytes on
32-bit machines, and it requires only *one* in-memory
representation of the integer digits, with no conversions.
If this was an option we had any interest in, it might be worth
discussing with the GMP people. If they don't want people
getting/setting mpz_t internals (even when you think you know
what you're doing) then perhaps they would be willing to
formalize something with similar effect, as part of the API,
i.e. perhaps something like:
void
mpz_compact_and_get_data (mpz_t src, int *size, mpz_limb_t **data);
or similar. This would first make sure that the limb data is
only as large as the integer that the digits represent (i.e. it
would realloc if needed, so that _mp_alloc becomes redundant b/c
_mp_alloc == _mp_size) and then it would return the pointer to
the limbs through *data, and the limb count through *size. This
would then be sufficient for us to manage our conversion.
All of this said, if there are others interested in this issue, I feel
like whatever we do I should probably make the (still not quite
finished -- i.e. random.c's bignum random is a dummy for now) gmp code
available somehow, whether in a CVS branch, patch, or similar so that
other people can test too. I'd rather not have our decision based
solely on my evaluation since it's always possible I goofed somewhere,
either in the implementation or the testing.
Thanks
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: gmp issues (long)
[not found] <E18ndhx-0007Cm-00@monty-python.gnu.org>
@ 2003-02-25 19:32 ` Stephen Compall
2003-02-25 20:08 ` Rob Browning
0 siblings, 1 reply; 10+ messages in thread
From: Stephen Compall @ 2003-02-25 19:32 UTC (permalink / raw)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rob Browning wrote:
replace the _mp_size field with a short, since I doubt that we'd
ever be likely to overflow long data[MAX_SHORT] digits. (What was
the size limit, if any, on our old bignums?).
My first use of GMP in C (after the requisite playing around while
learning) was to try to build up a Godel number as an example in a
project involving semigroups I'm working on (OT). After creating one of
these numbers, I believe the memory usage of the mpz_t & friends was ~5
MB. While this was an abnormal case, it's still far off from 256k.
er....
- --
Stephen Compall - Also known as S11001001
DotGNU `Contributor' -- http://dotgnu.org
Jabber ID: sirian@theoretic.com
To be a hacker, one had to accept the philosophy that writing a
software program was only the beginning. Improving a program was the
true test of a hacker's skills.
-- Sam Williams, "Free as in Freedom"
According to Stallman, improving software programs was secondary to
building them in the first place.
-- Sam Williams, "Free as in Freedom"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+W8TF2AceYinZ4EgRAlZNAJ9P9F9eTsPNfc4jT2sT5eOuVfXmQwCffLBT
vXQI6o8La5tvIOsd07kuFgo=
=Et+6
-----END PGP SIGNATURE-----
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: gmp issues (long)
2003-02-25 19:32 ` gmp issues (long) Stephen Compall
@ 2003-02-25 20:08 ` Rob Browning
0 siblings, 0 replies; 10+ messages in thread
From: Rob Browning @ 2003-02-25 20:08 UTC (permalink / raw)
Cc: guile-devel
Stephen Compall <s11@member.fsf.org> writes:
> Rob Browning wrote:
> replace the _mp_size field with a short, since I doubt that we'd
> ever be likely to overflow long data[MAX_SHORT] digits. (What was
> the size limit, if any, on our old bignums?).
>
> My first use of GMP in C (after the requisite playing around while
> learning) was to try to build up a Godel number as an example in a
> project involving semigroups I'm working on (OT). After creating one of
> these numbers, I believe the memory usage of the mpz_t & friends was ~5
> MB. While this was an abnormal case, it's still far off from 256k.
> er....
Wow. That's a pretty giant number :>
OK. If we want to accomodate numbers this big without a 2-tier hybrid
approach, or something, people should adjust my storage computations
to account for a 4-byte size rather than a 2-byte-size.
Also, just for comparison, and presuming I read the code correctly,
our previous implementation used a 16-bit (plus sign bit) size field,
so moving to a 4-byte size field would be a substantial increase over
what we supported before.
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: gmp issues (long)
2003-02-24 22:29 Rob Browning
@ 2003-02-25 20:54 ` Marius Vollmer
2003-02-25 22:10 ` Rob Browning
0 siblings, 1 reply; 10+ messages in thread
From: Marius Vollmer @ 2003-02-25 20:54 UTC (permalink / raw)
Cc: guile-devel
Rob Browning <rlb@defaultvalue.org> writes:
> The second (perhaps related) issue involves memory use. It turns out
> that an mpz_t, which is the GMP integer type, takes up a minimum of 12
> bytes (when an int is 4 bytes), and will always be more than that
> because that 12 bytes doesn't include any space for the actual digits.
I'm not so much worried about the size of an mpz_t but about the fact
that it requires an additional malloc. 12 bytes is just right for our
double cells, tho. So I would suggest making bignums a double cell
and putting the mpz_t structure into slots 1, 2, and 3. There should
be a test somewhere whether mpz_t really fits into this space. For
now we can just wait for this test to fail, I'd say.
This also removes the additional indirection.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: gmp issues (long)
2003-02-25 20:54 ` Marius Vollmer
@ 2003-02-25 22:10 ` Rob Browning
2003-02-25 22:32 ` Marius Vollmer
0 siblings, 1 reply; 10+ messages in thread
From: Rob Browning @ 2003-02-25 22:10 UTC (permalink / raw)
Cc: guile-devel
Marius Vollmer <mvo@zagadka.de> writes:
> I'm not so much worried about the size of an mpz_t but about the
> fact that it requires an additional malloc.
OK, though an extra 6 bytes of overhead (actually 8 if you include the
fact that mpzs can't allocate in 2-byte-increments) for a 6 byte
integer still concerns me a bit, but perhaps it's OK -- and not
worrying about it will certainly keep the code simpler.
> 12 bytes is just right for our double cells, tho. So I would
> suggest making bignums a double cell and putting the mpz_t structure
> into slots 1, 2, and 3.
Hmm good idea -- didn't think about the fact that that could work this
time...
So is there a way we can memcpy the mpz_t data into the double cell's
three words, or would I need to pass the individual coerced pieces of
the mpz_t to a call to scm_double_cell? i.e. is it OK to presume cell
words are guaranteed to be contiguous, or are you required to go
through the SCM_CELL_N interface?
> There should be a test somewhere whether mpz_t really fits into this
> space. For now we can just wait for this test to fail, I'd say.
What would be the correct formulation of this test? Would this be
right?
sizeof (mpz_t) <= 3 * sizeof (SCM)
or perhaps given scm_double_cell's prototype
sizeof (mpz_t) <= 3 * sizeof (scm_t_bits)
> This also removes the additional indirection.
Yep.
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: gmp issues (long)
2003-02-25 22:10 ` Rob Browning
@ 2003-02-25 22:32 ` Marius Vollmer
2003-02-25 22:50 ` Rob Browning
0 siblings, 1 reply; 10+ messages in thread
From: Marius Vollmer @ 2003-02-25 22:32 UTC (permalink / raw)
Cc: guile-devel
Rob Browning <rlb@defaultvalue.org> writes:
> Marius Vollmer <mvo@zagadka.de> writes:
>
> > I'm not so much worried about the size of an mpz_t but about the
> > fact that it requires an additional malloc.
>
> OK, though an extra 6 bytes of overhead (actually 8 if you include the
> fact that mpzs can't allocate in 2-byte-increments) for a 6 byte
> integer still concerns me a bit, but perhaps it's OK -- and not
> worrying about it will certainly keep the code simpler.
If can reduce the overhead, that would be a good thing of course. But
for the immediate performance problem, I wouldn't worry about it.
> So is there a way we can memcpy the mpz_t data into the double cell's
> three words, or would I need to pass the individual coerced pieces of
> the mpz_t to a call to scm_double_cell?
The way I understand things, GMP does not allocate the mpz_t's itself,
right? Then you should be able to do things like
SCM z = scm_double_cell (bignum_tag, 0, 0, 0);
mpz_init (SCM_CELL_ADDR_1 (z));
where SCM_CELL_ADDR_1 or something similar needs to be added to gc.h.
> i.e. is it OK to presume cell words are guaranteed to be contiguous,
Yes.
> or are you required to go through the SCM_CELL_N interface?
We can make an additional interface (say SCM_CELL_BODY_ADDR) for
treating the last three slots of a double cell as one memory block.
> > There should be a test somewhere whether mpz_t really fits into this
> > space. For now we can just wait for this test to fail, I'd say.
>
> What would be the correct formulation of this test? Would this be
> right?
>
> sizeof (mpz_t) <= 3 * sizeof (SCM)
>
> or perhaps given scm_double_cell's prototype
>
> sizeof (mpz_t) <= 3 * sizeof (scm_t_bits)
Hmm, both look good to me... but the latter is probably more right.
When we have SCM_CELL_BODY_ADDR we can also have
SCM_SIZEOF_DOUBLE_CELL_BODY.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: gmp issues (long)
2003-02-25 22:32 ` Marius Vollmer
@ 2003-02-25 22:50 ` Rob Browning
2003-02-25 23:01 ` Marius Vollmer
0 siblings, 1 reply; 10+ messages in thread
From: Rob Browning @ 2003-02-25 22:50 UTC (permalink / raw)
Cc: guile-devel
Marius Vollmer <mvo@zagadka.de> writes:
> The way I understand things, GMP does not allocate the mpz_t's itself,
> right? Then you should be able to do things like
>
> SCM z = scm_double_cell (bignum_tag, 0, 0, 0);
> mpz_init (SCM_CELL_ADDR_1 (z));
> where SCM_CELL_ADDR_1 or something similar needs to be added to gc.h.
Hmm. Yep, that should work, and would be even faster.
Any easy way we could rearrange things to that we allocate a double
cell without initializing its fields at all (until the mpz_init),
i.e. save the redundant init to 0, without causing trouble with the
GC?
Anyway, thanks for the suggestion. I think I can get this working
pretty quickly so we can see how it fares. It'd be nice if it helps
out noticably on the performance side too...
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: gmp issues (long)
2003-02-25 22:50 ` Rob Browning
@ 2003-02-25 23:01 ` Marius Vollmer
2003-02-25 23:23 ` Rob Browning
2003-02-26 22:07 ` Kevin Ryde
0 siblings, 2 replies; 10+ messages in thread
From: Marius Vollmer @ 2003-02-25 23:01 UTC (permalink / raw)
Cc: guile-devel
Rob Browning <rlb@defaultvalue.org> writes:
> Marius Vollmer <mvo@zagadka.de> writes:
>
> > The way I understand things, GMP does not allocate the mpz_t's itself,
> > right? Then you should be able to do things like
> >
> > SCM z = scm_double_cell (bignum_tag, 0, 0, 0);
> > mpz_init (SCM_CELL_ADDR_1 (z));
>
> > where SCM_CELL_ADDR_1 or something similar needs to be added to gc.h.
>
> Hmm. Yep, that should work, and would be even faster.
>
> Any easy way we could rearrange things to that we allocate a double
> cell without initializing its fields at all (until the mpz_init),
> i.e. save the redundant init to 0, without causing trouble with the
> GC?
Possibly, but we would have to break into the scm_double_cell
abstraction. I.e., we should _not_ provide a function that creates an
unintialized double cell, but we might add another function that
creates a double cell and simultaneously initializes it as a mpz_t.
'mpz_init' is probably very simple and maybe just initializing it with
zeros is all it takes. Maybe the compiler can inline both
scm_double_cell and mpz_init and optimize the redundant stores away.
Also, maybe we can initialize a mpz_t by copying a constant struct
into it (the way POSIX mutxes can be initialized):
mpz_t n = MPZ_INITIALIZER;
We can then have a new function that initializes a double cell from a
12-byte constant struct and then do:
mpz_t scm_i_mpz_initializer = MPZ_INITIALIZER;
...
z = scm_double_cell_from_struct (bignum_tag,
(scm_t_bits *)&scm_i_mpz_initializer);
> Anyway, thanks for the suggestion. I think I can get this working
> pretty quickly so we can see how it fares. It'd be nice if it helps
> out noticably on the performance side too...
Hopefully! :-)
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: gmp issues (long)
2003-02-25 23:01 ` Marius Vollmer
@ 2003-02-25 23:23 ` Rob Browning
2003-02-26 22:07 ` Kevin Ryde
1 sibling, 0 replies; 10+ messages in thread
From: Rob Browning @ 2003-02-25 23:23 UTC (permalink / raw)
Cc: guile-devel
Marius Vollmer <mvo@zagadka.de> writes:
> Possibly, but we would have to break into the scm_double_cell
> abstraction. I.e., we should _not_ provide a function that creates an
> unintialized double cell, but we might add another function that
> creates a double cell and simultaneously initializes it as a mpz_t.
That's probably the easiest thing, though given the fact that we can't
just skip the initialization, for now it's probably best to just leave
any optimizations for later since there will probably also be times
where we'll want to
SCM z = scm_double_cell (bignum_tag, 0, 0, 0);
mpz_init_set (SCM_CELL_ADDR_1 (z), SCM_I_BIG_MPZ (x));
or
mpz_init_set_si (SCM_CELL_ADDR_1 (z), x);
etc.
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: gmp issues (long)
2003-02-25 23:01 ` Marius Vollmer
2003-02-25 23:23 ` Rob Browning
@ 2003-02-26 22:07 ` Kevin Ryde
1 sibling, 0 replies; 10+ messages in thread
From: Kevin Ryde @ 2003-02-26 22:07 UTC (permalink / raw)
Marius Vollmer <mvo@zagadka.de> writes:
>
> 'mpz_init' is probably very simple and maybe just initializing it with
> zeros is all it takes. Maybe the compiler can inline both
> scm_double_cell and mpz_init and optimize the redundant stores away.
Alas mpz_init is a function, it allocates an initial block of memory
for the data.
> mpz_t n = MPZ_INITIALIZER;
That suggestion had been floated another time, but unfortunately it's
not feasible in the current implementation. It's a nice enough idea,
and it's on the gmp tasks list to give more thought to, but actually
doing anything about it is probably a distance away.
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2003-02-26 22:07 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <E18ndhx-0007Cm-00@monty-python.gnu.org>
2003-02-25 19:32 ` gmp issues (long) Stephen Compall
2003-02-25 20:08 ` Rob Browning
2003-02-24 22:29 Rob Browning
2003-02-25 20:54 ` Marius Vollmer
2003-02-25 22:10 ` Rob Browning
2003-02-25 22:32 ` Marius Vollmer
2003-02-25 22:50 ` Rob Browning
2003-02-25 23:01 ` Marius Vollmer
2003-02-25 23:23 ` Rob Browning
2003-02-26 22:07 ` Kevin Ryde
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).