[pypy-dev] Duplicated guards

[Hakan Ardo]

On 8/20/11, Alex Gaynor <alex.gaynor at gmail.com> wrote:
> I believe mozilla worked on this issue.  if.you're interested in this
> perhaps we should get you in contact with them.

Good idea. Do you have some contact?

Does the following approach make sens:

When a guard is traced we trace to the next jit_merge_point() only,
and construct a small bridge there. That would be to complete the
current python bytecode, right? From that point we then produce
something similar to our current loops. The difference would be that
it does not end with a jump to itself but to somewhere else. It would
probably not need a preamble at all (unsure) but it would have a
peeled loop with a virtual state that matches the state needed by the
bridge.

Later, when "the same" guard in a different location is traced, it
will end up at the same jit_merge_point() where it discovers a
compiled loop and if it's virtual state matches it will jump to it and
if not the retrace feature will produce a new version of it that
matches the current bridge.

This way the duplicated part of the bridges will be very small (less
than a bytecode). Hmm, maybe it's actually possible to unify the
notions of perambles, peeled loops and bridges into traces attached to
a greenkey with a specific virtual state.

> On Aug 20, 2011 3:35 AM, "Hakan Ardo" <hakan at debian.org> wrote:
>> Hi,
>> I've been experimenting a bit with heuristics such as "not retracing
>> loops with a lot of guards" or "not unrolling if the peel loop is not
>> much better than the preamble". In some situations is seem possible to
>> increase performace by such means (go: +37%, html5lib: +13%, rietveld:
>> +8%). However I think the real problem is that we duplicate guards and
>> that this leads to an explosion of bridges. I added
>> test_excessive_bridgeing to test_ajit on the jit-limit_peeling branch.
>> It is a simple example where the last part of the loop is traced 8
>> times producing 8 identical bridges.
>>
>> Is there any chance of identifying copies of "the same guard" (in some
>> sens that considers both the address of the guard and the state of
>> virtuals) and when the second copy of the guards is about to be traced
>> we would just connect it to the already compiled bridge? Maybe by
>> producing a small header-bridge that moves things around and then
>> jumps to the already compiled bridge?
>>
>> --
>> Håkan Ardö
>> _______________________________________________
>> pypy-dev mailing list
>> pypy-dev at python.org
>> http://mail.python.org/mailman/listinfo/pypy-dev
>


-- 
Håkan Ardö