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: Fri, 16 Oct 2015 08:29:11 -0700 Organization: UCLA Computer Science Department Message-ID: <562117C7.5050501@cs.ucla.edu> 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> <83k2qn6xfm.fsf@gnu.org> <5620B4FA.1000804@cs.ucla.edu> <87y4f3tdsr.fsf@fencepost.gnu.org> 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 1445009429 7138 80.91.229.3 (16 Oct 2015 15:30:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Oct 2015 15:30:29 +0000 (UTC) Cc: lekktu@gmail.com, Eli Zaretskii , emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 16 17:30:08 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 1Zn6x7-00009m-5s for ged-emacs-devel@m.gmane.org; Fri, 16 Oct 2015 17:29:53 +0200 Original-Received: from localhost ([::1]:54439 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn6x6-0000aj-Ji for ged-emacs-devel@m.gmane.org; Fri, 16 Oct 2015 11:29:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn6wl-0000XC-Jo for emacs-devel@gnu.org; Fri, 16 Oct 2015 11:29:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zn6wg-0003gr-0e for emacs-devel@gnu.org; Fri, 16 Oct 2015 11:29:31 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:50315) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn6wY-0003XT-6W; Fri, 16 Oct 2015 11:29:18 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8A708160D6B; Fri, 16 Oct 2015 08:29:17 -0700 (PDT) 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 skaC4SgZ3Xxa; Fri, 16 Oct 2015 08:29:16 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8AFA2160DFA; Fri, 16 Oct 2015 08:29:16 -0700 (PDT) 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 zX5hGT2smIFp; Fri, 16 Oct 2015 08:29:16 -0700 (PDT) Original-Received: from [192.168.1.9] (pool-100-32-155-148.lsanca.fios.verizon.net [100.32.155.148]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 6868A160D96; Fri, 16 Oct 2015 08:29:16 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: <87y4f3tdsr.fsf@fencepost.gnu.org> 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:191766 Archived-At: David Kastrup wrote: > I don't it's sensible to configure a non-native default turning > everything into multiple-register operations and obliterating compact > data structures matching the architecture's choices. That's what I was worried about too, before I implemented --with-wide-int. But it turned out to not be a problem. Performance is a bit worse, but I have to measure it to see it. This can be surprising, until you try it. For example, on 32-bit x86, the hot path (cdr of a cons) for the Fcdr function is 9 instructions with a narrow int, and 11 instructions --with-wide-int. Most of those 9 instructions are call overhead and bit-twiddling for runtime tests, and these are the same either way. --with-wide-int causes Fcdr to need one extra instruction to load the extra word of the argument, and one extra instruction to load the extra word of the result, and that's it. If you're interested in squeezing out more performance on a --with-wide-int configuration, you can try the x32 ABI. E.g., see for Debian or Ubuntu. I haven't bothered, though, as x86 is good enough and works everywhere. Of course I'd rather have something with GMP and bignums. But that's considerably more work than --with-wide-int. > a GMP number should be > converted back to a native LISP integer whenever it's small enough > again. Obviously. And one can even work around the = vs eq problem for larger integers. But these are things that are still on the drawing board. --with-wide-int works now.