Dan writes:True enough. Oh, don't get me wrong, I think we can go faster than the perl 5 regex engine. I just don't think we can do in 2 seconds what takes perl 5 10 seconds... :-P
Yeah, I meant the other way around.
I know. :)
Lacking any kind of formal specification for it, my general thought is that people will generally (but not the biotech or chip design guys) feel OK about parrot if their regexes are only 5x slower. After that people start asking pointed questions.
If we come in 5x slower, I'll consider it a total and utter failure. I'm not sure I'll consider anything worse than 5-10% slower than perl 5.005's regex speed acceptable enough to commit.
> Last time I looked at the perl 5 regex engine (and I'm stillrecovering, but the medication's helping) it was just a little bytecode engine with massive amounts of Nasty Evil piled on top. I think we can get a nice boost from the JIT or computed goto core, enough so that a single big bytecode interpreter (parrot) will work better than two smaller bytecode interpreters (which is what perl 5 w/the regex engine is, more or less)
It'll be interesting to see how much cache coherency plays into the picture. The twitchy, beady-eyed fanged little hairy regex engine does have the benefit of being able to nestle into modern CPU caches, and get 1-5 ns access time rather than 30-120 ns. Probably accounts for its evolutionary hardiness.
Yep, that 1 cycle access time does make quite a difference. Still, there's a lot to be gained by eliminating the bytecode interpreter loop (if we JIT) or trim a lot of cycles off it (if we just use the computed goto core) so there's a chunk to be saved there. What'll kill us is abstract access to strings, which is what I was hoping this thread could help us kill. ;)
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
