With Libmarpa itself, my goal is maintaining the time complexity -- the
claims stated in my paper -- rather than speed. I pay a good deal of
attention to avoiding any O(n log n) logic where I am claiming O(n), for
example. Also, I do write all the code in an optimized style, but that
is as opposed to actually optimizing it against measurement. This is
because at the moment it only runs inside Perl, and Perl overhead swamps
all but the biggest changes in Libmarpa's speed. Measurement at this
point only makes statements about the Perl overhead.
I expect, by the way that phase one, now complete, improved speed --
many pages of codes were eliminated and entire complex objects elimated,
along with their storage, the CPU needed to allocate memory for them,
sort them, etc. But note I made no claim to that effect in my report --
I am not sure the improvement could be measured against the "background"
noise of Perl overhead. Libmarpa takes less than 10% of the time, so a
10% change in its speed is a 1% change in the overall result, which on
Linux I do not think is measureable.
Currently the only useable speed metric I have is that Libmarpa is much
faster than it needs to be for its current uses, and it's hard to
measure changes against that.
By the way, running my test suite on the forthcoming version may be
significantly faster, but that's because I've dropped an expensive but
no longer useful test.
-- jeffrey
On 01/15/2014 12:25 PM, Deyan Ginev wrote:
Hi Jeffrey,
Very interesting read, thanks for sharing the full details!
I wonder how you maintain your "developer sanity" in practice - do you
have a Marpa benchmark over a variety of test grammars and input
strings, which helps you to evaluate if and by what degree the Marpa
performance (i.e. runtime, rather than just coverage) has
improved/deteriorated?
Apart from that, the way you have described the LR(0) manipulation, it
seems quite clearly an unpleasant mechanism to both develop and
maintain in the long run. So best of luck making Marpa better, both
for us to use and for you to maintain!
Deyan
On Wed, Jan 15, 2014 at 8:11 PM, Jeffrey Kegler
<[email protected]
<mailto:[email protected]>> wrote:
I'm doing this all on the master branch. "safe" is a branch which
does not include any of this, though I'd probably revert to the
last developer's release if it came to that. -- jeffrey
On 01/15/2014 11:04 AM, Durand Jean-Damien wrote:
Many thanksfor these explanations, in which I recognize pedagogic
efforts for non language-theorist!
Looking forward the dev. releases.
Which is the git branch ?
Thanks / JD.
--
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]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/groups/opt_out.
--
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]
<mailto:marpa-parser%[email protected]>.
For more options, visit https://groups.google.com/groups/opt_out.
--
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/groups/opt_out.
--
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/groups/opt_out.
