GNU bug report logs - #42147
28.0.50; pure vs side-effect-free, missing optimizations?

Previous Next

Full log

Message #68 received at 42147 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Andrea Corallo <andrea_corallo <at> yahoo.it>, 42147 <at> debbugs.gnu.org
Subject: Re: bug#42147: 28.0.50; pure vs side-effect-free, missing
 optimizations?
Date: Fri, 3 Jul 2020 10:32:56 +0200

3 juli 2020 kl. 01.16 skrev Paul Eggert <eggert <at> cs.ucla.edu>:

> 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.

Thanks for the examples and these were indeed what I had in mind (there's also the effect from having a greater exponent range in the intermediate result); Monniaux [1] is a good reference.

In practice, the extra precision of x87 code is so unreliable and fickle (unless the 80-bit long double is used throughout) that it's almost never worth it. (Being much slower doesn't help either.)

Fortunately modern compilers generate SSE code by default, only passing return values on the x87 stack as per the x86 ABI (which causes no harm). This reduces an already tiny risk to nil. We could add an elaborate configure or run-time test and admonishments to the installation instructions but frankly we have better use of our time. I suggest we replace byte-opt--portable-numberp with numberp (or nothing at all, depending on where it occurs) and be done with it.

---
[1] https://hal.archives-ouvertes.fr/hal-00128124/file/floating-point-article.pdf

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.