Re: Bug#38708: eq vs eql in byte-compiled code

[Stefan Monnier <monnier@iro.umontreal.ca>]

> * Should we try hash-consing floats too?

A float operation is typically extremely quick (less than 10 CPU
cycles), so the relative overhead of hash-consing them will be very
much higher than the 38% worst case you got on bignums.

IOW, it would be fine for the case where we don't use floats very much,
but it would make float operations too expensive IMO.

> * The attached patch could probably be sped up a bit by supporting
> sets as well as mappings at the low level, since bignum_map is really
> just a set of bignums.  Not sure it's worth the effort, though.

I don't think a "hash-set" would be much smaller than a hash-map, so the
benefit would be fairly small (the ~5 words-per-entry cost of
a hash-table are hash+index+next+key+value, so a set would only save one
of those).

OTOH defining a hash-set as the base structure and then building
hash-table on-top would make it possible to safely export the
"hash-lookup" such that `incf` on a hash-table could perform the lookup
only once.

> From 2cc2d34a4f0fe866714f062dde7bfcc485b3b9e4 Mon Sep 17 00:00:00 2001
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 1 Jan 2020 23:18:58 -0800
> Subject: [PATCH] Hash-cons bignums
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Suggested by Stefan Monnier in:
> https://lists.gnu.org/r/emacs-devel/2020-01/msg00010.html
> This improves performance of ‘make compile-always’
> by about 7% on my platform (x86-64 Ubuntu 18.04.3).

> * src/alloc.c (make_pure_bignum): Remove, as we can’t copy (much
> less purecopy) bignums any more.

Sounds dangerous: it means that pure objects which point to bignums
could end up with dangling pointers because the GC won't see those
pointers and will then GC the corresponding bignum.

I think we should instead *move* the bignum to pure space.


        Stefan