On Mon, Jan 14, 2002 at 01:49:44AM -0800, Brent Dax wrote:
> I wrote a _very_ simple benchmark program to compare Perl 5 and Parrot.
> Here's the result of a test run on my machine:
>
> C:\brent\Visual Studio Projects\Perl 6\parrot\parrot>..\benchmark
> Benchmarking "bbcdefg" =~ /b[cde]*.f/...
> perl: 0.03000 seconds for 10_000 iters
> parrot: 0.24100 seconds for 10_000 iters
> Best: perl, worst: parrot. Spread of 0.21100.
>
> The program is attached; it requires my latest regex patch to work. You
> may need to tr{\\}{/} in a few places to get it to work on Unix systems.
Are you compiling with optimization? I have my own implementation I've
been toying with, and the first time I benchmarked it, it was pretty
much identical to yours (a little surprising, considering I was
benchmarking a totally different expression!) Then I noticed that I
had compiled it without optimization and tried again with -O3, and the
gap narrowed significantly.
With mine, I am currently seeing:
Benchmarking "xxabbbxx" =~ /ab+a*b/...
perl: 1.20323 seconds for 500_000 iters
parrot: 2.87138 seconds for 500_000 iters
Mine doesn't yet handle character classes, so I can't do a direct
comparison. If you want, you can send me an rx.ops implementation of
/ab+a*b/ and I'll report the timings of all three. (This isn't a very
fair benchmark, though, because perl5's optimizations come into play
with this one, and neither of our engines has a "scan for exact
string" op that would let us emulate the optimized expression.)
I notice that string_ord() is taking up a pretty big chunk of time.
Which isn't too surprising, considering that string_index() is
return s->encoding->decode(s->encoding->skip_forward(s->bufstart, idx))
which is more levels of indirection than you can shake a stick at. And
that makes me wonder if we can ever compete fairly with perl5 without
implementing a binary buffer matching mode. Seems like we're always
paying a penalty for doing "proper" string matching by going through
all these levels of encoding.
My RE engine is still pretty rudimentary, but I'll mail a patch to
anyone who wants to take a look at it. The core really isn't much
different from Brent's rx stuff; I think his is slightly more
explicit. The internal wiring is likely to be rather different,
though.
