From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#42147: 28.0.50; pure vs side-effect-free, missing optimizations? Date: Thu, 2 Jul 2020 16:16:04 -0700 Organization: UCLA Computer Science Department Message-ID: <1288c6a5-545b-f68c-ff6b-7683db3e54c1@cs.ucla.edu> References: <3A9CC2A3-8307-47B2-8D80-795C0AF020E1@acm.org> <0433A879-C98D-4B1A-B85C-A15DA9289099@acm.org> <1621669100.2102667.1593639091621@mail.yahoo.com> <775819003.2516724.1593687594435@mail.yahoo.com> <5F2B4684-34D1-4474-8909-9F435369FE54@acm.org> <705260433.2731607.1593698199171@mail.yahoo.com> <6CF8EE58-9A49-40E7-AA86-48AB39BF94BA@acm.org> <28B19D86-343C-4126-B95F-1F38735F73F2@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8564"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 Cc: Andrea Corallo , 42147@debbugs.gnu.org To: Stefan Monnier , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jul 03 01:17:14 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jr8S7-00022i-LR for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 03 Jul 2020 01:17:11 +0200 Original-Received: from localhost ([::1]:49066 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jr8S6-0005yO-AY for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 02 Jul 2020 19:17:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60562) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jr8Ry-0005yG-SD for bug-gnu-emacs@gnu.org; Thu, 02 Jul 2020 19:17:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44354) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jr8Ry-0003x1-Ix for bug-gnu-emacs@gnu.org; Thu, 02 Jul 2020 19:17:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jr8Ry-0006z9-Dq for bug-gnu-emacs@gnu.org; Thu, 02 Jul 2020 19:17:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Jul 2020 23:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42147 X-GNU-PR-Package: emacs Original-Received: via spool by 42147-submit@debbugs.gnu.org id=B42147.159373177526793 (code B ref 42147); Thu, 02 Jul 2020 23:17:02 +0000 Original-Received: (at 42147) by debbugs.gnu.org; 2 Jul 2020 23:16:15 +0000 Original-Received: from localhost ([127.0.0.1]:55900 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jr8RC-0006y4-T9 for submit@debbugs.gnu.org; Thu, 02 Jul 2020 19:16:15 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:59364) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jr8RA-0006xo-7g for 42147@debbugs.gnu.org; Thu, 02 Jul 2020 19:16:13 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E1FA91600C3; Thu, 2 Jul 2020 16:16:05 -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 bmWGKnCZyd28; Thu, 2 Jul 2020 16:16:05 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 28C1A1600C4; Thu, 2 Jul 2020 16:16:05 -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 SzolEihRuuZt; Thu, 2 Jul 2020 16:16:05 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-75-82-69-226.socal.res.rr.com [75.82.69.226]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id EF0FA1600C3; Thu, 2 Jul 2020 16:16:04 -0700 (PDT) Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoU In-Reply-To: Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:182653 Archived-At: On 7/2/20 2:41 PM, Stefan Monnier wrote: > I'd tend to assume that x87 rounding can virtually never be seen from > Elisp because it's hard to imagine how the C compiler will manage to > keep our Elisp floats long enough in the x87 stack to avoid rounding > back to 64bit floats between every Elisp-level operation. It can happen in floatop_arith_driver, which has an accumulator of type 'double' that on x87 is put into an 80-bit register. For example, on x86+x87 compiled with the usual gcc -O2, (+ 1e16 2.9999 2.9999) returns 10000000000000008.0 (the exact answer rounded to 'double'), whereas with SSE2 the same expression yields 10000000000000004.0 (which is a bit off, because the accumulator is only 64 bits and suffered from rounding intermediate results). > Or are we worried about the double-rounding of x87? That too. For example, with x87, (+ 1e16 2.9999) yields 10000000000000004.0 due to double-rounding, whereas with SSE2 the same expression yields 10000000000000002.0 which is the correctly-rounded answer. As you can see, sometimes SSE2 is closer to the mathematically-correct answer and sometimes x87 is. In typical C math code, x87 is better; in Emacs I imagine the reverse is true (for the reasons you mentioned), though I have not attempted to measure this.