Re: gmp issues (long)

[Marius Vollmer]

Rob Browning <address@hidden> writes:

> Marius Vollmer <address@hidden> 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