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: Sun, 15 Nov 2015 23:19:00 +0100 Message-ID: <87d1valxd7.fsf@fencepost.gnu.org> 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> <22087.29085.814201.779385@a1i15.kph.uni-mainz.de> <83h9knc96e.fsf@gnu.org> <87lh9zkmwc.fsf@fencepost.gnu.org> <83bnavc6qh.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447708963 26871 80.91.229.3 (16 Nov 2015 21:22:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Nov 2015 21:22:43 +0000 (UTC) Cc: rudalics@gmx.at, ulm@gentoo.org, 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 Mon Nov 16 22:22:41 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 1ZyRET-0007JH-2Y for ged-emacs-devel@m.gmane.org; Mon, 16 Nov 2015 22:22:37 +0100 Original-Received: from localhost ([::1]:49703 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyREN-0008Sy-Gk for ged-emacs-devel@m.gmane.org; Mon, 16 Nov 2015 16:22:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55528) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zy5eN-0002Ma-Rc for emacs-devel@gnu.org; Sun, 15 Nov 2015 17:19:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zy5eM-0005XX-Ld for emacs-devel@gnu.org; Sun, 15 Nov 2015 17:19:55 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41382) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zy5eF-0005WD-IZ; Sun, 15 Nov 2015 17:19:47 -0500 Original-Received: from localhost ([127.0.0.1]:55195 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1Zy5dw-0002hf-LI; Sun, 15 Nov 2015 17:19:29 -0500 Original-Received: by lola (Postfix, from userid 1000) id 6D3B7DFA97; Sun, 15 Nov 2015 23:19:00 +0100 (CET) In-Reply-To: <83bnavc6qh.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 15 Nov 2015 23:06:46 +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:194559 Archived-At: Eli Zaretskii writes: >> From: David Kastrup >> Cc: Ulrich Mueller , rudalics@gmx.at, >> jwiegley@gmail.com, rms@gnu.org, emacs-devel@gnu.org >> Date: Sun, 15 Nov 2015 21:50:27 +0100 >> >> A performance hit by 30% and noticeable increase of memory usage are not >> exactly a bargain for being able to load ridiculously large files into >> an editor on a 32-bit system. >> >> If people had wagonloads of memory to spare, they'd be running 64-bit >> systems in the first place. > > How is this related to what I wrote, may I ask? Ulrich never > mentioned these factors, and I replied to what he wrote. So? You attack Ulrich because he did not sufficiently stress the advantages: >> > Did the option you offer mention the fact that using it enlarges >> > the maximum buffer and string size to (almost) 2GB? If not, it's >> > quite possible that your users simply did not realize what this >> > option would give them in user-level functionality, and treated it >> > as yet another obscure build feature. >> > >> > Also, I must say it sounds strange to me that you wait for user >> > complaints before you decide that some option should be on by >> > default. and more or less state that apparently the only reason for nobody complaining about that setting is that he has omitted to properly describe the option's advantages, not because there would be any actual justification for the chosen default. At the same time you are completely unworried about the _disadvantages_ (which affect every user editing any file, not just the ones loading files larger than 512MByte into memory) not getting mentioned at all. What's wrong with an actual qualified choice based on knowledge of both advantages and disadvantages? > Once again, how is that relevant to what I wrote in my message to > Ulrich? Because you are only interested in having the advantages of wide ints listed. > Look, it's clear that you are against this option. Not at all. I am against enabling it by default on unsuspecting users of 32bit systems. I am fine with enabling it by default on 64bit systems since on those, the gained window of usefulness between 512MB buffers and a reasonable fraction of the virtual memory available to Emacs is potentially quite larger. Also the performance cost of using 64bit entities for everything should be quite less noticeable. I am also fine with making this option an announced and properly described user option to users of a compile-your-own system like Gentoo. If you want a detailed mention of the reason for setting such an option, it does not make sense to omit the drawbacks of doing so: that seems only tailored towards having users make complaints (the absence of which you do not like) rather than an actual informed choice. The desired complaints would likely have the form "why is this option not enabled by default?" and of course there is a valid answer for that as well as a valid answer for why some user would want it enabled by default. > You made that clear several times already; repeating it time and again > doesn't add weight to your opinions. Especially when those opinions > are plugged with no relation whatsoever to what I wrote. Shrug. You don't see a relation, I see one. Others are reading this exchange, so there is a chance that it contributes to forming opinions and eventually may help with making and explaining decisions. -- David Kastrup