FEXPRs vs. vtable: how LispE interpreter works(github.com)

104 pointsby birdculture20 gün önce6 comments

FEXPRs vs. vtable: how LispE interpreter works

https://github.com/naver/lispe/wiki/2.7-FEXPR-vs.-vtable

7 comments

Joker_vD17 gün önce

> What LispE proposes is to turn each instruction of the language into a derived class that exposes an eval method. Every class has its own override of eval. And since all these classes derive from a single mother class with an original and evocative name, Element, you can build a C++ vector that holds them all. And that is where the miracle happens: the AST is kept alive, but each node is an object that can be optimized to the hilt with the full C++ arsenal.

That's... a tree-walking interpreter. And IIRC the most overhead of it comes from traversing the tree itself, then from the overhead of invoking (virtual) eval() methods, and only then from whatever inefficiencies are inside of those tiny eval() implementations.

ncruces17 gün önce

If you build flattened a vector of them (as they argue), it can approach a byte code interpreter, though it won't be a very dense vector, if it holds "pointers" (that you need to chase) to the instructions instead of the instructions themselves.

A lot of the slowness of interpreters (and why JITs work) comes from the fact that you're executing (and trying to predict) the interpreter's branches - not the branches in the interpreted code.

This doesn't move the needle there, at all.

wrs17 gün önce

So…you can transform it into a threaded interpreter?

This seems like a ton of LLM verbiage making two simple and very standard techniques sound artificially profound.

Joker_vD17 gün önce

> If you build flattened a vector of them

Well, yes, it's an old way to represent ASTs: allocate them all sequentially from a huge arena (worked especially nicely for BCPL). Except the author actually uses their home-grown vecte<Element*> which, as far as I can tell, uses malloc/realloc. And there are several pointer indirections inside the liste/ITEM/LIST classes so... yeah.

[deleted]17 gün önce

sourdecor17 gün önce

What I find interesting is not only that this is a cool alternative Lisp but that it is developed by a Korean company called Naver[0].

[0]: https://github.com/naver

[1]: https://www.naver.com/

rjsw17 gün önce

Lisp has had good native compilers for a long time, just use one of those.