First off, thanks to our relentless..., er, tireless summarizer for continuing to digest and clarify our wandering discussion.
On Tue, 25 Feb 2003, Piers Cawley wrote: > Using IMCC as JIT optimizer > Apparently, Leo Tötsch finds it unbearable that 'optimized compiled C is > still faster than parrot -j' so he's been experimenting with adding > smarts to IMCC, making it add hardware register allocation hints to its > emitted bytecode. Sean O'Rourke liked the basic idea, but reckoned that > the information generated by IMCC should really be platform-independent, > suggesting that it'd be okay to pass a control flow graph to the JIT, This isn't really my idea, but is instead an area of active research. A good jumping-off point is http://citeseer.nj.nec.com/krintz01using.html. > Dan thought the idea was interesting too, but worried that the JIT might > spend more time optimizing code than it could possibly gain from the > optimization. Dan -- you might be interested in http://www.usenix.org/events/javavm02/chen_m.html (if you have a USENIX subsription or a nearby university library). They stuff a full data-flow compiler into a JVM and, by carefully minimizing the number of passes, make it end up faster than a lightweight JIT on a number of programs. Granted, (IIRC) the real wins are on longer-running programs, so the result isn't as relevant to Parrot, but it _does_ show that there's room to put a fair amount of optimization into a JIT. /s
