Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emacs Bytecode Internals (2014)

nullprogram.com

Post reply on HN
Print view View original

21–26 of 26 posts

Re: Emacs Bytecode Internals (2014)

#21

Post by abecedarius »

__s wrote: post #19
_ph_ wrote: post #4

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.

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

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.

Re: Emacs Bytecode Internals (2014)

#22

Post by abecedarius »

imglorp wrote: post #15
barrkel wrote: post #13

Earlier quoted context omitted.

Bytecode is not a novel idea and I wouldn't expect it to be difficult at all to map the well-known concepts to the particulars of the Emacs implementation. Documentation of source code is often overrated IMO. Most software isn't difficult to understand if it's at least somewhat well-structured - and when the structure is poor, documentation doesn't help much. It's usually the application domain that's hard to underst…

It was probably a novel application when it was first implemented in emacs 1985-ish (going by the bytecomp.el header comment by JWZ). First editor bytecode? First lisp bytecode? First interpreter bytecode? O-code predates it by a couple decades for general purpose compilation: https://en.wikipedia.org/wiki/O-code

Peter Deutsch published a paper on a compact Lisp bytecode in the 70s, http://www.softwarepreservation.org/projects/LISP/interlisp-.... IIRC the Smalltalk-80 bytecode was pretty similar, descended from Smalltalk-76.

Re: Emacs Bytecode Internals (2014)

#23

Post by rurban »

_ph_ wrote: post #4

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.

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

Re: Emacs Bytecode Internals (2014)

#24

Post by kazinator »

abecedarius wrote: post #22
imglorp wrote: post #15

Earlier quoted context omitted.

It was probably a novel application when it was first implemented in emacs 1985-ish (going by the bytecomp.el header comment by JWZ). First editor bytecode? First lisp bytecode? First interpreter bytecode? O-code predates it by a couple decades for general purpose compilation: https://en.wikipedia.org/wiki/O-code

Peter Deutsch published a paper on a compact Lisp bytecode in the 70s, http://www.softwarepreservation.org/projects/LISP/interlisp-... . IIRC the Smalltalk-80 bytecode was pretty similar, descended from Smalltalk-76.

The cell counts seem to be off by one in the Appendix examples (REVERSE and SUBST lambdas). I count 35 and 40 conses, respectively. :)

Re: Emacs Bytecode Internals (2014)

#25

Post by smindinvern »

throwaway161220 wrote: post #11
_ph_ wrote: post #4

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.

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.

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/

Re: Emacs Bytecode Internals (2014)

#26

Post by throwaway161220 »

smindinvern wrote: post #25
throwaway161220 wrote: post #11

Earlier quoted context omitted.

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.

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

This branch being in the official repository, I took it to be favored. Do you know what's going on?
Post reply on HN