GNU bug report logs -
#42147
28.0.50; pure vs side-effect-free, missing optimizations?
Previous Next
Reported by: Andrea Corallo <andrea_corallo <at> yahoo.it>
Date: Tue, 30 Jun 2020 22:28:02 UTC
Severity: normal
Found in version 28.0.50
Done: Mattias Engdegård <mattiase <at> acm.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 42147 in the body.
You can then email your comments to 42147 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Tue, 30 Jun 2020 22:28:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Andrea Corallo <andrea_corallo <at> yahoo.it>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 30 Jun 2020 22:28:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi all,
I was looking in byte-opt.el to how are classified a number of
functions.
My understanding is that pure functions should be technically a subset
of side-effect-and-error-free for which the environment has no influence
on the value the function evaluates to. For this reason they can be
constant folded in the compile time if possible.
Now in pure functions I see we do not have a lot of functions that (to
my understanding) would classify for that. I'm thinking to simple
predicates acting on immutable objects as consp or fixnump to give an
example.
Shouldn't we move these into the pure class?
ATM for instance this does not get optimized:
(defun foo ()
(fixnump 3))
In case this makes sense I'll be happy to work on it and prepare a
patch.
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Tue, 30 Jun 2020 23:15:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 42147 <at> debbugs.gnu.org (full text, mbox):
Ok I realized that fixnump is a very bad example because the result is
strictly platform dependent.
Please replace it with numberp or some other simple predicate.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Wed, 01 Jul 2020 12:45:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 42147 <at> debbugs.gnu.org (full text, mbox):
Actually, pure functions are side-effect-free but not necessarily error-free. But in essence, you are right.
The following functions look like they could be marked pure. Given that they currently aren't, there may be a good reason for their omission -- do correct me!
integerp
natnump
floatp
characterp
numberp
arrayp
vectorp
bool-vector-p
char-or-string-p
integer-or-marker-p
keywordp
number-or-marker-p
sequencep
length
safe-length
... and some more (symbolp, stringp etc) that are already explicitly optimised.
Regarding fixnump, we could add an optimiser since this predicate can be constant-folded for certain arguments, but it's unclear whether it's worth the trouble since this predicate (and bignump) are less commonly used today. Most uses of fixnump (in Emacs) are in Calc, and those are probably relics that should be replaced.
More useful would be the ability to constant-fold ash, expt, %, mod and abs for a subset of each respective domain. I can write a patch.
We could also decide that it's not a problem if an operation returns either a fixnum or bignum depending on the platform, on the grounds that
(1) the distinction is not directly carried over through numeric constants (bignums and fixnums look the same in .elc files)
(2) any attempt to discriminate between fixnums and bignums is non-portable anyway (and we can punt the discrimination to runtime)
and thus constant-fold all integer operations (+, -, * etc), not just those resulting in a portable fixnum.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Wed, 01 Jul 2020 12:48:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 42147 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
The attached is setting as pure: arrayp, bool-vector-p, consp,
char-or-string-p, floatp, hash-table-p, integerp, listp, natnump,
nlistp, not, null, string-lessp, stringp, symbolp, vectorp.
Feedback welcome.
Thanks
Andrea
[0001-Add-some-function-to-pure-fns.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Wed, 01 Jul 2020 16:09:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 42147 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Andrea, I see nothing directly wrong with your patch, but perhaps our messages went past one another since our lists of proposed pure functions differ.
> More useful would be the ability to constant-fold ash, expt, %, mod and abs for a subset of each respective domain. I can write a patch.
Here is that patch.
[0001-Constant-fold-mod-ash-expt-and-abs-with-constant-int.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Wed, 01 Jul 2020 21:32:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 42147 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård <mattiase <at> acm.org> writes:
> More useful would be the ability to constant-fold ash, expt, %, mod and abs for a subset of each respective domain. I can write a patch.
Hi Mattias,
I'm not sure what would be more useful, I guess both are a good thing to
have. Another reason why I'm interested is that I reuse these
definitions in the native compiler.
> Andrea, I see nothing directly wrong with your patch, but perhaps our messages went past one another since our lists of proposed pure functions differ.
yes that exactly what happen, thanks for looking at it.
I diffed our two lists and this is the results, functions included in
mine but not in your:
consp, hash-table-p, listp, nlistp, not, null, string-lessp, stringp,
symbolp.
functions included in your but not in mine:
characterp, integer-or-marker-p, keywordp, length, number-or-marker-p,
numberp, safe-length, sequencep.
I guess for the most part I can just include the one I've missed. I'm
not only sure about the one operating on lists like `length' given the
list may be modified in the runtime (?).
I'll update the patch once this point is clarified.
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Thu, 02 Jul 2020 10:28:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 42147 <at> debbugs.gnu.org (full text, mbox):
1 juli 2020 kl. 23.31 skrev Andrea Corallo <andrea_corallo <at> yahoo.it>:
> Another reason why I'm interested is that I reuse these
> definitions in the native compiler.
In that case there are probably more functions you may want to consider for purity -- what about:
< > <= >= = /=
string< string= string-equal
eq eql equal
proper-list-p
identity
memq memql member
assq assql assoc
> I guess for the most part I can just include the one I've missed.
By all means, but do not take my word for the correctness of my list -- think it through yourself. We mustn't err here.
> I'm not only sure about the one operating on lists like `length' given the
> list may be modified in the runtime (?).
Not sure why this would be an obstacle, but I could have overlooked something important! Could you explain your thinking in greater detail, and if possible provide an example of code that you think might be miscompiled if 'length' or 'safe-length' were marked pure?
I still wonder if there is any reason to limit arithmetic constant folding to the portable fixnum range. Given that we don't evaluate fixnump or bignump at compile-time, what observable effects would constant-folding, say, (ash 1 32) have? Advice from deeper thinkers solicited!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Thu, 02 Jul 2020 11:01:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 42147 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård <mattiase <at> acm.org> writes:
> 1 juli 2020 kl. 23.31 skrev Andrea Corallo <andrea_corallo <at> yahoo.it>:
>
>> Another reason why I'm interested is that I reuse these
>> definitions in the native compiler.
>
> In that case there are probably more functions you may want to consider for purity -- what about:
>
> < > <= >= = /=
> string< string= string-equal
> eq eql equal
> proper-list-p
> identity
> memq memql member
> assq assql assoc
Good point
>> I guess for the most part I can just include the one I've missed.
>
> By all means, but do not take my word for the correctness of my list -- think it through yourself. We mustn't err here.
>
>> I'm not only sure about the one operating on lists like `length' given the
>> list may be modified in the runtime (?).
>
> Not sure why this would be an obstacle, but I could have overlooked
> something important! Could you explain your thinking in greater
> detail, and if possible provide an example of code that you think
> might be miscompiled if 'length' or 'safe-length' were marked pure?
No, thinking about I believe you are correct.
I mixed in mind the fact that now the native compiler must handle
correctly in the CFG also pure functions taking mutable objects (given we
are adding them), but that is unrelated. This is no problem for the
bytecompiler given the constant folding is done only locally.
So yes these are pure functions and so they should be marked.
> I still wonder if there is any reason to limit arithmetic constant
> folding to the portable fixnum range. Given that we don't evaluate
> fixnump or bignump at compile-time, what observable effects would
> constant-folding, say, (ash 1 32) have? Advice from deeper thinkers
> solicited!
I always thought the general idea is to respect the allocation side
effect we have creating a bignum. Not sure if the class of example you
have in mind here fits this case.
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Thu, 02 Jul 2020 12:48:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 42147 <at> debbugs.gnu.org (full text, mbox):
2 juli 2020 kl. 12.59 skrev Andrea Corallo <andrea_corallo <at> yahoo.it>:
>> I still wonder if there is any reason to limit arithmetic constant
>> folding to the portable fixnum range. Given that we don't evaluate
>> fixnump or bignump at compile-time, what observable effects would
>> constant-folding, say, (ash 1 32) have? Advice from deeper thinkers
>> solicited!
>
> I always thought the general idea is to respect the allocation side
> effect we have creating a bignum. Not sure if the class of example you
> have in mind here fits this case.
Number allocation isn't a semantically visible effect and we probably don't want to change that. As far as I can tell, only fixnump and bignump can discriminate fixnums from bignums. There may be functions that only accept fixnums as arguments and thus fail with a different error, but I don't think we constant-fold any of them, and they would be easy to fix if we did.
It may be preferable to defer generation of very big numbers to run-time, to avoid evaluation of (ash 1 1000) at compile-time, but such a limit should, if implemented, be independent of the fixnum limit (and likely higher).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Thu, 02 Jul 2020 13:57:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 42147 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård <mattiase <at> acm.org> writes:
> 2 juli 2020 kl. 12.59 skrev Andrea Corallo <andrea_corallo <at> yahoo.it>:
>
>>> I still wonder if there is any reason to limit arithmetic constant
>>> folding to the portable fixnum range. Given that we don't evaluate
>>> fixnump or bignump at compile-time, what observable effects would
>>> constant-folding, say, (ash 1 32) have? Advice from deeper thinkers
>>> solicited!
>>
>> I always thought the general idea is to respect the allocation side
>> effect we have creating a bignum. Not sure if the class of example you
>> have in mind here fits this case.
>
> Number allocation isn't a semantically visible effect and we probably
> don't want to change that.
Well is cons allocation a semantically visible effect then? How is it
different?
I thought the reason why cons is not constant folded is to respect the
allocation side effect, at least that's what I convinced my-self of :)
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Thu, 02 Jul 2020 14:52:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 42147 <at> debbugs.gnu.org (full text, mbox):
2 juli 2020 kl. 15.56 skrev Andrea Corallo <andrea_corallo <at> yahoo.it>:
> Well is cons allocation a semantically visible effect then? How is it
> different?
Conses are mutable and thus each have their own identity. Numbers are immutable and have none; there is no defined way to distinguish two numbers that have the same value ('eq' does not give well-defined results). The compiler is free to, and does, deduplicate equal bignums. For instance, try
(disassemble (lambda () (list 18723645817263338474859 18723645817263338474859)))
and you will see that the resulting code will only contain one instance of the number.
> I thought the reason why cons is not constant folded is to respect the
> allocation side effect, at least that's what I convinced my-self of :)
Yes, in the sense that
(defun f () (cons 'a 'b))
produces a fresh (a . b) each time (f) is called, because the returned values can be distinguished both explicitly by 'eq' and by mutating it and observing whether the change affects previously returned values or not. Neither works for numbers.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Thu, 02 Jul 2020 15:33:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 42147 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård <mattiase <at> acm.org> writes:
>> I thought the reason why cons is not constant folded is to respect the
>> allocation side effect, at least that's what I convinced my-self of :)
>
> Yes, in the sense that
>
> (defun f () (cons 'a 'b))
>
> produces a fresh (a . b) each time (f) is called, because the returned
> values can be distinguished both explicitly by 'eq' and by mutating it
> and observing whether the change affects previously returned values or
> not. Neither works for numbers.
Understand makes perfectly sense. Cons allocation is something
very visible in Lisp.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Thu, 02 Jul 2020 15:50:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 42147 <at> debbugs.gnu.org (full text, mbox):
> Conses are mutable and thus each have their own identity. Numbers are
> immutable and have none; there is no defined way to distinguish two numbers
> that have the same value ('eq' does not give well-defined results).
Better yet, there's still hope that we change things such that `eq`
behaves like `eql` on bignums (and maybe also on floats).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Thu, 02 Jul 2020 18:02:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 42147 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
2 juli 2020 kl. 17.49 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:
> Better yet, there's still hope that we change things such that `eq`
> behaves like `eql` on bignums (and maybe also on floats).
Speaking of which, Andrea may be in a good position to provide us with performance data about such a change, since making 'eq' more expensive is likely to be more visible in native code (assuming the operation is open-coded) than in bytecode or interpreted lisp. On the other hand, perhaps his compiler thingamajig is able to eliminate some checks statically by type propagation?
Anyway, since we now have bignums and have standardised on IEEE 754 binary64 floats, is there a reason to keep byte-opt-portable-numberp?
If we want to make allowance for capricious x87 rounding, what about rewriting it to accept integral floats in the ±2^53 range, as well as any integer? This is what it might look like:
[0001-Relax-portable-number-predicate-in-byte-compiler.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Thu, 02 Jul 2020 18:56:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 42147 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård <mattiase <at> acm.org> writes:
> 2 juli 2020 kl. 17.49 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:
>
>> Better yet, there's still hope that we change things such that `eq`
>> behaves like `eql` on bignums (and maybe also on floats).
>
> Speaking of which, Andrea may be in a good position to provide us with
> performance data about such a change, since making 'eq' more expensive
> is likely to be more visible in native code (assuming the operation is
> open-coded) than in bytecode or interpreted lisp. On the other hand,
> perhaps his compiler thingamajig is able to eliminate some checks
> statically by type propagation?
Correct, in case we would certainly opencode it and use the thingamajig
trying to eliminate the type checks we can.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Thu, 02 Jul 2020 19:10:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 42147 <at> debbugs.gnu.org (full text, mbox):
Am Do., 2. Juli 2020 um 12:28 Uhr schrieb Mattias Engdegård <mattiase <at> acm.org>:
>
> 1 juli 2020 kl. 23.31 skrev Andrea Corallo <andrea_corallo <at> yahoo.it>:
>
> > Another reason why I'm interested is that I reuse these
> > definitions in the native compiler.
>
> In that case there are probably more functions you may want to consider for purity -- what about:
>
> < > <= >= = /=
> string< string= string-equal
> eq eql equal
> proper-list-p
> identity
> memq memql member
> assq assql assoc
I don't think most of those are pure, as they have to "look into" an
object. For example, the result of "equal" does not only depend on the
argument objects, but also the objects they refer to.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Thu, 02 Jul 2020 19:39:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 42147 <at> debbugs.gnu.org (full text, mbox):
>> Better yet, there's still hope that we change things such that `eq`
>> behaves like `eql` on bignums (and maybe also on floats).
> Speaking of which, Andrea may be in a good position to provide us with
> performance data about such a change, since making 'eq' more expensive is
> likely to be more visible in native code (assuming the operation is
> open-coded) than in bytecode or interpreted lisp. On the other hand, perhaps
> his compiler thingamajig is able to eliminate some checks statically by
> type propagation?
Note that it can also be done without slowing down `eq` (by
hash-consing the bignums).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Thu, 02 Jul 2020 20:10:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 42147 <at> debbugs.gnu.org (full text, mbox):
On 7/2/20 12:38 PM, Stefan Monnier wrote:
> Note that it can also be done without slowing down `eq` (by
> hash-consing the bignums).
Yes, that's a better way to go. I wrote a patch to do that a while ago but never
got around to the laborious part, which was benchmarking.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Thu, 02 Jul 2020 20:33:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 42147 <at> debbugs.gnu.org (full text, mbox):
On 7/2/20 11:01 AM, Mattias Engdegård wrote:
> If we want to make allowance for capricious x87 rounding, what about rewriting it to accept integral floats in the ±2^53 range, as well as any integer? This is what it might look like:
Another plausible option would be for Emacs to drop support for x87 rounding, in
the interest of portability. All Apple Intel machines have had SSE2, Microsoft
has been requiring SSE2 by default since MSVC 2012, and it's easy enough to do
the same with GCC and clang.
We'd be in good company as lots of other software packages have dropped support
for non-SSE2 machines, including Cygwin, Java, OpenOffice, PostgreSQL, Python,
QEMU, Thunderbird, VirtualBox; see <http://matejhorvat.si/en/unfiled/nosse2.htm>.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Thu, 02 Jul 2020 21:42:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 42147 <at> debbugs.gnu.org (full text, mbox):
> Anyway, since we now have bignums and have standardised on IEEE 754 binary64
> floats, is there a reason to keep byte-opt-portable-numberp?
Indeed, it seems like it might not be needed any more.
> If we want to make allowance for capricious x87 rounding, what about
> rewriting it to accept integral floats in the ±2^53 range, as well as any
> integer? This is what it might look like:
I must say I don't know what x87 rounding has to do with it.
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.
Or are we worried about the double-rounding of x87?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Thu, 02 Jul 2020 23:17:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 42147 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Fri, 03 Jul 2020 08:34:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 42147 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Fri, 03 Jul 2020 09:26:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 42147 <at> debbugs.gnu.org (full text, mbox):
2 juli 2020 kl. 21.09 skrev Philipp Stephani <p.stephani2 <at> gmail.com>:
> I don't think most of those are pure, as they have to "look into" an
> object. For example, the result of "equal" does not only depend on the
> argument objects, but also the objects they refer to.
Unless I'm mistaken, they are pure enough for the purpose of constant folding, where the arguments are already known (constant) at compile-time; do come with a counter-example if you disagree.
Were you thinking about other uses of pure functions? Perhaps our notion of purity is underspecified.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Fri, 03 Jul 2020 09:33:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 42147 <at> debbugs.gnu.org (full text, mbox):
2 juli 2020 kl. 22.09 skrev Paul Eggert <eggert <at> cs.ucla.edu>:
>> Note that it can also be done without slowing down `eq` (by
>> hash-consing the bignums).
>
> Yes, that's a better way to go. I wrote a patch to do that a while ago but never
> got around to the laborious part, which was benchmarking.
Hash-consing bignums may be a good idea (I'm neutral on the idea), but there could be a reason why it isn't very commonly seen in other runtimes; perhaps they have more efficient GCs (generational and/or incremental), but Emacs would benefit (a lot) from that, too.
In any case, it's a one-way decision: once we guarantee eq to provide numerical equality (whether by hash-consing or otherwise), there is no way back.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Fri, 03 Jul 2020 13:12:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 42147 <at> debbugs.gnu.org (full text, mbox):
> 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.
Agreed,
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Fri, 03 Jul 2020 13:40:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 42147 <at> debbugs.gnu.org (full text, mbox):
> Hash-consing bignums may be a good idea (I'm neutral on the idea), but there
> could be a reason why it isn't very commonly seen in other runtimes; perhaps
> they have more efficient GCs (generational and/or incremental), but Emacs
> would benefit (a lot) from that, too.
I don't think the GC performance has very much to do with it. I think
it's simply that hash-consing bignums has a negative effect on the
performance of bignum operations (by a constant factor which
I guesstimate to be around 50%). For a general purpose language this
can be significant. In my opinion for Emacs Lisp this is irrelevant
(we've lived without real bignums (using slow emulations instead) for
more than 30 years, so even half-speed bignums are much better than what
we really need).
It could become relevant if/when we replace wide-int with bignums, in
which case performance of "small bignums" could be fairly important.
But I'm not sure if we'll ever want to replace wide-ints with bignums
(tho I do hope we will).
> In any case, it's a one-way decision: once we guarantee eq to provide
> numerical equality (whether by hash-consing or otherwise), there is no
> way back.
Yes, once you've had the taste of clean semantics it's hard to go back ;-)
Stefan "in favor of redefining `eq` to `eql`"
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Fri, 03 Jul 2020 18:32:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 42147 <at> debbugs.gnu.org (full text, mbox):
On 7/3/20 1:32 AM, Mattias Engdegård wrote:
> 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.
Depends on whether you want reproducibility or accuracy. We prefer the former,
it seems.
> Fortunately modern compilers generate SSE code by default
No, GCC generates x87 code by default. You need to specify -mfpmath=sse to
convince it to not generate x87 code. (Or, when you build GCC, you need to pass
--with-mfpmath=sse to 'configure'; but I think this is uncommon, at least in the
GNU/Linux world.)
Having Emacs use --with-mfpmath=sse should improve performance a bit on x86. But
more important, it should make floating point more reproducible. If I get the
time I'll look into having 'configure' add it automatically.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Fri, 03 Jul 2020 18:36:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 42147 <at> debbugs.gnu.org (full text, mbox):
3 juli 2020 kl. 15.11 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:
>
>> 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.
>
> Agreed,
Thanks -- patch attached. Some expressions will still not be constant-folded entirely; for example
(byte-optimize-form '(+ #x100000000000000 1 1))
=> (+ 72057594037927936 1 1)
This will be fixed automatically by marking + as pure; the same should be done for the other arithmetic functions.
By the way, is it a bug or a feature that calls to pure functions with constant but invalid arguments raise an error at compile-time? For example:
(disassemble (lambda () (if nil (regexp-quote nil))))
will raise an error despite none would be generated at run time if this function were interpreted.
It's easy to suppress those errors, but I see how they can be useful in practice.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Fri, 03 Jul 2020 18:45:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 42147 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> patch attached
Now.
[0001-Relax-portable-number-check-in-byte-compiler-bug-421.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Fri, 03 Jul 2020 18:48:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 42147 <at> debbugs.gnu.org (full text, mbox):
3 juli 2020 kl. 20.31 skrev Paul Eggert <eggert <at> cs.ucla.edu>:
> No, GCC generates x87 code by default.
Sorry, my mistake -- I was testing various compiler options with godbolt and must have looked at LLVM instead.
> Having Emacs use --with-mfpmath=sse should improve performance a bit on x86. But
> more important, it should make floating point more reproducible. If I get the
> time I'll look into having 'configure' add it automatically.
Thank you, this would be a prerequisite for further improvements.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Fri, 03 Jul 2020 19:06:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 42147 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Mattias Engdegård <mattiase <at> acm.org> writes:
> This will be fixed automatically by marking + as pure; the same should be done for the other arithmetic functions.
Hi,
attached the updated version of the patch updating the pure function
classification.
Please have a look.
Thanks
Andrea
[0001-Add-a-number-of-functions-to-pure-fns-bug-42147.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 04 Jul 2020 14:59:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 42147 <at> debbugs.gnu.org (full text, mbox):
3 juli 2020 kl. 21.05 skrev Andrea Corallo <andrea_corallo <at> yahoo.it>:
> attached the updated version of the patch updating the pure function
> classification.
Thanks Andrea! Philipp Stephani raised the interesting question of (essentially) whether 'car' is pure. For the purposes of the current constant folding in the byte compiler the answer is yes, but perhaps you have wider ambitions in your work?
Clearly, (car X) cannot be moved past some operations with side-effects if X is aliased:
(let* ((x (list 'a))
(y (car x)))
(f x)
y)
Here, (car x) cannot be sunk past the call to f despite x remaining unchanged (assuming lexical binding).
It would be useful to know more exactly what notion of purity you require.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 04 Jul 2020 15:07:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 42147 <at> debbugs.gnu.org (full text, mbox):
> Thanks -- patch attached. Some expressions will still not be constant-folded
> entirely; for example
LGTM,
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 04 Jul 2020 15:58:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 42147 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 7/3/20 11:47 AM, Mattias Engdegård wrote:
>> Having Emacs use --with-mfpmath=sse should improve performance a bit on x86. But
>> more important, it should make floating point more reproducible. If I get the
>> time I'll look into having 'configure' add it automatically.
> Thank you, this would be a prerequisite for further improvements.
Attached is a patch to do that. I looked at the GCC source code, and x86 is the
only platform where this sort of thing should be necessary. I'll mention this
patch on emacs-devel, to give people a heads-up before installing.
[0001-Prefer-standard-rounding-on-x86.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 04 Jul 2020 16:15:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 42147 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Mattias Engdegård <mattiase <at> acm.org> writes:
> 3 juli 2020 kl. 21.05 skrev Andrea Corallo <andrea_corallo <at> yahoo.it>:
>
>> attached the updated version of the patch updating the pure function
>> classification.
>
> Thanks Andrea! Philipp Stephani raised the interesting question of (essentially) whether 'car' is pure. For the purposes of the current constant folding in the byte compiler the answer is yes, but perhaps you have wider ambitions in your work?
>
> Clearly, (car X) cannot be moved past some operations with side-effects if X is aliased:
>
> (let* ((x (list 'a))
> (y (car x)))
> (f x)
> y)
>
> Here, (car x) cannot be sunk past the call to f despite x remaining unchanged (assuming lexical binding).
> It would be useful to know more exactly what notion of purity you require.
Thanks for the observation, today I was studying the situation.
I think the notion of purity has to be the same one we use in the byte
compiler. The trickiness is in if the considered object is immutable or
not. The optimizer must stay in the boundary of what is allowed in this
regard.
To put in elisp what I think ATM:
(defun aaa ()
(let ((x (list 1 2)))
(1+ (car x)) ; <= legally optimizable
))
(defun bbb ()
(let ((x (list 1 2)))
(f x) ; f is not pure
(1+ (car x)) ; <= cannot optimize
))
(defun ccc ()
(let ((x '(1 2)))
(f x) ; f is not pure
(1+ (car x)) ; <= legally optimizable because immutable
))
(defun ddd ()
(let ((x (list 1 2)))
(f x) ; f is pure
(1+ (car x)) ; <= legally optimizable
))
Now given we are not constant folding `cons' we are not materializing
conses, as a consequence of these three example we would optimize only
`ccc' if we include `car' as pure. AFAIU this is correct given
modifying an immutable object in `f' would be undefined.
So yes for me `car' is pure and I think we should add it to the list.
BTW reading the code of the native compiler I realized I am already
extrapolating for use a very similar list of optimizable functions to the one
proposed. I still think would quite cleaner to classify these in
byte-opt.el.
Attached the updated patch where I'm adding car, car-safe, cdr,
cdr-safe, max, min.
Feedback welcome
Thanks
Andrea
[0001-Add-a-number-of-functions-to-pure-fns-bug-42147.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 04 Jul 2020 16:16:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 42147 <at> debbugs.gnu.org (full text, mbox):
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 4 Jul 2020 08:57:08 -0700
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,
> Andrea Corallo <andrea_corallo <at> yahoo.it>, 42147 <at> debbugs.gnu.org
>
> This makes Emacs behavior more consistent across platforms,
> and should make some byte-code optimizations safer (Bug#42147).
> We can assume SSE2 by now, since it has been out for 20 years.
> * configure.ac: On x86 with GCC, default to -msse2 -mfpmath=sse.
This assumes that the system on which Emacs runs is the same as where
it was built, doesn't it? Is that assumption valid enough to do this
by default?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 04 Jul 2020 16:28:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 42147 <at> debbugs.gnu.org (full text, mbox):
On 7/4/20 9:15 AM, Eli Zaretskii wrote:
>> * configure.ac: On x86 with GCC, default to -msse2 -mfpmath=sse.
> This assumes that the system on which Emacs runs is the same as where
> it was built, doesn't it?
It doesn't assume they're the same system. It merely assumes that build and
host platforms both support SSE2, which is a safe assumption nowadays.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 04 Jul 2020 16:35:01 GMT)
Full text and
rfc822 format available.
Message #116 received at 42147 <at> debbugs.gnu.org (full text, mbox):
>>> * configure.ac: On x86 with GCC, default to -msse2 -mfpmath=sse.
>> This assumes that the system on which Emacs runs is the same as where
>> it was built, doesn't it?
> It doesn't assume they're the same system. It merely assumes that build and
> host platforms both support SSE2, which is a safe assumption nowadays.
Is there a way to tell gcc to try and avoid x87's idiosyncrasies without
being platform-dependent (or at least without imposing SSE2, since
I still use Emacs on my old Thinkpad X30)?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 04 Jul 2020 16:45:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 42147 <at> debbugs.gnu.org (full text, mbox):
4 juli 2020 kl. 18.33 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:
> Is there a way to tell gcc to try and avoid x87's idiosyncrasies without
> being platform-dependent (or at least without imposing SSE2, since
> I still use Emacs on my old Thinkpad X30)?
There is -ffloat-store, which cures the 80 bit intermediary result problem while retaining the double-rounding one (which tends to be less common in practice). Maybe it is good enough?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 04 Jul 2020 17:01:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 42147 <at> debbugs.gnu.org (full text, mbox):
On 7/4/20 9:33 AM, Stefan Monnier wrote:
> Is there a way to tell gcc to try and avoid x87's idiosyncrasies without
> being platform-dependent (or at least without imposing SSE2, since
> I still use Emacs on my old Thinkpad X30)?
Not as far as I know. GCC's -fexcess-precision=standard option tries to do that,
by causing GCC to convert 80-bit results to 64-bit results after every 80-bit
operation. However, this still suffers from double-rounding on the x86 unless
you also specify -msse2 -mfpmath=sse. (-fexcess-precision=standard supports the
C standard better than the older -ffloat-store option, which generates code that
is faster but has more double-rounding problems than -fexcess-precision=standard
does.)
Several GNU/Linux distributions have already dropped support for x86-only
hardware like the circa-2001 Intel Mobile Pentium III-M in your laptop. On the
distributions that still support i686, you can still build and run Emacs on your
laptop (which has SSE but not SSE2) by configuring with CFLAGS='-msse
-mfpmath=sse -fexcess-precision=standard'; this should avoid some (but not all)
of the rounding problems.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 04 Jul 2020 17:11:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 42147 <at> debbugs.gnu.org (full text, mbox):
> Cc: mattiase <at> acm.org, monnier <at> iro.umontreal.ca, andrea_corallo <at> yahoo.it,
> 42147 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 4 Jul 2020 09:27:23 -0700
>
> On 7/4/20 9:15 AM, Eli Zaretskii wrote:
> >> * configure.ac: On x86 with GCC, default to -msse2 -mfpmath=sse.
> > This assumes that the system on which Emacs runs is the same as where
> > it was built, doesn't it?
> It doesn't assume they're the same system. It merely assumes that build and
> host platforms both support SSE2, which is a safe assumption nowadays.
What about the effect on the ABI? If Emacs compiled with these
switches is linked against libraries compiled without them, could
there be problems in the produced binary?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 04 Jul 2020 18:39:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 42147 <at> debbugs.gnu.org (full text, mbox):
On Sat, Jul 4, 2020 at 5:01 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> On 7/4/20 9:33 AM, Stefan Monnier wrote:
> > Is there a way to tell gcc to try and avoid x87's idiosyncrasies without
> > being platform-dependent (or at least without imposing SSE2, since
> > I still use Emacs on my old Thinkpad X30)?
>
> Not as far as I know. GCC's -fexcess-precision=standard option tries to do that,
> by causing GCC to convert 80-bit results to 64-bit results after every 80-bit
> operation. However, this still suffers from double-rounding on the x86 unless
> you also specify -msse2 -mfpmath=sse. (-fexcess-precision=standard supports the
> C standard better than the older -ffloat-store option, which generates code that
> is faster but has more double-rounding problems than -fexcess-precision=standard
> does.)
So it's a GCC bug? Wouldn't it be better to fix that?
(The double-rounding issues you mention don't appear to be documented;
but -fexcess-precision=standard is documented to be a nop if
-mfpmath=sse is specified...)
> Several GNU/Linux distributions have already dropped support for x86-only
> hardware like the circa-2001 Intel Mobile Pentium III-M in your laptop. On the
> distributions that still support i686, you can still build and run Emacs on your
> laptop (which has SSE but not SSE2) by configuring with CFLAGS='-msse
> -mfpmath=sse -fexcess-precision=standard'; this should avoid some (but not all)
> of the rounding problems.
I think we should either drop x86 entirely or support it, and the
former is not yet an option. The minor issue fixed by dropping support
for pre-SSE x86 can, if I understand the GCC docs correctly, be evaded
by making sure the C code does the appropriate amount of casting.
FWIW, SSE instructions require special OS support, too. We still have
things like the (broken) snprintf implementation in sysdep.c, so
people may be forgiven for getting the impression we care about
non-typical hardware/OS combinations.
I also think it's unwise to establish that Emacs uses 64-bit IEEE-754
floating point numbers exclusively. I'm inclined to believe that the
current consensus on that particular format is likely to be temporary
only.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 04 Jul 2020 19:03:05 GMT)
Full text and
rfc822 format available.
Message #131 received at 42147 <at> debbugs.gnu.org (full text, mbox):
4 juli 2020 kl. 19.00 skrev Paul Eggert <eggert <at> cs.ucla.edu>:
> Not as far as I know. GCC's -fexcess-precision=standard option tries to do that,
> by causing GCC to convert 80-bit results to 64-bit results after every 80-bit
> operation.
Not quite after every operation:
y = x * a + b;
With -fexcess-precision=standard, the 80-bit result of the multiplication will be used in the addition. With -ffloat-store, a 64-bit store and reload will take place between the two operations, forcing excess fraction bits to be discarded.
Another option is to set the Precision Control field in the x87 control word to 53-bit precision; that pretty much eliminates double rounding, but still uses the extended exponent range (only matters in overflow and underflow cases). And it may confuse libc's carefully crafted floating-point functions.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 04 Jul 2020 19:27:01 GMT)
Full text and
rfc822 format available.
Message #134 received at 42147 <at> debbugs.gnu.org (full text, mbox):
On 7/4/20 10:10 AM, Eli Zaretskii wrote:
> What about the effect on the ABI? If Emacs compiled with these
> switches is linked against libraries compiled without them, could
> there be problems in the produced binary?
No. These compiler options do not change the ABI. All that changes is the use of
registers and temporaries within each function, not how the function deals with
callers, callees, or storage visible to callers or callees.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 04 Jul 2020 21:06:01 GMT)
Full text and
rfc822 format available.
Message #137 received at 42147 <at> debbugs.gnu.org (full text, mbox):
> So it's a GCC bug? Wouldn't it be better to fix that?
Not really, no: the x87 hardware makes it difficult to get the exact
behavior of 64bit floats, so either you live with "almost" the right
behavior or you don't use the x87 hardware (which on pre-SSE2 hardware
implies a massive slow down on floating point operations).
>> Several GNU/Linux distributions have already dropped support for x86-only
>> hardware like the circa-2001 Intel Mobile Pentium III-M in your laptop. On the
>> distributions that still support i686, you can still build and run Emacs on your
>> laptop (which has SSE but not SSE2) by configuring with CFLAGS='-msse
>> -mfpmath=sse -fexcess-precision=standard'; this should avoid some (but not all)
>> of the rounding problems.
If I need to change the flags, then I'm much more likely to just use the
"normal" compilation option: I actually couldn't care less about the
potential differences in rounding.
I'm actually not completely sure why we care about those minor
rounding differences.
After all, even if we use SSE2, there's no guarantee that the output of
`sin` in one version of Emacs will be exactly the same as in another
version of Emacs. And while I know that there's some hope that those
differences will disappear in some distant future (since someone
finally figured out how to implement `sin` efficiently with perfect
rounding), I don't think we'll be able to rely on that any time soon,
and I don't see why `+` should not be allowed to vary wile `sin` is.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 04 Jul 2020 22:27:02 GMT)
Full text and
rfc822 format available.
Message #140 received at 42147 <at> debbugs.gnu.org (full text, mbox):
On Sat, Jul 4, 2020 at 9:05 PM Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
> > So it's a GCC bug? Wouldn't it be better to fix that?
>
> Not really, no: the x87 hardware makes it difficult to get the exact
> behavior of 64bit floats, so either you live with "almost" the right
> behavior or you don't use the x87 hardware (which on pre-SSE2 hardware
> implies a massive slow down on floating point operations).
Precisely. Those are the two options GCC should offer, instead of (or
in addition to) three degrees of wrongness. This is obsolete hardware
which does not, apparently, provide any support for adding two IEEE
754 64-bit floats. Pretending it does is not helpful and, at the very
least, a bug in the documentation.
> >> Several GNU/Linux distributions have already dropped support for x86-only
> >> hardware like the circa-2001 Intel Mobile Pentium III-M in your laptop. On the
> >> distributions that still support i686, you can still build and run Emacs on your
> >> laptop (which has SSE but not SSE2) by configuring with CFLAGS='-msse
> >> -mfpmath=sse -fexcess-precision=standard'; this should avoid some (but not all)
> >> of the rounding problems.
FWIW, that doesn't seem to have any effect here, it just uses x87 instructions.
> If I need to change the flags, then I'm much more likely to just use the
> "normal" compilation option: I actually couldn't care less about the
> potential differences in rounding.
>
> I'm actually not completely sure why we care about those minor
> rounding differences.
Neither am I. If the idea is to standardize Emacs on a single
floating-point representation, let's at least use the 61-bit floats
Paul suggested a while back? (Incidentally, I believe those can be
implemented somewhat more efficiently on x87 hardware). Or we could go
with bignum ratios or GMP floats.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sun, 05 Jul 2020 02:39:01 GMT)
Full text and
rfc822 format available.
Message #143 received at 42147 <at> debbugs.gnu.org (full text, mbox):
> From: Pip Cet <pipcet <at> gmail.com>
> Date: Sat, 4 Jul 2020 22:25:55 +0000
> Cc: mattiase <at> acm.org, Paul Eggert <eggert <at> cs.ucla.edu>, andrea_corallo <at> yahoo.it,
> 42147 <at> debbugs.gnu.org
>
> > I'm actually not completely sure why we care about those minor
> > rounding differences.
>
> Neither am I. If the idea is to standardize Emacs on a single
> floating-point representation, let's at least use the 61-bit floats
> Paul suggested a while back? (Incidentally, I believe those can be
> implemented somewhat more efficiently on x87 hardware). Or we could go
> with bignum ratios or GMP floats.
Some other relevant questions:
. why didn't GCC folks made SSE2 the default output? shouldn't
Emacs follow the defaults, and leave it to the experts to decide
which instruction set should be the default?
. which other projects use this non-standard instruction set? GNU
Guile, for example, doesn't, so why should we?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sun, 05 Jul 2020 08:29:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 42147 <at> debbugs.gnu.org (full text, mbox):
On 7/4/20 7:38 PM, Eli Zaretskii wrote:
> . which other projects use this non-standard instruction set?
Wait a minute, SSE2 is not "non-standard". It was introduced in 2000 as part of
the evolving Intel/AMD x86 instruction set, and is supported by pretty much
every x86-compatible chip that first shipped after 2003-or-so and that is a
plausible candidate for Emacs. (Stefan's old laptop uses a circa-2001 chip.)
To get back to your question, many software projects already require SSE2 on
x86. This includes Chromium since build 35 (2014), Firefox since Firefox 53
(2017), and WebKit2GTK since version 2.24.0 (2019). Since Emacs links to
WebKit2GTK by default, recent Emacs by default already requires SSE2 on x86.
Similarly, many Gnome applications require SSE2 on x86, as they also link to
WebKit2GTK.
Among proprietary systems, Mac OS X on x86 (2006-2011) always required SSE2, and
MS-Windows development platforms have been requiring SSE2 by default since 2012,
which means pretty much every application built for 32-bit MS-Windows requires
SSE2 nowadays. Also, all supported MS-Windows operating systems have required
SSE2 since 2018, which is when Microsoft pushed out an update for MS-Windows 7
that required SSE2.
So it would not at all be outlandish for Emacs to default to requiring SSE2 on
GNU/Linux x86 (particularly since it does so already :-).
> . why didn't GCC folks made SSE2 the default output?
I suspect they think x86 is on its way out and not worth worrying about. Which
is a valid point of view. After all, Microsoft dropped distributing 32-bit
builds for MS-Windows starting with the May 2020 update, and they're pretty
conservative about this sort of thing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sun, 05 Jul 2020 08:40:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 42147 <at> debbugs.gnu.org (full text, mbox):
On Jul 05 2020, Paul Eggert wrote:
>> . why didn't GCC folks made SSE2 the default output?
>
> I suspect they think x86 is on its way out and not worth worrying
> about.
It all depends on how you configure it. You can make -mfpmath=sse the
default if you like, but gcc still supports pre-SSE2 configurations.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sun, 05 Jul 2020 09:57:01 GMT)
Full text and
rfc822 format available.
Message #152 received at 42147 <at> debbugs.gnu.org (full text, mbox):
On 7/4/20 11:37 AM, Pip Cet wrote:
> So it's a GCC bug? Wouldn't it be better to fix that?
Not without such a performance hit that nobody has wanted to do it. I expect it
would need software emulation for most floating-point operations.
Also, in theory the Linux kernel could emulate missing SSE2 instructions.
However, this is another workaround that nobody has wanted to do because it's
not worth the hassle to support these old CPUs.
> (The double-rounding issues you mention don't appear to be documented;
It's obvious from the generated code.
-fexcess-precision doesn't mean floating-point operations conform to IEEE-754
double; all it means is that floating-point values are representable as IEEE-754
double. This is why one cannot rely on -fexcess-precision=standard to get
reproducible results.
> The minor issue fixed by dropping support
> for pre-SSE x86 can, if I understand the GCC docs correctly, be evaded
> by making sure the C code does the appropriate amount of casting.
That won't suffice. On x87+387, GCC preserves excess precision through casts,
even if -ffloat-store is specified.
> SSE instructions require special OS support, too.
The Linux kernel has supported SSE2 since Linux 2.4 (2001). Any Linux kernel
that doesn't support SSE2 is so old that I suspect it won't run current Emacs
anyway, for other reasons.
> I also think it's unwise to establish that Emacs uses 64-bit IEEE-754
> floating point numbers exclusively.
What, will we switch to IBM mainframe floating-point format? :-)
Part of the problem we're trying to solve here is rounding discrepancies between
build-time and run-time computation. The idea is that an Elisp floating-point
operation should yield the same value regardless of whether it's byte-compiled
(or even machine-compiled, if we want to do that). Even if Emacs changed
floating-point format (by stealing a few bits for tags, say), we'd still run
into the same problem.
PS. I finally got around to benchmarking, and on my usual benchmark (make
compile-always, Fedora 31 x86), using SSE2 sped up Emacs by 4.6%. So there is a
performance argument for the change as well as a fix-the-rounding-glitches argument.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sun, 05 Jul 2020 10:04:01 GMT)
Full text and
rfc822 format available.
Message #155 received at 42147 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> PS. I finally got around to benchmarking, and on my usual benchmark (make
> compile-always, Fedora 31 x86), using SSE2 sped up Emacs by 4.6%. So there is a
> performance argument for the change as well as a fix-the-rounding-glitches argument.
Hi Paul,
Wow I'm really surprised by this result! Are we doing so much floating
point while compiling Emacs? I expected it to be very marginal,
possibly something else is boiling here we are not considering?
Regards
Andrea
--
akrl <at> sdf.org
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sun, 05 Jul 2020 13:01:02 GMT)
Full text and
rfc822 format available.
Message #158 received at 42147 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
4 juli 2020 kl. 18.13 skrev Andrea Corallo <andrea_corallo <at> yahoo.it>:
> (defun bbb ()
> (let ((x (list 1 2)))
> (f x) ; f is not pure
> (1+ (car x)) ; <= cannot optimize
> ))
(A more precise property for 'f' in your examples would be 'side-effect-free' rather than 'pure'.)
> BTW reading the code of the native compiler I realized I am already
> extrapolating for use a very similar list of optimizable functions to the one
> proposed. I still think would quite cleaner to classify these in
> byte-opt.el.
Certainly, but be sure to state your criteria with clarity. There must be no doubt whether or not a function should have a certain property!
> Attached the updated patch where I'm adding car, car-safe, cdr,
> cdr-safe, max, min.
Thank you Andrea! Attached is an update with the following modifications:
* I tried to segregate pure functions that operate on mutable objects, such as car, length and equal, from the rest. This way we can more easily separate them entirely (using different properties) later on if desired.
* The list of pure functions was expanded further. Related functions were grouped rather than ordered alphabetically, because I found it easier to read this way -- you may disagree.
* 'expt' was prudently removed because it doesn't necessarily give portable results for arbitrary floating-point arguments. (exp, sin etc were not included either for the same reason.)
* It turned out that in order to bootstrap, we have to prevent the constant evaluation in the byte compiler from raising errors on invalid input. For example, the macro dired-map-over-marks expands to (essentially)
(if (integerp ARG)
(< ARG 0)
where ARG is a macro argument that can be nil. Since < is now pure, compilation would fail despite the offending code being unreachable. As this style of code exists and is not unreasonable, the error has to be suppressed.
[0001-Mark-more-functions-pure-bug-42147.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sun, 05 Jul 2020 13:17:02 GMT)
Full text and
rfc822 format available.
Message #161 received at 42147 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård <mattiase <at> acm.org> writes:
> 4 juli 2020 kl. 18.13 skrev Andrea Corallo <andrea_corallo <at> yahoo.it>:
>
>> (defun bbb ()
>> (let ((x (list 1 2)))
>> (f x) ; f is not pure
>> (1+ (car x)) ; <= cannot optimize
>> ))
>
> (A more precise property for 'f' in your examples would be 'side-effect-free' rather than 'pure'.)
Right good point!
>> BTW reading the code of the native compiler I realized I am already
>> extrapolating for use a very similar list of optimizable functions to the one
>> proposed. I still think would quite cleaner to classify these in
>> byte-opt.el.
>
> Certainly, but be sure to state your criteria with clarity. There must be no doubt whether or not a function should have a certain property!
Absolutley, actually part of the scope of the patch in discussion (for
me) is exactly this given I'll just fetch this as a definition.
Thanks for improving the patch!
Andrea
--
akrl <at> sdf.org
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sun, 05 Jul 2020 14:48:02 GMT)
Full text and
rfc822 format available.
Message #164 received at 42147 <at> debbugs.gnu.org (full text, mbox):
> Cc: monnier <at> iro.umontreal.ca, mattiase <at> acm.org, andrea_corallo <at> yahoo.it,
> 42147 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sun, 5 Jul 2020 01:28:46 -0700
>
> On 7/4/20 7:38 PM, Eli Zaretskii wrote:
>
> > . which other projects use this non-standard instruction set?
>
> Wait a minute, SSE2 is not "non-standard". It was introduced in 2000 as part of
> the evolving Intel/AMD x86 instruction set, and is supported by pretty much
> every x86-compatible chip that first shipped after 2003-or-so and that is a
> plausible candidate for Emacs. (Stefan's old laptop uses a circa-2001 chip.)
That's not what I meant: I meant "non-standard" in the sense that the
compiler doesn't generate these instructions by default when dealing
with FP calculations.
> To get back to your question, many software projects already require SSE2 on
> x86. This includes Chromium since build 35 (2014), Firefox since Firefox 53
> (2017), and WebKit2GTK since version 2.24.0 (2019). Since Emacs links to
> WebKit2GTK by default, recent Emacs by default already requires SSE2 on x86.
> Similarly, many Gnome applications require SSE2 on x86, as they also link to
> WebKit2GTK.
>
> Among proprietary systems, Mac OS X on x86 (2006-2011) always required SSE2, and
> MS-Windows development platforms have been requiring SSE2 by default since 2012,
> which means pretty much every application built for 32-bit MS-Windows requires
> SSE2 nowadays. Also, all supported MS-Windows operating systems have required
> SSE2 since 2018, which is when Microsoft pushed out an update for MS-Windows 7
> that required SSE2.
Thanks, I knew all that. Emacs is not an OS, it's an application, and
the issue here is about using these instructions for FP calculations,
not for anything else. That was what I was asking about: applications
doing FP math.
> > . why didn't GCC folks made SSE2 the default output?
>
> I suspect they think x86 is on its way out and not worth worrying about.
Then why won't we do the same, and simply ignore the issue? We have
enough real development and maintenance work on our hands. Making
non-trivial change in the code we produce for Emacs, for the benefit
of (at best) insignificant speed improvement on a dying platform,
while risking breakage for at least some systems, is not a good use of
our scarce resources, IMO.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sun, 05 Jul 2020 15:12:01 GMT)
Full text and
rfc822 format available.
Message #167 received at 42147 <at> debbugs.gnu.org (full text, mbox):
> Since Emacs links to WebKit2GTK by default,
I don't believe this is the case.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sun, 05 Jul 2020 15:27:02 GMT)
Full text and
rfc822 format available.
Message #170 received at 42147 <at> debbugs.gnu.org (full text, mbox):
4 juli 2020 kl. 17.06 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:
>
>> Thanks -- patch attached. Some expressions will still not be constant-folded
>> entirely; for example
>
> LGTM,
Thank you, pushed to master.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sun, 05 Jul 2020 15:32:02 GMT)
Full text and
rfc822 format available.
Message #173 received at 42147 <at> debbugs.gnu.org (full text, mbox):
> That's not what I meant: I meant "non-standard" in the sense that the
> compiler doesn't generate these instructions by default when dealing
> with FP calculations.
It depends on the architecture you generate for.
It's clear that when that architecture is too old to include SSE2
instructions, GCC won't use SSE2 instructions (tho it still could at the cost
of runtime tests for the presence of the feature).
I don't know what GCC does if the target architecture is recent enough
to include SSE2, but I'd expect it to then use SSE2 for most/all
floating point operations since it generally leads to more efficient
code (and it's easier for GCC to generate efficient code with it).
>> I suspect they think x86 is on its way out and not worth worrying about.
> Then why won't we do the same, and simply ignore the issue?
Sounds good to me,
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sun, 05 Jul 2020 23:58:02 GMT)
Full text and
rfc822 format available.
Message #176 received at 42147 <at> debbugs.gnu.org (full text, mbox):
On 7/5/20 3:03 AM, Andrea Corallo wrote:
> Wow I'm really surprised by this result! Are we doing so much floating
> point while compiling Emacs?
No, and you are right to be skeptical. I checked again, and unfortunately I
originally measured the performance incorrectly, as I used a script that I had
forgotten adds '-march=native' which makes the benchmark results not reflect
what distros normally do (unless one is assuming something like Gentoo which is
far less common).
When I removed -march=native and stuck with just CC='gcc -m32' versus CC='gcc
-m32 -msse2 -mfpmath=sse', the performance difference went the other way on my
AMD Phenom II X4 910e (2010): the version generated with -msse2 -mfpmath=sse was
3.7% slower on the 'make compile-always' benchmark.
I suppose it's possible both of these numbers are artifacts, though I don't know
what would cause the artifacts. At any rate obviously I was wrong to suggest
that -msse2 improves performance on this benchmark. Sorry about the noise.
On 7/5/20 8:07 AM, Stefan Monnier wrote:
> Could it be that your measurements also included the time spent
> compiling C files and that GCC is significantly faster at generating
> code for SSE2?
I do a plain 'make' before running 'cd lisp; make compile-always' so GCC is not
involved; it's mostly an Emacs byte-compiler benchmark.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Mon, 06 Jul 2020 00:11:02 GMT)
Full text and
rfc822 format available.
Message #179 received at 42147 <at> debbugs.gnu.org (full text, mbox):
On 7/5/20 8:11 AM, Stefan Monnier wrote:
>> Since Emacs links to WebKit2GTK by default,
> I don't believe this is the case.
Oh, you're right. I mistakenly assumed Fedora used a default configuration, ran
"ldd /usr/bin/emacs", and saw libwebkit2gtk-4.0.so.37, so I thought WebKit2GTK
was in by default.
To get WebKit2GTK linked, one must configure Emacs with --with-xwidgets. Fedora
does that, so their x86 Emacs would require SSE2 if they still supported x86.
Which they do not - they dropped support for x86 in Fedora 31 (2019).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Mon, 06 Jul 2020 00:15:02 GMT)
Full text and
rfc822 format available.
Message #182 received at 42147 <at> debbugs.gnu.org (full text, mbox):
On 7/5/20 8:30 AM, Stefan Monnier wrote:
>>> I suspect they think x86 is on its way out and not worth worrying about.
>> Then why won't we do the same, and simply ignore the issue?
> Sounds good to me,
Me too. I assume this means we needn't worry about the x86 rounding glitches,
except perhaps to document them. So we can fold constant expressions involving
floating point without worrying abouth these glitches.
For sanity's sake, we should generate Emacs tarballs on a platform other than
GNU/Linux x86, which is a pretty easy bit of advice to follow as hardly anybody
runs that platform for software development nowadays.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Mon, 06 Jul 2020 17:21:01 GMT)
Full text and
rfc822 format available.
Message #185 received at 42147 <at> debbugs.gnu.org (full text, mbox):
5 juli 2020 kl. 15.16 skrev Andrea Corallo <akrl <at> sdf.org>:
> Absolutley, actually part of the scope of the patch in discussion (for
> me) is exactly this given I'll just fetch this as a definition.
Very good, it looks like we are all set then. I've pushed that patch and a follow-up that removes explicit optimisation functions that no longer are useful with the added pure functions.
Are you happy with this resolution, or is there anything else that needs our attention?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Mon, 06 Jul 2020 21:24:02 GMT)
Full text and
rfc822 format available.
Message #188 received at 42147 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård <mattiase <at> acm.org> writes:
> 5 juli 2020 kl. 15.16 skrev Andrea Corallo <akrl <at> sdf.org>:
>
>> Absolutley, actually part of the scope of the patch in discussion (for
>> me) is exactly this given I'll just fetch this as a definition.
>
> Very good, it looks like we are all set then. I've pushed that patch
> and a follow-up that removes explicit optimisation functions that no
> longer are useful with the added pure functions.
Great, the branch I'm working on is already based on your commit
therefore I was looking forward to see it on master.
> Are you happy with this resolution, or is there anything else that needs our attention?
Yes I am happy :) Not sure about the floating point discussion
originated from this but on my side this bug can be closed.
Thanks
Andrea
Reply sent
to
Mattias Engdegård <mattiase <at> acm.org>:
You have taken responsibility.
(Tue, 07 Jul 2020 15:56:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Andrea Corallo <andrea_corallo <at> yahoo.it>:
bug acknowledged by developer.
(Tue, 07 Jul 2020 15:56:02 GMT)
Full text and
rfc822 format available.
Message #193 received at 42147-done <at> debbugs.gnu.org (full text, mbox):
6 juli 2020 kl. 23.23 skrev Andrea Corallo <andrea_corallo <at> yahoo.it>:
> Yes I am happy :) Not sure about the floating point discussion
> originated from this but on my side this bug can be closed.
Then closed it is. I would happily write something in NEWS but -- as Eli noted -- for any noticeable change in behaviour to occur, many conditions need to be met, several of which are quite unlikely.
More improvements to the constant-folding are possible and desirable. For example, I have a patch that deals with constant expressions in let-bindings, so that
(let ((x (+ 1 2)))
(f x))
simplifies to (f 3), with the variable x removed. This in turn generates more opportunities for further simplification and dead-code elimination. Tell me if you are interested.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Tue, 07 Jul 2020 16:25:02 GMT)
Full text and
rfc822 format available.
Message #196 received at 42147-done <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård <mattiase <at> acm.org> writes:
> 6 juli 2020 kl. 23.23 skrev Andrea Corallo <andrea_corallo <at> yahoo.it>:
>
>> Yes I am happy :) Not sure about the floating point discussion
>> originated from this but on my side this bug can be closed.
>
> Then closed it is. I would happily write something in NEWS but -- as
> Eli noted -- for any noticeable change in behaviour to occur, many
> conditions need to be met, several of which are quite unlikely.
>
> More improvements to the constant-folding are possible and desirable. For example, I have a patch that deals with constant expressions in let-bindings, so that
>
> (let ((x (+ 1 2)))
> (f x))
>
> simplifies to (f 3), with the variable x removed. This in turn
> generates more opportunities for further simplification and dead-code
> elimination. Tell me if you are interested.
Sure I'm. The native compiler does it already but I'm curious to see
how you do it at source level and how generic it is.
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Tue, 07 Jul 2020 16:57:01 GMT)
Full text and
rfc822 format available.
Message #199 received at 42147-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
7 juli 2020 kl. 18.24 skrev Andrea Corallo <andrea_corallo <at> yahoo.it>:
> Sure I'm. The native compiler does it already but I'm curious to see
> how you do it at source level and how generic it is.
Not very, but doing it at source level has some advantages since it can enable other source-level transformations.
It's mainly a proof of concept -- for simplicity, it doesn't attempt to be overly clever in the face of loops or setq.
One snag is that because Emacs inline functions (defsubst) are inlined as bytecode, they are usually not amenable to source optimisations. It is only when a defsubst is imported from a different .el file that has not yet been byte-compiled that it is integrated as source, and then the machinery in this patch will nicely propagate constant arguments into the body.
[0001-Constprop-of-lexical-variables.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Tue, 07 Jul 2020 17:43:02 GMT)
Full text and
rfc822 format available.
Message #202 received at 42147-done <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård <mattiase <at> acm.org> writes:
> 7 juli 2020 kl. 18.24 skrev Andrea Corallo <andrea_corallo <at> yahoo.it>:
>
>> Sure I'm. The native compiler does it already but I'm curious to see
>> how you do it at source level and how generic it is.
>
> Not very, but doing it at source level has some advantages since it can enable other source-level transformations.
> It's mainly a proof of concept -- for simplicity, it doesn't attempt to be overly clever in the face of loops or setq.
>
> One snag is that because Emacs inline functions (defsubst) are inlined
> as bytecode, they are usually not amenable to source optimisations. It
> is only when a defsubst is imported from a different .el file that has
> not yet been byte-compiled that it is integrated as source, and then
> the machinery in this patch will nicely propagate constant arguments
> into the body.
Well loops and setq without CFG IMO are likely to be difficult if not
impossible to optimize in a generic way. But I agree that having a
simple optimization done earlier is always better given it can benefit
other ones.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Wed, 08 Jul 2020 19:16:01 GMT)
Full text and
rfc822 format available.
Message #205 received at 42147-done <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård <mattiase <at> acm.org> writes:
> +(defun byte-optimize--substitutable-p (expr)
> + "Whether EXPR is a constant that can be propagated."
> + ;; Only consider numbers, symbols and strings to be values for substitution
> + ;; purposes. Numbers and symbols are immutable, and mutating string
> + ;; literals (or results from constant-evaluated string-returning functions)
> + ;; can be considered undefined.
> + ;; (What about other quoted values, like conses?)
> + (or (booleanp expr)
> + (numberp expr)
> + (stringp expr)
> + (and (consp expr)
> + (eq (car expr) 'quote)
> + (symbolp (cadr expr)))
> + (keywordp expr)))
Hi Mattias,
in the branch I'm working I've a function similar in scope to this so
reading your patch this got my attention.
In my version I assumed (after a look to the manual) to have strings to
be immutable only at speed 3. Is it safe to assume this always instead?
Also I wanted ask why symbols are not included but only keywords, is
this to respect the side effect of interning them or something else?
Thanks!
Andrea
--
akrl <at> sdf.org
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Wed, 08 Jul 2020 21:27:02 GMT)
Full text and
rfc822 format available.
Message #208 received at 42147-done <at> debbugs.gnu.org (full text, mbox):
Hello Andrea,
> In my version I assumed (after a look to the manual) to have strings to
> be immutable only at speed 3. Is it safe to assume this always instead?
Ultimately it depends on the transformations you do, but yes: this patch substitutes let-bound names for their values, and since the behaviour of mutating string literals is undefined, it's safe. Consider:
(let ((s "abc"))
(f s)
s)
It doesn't matter what 'f' does; since it isn't permitted to mutate its argument string, the transformation to
(progn (f "abc") "abc")
is safe (assuming lexical binding, since f could otherwise set s to something else).
> Also I wanted ask why symbols are not included but only keywords, is
> this to respect the side effect of interning them or something else?
Symbols are included, but since this is (normalised) Lisp source, plain symbols are variables; constants of symbol type are represented as (quote SYM), matched by the and-expression. Keywords are just symbols whose name begin with a colon, like :chocolate, and need no quoting.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Wed, 08 Jul 2020 22:20:02 GMT)
Full text and
rfc822 format available.
Message #211 received at 42147-done <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård <mattiase <at> acm.org> writes:
> Hello Andrea,
>
>> In my version I assumed (after a look to the manual) to have strings to
>> be immutable only at speed 3. Is it safe to assume this always instead?
>
> Ultimately it depends on the transformations you do, but yes: this
> patch substitutes let-bound names for their values, and since the
> behaviour of mutating string literals is undefined, it's
> safe. Consider:
>
> (let ((s "abc"))
> (f s)
> s)
>
> It doesn't matter what 'f' does; since it isn't permitted to mutate its argument string, the transformation to
>
> (progn (f "abc") "abc")
>
> is safe (assuming lexical binding, since f could otherwise set s to something else).
Understand, in your code this predicate is used for substitution
therefore is just correct to substitute with the original object.
In mine is governating the objects we can materialize with const folding
so I had it a little stricter. But this raise to me another doubt on
the topic that is: why don't we have the same in the byte-compiler?
That is:
(defun foo (x)
(concat "bar" "foo"))
is byte compiled optimizing on `concat' because pure. But doing that
the resulting string "barfoo" becomes immutable.
I'd expect "barfoo" to be mutable because without optimizations the
allocation would be done in the run-time. In general how I imagined the
thing is that we can optimize only pure functions returning immutable
objects to avoid the risk of unexpectedly creating objects that should
not be changed.
Or is it maybe that the only way to certainly have a mutable string is
with `copy-sequence' or `make-string'?
>> Also I wanted ask why symbols are not included but only keywords, is
>> this to respect the side effect of interning them or something else?
>
> Symbols are included, but since this is (normalised) Lisp source,
> plain symbols are variables; constants of symbol type are represented
> as (quote SYM), matched by the and-expression. Keywords are just
> symbols whose name begin with a colon, like :chocolate, and need no
> quoting.
Understand
It's a little late hope I'm not talking stupid, thanks for your
patience.
Andrea
--
akrl <at> sdf.org
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Thu, 09 Jul 2020 10:22:01 GMT)
Full text and
rfc822 format available.
Message #214 received at 42147-done <at> debbugs.gnu.org (full text, mbox):
9 juli 2020 kl. 00.19 skrev Andrea Corallo <akrl <at> sdf.org>:
> Or is it maybe that the only way to certainly have a mutable string is
> with `copy-sequence' or `make-string'?
Yes; since the need for a mutable value is very unlikely, creating a fresh copy every time just in case would be a big waste of resources. Otherwise, we could only 'optimise'
(concat "abc" "def")
to
(copy-sequence "abcdef")
which would be a very modest improvement, for very little gain.
The two functions you mentioned are indeed guaranteed to return fresh, mutable strings and thus cannot be marked 'pure'.
String mutation is something of a special case: it is rare, yet its mere possibility incurs costs even for code that doesn't use it. Better try to keep that cost to a minimum.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Thu, 09 Jul 2020 12:48:01 GMT)
Full text and
rfc822 format available.
Message #217 received at 42147-done <at> debbugs.gnu.org (full text, mbox):
> String mutation is something of a special case: it is rare, yet its mere
> possibility incurs costs even for code that doesn't use it.
Yes and no: it's *very* rare to change the sequence of characters which
compose a string, yes, but until the addition of `propertize` (in
Emacs-21) mutation was the only way to add text-properties to a string,
so it's still quite common.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Thu, 09 Jul 2020 12:58:02 GMT)
Full text and
rfc822 format available.
Message #220 received at 42147-done <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> String mutation is something of a special case: it is rare, yet its mere
>> possibility incurs costs even for code that doesn't use it.
>
> Yes and no: it's *very* rare to change the sequence of characters which
> compose a string, yes, but until the addition of `propertize` (in
> Emacs-21) mutation was the only way to add text-properties to a string,
> so it's still quite common.
Hi Stefan,
What's your suggestion on this optimization? Do you think can be on with
default settings or is it dangerous?
Andrea
--
akrl <at> sdf.org
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Thu, 09 Jul 2020 14:37:02 GMT)
Full text and
rfc822 format available.
Message #223 received at 42147-done <at> debbugs.gnu.org (full text, mbox):
> What's your suggestion on this optimization? Do you think can be on with
> default settings or is it dangerous?
AFAICT it's been on since Emacs-21, which seems to argue for "not too dangerous".
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Thu, 09 Jul 2020 15:20:02 GMT)
Full text and
rfc822 format available.
Message #226 received at 42147-done <at> debbugs.gnu.org (full text, mbox):
On 7/9/20 7:35 AM, Stefan Monnier wrote:
> AFAICT it's been on since Emacs-21, which seems to argue for "not too dangerous".
I feel the same way.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Thu, 09 Jul 2020 15:39:01 GMT)
Full text and
rfc822 format available.
Message #229 received at 42147-done <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> What's your suggestion on this optimization? Do you think can be on with
>> default settings or is it dangerous?
>
> AFAICT it's been on since Emacs-21, which seems to argue for "not too dangerous".
Great, thanks both for your suggestions.
BTW IMO if the only way to *certainly* get a mutable string is with
`copy-sequence' or `make-string' I think we could document it. Is a
simple rule easy to understand and clarifies the situation.
Andrea
--
akrl <at> sdf.org
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 25 Jul 2020 17:10:02 GMT)
Full text and
rfc822 format available.
Message #232 received at 42147 <at> debbugs.gnu.org (full text, mbox):
Am Fr., 3. Juli 2020 um 11:25 Uhr schrieb Mattias Engdegård <mattiase <at> acm.org>:
>
> 2 juli 2020 kl. 21.09 skrev Philipp Stephani <p.stephani2 <at> gmail.com>:
>
> > I don't think most of those are pure, as they have to "look into" an
> > object. For example, the result of "equal" does not only depend on the
> > argument objects, but also the objects they refer to.
>
> Unless I'm mistaken, they are pure enough for the purpose of constant folding, where the arguments are already known (constant) at compile-time; do come with a counter-example if you disagree.
>
> Were you thinking about other uses of pure functions? Perhaps our notion of purity is underspecified.
>
Yes, I think so. The term is mentioned in the Lisp manual, but I've
always had trouble deciding whether a given function was pure or not.
To be useful, the definition shouldn't depend on what the byte
compiler happens to do; rather, we need to formally define purity (and
side effect-freedom) based on the observable behavior of the function
in question alone and then adapt the behavior of the byte compiler to
the definition, if necessary.
My working hypothesis is that "pure" is like GCC's "const"
(https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html)
and "side-effect free" is like GCC's "pure." That is, a side-effect
free function can dereference pointers stored in Lisp_Objects, but a
pure function can't. So functions like consp or eq are pure, while car
or equal are merely side-effect free. eql is a bit of an exception, as
floating-point objects and big integers are truly immutable, so it
probably also qualifies as pure using this definition.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 25 Jul 2020 18:12:01 GMT)
Full text and
rfc822 format available.
Message #235 received at 42147 <at> debbugs.gnu.org (full text, mbox):
> and "side-effect free" is like GCC's "pure." That is, a side-effect
> free function can dereference pointers stored in Lisp_Objects, but a
> pure function can't.
I think it's still not very satisfactory since it's written in terms of
low-level operations in the C code.
I think the current intention of our "pure" goes something along the
lines of: the function will always return the "same" (the sense of `eql`)
value (or signal the same error) when called with `eql` arguments.
IOW "the function preserves `eql`ity".
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 25 Jul 2020 20:04:01 GMT)
Full text and
rfc822 format available.
Message #238 received at 42147 <at> debbugs.gnu.org (full text, mbox):
Am Sa., 25. Juli 2020 um 20:10 Uhr schrieb Stefan Monnier
<monnier <at> iro.umontreal.ca>:
>
> > and "side-effect free" is like GCC's "pure." That is, a side-effect
> > free function can dereference pointers stored in Lisp_Objects, but a
> > pure function can't.
>
> I think it's still not very satisfactory since it's written in terms of
> low-level operations in the C code.
Agreed, I'd rather think of this hypothesis as a first step towards a
definition that we can put into the manual.
>
> I think the current intention of our "pure" goes something along the
> lines of: the function will always return the "same" (the sense of `eql`)
> value (or signal the same error) when called with `eql` arguments.
> IOW "the function preserves `eql`ity".
>
That sounds like a very reasonable definition. Do you think it's
equivalent to my hypothesis and/or to the current behavior of the byte
optimizer? Is it a complete definition in the sense that it gives an
unambiguous yes/no answer for every current and future function?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 25 Jul 2020 20:09:02 GMT)
Full text and
rfc822 format available.
Message #241 received at 42147 <at> debbugs.gnu.org (full text, mbox):
> That sounds like a very reasonable definition. Do you think it's
> equivalent to my hypothesis and/or to the current behavior of the byte
> optimizer?
Probably not exactly: there might be functions which don't always
"preserve `eql`" but for which we decide nevertheless that it's OK to
precompute them at compile time for pragmatic reasons.
E.g. `concat`.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 25 Jul 2020 20:13:02 GMT)
Full text and
rfc822 format available.
Message #244 received at 42147 <at> debbugs.gnu.org (full text, mbox):
Am Sa., 25. Juli 2020 um 22:07 Uhr schrieb Stefan Monnier
<monnier <at> iro.umontreal.ca>:
>
> > That sounds like a very reasonable definition. Do you think it's
> > equivalent to my hypothesis and/or to the current behavior of the byte
> > optimizer?
>
> Probably not exactly: there might be functions which don't always
> "preserve `eql`" but for which we decide nevertheless that it's OK to
> precompute them at compile time for pragmatic reasons.
>
> E.g. `concat`.
I don't think we can really do that, as that would allow the byte
compiler to introduce bugs in the code, right? The manual states that
"This function [concat] always constructs a new string that is not
‘eq’ to any existing string" so I don't see how it could ever be pure.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 25 Jul 2020 21:01:01 GMT)
Full text and
rfc822 format available.
Message #247 received at 42147 <at> debbugs.gnu.org (full text, mbox):
25 juli 2020 kl. 22.11 skrev Philipp Stephani <p.stephani2 <at> gmail.com>:
> The manual states that
> "This function [concat] always constructs a new string that is not
> ‘eq’ to any existing string" so I don't see how it could ever be pure.
Actually that part of the manual was corrected fairly recently, as that statement hasn't been true for decades.
More to the point, the current set of functions marked as 'pure' are really the superset 'pure-absent-mutation': functions that are pure when it can be assumed that the arguments are not modified. This assumption can be based on physical immutability (integers), by convention (string constants), or anything else the compiler can prove such as control flow.
There is also the question of what equality to use and here the answer is probably 'equal' since we are only dealing with immutables. (The return values of these functions cannot be considered mutable for obvious reasons, so make-string is out.)
If you want to rename the property accordingly then I won't object. In any case, it is certainly a good idea to be precise about what the various sets really mean.
There are also some functions declared 'pure' that appear to have side effects: kbd, package-get-version
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 25 Jul 2020 21:10:02 GMT)
Full text and
rfc822 format available.
Message #250 received at 42147 <at> debbugs.gnu.org (full text, mbox):
> I don't think we can really do that, as that would allow the byte
> compiler to introduce bugs in the code, right? The manual states that
> "This function [concat] always constructs a new string that is not
> ‘eq’ to any existing string" so I don't see how it could ever be pure.
And yet, `concat` has been marked as "pure" even before we introduced
the notion of pure. More specifically, the code in byte-opt.el which
optimizes calls to pure functions was originally written exclusively for
`concat`:
commit 79d137ffe7dac5fe3041b4916c715f4ce91143af
Author: Karl Heuer <kwzh <at> gnu.org>
Date: Mon Nov 3 03:58:23 1997 +0000
(byte-optimize-concat): New function.
followed by:
commit e856a453a1c1ce1907b3b582841bce3e9cff8cec
Author: Stefan Monnier <monnier <at> iro.umontreal.ca>
Date: Mon Mar 22 15:21:08 2004 +0000
(byte-compile-log-lap, byte-compile-inline-expand): Use backquote.
(byte-optimize-pure-func): Rename from byte-optimize-concat.
(symbol-name, regexp-opt, regexp-quote): Mark as pure.
-- Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 25 Jul 2020 21:30:02 GMT)
Full text and
rfc822 format available.
Message #253 received at 42147 <at> debbugs.gnu.org (full text, mbox):
> There are also some functions declared 'pure' that appear to have side
> effects: kbd, package-get-version
Which side-effects are you thinking of?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 25 Jul 2020 21:40:02 GMT)
Full text and
rfc822 format available.
Message #256 received at 42147 <at> debbugs.gnu.org (full text, mbox):
Am Sa., 25. Juli 2020 um 23:29 Uhr schrieb Stefan Monnier
<monnier <at> iro.umontreal.ca>:
>
> > There are also some functions declared 'pure' that appear to have side
> > effects: kbd, package-get-version
>
> Which side-effects are you thinking of?
>
I wouldn't know about side effects, but `kbd' is definitely not pure
by the "homomorphism w.r.t. eql" definition as it takes a string
argument.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 25 Jul 2020 21:55:01 GMT)
Full text and
rfc822 format available.
Message #259 received at 42147 <at> debbugs.gnu.org (full text, mbox):
25 juli 2020 kl. 23.29 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:
>
>> There are also some functions declared 'pure' that appear to have side
>> effects: kbd, package-get-version
>
> Which side-effects are you thinking of?
They both clobber the match data. Not that it matters for the purpose of compile-time evaluation, but we were discussing exact definitions.
('package-get-version' does a lot more but at least it admits to lying in a comment, so I suppose that's all right then.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 25 Jul 2020 22:28:02 GMT)
Full text and
rfc822 format available.
Message #262 received at 42147 <at> debbugs.gnu.org (full text, mbox):
>> > There are also some functions declared 'pure' that appear to have side
>> > effects: kbd, package-get-version
>>
>> Which side-effects are you thinking of?
>>
>
> I wouldn't know about side effects, but `kbd' is definitely not pure
> by the "homomorphism w.r.t. eql" definition as it takes a string
> argument.
Taking string arguments is not a problem (`eql` strings are also
`equal`). It's returning a fresh new string/vector that is a problem
(which also affects `kbd`, indeed).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sat, 25 Jul 2020 22:31:01 GMT)
Full text and
rfc822 format available.
Message #265 received at 42147 <at> debbugs.gnu.org (full text, mbox):
>>> There are also some functions declared 'pure' that appear to have side
>>> effects: kbd, package-get-version
>> Which side-effects are you thinking of?
> They both clobber the match data.
It's not a problem w.r.t optimizing pure functions, tho: those functions
don't promise to modify the match data, so it's OK to replace calls to
them with their return value.
But yes, it's a problem because `C-h o kbd RET` says explicitly that it
doesn't change the match data :-(
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Sun, 26 Jul 2020 09:07:01 GMT)
Full text and
rfc822 format available.
Message #268 received at 42147 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
26 juli 2020 kl. 00.30 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:
> But yes, it's a problem because `C-h o kbd RET` says explicitly that it
> doesn't change the match data :-(
Motivation enough for them to save the match data then.
What about the attached patch?
[0001-Preserve-match-data-in-kbd-and-package-get-version.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Wed, 29 Jul 2020 12:55:02 GMT)
Full text and
rfc822 format available.
Message #271 received at 42147 <at> debbugs.gnu.org (full text, mbox):
Am So., 26. Juli 2020 um 00:27 Uhr schrieb Stefan Monnier
<monnier <at> iro.umontreal.ca>:
>
> >> > There are also some functions declared 'pure' that appear to have side
> >> > effects: kbd, package-get-version
> >>
> >> Which side-effects are you thinking of?
> >>
> >
> > I wouldn't know about side effects, but `kbd' is definitely not pure
> > by the "homomorphism w.r.t. eql" definition as it takes a string
> > argument.
>
> Taking string arguments is not a problem (`eql` strings are also
> `equal`).
Only if the strings aren't modified between two invocations.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Wed, 29 Jul 2020 13:11:02 GMT)
Full text and
rfc822 format available.
Message #274 received at 42147 <at> debbugs.gnu.org (full text, mbox):
Am Sa., 25. Juli 2020 um 23:00 Uhr schrieb Mattias Engdegård <mattiase <at> acm.org>:
>
> 25 juli 2020 kl. 22.11 skrev Philipp Stephani <p.stephani2 <at> gmail.com>:
>
> > The manual states that
> > "This function [concat] always constructs a new string that is not
> > ‘eq’ to any existing string" so I don't see how it could ever be pure.
>
> Actually that part of the manual was corrected fairly recently, as that statement hasn't been true for decades.
>
> More to the point, the current set of functions marked as 'pure' are really the superset 'pure-absent-mutation': functions that are pure when it can be assumed that the arguments are not modified. This assumption can be based on physical immutability (integers), by convention (string constants), or anything else the compiler can prove such as control flow.
>
> There is also the question of what equality to use and here the answer is probably 'equal' since we are only dealing with immutables. (The return values of these functions cannot be considered mutable for obvious reasons, so make-string is out.)
>
> If you want to rename the property accordingly then I won't object. In any case, it is certainly a good idea to be precise about what the various sets really mean.
It looks like these are really two separate concepts, which should be
documented separately and should get separate function properties:
- Fully-pure functions are guaranteed to either return results that
are "eql" or signal error data that is "equal-including-properties"
when given arguments that are pairwise "eql", for all possible
arguments, mutable or not.
- Pure-unless-mutable functions are a strict superset whose
restrictions to immutable arguments are guaranteed to either return
results or signal error data that are "equal-including-properties"
when given arguments that are immutable and pairwise
"equal-including-properties".
Both categories must be free of observable side effects as well.
>
> There are also some functions declared 'pure' that appear to have side effects: kbd, package-get-version
>
kbd can and should be made pure-unless-mutable at least.
package-get-version should be neither, but should be marked using a
third to-be-introduced property (e.g. "eval-when-compile") to state
the intention without resorting to hacks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Wed, 29 Jul 2020 14:29:01 GMT)
Full text and
rfc822 format available.
Message #277 received at 42147 <at> debbugs.gnu.org (full text, mbox):
>> > I wouldn't know about side effects, but `kbd' is definitely not pure
>> > by the "homomorphism w.r.t. eql" definition as it takes a string
>> > argument.
>> Taking string arguments is not a problem (`eql` strings are also `equal`).
> Only if the strings aren't modified between two invocations.
Indeed, you're right. In practice this is not a problem, for all kinds
of circumstantial reasons, but in theory you're quite right.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Wed, 29 Jul 2020 16:04:01 GMT)
Full text and
rfc822 format available.
Message #280 received at 42147 <at> debbugs.gnu.org (full text, mbox):
>> But yes, it's a problem because `C-h o kbd RET` says explicitly that it
>> doesn't change the match data :-(
>
> Motivation enough for them to save the match data then.
I pushed the save-match-data around 'kbd' since that one looked rather obvious.
Regarding package-get-version: perhaps we should drop the 'pure' property and just let callers wrap it in eval-when-compile?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Wed, 29 Jul 2020 20:41:02 GMT)
Full text and
rfc822 format available.
Message #283 received at 42147 <at> debbugs.gnu.org (full text, mbox):
> Regarding package-get-version: perhaps we should drop the 'pure' property
> and just let callers wrap it in eval-when-compile?
I'd rather not: the benefit is too subtle, I'd expect most users won't
know/bother to use `eval-when-compile` around it even though I'd expect
a vast majority of the uses can benefit from compile-time evaluation.
In contrast the cases where the impurity will get in the way
should be rare. Feel free to add a `save-match-data` if you think it's
worth the trouble (but please include a comment explaining it's only
there in order to satisfy the `pure` annotation).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Mon, 03 Aug 2020 15:08:02 GMT)
Full text and
rfc822 format available.
Message #286 received at 42147 <at> debbugs.gnu.org (full text, mbox):
29 juli 2020 kl. 22.39 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:
>
>> Regarding package-get-version: perhaps we should drop the 'pure' property
>> and just let callers wrap it in eval-when-compile?
>
> I'd rather not: the benefit is too subtle, I'd expect most users won't
> know/bother to use `eval-when-compile` around it even though I'd expect
> a vast majority of the uses can benefit from compile-time evaluation.
> In contrast the cases where the impurity will get in the way
> should be rare. Feel free to add a `save-match-data` if you think it's
> worth the trouble (but please include a comment explaining it's only
> there in order to satisfy the `pure` annotation).
Thank you, I'll let you make the decision since you introduced the function. Another possibility would be to turn it into a macro again (or more likely a macro that calls a function at compile-time), or use define-inline.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Mon, 10 Aug 2020 13:40:01 GMT)
Full text and
rfc822 format available.
Message #289 received at 42147 <at> debbugs.gnu.org (full text, mbox):
Am Mo., 3. Aug. 2020 um 17:07 Uhr schrieb Mattias Engdegård <mattiase <at> acm.org>:
>
> 29 juli 2020 kl. 22.39 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:
> >
> >> Regarding package-get-version: perhaps we should drop the 'pure' property
> >> and just let callers wrap it in eval-when-compile?
> >
> > I'd rather not: the benefit is too subtle, I'd expect most users won't
> > know/bother to use `eval-when-compile` around it even though I'd expect
> > a vast majority of the uses can benefit from compile-time evaluation.
> > In contrast the cases where the impurity will get in the way
> > should be rare. Feel free to add a `save-match-data` if you think it's
> > worth the trouble (but please include a comment explaining it's only
> > there in order to satisfy the `pure` annotation).
>
> Thank you, I'll let you make the decision since you introduced the function. Another possibility would be to turn it into a macro again (or more likely a macro that calls a function at compile-time), or use define-inline.
>
Another option would be to create a separate function property (such
as `eval-when-compile' or `force-inline') that would force the byte
compiler to inline each call, as if surrounded by `eval-when-compile'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Mon, 10 Aug 2020 13:44:02 GMT)
Full text and
rfc822 format available.
Message #292 received at 42147 <at> debbugs.gnu.org (full text, mbox):
Am Mi., 29. Juli 2020 um 22:39 Uhr schrieb Stefan Monnier
<monnier <at> iro.umontreal.ca>:
>
> > Regarding package-get-version: perhaps we should drop the 'pure' property
> > and just let callers wrap it in eval-when-compile?
>
> I'd rather not: the benefit is too subtle, I'd expect most users won't
> know/bother to use `eval-when-compile` around it even though I'd expect
> a vast majority of the uses can benefit from compile-time evaluation.
> In contrast the cases where the impurity will get in the way
> should be rare.
Arguments relating to probabilities ("most users", "vast majority",
"rare") don't really apply here, as the discussion is about
correctness. A pure function must be pure 100% of the time, no
exceptions allowed. `package-get-version' can't possibly be pure: it
doesn't take any argument, so if it were pure, it would have to return
a constant in the mathematical sense.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Mon, 10 Aug 2020 22:08:01 GMT)
Full text and
rfc822 format available.
Message #295 received at 42147 <at> debbugs.gnu.org (full text, mbox):
> Another option would be to create a separate function property (such
> as `eval-when-compile' or `force-inline') that would force the byte
> compiler to inline each call, as if surrounded by `eval-when-compile'.
It can't always be done, so I think from that point of view what we have
is fine, the only problem is that we don't have a way to say "this can
be considered as pure by the compiler" without also saying "this doesn't
change the march-data".
So maybe a new value of `pure` is in order?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42147; Package
emacs.
(Mon, 10 Aug 2020 22:11:01 GMT)
Full text and
rfc822 format available.
Message #298 received at 42147 <at> debbugs.gnu.org (full text, mbox):
> Arguments relating to probabilities ("most users", "vast majority",
> "rare") don't really apply here, as the discussion is about
> correctness. A pure function must be pure 100% of the time, no
> exceptions allowed. `package-get-version' can't possibly be pure: it
> doesn't take any argument, so if it were pure, it would have to return
> a constant in the mathematical sense.
It's a borderline case: it's designed such that if the compiler
pre-evaluates it, the result will indeed be the same as if it were
evaluated later at run-time.
So it's correct w.r.t "allow constant-folding", even tho it's not
"pure".
Stefan
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 08 Sep 2020 11:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 229 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.