On Wed, 7 Aug 2002, Nicholas Clark wrote:
> > > I'd not thought of this. You're right, but I think the trade off is the
> > > cumulative time you save each time the JITted routine is called, versus
> > > the time you took to track usage. I guess inside frequently called functions
> > > it could become worthwhile.
> >
> > The JITted routine is called only once, right?
>
> Er, yes, D'oh. Good point. I was thinking in terms of the JIT being run
> per subroutine, but actually it's run per block of bytecode.
>
> Except that
>
> 1: If I understand the plan, loading any sort of perl module ("use Foo.pm;")
> could cause parrot to load pre-compiled bytecode for that module, rather
> than the module. In which case, parrot is going to have multiple
> discontinuous blocks of bytecode in memory, with calls between them.
> So I assume that the JIT will be JITting the perl script first, then as
> and when each module is loaded, that gets JITted.
>
> 2: BEGIN blocks.
> (As in, they need to run as soon as the closing } is seen, which means that
> certainly bytecode, if not JITted bytecode, is going to get run in chunks
> in a script that uses a BEGIN block)
>
> 3: regexps are going to compile to bytecode, and I was assuming that in turn
> that bytecode was going to get JITted, and called into once per regexp
> match
Right.
>
> 4: We may want to create "fat" bytecode files, with pre-JITted (ie compiled)
> code next to the bytecode for CPU(s) of the machine the file is mounted to.
>
That's an idea, we can also make native executables.
> > > It would be useful if the bytecode had a way for the bytecode generator to
> > > give a hint about how hard any sort of runtime optimiser should try to
> > > optimise a function. So we'd only do this sort of thing for (say) repeatedly
> > > run regexps.
> >
> > In some time we can try to do some profiling on the fly to decide where to
> > optimise.
>
> If I follow the recent work on imcc correctly, then it is already trying to
> determine where loops are to avoid spilling registers inside loops (by
> spilling them outside. Is this the waterbed theory of graph colouring?)
> If so, imcc has already done some work about where slightly more JIT effort
> might pay off, so it seems a shame to throw that out.
Yes, that's why we are not going to do any kind of optimization that is
not required to be done at runtime, that means, we expect the most optimal
bytecode.
Daniel Grunblatt.
