GNU bug report logs - #42147
28.0.50; pure vs side-effect-free, missing optimizations?

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, Andrea Corallo <andrea_corallo <at> yahoo.it>, 42147 <at> debbugs.gnu.org
Subject: bug#42147: Hash-consing bignums (was: bug#42147: 28.0.50; pure vs side-effect-free, missing optimizations?)
Date: Fri, 03 Jul 2020 09:39:10 -0400

> Hash-consing bignums may be a good idea (I'm neutral on the idea), but there
> could be a reason why it isn't very commonly seen in other runtimes; perhaps
> they have more efficient GCs (generational and/or incremental), but Emacs
> would benefit (a lot) from that, too.

I don't think the GC performance has very much to do with it.  I think
it's simply that hash-consing bignums has a negative effect on the
performance of bignum operations (by a constant factor which
I guesstimate to be around 50%).  For a general purpose language this
can be significant.  In my opinion for Emacs Lisp this is irrelevant
(we've lived without real bignums (using slow emulations instead) for
more than 30 years, so even half-speed bignums are much better than what
we really need).

It could become relevant if/when we replace wide-int with bignums, in
which case performance of "small bignums" could be fairly important.
But I'm not sure if we'll ever want to replace wide-ints with bignums
(tho I do hope we will).

> In any case, it's a one-way decision: once we guarantee eq to provide
> numerical equality (whether by hash-consing or otherwise), there is no
> way back.

Yes, once you've had the taste of clean semantics it's hard to go back ;-)


        Stefan "in favor of redefining `eq` to `eql`"

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.