From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Making --with-wide-int the default Date: Tue, 17 Nov 2015 10:42:22 -0800 Organization: UCLA Computer Science Department Message-ID: <564B750E.4050305@cs.ucla.edu> References: <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> <83lha1dl87.fsf@gnu.org> <871tbrmeu3.fsf@fencepost.gnu.org> <564A63FB.7040209@cs.ucla.edu> <564AC9EA.5060200@cs.ucla.edu> <22090.61048.541688.443882@a1i15.kph.uni-mainz.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1447785768 20248 80.91.229.3 (17 Nov 2015 18:42:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2015 18:42:48 +0000 (UTC) Cc: Random832 , emacs-devel@gnu.org To: Ulrich Mueller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 17 19:42:40 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 1ZylDC-0000ws-Jm for ged-emacs-devel@m.gmane.org; Tue, 17 Nov 2015 19:42:38 +0100 Original-Received: from localhost ([::1]:60222 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZylDC-0005hg-0n for ged-emacs-devel@m.gmane.org; Tue, 17 Nov 2015 13:42:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38299) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZylD3-0005eX-0L for emacs-devel@gnu.org; Tue, 17 Nov 2015 13:42:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZylCy-0005Yp-Qv for emacs-devel@gnu.org; Tue, 17 Nov 2015 13:42:28 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:52062) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZylCy-0005Y3-L2 for emacs-devel@gnu.org; Tue, 17 Nov 2015 13:42:24 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 63779160192; Tue, 17 Nov 2015 10:42:23 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ueIFJbnFnF-s; Tue, 17 Nov 2015 10:42:22 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id AE916160779; Tue, 17 Nov 2015 10:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 80o8_D5v30Lk; Tue, 17 Nov 2015 10:42:22 -0800 (PST) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 9305F160192; Tue, 17 Nov 2015 10:42:22 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 In-Reply-To: <22090.61048.541688.443882@a1i15.kph.uni-mainz.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 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:194663 Archived-At: On 11/17/2015 01:08 AM, Ulrich Mueller wrote: > A limit imposed by the machine's word size doesn't seem so arbitrary Yes, quite so, and that's what --with-wide-int does: it changes Emacs so that buffer sizes are limited by the machine word size, instead of being limited by some arbitrary truncation of that word size, a truncation not imposed by the machine. > if it can only be surpassed with a significant performance penalty That's too strict and we have never been that strict. On the contrary we regularly make changes to Emacs that impose a significant penalty -- i.e., a penalty that can be measured in a statistically significant way. Even the GNU Coding Standard's guideline about allocating data dynamically can impose a significant performance penalty compared to static allocation, in many cases. But that's OK. We can impose a small (albeit significant) performance penalty if this removes an important arbitrary limit on a data structure size.