At 02:46 AM 11/8/2001 -0600, Dave Goehrig wrote:
>On Wed, Nov 07, 2001 at 06:46:20PM -0500, Ken Fox wrote:
> >
> > JITs help when the VM is focused on lots of small instructions
> > with well-known, static semantics. Perl's use of Parrot is going
> > to be focused almost completely on PMC vtable ops. A JIT has
> > no advantage over a threaded interpreter.
>
>Unless we can get Perl to use the other features of Parrot outside
>the scope of the PMC vtable ops, Parrot won't give you any real
>benefits other than a clean rewrite of the Perl internals to
>look more like Ruby :)
Never underestimate the advantages of a clean rewrite. Threads, anyone? :)
We should be faster as well, and we get the side-effect of interoperability
with other languages that compile down to parrot code.
Faster and clean are the two core purposes behind the rewrite for perl 6.
The rest is (highly desirable, and very leverageable) gravy.
> > About the only place where a JIT might really win big is in
> > regexps.
>
>It would be interesting to see how JIT regexs would compare with
>something like libpcre (which is pretty damn fast).
Unless libpcre generates machine code, a JITted interpreter would blow the
doors off of it.
The RE engines I've seen, which includes perl's, are essentially small
interpreters. (Or state machines, if you want to look at it that way) Ones
that are very special-purpose, sure, but interpreters anyway, complete with
the overhead that goes with them. You can make them fast, sure--recent
experiments with parrot bear that one out. But regardless, no matter what
you do to optimize things, this:
do_x
do_y
do_z
will be faster than
do_x
goto op[*pc++]
do_y
goto op[*pc++]
do_z
Fewer instructions executed, and fewer branches presented to the CPU which
means fewer pipeline flushes.
Plus it also means that your RE, being executable, lives in your
processor's I cache, rather than competing with your data for D cache space.
> > Have other people come to the same conclusion?
>
>I think there is still a good cause for JIT.
There's a hugely good case for JITting.
> > Is there any interest in a less dynamic dialect of Perl that can
> > take advantage of a JIT?
>
>I will admit to probably being one of the worst offenders of the special
>cases Dan has been mentioning, but I know that most of my code is of
>the sort that would benefit from JIT. More importantly, I think a lot
>of the problems currently facing Parrot really doing its job well, is
>the nasty habits people have relying upon the side effects of perl5
>lexical scoping. The same results could be had, but in a different fashion.
Everyone's code can benefit from JIT compilation. It doesn't suffer from
the issues that come up with optimizations. In fact, the only issue there
really is is the need to invalidate the JIT version of a sub if that sub
changes.
JITting is really just the next step past TIL. It doesn't reorder the code,
inline things, or otherwise transform your program. All it really does is
cut out a lot of the otherwise unneeded overhead.
If you think about it, the interpreter loop is essentially:
while (code) {
code = (func_table[*code])();
}
you pay a lot of overhead there in looping (yes, even with the computed
goto, that computation's loop overhead), plus all the pipeline misses from
the indirect branching. (And the contention for D cache with your real data)
TIL code turns the program into
function_a();
function_b();
function_c();
function_a();
which cuts out all the loop overhead, turns your program into executable
code so it lives in I cache, and makes things generally more predictable
for the processor, so that's good.
JITting your code turns the program into
{insert function_a body}
{insert function_b body}
{insert function_c body}
which, in addition to the wins from TILling the code cuts out the function
preamble and postambles.
Now, we can't do this for all our opcodes as we're allowing them to be
overridden (and we require it for Safe mode execution to be reasonably
safe) but for the core opcodes, which I'd guess something like 85-95% of a
program will be made up of, we can do it with no change in program
behaviour other than the odd speedup.
Dynamic languages have potential overheads that can't be generally factored
out the way you can with static languages--nature of the beast, and one of
the things that makes dynamic languages nice. So maybe perl code will never
be as fast as the equivalent FORTRAN. That's life, but it doesn't mean that
Parrot executing perl code can't be a darned sight faster than Perl 5
executing the same code...
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
