[ this reply is re $subject, not re $author in person] Am Montag, 14. September 2009 19:09 schrieb Andrew Whitworth: > It's a fundamental problem with the design that's the killer. > Parrot JIT does essentially NOTHING to improve execution performance, > other then streamlining op dispatch.
Sure thing, if you are going to rip out PIC too, you are exactly at that. It's the combination of CGP, PIC, and JIT, which very well did (and maybe still does) the runtime optimizations you are looking for. eg.: http://use.perl.org/~leo/journal/28623 http://www.nntp.perl.org/group/perl.perl6.internals/2008/01/msg42991.html These were early optimization examples of course, only a minimal set of PIC opcodes was implemented, but you might see the picture. See als "polymorphic inline cache" and "dynamic recompiling" ... from (a probably old) src/pic.c: static int is_pic_func(PARROT_INTERP, ARGIN(void **pc), ARGOUT(Parrot_MIC *mic), int core_type) { /* * if we have these opcodes * * set_args '..' ... * set_p_pc Px, PFunx * get_results '..' ... * invokecc_p Px * * and all args are matching the called sub and we don't have * too many args, and only INTVAL or FLOATVAL, the * whole sequence is replaced by the C<callr> pic opcode. * * Oh, I forgot to mention - the to-be-called C function is of * course compiled on-the-fly by the JIT compiler ;) * * pc is at set_args */ leo _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
