diff options
Diffstat (limited to '2021/talks/native.md')
| -rw-r--r-- | 2021/talks/native.md | 84 |
1 files changed, 83 insertions, 1 deletions
diff --git a/2021/talks/native.md b/2021/talks/native.md index eac47447..2916c9f5 100644 --- a/2021/talks/native.md +++ b/2021/talks/native.md @@ -9,7 +9,6 @@ Andrea Corallo - [[!inline pages="internal(2021/info/native-schedule)" raw="yes"]] Emacs Lisp (Elisp) is the Lisp dialect used by the Emacs text editor @@ -33,7 +32,89 @@ Format: 40 minutes # Discussion +Pad: + +- Q1: Why do you say that Elisp is *nearly* a general purpose + programming lang? What's missing? (and btw, huge thanks for your + work!) + - A: +- Q2: Is this the "rudiments" that the garbage collector talk was + discussing yesterday? Feel free to ignore this n00b question. + - A: +- Q3:Is the idea to enventually develop Emacs itself in ELisp (c.f. + Smalltalk VM developed in Smalltalk)? + - A: +- Q4: How did you work on this? Did you use Org Mode to keep track of + your progress? Did you use pictures to keep track of your compiler + transformations or you made only for the presentation? Asking + because it seems a complex project and I am not sure how you kept + that all in your mind! For example, make sure to pick stuff that FSF + was okay with while also deciding how to implement the optimization. + Great job anyway! + - A: +- Q5:Is this pipeline a possible source of new security + vulnerabilities, or a new category of vulnerabilities? Is it + something you are worried about or have had to deal with? + - A: +- Q6: What code, if any, would still benefit significantly from being + written in C? Could/should some of the existing C code be converted + without significant performance loss? + - A: +- Q7: What's the risk of (setq native-comp-speed 3)? + - A: Not sigificant risks. Some side effects might include: + needing to recompile a whole file or compilation unit when + redefining a function, otherwise the old function definition + could be used. +- Q8: Are there any limits introduced by native comp with respect to + runtime introspectability, changeability/redefinability, etc? + - A: +- Q9: Is there a benefit in setting native-comp-compiler-options to + "-mtune=native -march=<cpu>"? + - A: Not at the moment. Maybe in the future if, e.g. libgccjit is + enhanced further. +- Q10: You mentioned native-comp coming in emacs 28, will this be the + default at build time, or will distros have to set this themselves? + - A: It will not be enabled by default. Distros would need to + enable it themselves.(Thanks!) +- Q11: Could we avoid libgccjit.so? Or consider using another jit lib + (e.g. dynasm used by luajit) et al to gain better optimization + - A: libgccjit is more for AoT compilation, more in-depth + optimization, which JITters don't typically do, so they aren't + really equivalent. +- Q12: How much of emacs C code base could be translated to + emacs-lisp? What is the minimum C code base necessary? (seems + duplicate of Q6) + - A: Very hard questions to answer. :) Not generally + feasible/worth to convert most of it. +- Q13: could we statically type elisp code (via macros?) to provide + more optimization hints to compiler? + - A: Hope to extend existing Elisp variable-type annotations to + arguments and use that for optimization. +- Q14: Elisp and Python all are dynamically typed langauge, but + benchmark shows that Elisp runs slower than Python. Could we learn + some best practices from the Python community? As you mentioned. + make parameter type annotated is a promising point. + - A: Not sure if Elisp is really generally slower than Python. + The Elisp bytecode VM is similar in design to the Python VM. + Some native-compiled Elisp may already be faster than Python, + e.g. for certain math code. +- Q15: Did you try to optimize with Rust too? What are your thoughts + on Rust for this particular optimization and security? + - A: Optimize what? There is no Rust here. :) Rust is + interesting, though. There may be some possibilities, e.g. with + regard to some similarities between Rust and some CL + implementations. +- Q16: Why not implement Emacs Lisp in Guile and use Guile's + compiler? + - A: (not Andrea answering) This has already been tried and done, + lookup Guilemacs, e.g. on EmacsWiki. + - A: I think they meant to implement Elisp in Guile, and not + to replace Elisp with Scheme + - Yes, that's already been done. Guile can already run + some subset of Elisp. Look it up. :) + BBB: + - Where did funding for your work came from? Will you be able to maintain this in the foreseeable future? - akrk: What kinds of applications do you envision native-comp enabling to work well in Emacs in the next few years, that wouldn't otherwise be possible? - Is this the first real-world practical use of libgccjit? @@ -78,6 +159,7 @@ BBB: - One thing I wondered if you wanted to talk more about andrea was, to the prior point about "myths" about what emacs-devel is "like", there's also "make the culture your own". do you have advice on how to approach the community you haven't gotten to yet? BBB feedback: + - Extremely impressive work, Andrea. Also, very needed for the long term sustainability of the platform. Thanks a lot for the hard work! - Yes, if there were an Emacs Hall of Fame, Andrea would deserve a prominent place in it. :) - we really do need an Emacs Hall of Fame so we can remember those who laid the foundations |