[pypy-dev] Interpreter level array implementation
p.giarrusso at gmail.com
Sat Jul 3 08:58:34 CEST 2010
On Sat, Jul 3, 2010 at 08:20, Maciej Fijalkowski <fijall at gmail.com> wrote:
> On Sat, Jul 3, 2010 at 12:14 AM, Hakan Ardo <hakan at debian.org> wrote:
>> On Fri, Jul 2, 2010 at 11:21 PM, Maciej Fijalkowski <fijall at gmail.com> 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
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
More information about the Pypy-dev