From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Making --with-wide-int the default Date: Fri, 13 Nov 2015 12:52:30 +0100 Message-ID: <878u62nmkh.fsf@fencepost.gnu.org> References: <56117F37.9060808@dancol.org> <83oag087gs.fsf@gnu.org> <83oafz70im.fsf@gnu.org> <5620AF43.4050401@cs.ucla.edu> <83k2qn6xfm.fsf@gnu.org> <5620B4FA.1000804@cs.ucla.edu> <83wptojs1r.fsf@gnu.org> <56444C66.8050506@gmx.at> <83r3jugx8g.fsf@gnu.org> <87io56nu0a.fsf@fencepost.gnu.org> <831tbugsaa.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447424710 5823 80.91.229.3 (13 Nov 2015 14:25:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Nov 2015 14:25:10 +0000 (UTC) Cc: rudalics@gmx.at, emacs-devel@gnu.org, rms@gnu.org, jwiegley@gmail.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 13 15:25:04 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 1ZxFHb-0007aV-NR for ged-emacs-devel@m.gmane.org; Fri, 13 Nov 2015 15:24:55 +0100 Original-Received: from localhost ([::1]:53308 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxFHb-00034U-1B for ged-emacs-devel@m.gmane.org; Fri, 13 Nov 2015 09:24:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59185) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxFHX-00034A-0Z for emacs-devel@gnu.org; Fri, 13 Nov 2015 09:24:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZxFHT-0003tD-2Z for emacs-devel@gnu.org; Fri, 13 Nov 2015 09:24:51 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55708) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxFHO-0003rx-9P; Fri, 13 Nov 2015 09:24:42 -0500 Original-Received: from localhost ([127.0.0.1]:41294 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1ZxFHG-0003TW-Q0; Fri, 13 Nov 2015 09:24:35 -0500 Original-Received: by lola (Postfix, from userid 1000) id 66294DFA8F; Fri, 13 Nov 2015 12:52:30 +0100 (CET) In-Reply-To: <831tbugsaa.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 13 Nov 2015 11:30:53 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:194364 Archived-At: Eli Zaretskii writes: >> From: David Kastrup >> Cc: rms@gnu.org, rudalics@gmx.at, emacs-devel@gnu.org, jwiegley@gmail.com >> Date: Fri, 13 Nov 2015 10:11:49 +0100 >> >> Also the cell size doubles, so the Lisp data structures take more >> memory. I think it is quite reasonable _not_ to use wide ints by >> default on architectures with a 32-bit address space. Everything takes >> up more memory, the maximum of virtual address space is something like >> 3GB anyway so it's not like you could hope to increase the amount of >> stuff you could be editing all that much: it is more likely that with >> several buffers loaded at once, you'll _decrease_ the overall amount of >> stuff you can keep loaded into buffers at the same time. > > I think the much large buffer size limit is more important than these > considerations. (Your fears about decreasing the buffer size are > unfounded: I actually tried using 1.5GB buffers, and it worked every > time). "with several buffers loaded at once". If buffer size was so much of a concern, we could represent integers like XEmacs does (basically with a single tag bit), allowing for buffers of 1GB size. When the maximal virtual memory size is something like 3GB, I don't think we'd be missing out on much. People wanting to edit files of several gigabyte size regularly will not be using a 32-bit userland these days anyway. -- David Kastrup