4 ms·

The reason it's difficult to make elisp fast is because the language defaults to dynamic scoping rather than lexical scoping. That means any function that uses

The reason it's difficult to make elisp fast is because the language defaults to dynamic scoping rather than lexical scoping. That means any function that uses `let` is no longer making a tailcall. Meaning you have to restore the value of each variable after you call whatever function would have been the tailcall. Stuff like that adds up. It's why Lua is so fast compared to JS, too.

rurban 8y ago
But this could be solved with escape analysis. Rarely do such let locals shadow outer locals, and as such don't need to be restored.
- dan-robertson 8y ago
  You can’t know whether you are shadowing an outer variable. With dynamic scope: (defun get-x () x) (defun foo (let ((x 7)) (get-x))) (foo) ;; => 7 (not shadowing x) (let ((x 4)) (foo)) ;; => 7 (is shadowing x) (setq old-get-x #'get-x) (defun get-x () (let ((x 10)) (funcall old-get-x))) (foo) ;; => 10
  - rurban 8y ago
    Ouch, you are right. So the only strategy would be to switch to lexical compilation blockwise, while fixing the remaining dynamic extent vars.
    - pzone 8y ago
      Which is more or less the strategy in the Emacs codebase - the intention is to incrementally port to lexical binding on a per-file basis. (This is seen through the annotation -- lexical-binding:t -- at the top of many .el files.)
  - kazinator 8y ago
    Emacs Lisp has supported lexical scope in its byte code compiler as an option for eons, and is starting to make more use of that. No reason why a brand new JIT couldn't follow suit.
tasty_freeze 8y ago
This indicates that node (v8 js) is much faster than lua, contrary to what you just said: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/lua-node.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- striking 8y ago
  Probably thinking of LuaJIT, not measured by this benchmark
- Ruud-v-A 8y ago
  Is that using the Lua interpreter, or LuaJIT?
  - igouy 8y ago
    That webpage says Lua 5.3.4 and seems like LuaJIT does not support Lua 5.3.4
- e12e 8y ago
  As others have mentioned, luajit is a lot faster than lua: http://luajit.org/performance_x86.html http://luajit.org/performance_x86.html As an aside, I see there a gitlab project for the benchmark game - but I was surprised there doesn't appear anyone has put together an automated, open, bring your own language/code/patches version? Maybe with some community voting (eg: prefer idiomatic vs max speed)? https://salsa.debian.org/benchmarksgame-team/benchmarksgame/blob/master/CONTRIBUTING.md https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...
  - igouy 8y ago
    > …but I was surprised there doesn't appear anyone has put together… Why haven't you? That's probably why no one else has :-) Instead be surprised that someone has continued to push the benchmarks game along, and that people have continued to contribute programs gratis.
    - 8y ago
michaelhoffman 8y ago
Lexical binding was available starting in Emacs 24.1, and most of the standard library has it enabled.

rurban 8y ago

But this could be solved with escape analysis. Rarely do such let locals shadow outer locals, and as such don't need to be restored.

dan-robertson 8y ago
You can’t know whether you are shadowing an outer variable. With dynamic scope: (defun get-x () x) (defun foo (let ((x 7)) (get-x))) (foo) ;; => 7 (not shadowing x) (let ((x 4)) (foo)) ;; => 7 (is shadowing x) (setq old-get-x #'get-x) (defun get-x () (let ((x 10)) (funcall old-get-x))) (foo) ;; => 10
- rurban 8y ago
  Ouch, you are right. So the only strategy would be to switch to lexical compilation blockwise, while fixing the remaining dynamic extent vars.
  - pzone 8y ago
    Which is more or less the strategy in the Emacs codebase - the intention is to incrementally port to lexical binding on a per-file basis. (This is seen through the annotation -- lexical-binding:t -- at the top of many .el files.)
- kazinator 8y ago
  Emacs Lisp has supported lexical scope in its byte code compiler as an option for eons, and is starting to make more use of that. No reason why a brand new JIT couldn't follow suit.

tasty_freeze 8y ago

This indicates that node (v8 js) is much faster than lua, contrary to what you just said: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/lua-node.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

striking 8y ago
Probably thinking of LuaJIT, not measured by this benchmark
Ruud-v-A 8y ago
Is that using the Lua interpreter, or LuaJIT?
- igouy 8y ago
  That webpage says Lua 5.3.4 and seems like LuaJIT does not support Lua 5.3.4
e12e 8y ago
As others have mentioned, luajit is a lot faster than lua: http://luajit.org/performance_x86.html http://luajit.org/performance_x86.html As an aside, I see there a gitlab project for the benchmark game - but I was surprised there doesn't appear anyone has put together an automated, open, bring your own language/code/patches version? Maybe with some community voting (eg: prefer idiomatic vs max speed)? https://salsa.debian.org/benchmarksgame-team/benchmarksgame/blob/master/CONTRIBUTING.md https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...
- igouy 8y ago
  > …but I was surprised there doesn't appear anyone has put together… Why haven't you? That's probably why no one else has :-) Instead be surprised that someone has continued to push the benchmarks game along, and that people have continued to contribute programs gratis.
  - 8y ago

michaelhoffman 8y ago

Lexical binding was available starting in Emacs 24.1, and most of the standard library has it enabled.