On Mon, Jul 29, 2002 at 09:47:53PM +0000, Angel Faus wrote: > I've made a patch for the regex engine, designed with the single goal > of seriously cheating for speed. :-)
And what would be unperlish about this "cheating" concept? :-) > Anyway, this patch has brought me the personal conviction that parrot > regexes can be as fast or faster than their perl equivalents, if we > put a bit of effort on optimitzation. This sounds very promising. Thanks for doing this. On Mon, Jul 29, 2002 at 10:34:00PM -0300, Daniel Grunblatt wrote: > On Mon, 29 Jul 2002, Nicholas Clark wrote: > > [although I strongly suspect that JITting the ops the regexps compile down > > to would be the first real world JIT priority. How fast would perl6 regexps > > be with that?] > > Yes, that should be one of the priorities. On Tue, Jul 30, 2002 at 01:21:30PM -0400, Dan Sugalski wrote: > At 10:34 PM -0300 7/29/02, Daniel Grunblatt wrote: > >On Mon, 29 Jul 2002, Nicholas Clark wrote: > > > As you can see from the patch all it does is implement the end > >and noop ops. > >> Everything else is being called. Interestingly, JITing like this is > >> slower > >> than computed goto: > > > >Yes, function calls are generally slower than computing a goto. > > Yup. There's the function preamble and postamble that get executed, > which can slow things down relative to computed goto, which doesn't > have to execute them. > > This brings up an interesting point. Should we consider making at > least some of the smaller utility functions JITtable? Not the opcode > functions, but things in string.c or pmc.c perhaps. (Or maybe getting > them inlined would be sufficient for us) I'm not sure. Effectively we'd need to define them well enough that we can support n parallel implementations - 1 in C for "everyone else", and 1 per JIT architecture. On Tue, Jul 30, 2002 at 03:14:48PM -0300, Daniel Grunblatt wrote: > Yes, we can do that, we can also try to go in and out from the computed > goto core if available. This sounds rather scary to me. I've managed to delete a message (I think by Simon Cozens) which said that perl5 used to have a good speed advantage over the competition, but they'd all been adding optimisations to their regexp engines (that we had already) and now they're as fast. My thoughts are: If on a particular platform we don't have a JIT implementation for a particular op then we have to JIT a call to that op's C implementation. Do enough of these (what proportion?) and the computed goto core is faster than the JIT. I think (I could look at the source code, but that would break a fine Usenet tradition) that for ops not in the computed goto core we have to make a call from either JIT or computed goto core, so there's no speed difference on them. *BUG* Also, we are currently failing to distinguish the size of INTVALs and NUMVALs in our JIT names (so this makes 4 possible JIT variants on most CPUs) IIRC there are currently >500 ops in the core, which makes it unlikely that we'll have sufficient people to JIT most ops on most CPUs. So we have the danger of the JIT being slower in the general case. IIRC the intent was that regexps would compile to regular parrot subs I would assume (please correct me) that the regexp engine is only going to use a small subset of parrot's ops in the subroutines it generates. Therefore, can we make it so that on a JIT-enabled platform the JIT can be run optionally over individual subs, replacing them with JITted versions? That way, perl could compile its regexps to a sub of opcodes, and then we can JIT that sub into native code. We'd only have to ensure that the majority of regexp related ops (ie rx and core ops used) to be fast than the GC core. (Rather than the majority of all the ops commonly used) [We might want to make it a pragmatic hint flag on the regexp to say "please try harder to optimise this regexp", with one form of "harder" being the JIT. Also, we might like to provide an attribute to hint that a particular sub would like to be optimised more] Hopefully regexps run as native code would give perl6 a stonking great advantage in the regexp speed arms race :-) Nicholas Clark -- Even better than the real thing: http://nms-cgi.sourceforge.net/
