unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Marius Vollmer <mvo@zagadka.de>
Cc: guile-devel@gnu.org
Subject: Re: gmp issues (long)
Date: 26 Feb 2003 00:01:41 +0100	[thread overview]
Message-ID: <87of506k2y.fsf@zagadka.ping.de> (raw)
In-Reply-To: <87d6lgq8jn.fsf@raven.i.defaultvalue.org>

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


  reply	other threads:[~2003-02-25 23:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-24 22:29 gmp issues (long) 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 [this message]
2003-02-25 23:23           ` Rob Browning
2003-02-26 22:07           ` Kevin Ryde
     [not found] <E18ndhx-0007Cm-00@monty-python.gnu.org>
2003-02-25 19:32 ` Stephen Compall
2003-02-25 20:08   ` Rob Browning

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87of506k2y.fsf@zagadka.ping.de \
    --to=mvo@zagadka.de \
    --cc=guile-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).