[pypy-dev] jit-short_from_state

Hakan Ardo hakan at debian.org
Wed Aug 10 18:55:11 CEST 2011


On Wed, Aug 10, 2011 at 6:15 PM, Antonio Cuni <anto.cuni at gmail.com> wrote:
> On 10/08/11 17:27, Alex Gaynor wrote:
>>
>> I remember you also showed me it made my HTML escaper about 20% faster on
>> some
>> benchmarks :)  Of the 3 test_pypy_  benchmarks, only the test_instance one
>> shows a really noticable regression (test_strings looks better
>> actually...),
>> can you explain why it got worse?
>
> while you are at it, could you please also explain what is the branch about
> again? :-)

For a branch to be able to jump directly to the peeled loop and not to
the preamble, a short preamble has to be inlined at the end of the
bridge. On trunk we try to create such short preambles by reordering
the operations of  the preamble. That very often fails because we are
unable to prove that reordering the operations as needed is safe. In
that case no short preamble is constructed and bridges have to jump to
the preamble.

In jit-short_from_state, only a subset of the optimizer state is
allowed to survive the recreation of the optimizer chain at the end of
the preamble. That way we can ensure that the state subset surviving
is always reconstructable by a short preamble and this short preamble
is created directly from the optimizer state. Thereby no reordering of
resops are needed and we will always get a short preamble.

Note that bridges might still end up jumping to the preamble. This
will happen if a guard in the short preamble is proven to always fail
during optimization. Also if a guard from the short preamble fails
often enough for a new bridge to be generated, this will be a bridge
to the preamble. A possible future improvement here would be to issue
a retrace instead.

-- 
Håkan Ardö


More information about the pypy-dev mailing list