At 4:17 PM -0800 3/17/02, Steve Fink wrote:
>On Sat, Mar 16, 2002 at 04:34:34PM -0500, Dan Sugalski wrote:
>> Now's your time to speak up, please.
>
>Ok, you asked for it. I just committed the regular expression
>compiler. It has known bugs, but I am completely out of tuits for now,
>and have been since about the time I announced this thing's existence.
>:-(
Fair enough--that's what I wanted to know.
>I do wonder what you'd replace the rx opcodes with. I don't see any
>use for some of the existing opcodes (regex flag setting, zwa_atend,
>etc.), but doing things like maintaining the backtracking stack using
>generic opcodes sounds very slow to me.
Maybe. I don't think so, though, and if some specialized constructs
are needed, I think they need to be brought outside the context of
the regex engine.
>The last benchmarking I did on the regex engine (with a single regex,
>admittedly) put it at somewhat better than half the speed of perl5's
>engine, which isn't too bad. Do you have newer (worse) numbers?
Half the speed is pretty abominable. However, code using the regex
opcodes to match /fo+ba?r/ runs at the same speed or slower than code
using plain positional ords, and the positional ord code sees
significant gains when using the JIT. Neither version came within
half the speed of perl, though. Both were slower than that.
>My compiler would be relatively easy to retarget to general opcodes or
>another set of regex opcodes, but I am very skeptical that regexen can
>be sufficiently fast without some tailored opcodes and a regex state
>PMC.
Possibly. Regardless, at the moment I'm thinking that the current
shot at regexes is, while good, insufficiently compelling over the
plain opcodes we have now.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
