@Christopher: I've thought more about this point (that is, which version
of Lua to go with) -- you're certainly right about the dangers of
chasing speed early in the decision making, and the inadvisability of
tieing Marpa into any single outside technology so large and complex as
a JIT. The chase for efficiency may not be the root of all evils, but
it certainly is the source of a lot of them.
Wikipedia recently switched their templating to Lua. They went with Lua
5.1, leaving LuaJIT as an option for the future. Lua's plain ol'
interpreter is very fast, and in Wikipedia's case it was already
delivering more benefits then they could absorb, including some major
speedups. So while the additional speedup from a JIT was certainly
desirable for the future, it was not an immediate priority at Wikipedia.
LuaJIT's team is committed to Lua 5.1 compatibility, so that Wikipedia
expects their Lua 5.1 templating code can run unchanged when (and if)
they move to LuaJIt.
Kollos/Marpa::R3 might do well to imitate the Wikipedians here and start
out on the basis of Lua 5.1.
-- jefrey
On 07/29/2014 01:09 PM, Christopher Layne wrote:
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.
