[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making 'eq' == 'eql' in bignum branch

From: Stefan Monnier
Subject: Re: Making 'eq' == 'eql' in bignum branch
Date: Sun, 29 Jul 2018 00:09:18 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

> That is, on a 64-bit host, if the low-order 4 bits of the significand are
> all zero, we encode the floating-point number directly in the Lisp_Object
> (with a tag) so that the Lisp_Object need not be dereferenced and uses zero
> bytes of floating-point heap.

Sounds like an interesting optimization, yes.

> into a special hash-consed table that should use about 16 bytes per entry
> (one for the double, one for the pointer to it).

I assume by "one for the pointer to it" you meant "one for the pointer
to the next member of the same bucket".

> I just checked 'make
> compile-always' and under this proposal a full run would create 95694 Lisp
> floats of which 80048 (84%) would use zero bytes and 15646 (16%) would use
> 16 bytes of floating-point heap.

I'm not sure this is very relevant: for "make compile-always" the
resource cost of floats is irrelevant anyway (as evidenced by the fact
that only 95694 of them are created).

Similarly for bignums: if we only use them to slightly extend the reach
of integers past the 2^29 or 2^63 limit, then it's OK to hash-cons them,
but if/when someone comes around and uses them for computing with large
numbers he might be disappointed at the resulting performance.
Tho maybe it's not that bad: contrarily to operations of floats (which
are basically super-fast on nowadays CPUs) given the non-linear
algorithmic cost of many bignum operations, adding hash-consing to them
wouldn't slow them down that much


reply via email to

[Prev in Thread] Current Thread [Next in Thread]