From 2b47dac39b443210eb0d34ac31257f19c4ab1a64 Mon Sep 17 00:00:00 2001 From: Sacha Chua Date: Thu, 2 Dec 2021 12:46:03 -0500 Subject: Add pad stuff --- 2021/talks/native.md | 81 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) (limited to '2021/talks/native.md') 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=\\"? + - 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? -- cgit v1.2.3