On Sat, Jul 3, 2010 at 08:20, Maciej Fijalkowski <[email protected]> wrote: > On Sat, Jul 3, 2010 at 12:14 AM, Hakan Ardo <[email protected]> wrote: >> On Fri, Jul 2, 2010 at 11:21 PM, Maciej Fijalkowski <[email protected]> wrote: >>> General note - we consider 2x optimized C a pretty good result :) Details >>> below >> >> As do I :) I just want to make this as jit-friendly as possible >> without rely knowing what's jit-friendly... > > I think it's fairly JIT friendly. You can look into traces (as you > did), but seems fine to me.
>>> Yes. We don't do loop invariant optimizations for some reasons, the >>> best of it being the fact that to loop you can always add a bridge >>> which will invalidate this invariant. >> >> Are you telling me that you probably never will include that kind of >> optimization because of the limitations it imposes on other parts of >> the jit or just that it would be a lot of work to get it in place? > > It requires thinking. It's harder to do because we don't know > statically upfront how many paths we'll compile to assembler, but I > can think about ways to mitigate that. Isn't there some existing research about that in the 'tracing' community? As far as I remember, the theory is that traces are assembled in trace trees, and that each time a (simplified*) SSA optimization pass is applied to the trace tree to compile it. Not sure whether they do it also for Javascript, since there compilation times have to be very fast, but I guess they did so in their Java compiler. Also, in other cases the general JIT approach is 'optimize and invalidate if needed'. For instance, if a Java class has no subclass, it's not safe to assume this will hold forever to perform optimization; but the optimization is performed and a hook is installed so that class loading will undo the optimization. Another issue: what is i4 for? It's not used at all in the loop, but it is reset to 27 at the end of it, each time. Doesn't such a var waste some (little) time? * SSA on trace trees took advantage of their simpler structure compared to graphs for some operations. -- Paolo Giarrusso - Ph.D. Student http://www.informatik.uni-marburg.de/~pgiarrusso/ _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
