[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8794: (b) make the 64bit-on-32bit the default (if supported)
From: |
Paul Eggert |
Subject: |
bug#8794: (b) make the 64bit-on-32bit the default (if supported) |
Date: |
Mon, 06 Jun 2011 10:54:24 -0700 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Thunderbird/3.1.10 |
[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.
bug#8794: (a) straightforward prerequisite fixes, Paul Eggert, 2011/06/03
bug#8794: (b) make the 64bit-on-32bit the default (if supported), Paul Eggert, 2011/06/03
bug#8794: (c) fix the cons<->int conversions, Paul Eggert, 2011/06/03