Front page | perl.perl6.internals |
Postings from January 2002
RE: parrot rx engine
Thread Previous
|
Thread Next
From:
Angel Faus
Date:
January 30, 2002 09:05
Subject:
RE: parrot rx engine
Message ID:
NDECKMNLNLHACJPEBADPKEBODGAA.afaus@corp.vlex.com
Ashley Winters wrote:
>First, we set the rx engine to case-insensitive. Why is that bad? It's
>setting a runtime property for what should be compile-time
>unicode-character-kung-fu. Assuming your "CPU" knows what the gritty
>details of unicode in the first place just feels wrong, but I digress.
I tend to agree to that. Many run-time options can be turned to compile-time
versions of the opcodes, which hopefully will produce a speed increase.
>Once you squash rx_literal and friends, any attempt to benchmark the
>"rx" engine really becomes a benchmark of parrot itself. When you speed
>up parrot, you speed up regular expressions. Voila, no more black box.
>If Parrot is just too damn slow for you, whip out libmylang and do the
>nitty gritty yourself. Since this is mostly a "just don't do it" post,
>no code is actually *required* from me, right? :)
We are already doing so. What you are suggesting in fact, is to compile down
regular expressions to Perl code (and this one to Parrot then). This will be
always slower than directly generating Parrot, because some Perl features
prevent the heavy use of some optimitzations (think JIT) that are necessary
if we want good regex perfomance.
In other words. With your proposal, if you have a better general-purpose
optimizer you will get better regex perfomance, but it will always remain
worse than the current state.
If what you are suggesting is that everything is compiled to general-purpose
opcodes (branch, unicode's, etc..) [which is what is derived from your
words, but not from your examples], I still believe this to be a perfomance
mistake. It would dramatically reduce the code density,
and no matter how fast parrot dispatch is, this will kill your perfomance.
And using too much stacks (as the usage of exceptions would probably
require), will also be too slow (as Brent Dax showed me when we
where discussing our two regex opcodes designs).
Just my 2 cents (of euros) :)
---
Angel faus
afaus@corp.vlex.com
Thread Previous
|
Thread Next