emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making --with-wide-int the default


From: David Kastrup
Subject: Re: Making --with-wide-int the default
Date: Fri, 16 Oct 2015 11:18:31 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: David Kastrup <address@hidden>
>> Cc: Eli Zaretskii <address@hidden>, Juanma Barranquero
>> <address@hidden>, address@hidden
>> Date: Fri, 16 Oct 2015 10:18:26 +0200
>> 
>> Instead of going to 64-bit unilaterally it would seem to make more sense
>> to me to degrade gracefully into gmp.
>
> How can GMP help extend the maximum size of buffers and strings beyond
> what a 32-bit EMACS_INT allows?

By choosing an appropriate data type for representing buffer/string
sizes in C and converting back-and-forth from the Lisp type as needed.
Pretty much the same way we do it now.  I think it would be a reasonable
restriction to keep to 2GB size of strings and buffers when working with
a 32bit executable.  That's what people expect on a 32-bit architecture.

> And how can GMP be faster than (or even close to) the native 64-bit
> integral types supported by the C compiler?

GMP will not get to see the vast majority of numbers passing through
Emacs, and on a 32-bit system 32-bit integral types will be faster than
64-bit integral types.

When you are editing gigabyte files, at some point of time, the Lisp
representation of the respective offsets in the high part of the buffer
will become the responsibility of GMP, yes.  I'm not worried about that.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]