From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Making 'eq' == 'eql' in bignum branch Date: Sun, 29 Jul 2018 00:09:18 -0400 Message-ID: References: <29f933ac-a6bf-8742-66a7-0a9d6d3e5a88@disroot.org> <0d3175d8-d996-651e-b221-71978bde3a65@cs.ucla.edu> <87tvpdnzgy.fsf@tromey.com> <4c2a814f-c254-29e5-39cf-11b5f2e5c9c8@cs.ucla.edu> <49d8ba62-c9a5-9203-d882-8e900b441ff3@cs.ucla.edu> <8e0320d9-e0d0-2b57-57cc-2df4399f133c@cs.ucla.edu> <87lgaio7xd.fsf@tromey.com> <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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1532837254 5395 195.159.176.226 (29 Jul 2018 04:07:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 29 Jul 2018 04:07:34 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 29 06:07:30 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 1fjczR-0001JF-GQ for ged-emacs-devel@m.gmane.org; Sun, 29 Jul 2018 06:07:30 +0200 Original-Received: from localhost ([::1]:47107 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fjd1W-0003RC-BP for ged-emacs-devel@m.gmane.org; Sun, 29 Jul 2018 00:09:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33126) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fjd1Q-0003Qu-Co for emacs-devel@gnu.org; Sun, 29 Jul 2018 00:09:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fjd1N-0003ZW-85 for emacs-devel@gnu.org; Sun, 29 Jul 2018 00:09:32 -0400 Original-Received: from [195.159.176.226] (port=49914 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fjd1M-0003ZK-Vj for emacs-devel@gnu.org; Sun, 29 Jul 2018 00:09:29 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1fjczC-00018j-Pb for emacs-devel@gnu.org; Sun, 29 Jul 2018 06:07:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 33 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:TfWp6geCp4bE9+/QRewgeeyZ5Cs= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:227938 Archived-At: > That is, on a 64-bit host, if the low-order 4 bits of the significand are > all zero, we encode the floating-point number directly in the Lisp_Object > (with a tag) so that the Lisp_Object need not be dereferenced and uses zero > bytes of floating-point heap. Sounds like an interesting optimization, yes. > into a special hash-consed table that should use about 16 bytes per entry > (one for the double, one for the pointer to it). I assume by "one for the pointer to it" you meant "one for the pointer to the next member of the same bucket". > I just checked 'make > compile-always' and under this proposal a full run would create 95694 Lisp > floats of which 80048 (84%) would use zero bytes and 15646 (16%) would use > 16 bytes of floating-point heap. I'm not sure this is very relevant: for "make compile-always" the resource cost of floats is irrelevant anyway (as evidenced by the fact that only 95694 of them are created). Similarly for bignums: if we only use them to slightly extend the reach of integers past the 2^29 or 2^63 limit, then it's OK to hash-cons them, but if/when someone comes around and uses them for computing with large numbers he might be disappointed at the resulting performance. Tho maybe it's not that bad: contrarily to operations of floats (which are basically super-fast on nowadays CPUs) given the non-linear algorithmic cost of many bignum operations, adding hash-consing to them wouldn't slow them down that much Stefan