Earlier quoted context omitted.
Yes? This is a meritocracy, if don't know how to do low level stuff, head to the College, or learn it properly.
tech is not a meritocracy.
It is.
Emacs-ng: Emacs with Deno runtime and TypeScript
151–154 of 154 posts
Re: Emacs-ng: Emacs with Deno runtime and TypeScript
#152Earlier quoted context omitted.
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.)
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 Here some not very updated results: http://akrl.sdf.org/gccemacs.html#org4297f0f
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)?
Re: Emacs-ng: Emacs with Deno runtime and TypeScript
#153Earlier quoted context omitted.
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 Here some not very updated results: http://akrl.sdf.org/gccemacs.html#org4297f0f
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 thi…
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...
Re: Emacs-ng: Emacs with Deno runtime and TypeScript
#154Earlier quoted context omitted.
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 thi…
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 sys…
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.