From: Arne Babenhauserheide <arne_bab@web.de>
To: guile-devel@gnu.org
Subject: Re: Immediate doubles (up to 2^256) and rationals coming to Guile 3
Date: Thu, 06 Jun 2019 21:37:22 +0200 [thread overview]
Message-ID: <87h89233pp.fsf@web.de> (raw)
In-Reply-To: <87zhmvaw5p.fsf@netris.org>
[-- Attachment #1: Type: text/plain, Size: 2609 bytes --]
Mark H Weaver <mhw@netris.org> writes:
> I have a working draft implementation that roughly doubles the speed of
> a simple "substract 1.0 until negative" loop for inexact reals less than
> 2^256, compared with current 'master' (near 2.9.2). The same loop for
> exact rationals runs in ~70% of the time compared with current master.
> More importantly, no heap allocation is required when working with these
> immediate values.
> More precisely, large finite doubles with magnitude >= 2^256
> (1.157920892373162e77) must be heap allocated. All other doubles,
> including all Inf/NaNs, are immediate floats, or "iflos".
>
> I call this approach "high-exponent boxing", because instead of using
> the space of ~2^53 NaNs for non-flonum purposes, I use the space of
> finite doubles with binary exponent larger than 255. That's 3/8ths of
> the total space of IEEE doubles. This gives us a total of (3 * 2^61)
> SCM values to use for other things.
…
> I've also implemented immediate exact rationals, or "fixrats". The
> precise rule is that on a 64-bit system, an exact non-integer rational
> is immediate if and only if it can be written with 54 binary digits or
> less. In terms of decimal digits, any rational that can be written with
> 16 decimal digits is immediate, and some that require 17 or 18 decimal
> digits are immediate.
Wow, that’s awesome!
> I should also mention that although the current patch set adds about 4
> bits to the size of all heap tags, e.g. changing most tc7 tags to tc11,
> I can see a way to avoid this: we could tag pairs in the low bits of
> their pointers, instead of in their CARs.
>
> More concretely, 1110 would become the "pair pointer" tag, thus
> eliminating the need for the 1110 "NOT_SCM" tag (a.k.a. the non-pair
> heap object tag). This would eliminate the need to change the heap tags
> at all, and dramatically reduce the size of my patch set. Moreover, the
> low bit would no longer need to be 1, so we would have many more tc7
> tags to work with.
I don’t understand the implications of this, but I realized that I would
love to have info about the sizes of different datastructures in Guile.
I recently started measuring how much memory is required for a record
compared to a list, so I could give people concrete guidelines which
datastructures to use for which algorithm, and for that such low-level
details would be great to have! (or just to know where to read them up —
or which keywords to look for)
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1076 bytes --]
next prev parent reply other threads:[~2019-06-06 19:37 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-06 9:40 Immediate doubles (up to 2^256) and rationals coming to Guile 3 Mark H Weaver
2019-06-06 12:56 ` Mark H Weaver
2019-06-06 19:37 ` Arne Babenhauserheide [this message]
2019-06-12 0:03 ` Mark H Weaver
2019-06-06 20:09 ` tomas
2019-06-07 19:46 ` Ludovic Courtès
2019-06-09 16:56 ` Mark H Weaver
2019-06-09 17:30 ` Mark H Weaver
2019-06-11 8:39 ` Ludovic Courtès
2019-06-11 10:58 ` Mark H Weaver
2019-06-11 12:21 ` Ludovic Courtès
2019-06-11 11:34 ` Mark H Weaver
2019-06-08 1:13 ` Mark H Weaver
2019-06-08 8:07 ` Arne Babenhauserheide
2019-06-08 9:08 ` Chris Vine
2019-06-08 9:46 ` Arne Babenhauserheide
2019-06-08 10:24 ` Chris Vine
2019-06-08 13:12 ` Hans Åberg
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=87h89233pp.fsf@web.de \
--to=arne_bab@web.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).