6 ms·

Nice article, but I was surprised to read that array accesses are not range checked for speed concerns. The emacs byte code interpreter is not known to be a ver

by _ph_ 10y ago

Nice article, but I was surprised to read that array accesses are not range checked for speed concerns. The emacs byte code interpreter is not known to be a very fast one, I doubt that the range checks would make a significant difference in run time. If anything, byte codes should bring high levels of safety.

gus_massa 10y ago
I think this is a difference in the point of view between the Java/C# word and the Lisp/Elisp/Scheme/Racket word. In the Java/C# word, you are expected to get some libraries or shared code distributed as bytecode, without been able to see the source code. So the bytecode must ensure safety, so an application can run untrusted code. [I'm more familiar with Racket.] In Lisp/Elisp/Scheme/Racket word you usually don't get shared code as bytecode, you get the source code. (An executable can be actually some bytecode packaged conveniently with the interpreter/JIT, but an executable can do whatever it likes, like formatting your hard disk.) So it's enough to ensure safety in the source code.
throwaway161220 10y ago
There's a JIT branch in the official upstream emacs repository. Just checkout nick.lloyd-bytecode-jit after cloning emacs from git and run `./configure --with-jit` once you have libjit (originally a part of GNU dotNET) to give it a try. libjit doesn't install a .pc file so you'll have to explicitly set the LIBJIT lib and C ./configure flags if you install libjit from source.
- smindinvern 10y ago
  If you want to try out that branch, do note that lisp functions are either explicitly JIT compiled with the `jit-compile' function or JIT can be enabled globally by setting `byte-code-jit-on' to non-nil. In my own testing I've found that global JIT seems to not help very much, and may actually be slower because of repeated compilations. Selectively compiling specific functions can give a decent speedup, though. Also, check out Burton Samograd's emacs-jit[1], which uses a very similar technique. [1] https://github.com/burtonsamograd/emacs-jit/ https://github.com/burtonsamograd/emacs-jit/
  - throwaway161220 10y ago
    This branch being in the official repository, I took it to be favored. Do you know what's going on?
__s 10y ago
Python bytecode can segfault too, doesn't detect stack underflow/overflow (can probably write to weird places with LOAD_FAST/STORE_FAST too)
- abecedarius 10y ago
  Yup, and you can create your own bytecode from within Python and immediately call it. Since the bytecode is imperfectly documented, I ran into some 'fun' problems debugging my Python-in-Python compiler.
rurban 10y ago
the performance hit is 20% typically. it is significant.

by _ph_ 10y ago

gus_massa 10y ago

I think this is a difference in the point of view between the Java/C# word and the Lisp/Elisp/Scheme/Racket word. In the Java/C# word, you are expected to get some libraries or shared code distributed as bytecode, without been able to see the source code. So the bytecode must ensure safety, so an application can run untrusted code. [I'm more familiar with Racket.] In Lisp/Elisp/Scheme/Racket word you usually don't get shared code as bytecode, you get the source code. (An executable can be actually some bytecode packaged conveniently with the interpreter/JIT, but an executable can do whatever it likes, like formatting your hard disk.) So it's enough to ensure safety in the source code.

throwaway161220 10y ago

There's a JIT branch in the official upstream emacs repository. Just checkout nick.lloyd-bytecode-jit after cloning emacs from git and run `./configure --with-jit` once you have libjit (originally a part of GNU dotNET) to give it a try. libjit doesn't install a .pc file so you'll have to explicitly set the LIBJIT lib and C ./configure flags if you install libjit from source.

smindinvern 10y ago
If you want to try out that branch, do note that lisp functions are either explicitly JIT compiled with the `jit-compile' function or JIT can be enabled globally by setting `byte-code-jit-on' to non-nil. In my own testing I've found that global JIT seems to not help very much, and may actually be slower because of repeated compilations. Selectively compiling specific functions can give a decent speedup, though. Also, check out Burton Samograd's emacs-jit[1], which uses a very similar technique. [1] https://github.com/burtonsamograd/emacs-jit/ https://github.com/burtonsamograd/emacs-jit/
- throwaway161220 10y ago
  This branch being in the official repository, I took it to be favored. Do you know what's going on?

__s 10y ago

Python bytecode can segfault too, doesn't detect stack underflow/overflow (can probably write to weird places with LOAD_FAST/STORE_FAST too)

abecedarius 10y ago
Yup, and you can create your own bytecode from within Python and immediately call it. Since the bytecode is imperfectly documented, I ran into some 'fun' problems debugging my Python-in-Python compiler.

rurban 10y ago

the performance hit is 20% typically. it is significant.