3 ms·

I'm highly skeptical. An interpreter-only implementation that performs better than compiled implementations?... Oh, but wait, it says it's better than "some" c

I'm highly skeptical. An interpreter-only implementation that performs better than compiled implementations?... Oh, but wait, it says it's better than "some" compiled implementations, so I guess if it beats "some" shitty compiled implementations that's true... How does it compare to, say, SBCL? As for the "As a consequence [of being interpreter-only], Pico Lisp is the most dynamic Lisp in existence today." part, I don't really see what notable advantages an interpreter-only implementation would have over a proper compiler-implementation in flexibility, given that it's Lisp we're talking about. Unless you wanted to muck with the deep internals or something... Also, I'm in the process of making my homebrewed web framework more flexible by making use of more compilation, thus making it less of an interpreter.

coffeemug 17y ago
This could make sense. In a sufficiently complex language, a single "VM" instruction translates to many native instructions. If you compile a program in such a language into native code, the size of the code explodes, resulting in really poor cache utilization. A tight interpreter on a modern processor (heavy cache fault penalties + branch prediction) can very well perform better than a natively compiled program. Performance is a very tough problem, unfortunately it's very difficult to find a "superior" solution - it just depends on far too many variables.
- camccann 17y ago
  If memory serves me, there are also cases where information available at run-time can allow better optimizations than could normally be done at compile-time--I think the JVM has some tricks along those lines for JITing bytecode into native instructions, but I suppose the same principle could apply elsewhere.
  - legooolas 17y ago
    Nothing stopping you doing these kinds of optimizations on Lisp code again at runtime when you have the extra info. Just automatically recompile if you know it will save you enough time to be worth it (which is a more difficult problem, of course...)

coffeemug 17y ago

This could make sense. In a sufficiently complex language, a single "VM" instruction translates to many native instructions. If you compile a program in such a language into native code, the size of the code explodes, resulting in really poor cache utilization. A tight interpreter on a modern processor (heavy cache fault penalties + branch prediction) can very well perform better than a natively compiled program. Performance is a very tough problem, unfortunately it's very difficult to find a "superior" solution - it just depends on far too many variables.

camccann 17y ago
If memory serves me, there are also cases where information available at run-time can allow better optimizations than could normally be done at compile-time--I think the JVM has some tricks along those lines for JITing bytecode into native instructions, but I suppose the same principle could apply elsewhere.
- legooolas 17y ago
  Nothing stopping you doing these kinds of optimizations on Lisp code again at runtime when you have the extra info. Just automatically recompile if you know it will save you enough time to be worth it (which is a more difficult problem, of course...)