On Jul 29, 2014, at 1013 PT, Jeffrey Kegler <[email protected]> wrote:
> At a certain point in their investigation into Lua, a Wikipedian said that it > was a done deal, barring last-minute revelations that Lua has some sort of a > sordid past. The Kollos investigation of Lua is pretty much at the same > point. I'm not making a "final" announcement, but it looks like Lua will be > the language of Kollos's semantics. > > As background -- Marpa allows full Perl callbacks, but these can be slow, > especially for trivial tasks. So many of the simpler tasks (such as return > the first child, or return all the children as a blessed array) are performed > with a very fast Marpa-internal mini-VM. This mini-VM has 22 instructions -- > it's evolving into a language. There's a history of gradually evolved > languages, and it's littered with disasters -- JCL and vim macros come to > mind. The Wikipedians found their templating language was headed in a similar > direction, and realized they needed to stop before heading down that path. > Lua was their answer. > > I have a question, aimed at those G+ group readers who are Lua-versed (if > there are any). What version of Lua? There is now a LuaJIT, based on Lua > 5.1, which is widely used to rave reviews. It's apparently as fast as Java's > JIT, or faster, depending on which benchmark you use. The implications of > this for Kollos interface are, I think, obvious. > > Lua's latest stable version is 5.2, but LuaJIT is based on Lua 5.1, with > selected Lua 5.2 features added. Users seem to be happy with this. > > CPAN has a Alien::LuaJIT, which installs LuaJIT version 2.0.2. I'm thinking > of requiring (at least initially) LuaJIT 2.0.2 or better. > > Thanks, jeffrey I'm not going to lie. The prospect of Lua vs the existing C/XS implementation has me worrying in ways for the same reasons Java and JIT complexity make me worry in general (too much complexity). I do understand where you're coming from, implementation-wise of libmarpa, but quite simply, is it slower or faster than R2? I do understand the concern of "it feels like I'm developing something here that has already been developed" - however, consider the *curve* of that development. You may have 22 ops, but do you expect a 100? Is the creation of a mini-VM a symptom rather than a solution; e.g. symptom of slow callbacks. BTW: On a whim, I converted all of the action callbacks in one of my Marpa::R2 grammar's to be entirely XS implementations. They were simple callbacks, which you've already seen, but the overall performance difference? Less than 5-10%. I credit this to Marpa's own internal implementation carrying most of the efficiency. Remember: is the mini-vm a symptom or a real solution for a problem? -cl -- You received this message because you are subscribed to the Google Groups "marpa parser" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
