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
next prev parent 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).