From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Making 'eq' == 'eql' in bignum branch Date: Fri, 10 Aug 2018 13:48:10 -0700 Organization: UCLA Computer Science Department Message-ID: <5aa7de0f-9b1a-2678-676a-4e4ef5670d77@cs.ucla.edu> References: <29f933ac-a6bf-8742-66a7-0a9d6d3e5a88@disroot.org> <877em1cb0i.fsf@tromey.com> <765767b2-d2e5-a9a6-f724-d58ecf4847bb@cs.ucla.edu> <76081b5d-8c10-0a37-2c97-d4864c0faa80@cs.ucla.edu> <09153aed-361d-4f82-d9ac-b502314769ae@cs.ucla.edu> <83600yt8ih.fsf@gnu.org> <83h8kgpnir.fsf@gnu.org> <7dd71d44-69bc-3adf-576b-8b9e31184a24@cs.ucla.edu> <83d0v4p1si.fsf@gnu.org> <827beb76-3adf-f2f9-33b1-1baee55680cd@cs.ucla.edu> <83wotbo04h.fsf@gnu.org> <77d5f8b0-2277-b28e-8565-d3e00c411795@cs.ucla.edu> <83ftzyocry.fsf@gnu.org> <837elao4bo.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1533934020 16099 195.159.176.226 (10 Aug 2018 20:47:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 10 Aug 2018 20:47:00 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 Cc: eliz@gnu.org, Stefan Monnier , emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 10 22:46:56 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1foEJA-0003yj-Fm for ged-emacs-devel@m.gmane.org; Fri, 10 Aug 2018 22:46:52 +0200 Original-Received: from localhost ([::1]:57953 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1foELG-0008Pb-Ic for ged-emacs-devel@m.gmane.org; Fri, 10 Aug 2018 16:49:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53226) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1foEKc-0008PW-QN for emacs-devel@gnu.org; Fri, 10 Aug 2018 16:48:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1foEKb-0002ND-Nx for emacs-devel@gnu.org; Fri, 10 Aug 2018 16:48:22 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:55692) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1foEKX-0002Jq-V3; Fri, 10 Aug 2018 16:48:18 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6B9E8161050; Fri, 10 Aug 2018 13:48:16 -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 hHY8B7DoTxgE; Fri, 10 Aug 2018 13:48:15 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 662361610C6; Fri, 10 Aug 2018 13:48:15 -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 pLggpavaHPiz; Fri, 10 Aug 2018 13:48:15 -0700 (PDT) Original-Received: from [192.168.1.9] (unknown [47.154.30.119]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 06B8A161050; Fri, 10 Aug 2018 13:48:14 -0700 (PDT) In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:228395 Archived-At: Pip Cet wrote: > That sounds promising! However, I wonder whether NaN-boxing isn't the > right thing to do once we have bignums (on platforms that support it, > by limiting pointers to 48 bits like x86-64 does). I worry that NaN-boxing is less portable. Won't it have problems, for example, on a system that uses ASLR and where randomized virtual addresses exceed the 2**52 limit? I suppose, though, that if all the Javascript guys are doing NaN boxing then we can live in their shadow. > the only real disadvantage is Qnil is no > longer an all-zeroes pattern. I believe that's true for 61-bit float > "immediates" as well, though, because they need the all-zero tag bits. Actually, Qnil is still all-zeroes with my patch. XFLOAT removes the Lisp_Float tag bits before treating the resulting Lisp_Object value as a double. I expect this costs an instruction with XFLOAT, and that it's worth it to keep NILP fast. We can play a similar trick with NaN boxing, so that Qnil is all-zeros there too. For example, we could complement all the bits in a Lisp_Object value before treating it as a double. So I don't view this as being a major advantage for the approach I suggested. > I also wonder how many of the non-immediate floats are infinities, or > other numbers that have all low-order mantissa bits set. Infinities have the significand bits all zero, no? I'm skeptical that this is a profitable way to explore. > I don't see how any of this applies to > 32-bit platforms with 32-bit EMACS_INTs. On those, we cannot have > float immediates or NaN boxing. We can if we're willing to limit ourselves to 'float' precision for Emacs floats and at most 2**22-or-so distinct non-numeric objects. That might be doable. However I would rather not spend a lot of time worrying about tuning 32-bit EMACS_INT platforms. > 61-bit floats would mean > giving up IEEE compliance and surprising the occasional user who wants > it. That's a very high price to pay for saving a few GCs. RMS had a different opinion; he didn't think full IEEE compliance was worth all that much trouble . Although I was originally striving for IEEE compliance, I'm becoming more inclined to try things along those lines as it should indeed be faster and I doubt whether Emacs users care all that much about full IEEE.