3 ms·

Asking as wasn't mention, was fib compiled with comp-speed 3? That should be considerably relevant in this benchmark. PS you can also run a wider set of bench

by koral 6y ago

Asking as wasn't mention, was fib compiled with comp-speed 3? That should be considerably relevant in this benchmark. PS you can also run a wider set of benchmarks to compare against stock Emacs using: https://elpa.gnu.org/packages/elisp-benchmarks.html https://elpa.gnu.org/packages/elisp-benchmarks.html Here some not very updated results: http://akrl.sdf.org/gccemacs.html#org4297f0f http://akrl.sdf.org/gccemacs.html#org4297f0f

hvis 6y ago
Hi Andrea (right?), IIUC, you're saying the fib benchmark gets optimized out at speed 3 (and thus run faster than all the implementations discussed here). But what about speed 2, which is the current default? If we're 15 times slower on this benchmark, does that mean that Node has much cheaper function calls, or something like that? Because we have to keep Emacs Lisp functions advice-able (which I agree is a good thing)?
- koral 6y ago
  IMO benchmarking is a way broader topic. Specifically a single fibonacci example is not a good performance indicator by any means. For instance let's assume V8 is faster in average at running this kind of nanobenchmarks (probably at least for now it is), but how much does it cost to convert non trivial data structures from Lisp to JS and back in a real case? I expect there will be a lot of back and forward if the system if JS and Lisp get mixed and have to cooperate. How much does it cost to go through foreign functions calls? This are just initial thoughts that are not accounted at all here. And even benchmarking nano-benchmarks can be surprisingly tricky ;) :) https://github.com/emacs-ng/emacs-ng/issues/187#issuecomment-802637690 https://github.com/emacs-ng/emacs-ng/issues/187#issuecomment...
  - hvis 6y ago
    Sure. My questions here are about whether these results indicate further optimization potential for native-comp (in the default configuration, hopefully). emacs-ng is an interesting experiment, but I think I will only be able to seriously consider it if it comes to reimplementing the Elisp VM on top of V8. Then it will be a single runtime, and little to no data structure conversion and FFI will be required. In the meantime, I'll keep following the native-comp progress ;), as well as dreaming of Web Workers in stock Elisp API.
deleted 6y ago
[deleted]

by koral 6y ago

hvis 6y ago

Hi Andrea (right?), IIUC, you're saying the fib benchmark gets optimized out at speed 3 (and thus run faster than all the implementations discussed here). But what about speed 2, which is the current default? If we're 15 times slower on this benchmark, does that mean that Node has much cheaper function calls, or something like that? Because we have to keep Emacs Lisp functions advice-able (which I agree is a good thing)?

koral 6y ago
IMO benchmarking is a way broader topic. Specifically a single fibonacci example is not a good performance indicator by any means. For instance let's assume V8 is faster in average at running this kind of nanobenchmarks (probably at least for now it is), but how much does it cost to convert non trivial data structures from Lisp to JS and back in a real case? I expect there will be a lot of back and forward if the system if JS and Lisp get mixed and have to cooperate. How much does it cost to go through foreign functions calls? This are just initial thoughts that are not accounted at all here. And even benchmarking nano-benchmarks can be surprisingly tricky ;) :) https://github.com/emacs-ng/emacs-ng/issues/187#issuecomment-802637690 https://github.com/emacs-ng/emacs-ng/issues/187#issuecomment...
- hvis 6y ago
  Sure. My questions here are about whether these results indicate further optimization potential for native-comp (in the default configuration, hopefully). emacs-ng is an interesting experiment, but I think I will only be able to seriously consider it if it comes to reimplementing the Elisp VM on top of V8. Then it will be a single runtime, and little to no data structure conversion and FFI will be required. In the meantime, I'll keep following the native-comp progress ;), as well as dreaming of Web Workers in stock Elisp API.

deleted 6y ago

[deleted]