[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium
From: |
Andrea Corallo |
Subject: |
Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium |
Date: |
Sat, 02 May 2020 09:48:15 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
Richard Stallman <address@hidden> writes:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > We can always discuss the dynamic binding support but has also to be
> > considered that the performance uplift is expected to be smaller for
> > this.
>
> Such is life. But even if dynamic-default binding can't get the same
> amount of speedup, it shoulod work correctly.
No doubt. I realize I haven't explained my self very well:
I'm sure it would work, what I'm not sure of is if is a good technical
solution.
> You might find a way to recognize that some bindings can't be seen by
> any other functions, and treat them as lexical on the grounds that
> doing so would not alter the result.
This the point. I think we could at best make this assumption only on
calls to C primitives (that we assume cannot be redefined) that are
known to be side effect free and not to use global variable bindings in
general. Any other call must have all variables spilled first.
Given the frequency of calls and that almost all of these cannot be
proved to target one function of this very specific class, I think one
would end-up spilling almost always all variables anyway.
I always thought this is one of the main reasons why lexical scope was
introduced and I think this optimization is not worth being implemented.
I believe that if there will be a speed-up compiling dynamic code this
will come just from non having to decode byte-op-codes and manipulating
the execution stack.
In case the speed-up would come-up to be minimal imposing long
compilation times for a compiler that is unable of optimizing much would
be sad.
OTOH I think no one as data on this speed-up. Given the discussed
suspect of poor performance I intentionally left this task aside to work
on more urgent tasks. Nothing prevents to have a try on this later if
we think is really important.
Andrea
--
address@hidden
- Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium, Richard Stallman, 2020/05/01
- Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium, Richard Stallman, 2020/05/01
- Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium,
Andrea Corallo <=
- Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium, Richard Stallman, 2020/05/02
- Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium, Stefan Monnier, 2020/05/03
- Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium, Richard Stallman, 2020/05/03
- Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium, Stefan Monnier, 2020/05/04
- Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium, Richard Stallman, 2020/05/04
- Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium, Stefan Monnier, 2020/05/04
- Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium, Andrea Corallo, 2020/05/04
Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium, Stefan Monnier, 2020/05/02