On Tue, 30 Jul 2002, Nicholas Clark wrote:
> 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. We can try and see, I'm not 100% sure if this will be faster. > > > 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. Ok, I don't know if I should say this ... and I'm not saying I'm going to do it, but there is a possibility to make an intermediate language. Daniel Grunblatt.
