Hacker News Reader

Comment by sillysaurus3 | Hacker News Reader

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.

View on HN

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

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.

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

Ouch, you are right. So the only strategy would be to switch to lexical compilation blockwise, while fixing the remaining dynamic extent vars.

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.)

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.

This indicates that node (v8 js) is much faster than lua, contrary to what you just said:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Probably thinking of LuaJIT, not measured by this benchmark

Is that using the Lua interpreter, or LuaJIT?

That webpage says Lua 5.3.4 and seems like LuaJIT does not support Lua 5.3.4

As others have mentioned, luajit is a lot faster than lua:

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/...

> …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.

It's been on my todo-list over neat ideas for a while. I just assumed someone would've beaten me to it by now :)

I suspect it might have to do with resources - dedicating multiple cores to benchmarking isn't going to be easy to do for free. Might be feasible for low cost, though.

Reply on news.ycombinator.com