On Tue, Sep 15, 2009 at 4:52 PM, Leopold Toetsch <[email protected]> wrote: > 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.
Thanks for the update Leo! You're right, I was simplifying a little bit. JIT itself doesn't offer any performance improvement but it's not the only piece of the pie. PIC is a great performance improvement, and Parrot will want to have PIC eventually as an added boost. CGP is nice but isn't nearly as efficient in terms of pipeline hazards as a more modern technique like context threading would be. CGP+PIC+JIT is a performance boost, no question about that. My problem with the design (and I did not mean any offense in my comments earlier) is that it isn't open really to adding anything beyond that. We need JIT and PIC, but we also need context threading, trace-based JIT, a whole suite of feedback-directed optimizations, multiversioning, etc. Not to mention we could also benefit strongly from machine-code-level optimizations that a JIT package like LLVM offers. A more modular design will allow us to mix and match new optimization strategies with a faster turnaround time. > These were early optimization examples of course, only a minimal set of PIC > opcodes was implemented, but you might see the picture. They say "you always throw the first one away", and we did learn a lot from the current PIC system. You are definitely right that whatever implementation we do end up with is going to need to do what the old system did and much more too. --Andrew Whitworth _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
