5 ms·

> Meanwhile, using `emacs --script fib.elc` to evaluate byte-compiled (fib 40) takes about 32s Which Emacs version is this? Any chance you want to try the nat

by hvis 6y ago

> Meanwhile, using `emacs --script fib.elc` to evaluate byte-compiled (fib 40) takes about 32s Which Emacs version is this? Any chance you want to try the native-comp branch and post its numbers here as well?

vitus 6y ago
This was emacs 27.1 (which is the version in the Arch repo). I can install native-comp via AUR. It'll take some time.
- vitus 6y ago
  I think this is what you're looking for. time emacs --script fib-0b03fe9a-6b386e71.eln emacs --script fib-0b03fe9a-6b386e71.eln 22.47s user 0.09s system 99% cpu 22.664 total About 50% faster, which is nothing to sneeze at, but still appreciably slower than most other things I tried. (I copied the .eln from the cache to confirm that's what I'm running against; I got a similar speedup from running against fib.elc.)
  - hvis 6y ago
    Thank you. That's an interesting result.
  - 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]
  - deleted 6y ago
    [deleted]
deleted 6y ago
[deleted]
- deleted 6y ago
  [deleted]

by hvis 6y ago

vitus 6y ago

This was emacs 27.1 (which is the version in the Arch repo). I can install native-comp via AUR. It'll take some time.

vitus 6y ago
I think this is what you're looking for. time emacs --script fib-0b03fe9a-6b386e71.eln emacs --script fib-0b03fe9a-6b386e71.eln 22.47s user 0.09s system 99% cpu 22.664 total About 50% faster, which is nothing to sneeze at, but still appreciably slower than most other things I tried. (I copied the .eln from the cache to confirm that's what I'm running against; I got a similar speedup from running against fib.elc.)
- hvis 6y ago
  Thank you. That's an interesting result.
- 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]
- deleted 6y ago
  [deleted]

deleted 6y ago

[deleted]

deleted 6y ago
[deleted]