From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Making --with-wide-int the default Date: Fri, 16 Oct 2015 13:09:28 +0300 Message-ID: <831tcv6s6f.fsf@gnu.org> References: <83h9unukbg.fsf@gnu.org> <54E0DEF8.7020901@dancol> <83egpruiyp.fsf@gnu.org> <54E0FF93.2000104@dancol.org> <5610ED13.1010406@dancol.org> <56117F37.9060808@dancol.org> <83oag087gs.fsf@gnu.org> <83oafz70im.fsf@gnu.org> <5620AF43.4050401@cs.ucla.edu> <8737xbusz1.fsf@fencepost.gnu.org> <83d1wf6v47.fsf@gnu.org> <87pp0ftbmg.fsf@fencepost.gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1444990203 10507 80.91.229.3 (16 Oct 2015 10:10:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Oct 2015 10:10:03 +0000 (UTC) Cc: lekktu@gmail.com, eggert@cs.ucla.edu, emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 16 12:09:54 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zn1xM-0005cZ-Qr for ged-emacs-devel@m.gmane.org; Fri, 16 Oct 2015 12:09:48 +0200 Original-Received: from localhost ([::1]:52424 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn1xM-00051C-9y for ged-emacs-devel@m.gmane.org; Fri, 16 Oct 2015 06:09:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53756) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn1x9-00050n-D7 for emacs-devel@gnu.org; Fri, 16 Oct 2015 06:09:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zn1x8-0000qH-8g for emacs-devel@gnu.org; Fri, 16 Oct 2015 06:09:35 -0400 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:49110) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn1x2-0000om-Dk; Fri, 16 Oct 2015 06:09:28 -0400 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NWB00N005GX9F00@mtaout28.012.net.il>; Fri, 16 Oct 2015 13:08:45 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWB00EUK5IKMU70@mtaout28.012.net.il>; Fri, 16 Oct 2015 13:08:45 +0300 (IDT) In-reply-to: <87pp0ftbmg.fsf@fencepost.gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.184 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:191735 Archived-At: > From: David Kastrup > Cc: eggert@cs.ucla.edu, lekktu@gmail.com, emacs-devel@gnu.org > Date: Fri, 16 Oct 2015 11:18:31 +0200 > > Eli Zaretskii writes: > > >> From: David Kastrup > >> Cc: Eli Zaretskii , Juanma Barranquero > >> , emacs-devel@gnu.org > >> 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. Sorry, I don't foollow: what "appropriate data type"? Would that be 'long long'? If so, that's exactly what we do now, which you say is "going to 64-bit unilaterally". What am I missing? > 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. That's what we have now in 32-bit builds --with-wide-int. So I'm not sure why you mention that as some kind of change related to this discussion. > > 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. I don't understand. C doesn't have dynamic types. If the variable that holds buffer positions needs to support 61-bit offsets, it will have to be a 64-bit integral data type from the get-go. And having 61-bit integers for integer arithmetics is also a valuable feature. So the EMACS_INT type will have to be able to support that.