3 ms·
It was a turn of phrase, but really I just meant that in my experience it's healthy to have something to aspire to – that's why we always compare to fully optim
by StefanKarpinski 13y ago
It was a turn of phrase, but really I just meant that in my experience it's healthy to have something to aspire to – that's why we always compare to fully optimized C and Fortran. It's easy to fall into an "interpreter bubble" and forget that there's a whole other realm of performance out there. And of course, interpreters can be quite fast – CPython is no slouch and Wren is giving it a run for its money, so kudos. Femtolisp [1] (which we use for Julia's parser) is a great example of a small and simple, yet fast and featureful interpreter. I really want Jeff to write a little book about it, walking the reader through the implementation.
[1] https://github.com/JeffBezanson/femtolisp https://github.com/JeffBezanson/femtolisp
- munificent 13y ago> I just meant that in my experience it's healthy to have something to aspire to I had actually thought that's what I was doing when I compared it to Lua! I was quite surprised at how well Wren did in comparison. The trick will be to see if I can keep it that fast as the implementation gets more robust. It takes some shortcuts right now that don't scale well, but happen to be faster. > I really want Jeff to write a little book about it, walking the reader through the implementation. I would love that. I've skimmed femtolisp a few times and it's clean but suffers from the almost total lack of documentation that other programming language implementations also seem to have.
- StefanKarpinski 13y agoI don't think that the standard Lua implementation is especially fast – it's the LuaJIT implementation that's so impressively fast. Programming language implementors do seem to be even less fond of writing comments than most programmers, don't they? I think one of the issues is that internals can change a lot fairly quickly and dealing with comments just makes that worse.