diff options
author | Sacha Chua <sacha@sachachua.com> | 2021-12-02 12:46:03 -0500 |
---|---|---|
committer | Sacha Chua <sacha@sachachua.com> | 2021-12-02 12:46:03 -0500 |
commit | 2b47dac39b443210eb0d34ac31257f19c4ab1a64 (patch) | |
tree | a6d5ff7dfd45f90c08615ff4386cc562dac17e59 /2021/talks/native.md | |
parent | 6ec428824567a2f8325da742171bff1166b2b5c3 (diff) | |
download | emacsconf-wiki-2b47dac39b443210eb0d34ac31257f19c4ab1a64.tar.xz emacsconf-wiki-2b47dac39b443210eb0d34ac31257f19c4ab1a64.zip |
Add pad stuff
Diffstat (limited to '')
-rw-r--r-- | 2021/talks/native.md | 81 |
1 files changed, 81 insertions, 0 deletions
diff --git a/2021/talks/native.md b/2021/talks/native.md index 642d979a..3395e56e 100644 --- a/2021/talks/native.md +++ b/2021/talks/native.md @@ -33,6 +33,87 @@ 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? |