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

[Stefan Monnier]

> 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


        Stefan