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 16:20:25 +0300 Message-ID: <83vba754rq.fsf@gnu.org> References: <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> <831tcv6s6f.fsf@gnu.org> <87d1wft8g7.fsf@fencepost.gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1445001676 3231 80.91.229.3 (16 Oct 2015 13:21:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Oct 2015 13:21:16 +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 15:21:06 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 1Zn4wM-0004Bh-T5 for ged-emacs-devel@m.gmane.org; Fri, 16 Oct 2015 15:20:59 +0200 Original-Received: from localhost ([::1]:53618 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn4wL-0002X9-OD for ged-emacs-devel@m.gmane.org; Fri, 16 Oct 2015 09:20:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39523) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn4vv-0002X1-NZ for emacs-devel@gnu.org; Fri, 16 Oct 2015 09:20:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zn4vu-0006xy-OT for emacs-devel@gnu.org; Fri, 16 Oct 2015 09:20:31 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:38746) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn4vq-0006v4-2M; Fri, 16 Oct 2015 09:20:26 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NWB00400EDAEF00@a-mtaout20.012.net.il>; Fri, 16 Oct 2015 16:20:24 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWB003Z3EDZNT80@a-mtaout20.012.net.il>; Fri, 16 Oct 2015 16:20:24 +0300 (IDT) In-reply-to: <87d1wft8g7.fsf@fencepost.gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:191751 Archived-At: > From: David Kastrup > Cc: eggert@cs.ucla.edu, lekktu@gmail.com, emacs-devel@gnu.org > Date: Fri, 16 Oct 2015 12:27:04 +0200 > > >> > 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? > > A change in the size of the Lisp data type. We are talking about the _implementation_ of Lisp data types, i.e. about the underlying C data types. What am I missing on that level? > >> 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. > > Isn't that also changing the size of a Lisp cell? And of integer > arithmetic? Part of it, yes. But since a Lisp cell can hold buffer or string position, what else can you expect? > >> 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. > > But Lisp does. I was talking about C implementation of Lisp 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. > > I repeat: we are talking about a 32-bit binary where restricting buffer > and string size to 32bit offsets would be reasonable and expected. You cannot have full 32-bit offsets without enlarging the width of a Lisp integer. We could use 34 or 35-bit numbers, but that would be slower than using a 64-bit 'long long'. > Choose a C type of your choosing for dealing with buffer offsets, create > aliases for its conversions, and you are good to go. We _have_ chosen: it's a 64-bit 'long long'. What do you suggest to choose instead? Any suggested type should be representable as an Emacs integer. > > And having 61-bit integers for integer arithmetics is also a valuable > > feature. > > 61-bit is some arbitrary junk number. Transparently degrading from > 29-bits to gmp numbers means that there are no arbitrary limits (or at > least you are unlikely to hit them) and the performance for the vast > majority of cases will be 29-bit performance. I don't understand how you intend to "transparently degrade" in the implementation of '+', for example. Are you going to test each argument for whether it fits into 32-bit limits, and if so, invoke 32-bit arithmetics, else 64-bit arithmetics? If so, I'm quite sure the test will steal cycles that will make this slower than just always using 64-bit arithmetics. If you mean something else, can you show some C code that would demonstrate your ideas? > > So the EMACS_INT type will have to be able to support that. > > I don't see why when one can use GMP (which effectively uses the same > kind arithmetic for 61-bit numbers as C does but does not stop there). Because calling a GMP function will most probably yield slower code than if we let the compiler emit a few instructions required for 64-bit arithmetics.