From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: "Mattias Engdegård" <mattiase@acm.org>,
"Pip Cet" <pipcet@gmail.com>,
emacs-devel@gnu.org
Subject: Re: Bug#38708: eq vs eql in byte-compiled code
Date: Sat, 04 Jan 2020 13:54:01 -0500 [thread overview]
Message-ID: <jwv5zhr5am7.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <1e0940ff-e418-bafc-66d3-72b562b2c65b@cs.ucla.edu> (Paul Eggert's message of "Wed, 1 Jan 2020 23:52:12 -0800")
> * 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
next prev parent reply other threads:[~2020-01-04 18:54 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-31 15:07 Bug#38708: eq vs eql in byte-compiled code Pip Cet
2019-12-31 15:51 ` Andrea Corallo
2019-12-31 16:05 ` Mattias Engdegård
2019-12-31 17:38 ` Paul Eggert
2020-01-01 12:38 ` Mattias Engdegård
2020-01-02 8:38 ` Paul Eggert
2020-01-02 17:26 ` Mattias Engdegård
2020-01-04 19:55 ` Stefan Monnier
2020-01-22 10:56 ` Mattias Engdegård
2020-01-25 0:59 ` Paul Eggert
2020-01-01 15:45 ` Stefan Monnier
2020-01-02 7:52 ` Paul Eggert
2020-01-02 12:27 ` Pip Cet
2020-01-02 23:12 ` Paul Eggert
2020-01-02 13:48 ` Eli Zaretskii
2020-01-04 18:54 ` Stefan Monnier [this message]
2020-01-04 19:33 ` Paul Eggert
2020-01-04 19:49 ` Stefan Monnier
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwv5zhr5am7.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=eggert@cs.ucla.edu \
--cc=emacs-devel@gnu.org \
--cc=mattiase@acm.org \
--cc=pipcet@gmail.com \
/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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.