Front page | perl.perl6.internals |
Postings from January 2002
Re: parrot rx engine
Thread Previous
|
Thread Next
From:
Bryan C. Warnock
Date:
January 30, 2002 17:42
Subject:
Re: parrot rx engine
Message ID:
20020131014226.HZIT14927.femail22.sdc1.sfba.home.com@there
On Wednesday 30 January 2002 11:13, 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
{snip}
> Now, the current CVS rx engine is/would do this at runtime.
We're also currently a compiler short.
> What I see is that rx_literal is a speed hack to avoid compiling this
> into parrot code:
{excellent example of a pure_parrot regex engine snipped}
Is something *wrong* with speed hacks?
When we talk about wanting to make Parrot blazingly, blindly fast, we're
talking in relative terms. The mechanics of interpretation - sans JIT -
pretty much restrict you to racing in the 125cc class. You may blow away
every other bike in the class, but good luck going up against some 800cc
monster. That's why these virtual machines aren't very RISCish. There's
entirely too much stuff that has to be done that is unrelated to what you're
actually trying to do - the more you can stuff into an op, the faster you
will be.
Yes, that means that the fastest regex engine would probably be, yes, one op.
match. The rationale for *not* doing that (yet) is a design choice - we
want regex ops - in some form - to be first-class citizens of Parrot
opcodes. But in truth, if Parrot can be four times as fast as Perl 5 -
currently, from an op dispatch perspective, it's a measly two; from a
functionality perspective, it's much greater, but then again, we don't have
all the functionality - would you be content in having your regexes run
twenty times slower?
"But if you know they're going to be twenty times slower, why are you doing
it?" Because we know / think / hope / pray / have been making sacrifices to
the gods that we can make up the speed in other ways. A smarter regex
engine. Faster op dispatch. Pure compilation. The JIT.
Our target is to match the current speed. If we can't do that, we'll more
than likely reduce the number of Parrot ops. If we blow away previous
marks; well, then, we can expand.
>
> Am I fool, or an idiot? Discuss.
Overzealous, perhaps. It'd be nice for Perl 7 to be written in Perl 7, but
I don't think that's realistic.
>
> Mostly, I'd like to hear how either Unicode character-ranges aren't
> deterministic at compile-time (I doubt that) or how crippling to
> performance this would be (and by implication how slow parrot will be)
> in either time or space.
Literal character classes ([abc]) will most likely be compiled.
Meta-character classes (\d) may be compiled. Character ranges ([a-f]) may
or may not be. It's hard to say, because we seem to still not be sure what
any of those mean. (Particularly when locale comes into play.) That's not
a regex issue, it's a Unicode one.
--
Bryan C. Warnock
bwarnock@capita.com
Thread Previous
|
Thread Next