Re:A site for Picolisp, a very true Lisp
by coffeemug on Thursday November 26, 2009 @08:36PM
(#963311)
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.
Re:A site for Picolisp, a very true Lisp
by camccann on Thursday November 26, 2009 @08:48PM
(#963314)
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.
Re:A site for Picolisp, a very true Lisp
by legooolas on Friday November 27, 2009 @04:39AM
(#963665)
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...)
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.