From: Paul Eggert <eggert@cs.ucla.edu>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 8794@debbugs.gnu.org, Emacs Development <Emacs-devel@gnu.org>
Subject: bug#8794: (b) make the 64bit-on-32bit the default (if supported)
Date: Mon, 06 Jun 2011 10:54:24 -0700 [thread overview]
Message-ID: <4DED1450.9090605__7519.690731033$1307395075$gmane$org@cs.ucla.edu> (raw)
In-Reply-To: <jwv39jnaub3.fsf-monnier+emacs@gnu.org>
[CC'ing to emacs-devel as this may be of more-general interest.
This is about a plan to widen Emacs integers to 64 bits
(62 bits after tagging) on typical 32-bit hosts.
The original thread is in <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8794>.]
On 06/06/11 07:52, Stefan Monnier wrote:
> let's keep it as an option for now and reconsider this choice for
> Emacs-24.2. We should make a --with-wide-int option for ./configure, tho.
OK, thanks, I'll add that option.
> I want to make sure the drawbacks
> are negligible. How is the memory use impacted by your change in
> "typical" sessions? How is the CPU use impacted in typical sessions?
> Benchmarks running the byte-compiler, Gnus, and any other intensive
> Elisp code would be welcome. Benchmarks testing the impact on
> redisplay performance wold also be welcome.
> I'd hope most of those benchmarks to show very little difference, but so
> far I haven't seen any reports to make confident that this is the case.
This all sounds reasonable. I haven't noticed much difference in
ordinary interactive use, but I haven't done quantitative benchmarks.
Thanks for reviewing it and for taking the time to make these suggestions.
One thing I plan to do while benchmarking is to replace EMACS_INT
with ptrdiff_t whenever the value is known to fit in a 32-bit quantity
on a 32-bit host. This won't make any difference unless --with-wide-int
is used, since EMACS_INT and ptrdiff_t are normally the same (on both
32-bit and 64-bit hosts). But in the --with-wide-int case it should
decrease both memory footprint and register pressure and should be a
measurable win.
I've started an effort to do that, and (as usual) I'm finding more
int-overflow bugs as a side effect. For example, on a 64-bit host,
(copy-sequence (make-bool-vector 17179869184 nil)) crashes Emacs,
due to integer overflow. I plan to fix those bugs independently of
the EMACS_INT->ptrdiff_t change.
next prev parent reply other threads:[~2011-06-06 17:54 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-03 8:43 bug#8794: cons_to_long fixes; making 64-bit EMACS_INT the default Paul Eggert
2011-06-03 10:52 ` Eli Zaretskii
2011-06-03 17:53 ` Paul Eggert
2011-06-03 19:43 ` Eli Zaretskii
2011-06-04 3:05 ` Paul Eggert
2011-06-03 15:54 ` Stefan Monnier
2011-06-03 19:28 ` Paul Eggert
2011-06-05 12:00 ` Stefan Monnier
2011-06-06 8:39 ` Paul Eggert
2011-06-06 16:01 ` Stefan Monnier
2011-06-06 8:39 ` bug#8794: (a) uncontroversial fixes (2011-06-06 version) Paul Eggert
2011-06-06 17:17 ` Stefan Monnier
2011-06-06 8:39 ` bug#8794: (c) fix the cons<->int conversions " Paul Eggert
2011-06-06 17:18 ` Stefan Monnier
2011-06-03 19:29 ` bug#8794: (a) straightforward prerequisite fixes Paul Eggert
2011-06-03 19:29 ` bug#8794: (b) make the 64bit-on-32bit the default (if supported) Paul Eggert
2011-06-06 14:52 ` Stefan Monnier
2011-06-06 17:54 ` Paul Eggert [this message]
2011-06-06 17:54 ` Paul Eggert
2011-06-07 4:21 ` Paul Eggert
2011-06-03 19:30 ` bug#8794: (c) fix the cons<->int conversions Paul Eggert
2016-02-25 6:49 ` Lars Ingebrigtsen
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='4DED1450.9090605__7519.690731033$1307395075$gmane$org@cs.ucla.edu' \
--to=eggert@cs.ucla.edu \
--cc=8794@debbugs.gnu.org \
--cc=Emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/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.