Dan Sugalski wrote:
> [native code regexps] There's a hugely good case for JITting.
Yes, for JITing the regexp engine. That looks like a much easier
problem to solve than JITing all of Parrot.
> If you think about it, the interpreter loop is essentially:
>
> while (code) {
> code = (func_table[*code])();
> }
That's *an* interpreter loop. ;)
> 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)
The gcc goto-label dispatcher cuts the overhead to a single indirect
jump through a register. No table lookups. No extra branches. This is
even on the register starved x86. Yeah, there's a stall potential,
but it looks easy enough to fill with other stuff.
If Perl code *requires* that everything goes through vtable PMC ops,
then the cost of the vtable fetch, the method offset, the address
fetch and the function call will completely dominate the dispatcher.
> 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.
I know just enough to be dangerous. Lots of people have done work in
this area -- and on languages like Self and Smalltalk which are as
hard to optimize as Perl. Are we aiming high enough with our
performance goals?
I'll be happy with a clean re-design of Perl. I'd be *happier* with
an implementation that only charges me for cool features when I use
them. (Oops. That's what Bjarne said and look where that took him... ;)
- Ken
