[pypy-dev] jit-short_from_state

[Hakan Ardo]

On Wed, Aug 10, 2011 at 5:27 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
>
>
> On Wed, Aug 10, 2011 at 8:06 AM, Maciej Fijalkowski <fijall at gmail.com>
> wrote:
>>
>> On Wed, Aug 10, 2011 at 4:43 PM, Hakan Ardo <hakan at debian.org> wrote:
>> > Hi,
>> > what I had in mind for jit-short_from_state is now in place and seem
>> > to be working. So if anyone feels like reviewing now is a good time :)
>> > Benchmarks show ai 15% faster, spectral-norm 47% faster and bm_mako
>> > 11% slower as compared to trunk. The others are not affected much:
>>
>> go is 35% faster (just reading the paste :)
>>
>> >
>> >    http://paste.pocoo.org/show/455974/
>> >
>> > There are still 3 test_pypy_c tests failing due worse optimization:
>> >
>> >    http://buildbot.pypy.org/summary?branch=jit-short_from_state
>> >
>> > Addressing those would need some though though...
>> >
>> > --
>> > Håkan Ardö
>> > _______________________________________________
>> > pypy-dev mailing list
>> > pypy-dev at python.org
>> > http://mail.python.org/mailman/listinfo/pypy-dev
>> >
>> _______________________________________________
>> pypy-dev mailing list
>> pypy-dev at python.org
>> http://mail.python.org/mailman/listinfo/pypy-dev
>
> 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?

In test_string, there is an extra int_eq, guard_false, probably
because intbounds now are generalized at the end of the preamble if
they are outside the range  pluss minus sys.maxint/2 in order to not
create a lot of identical version of the same loop that are
specialized to silly intbounds.

I'm not sure why test_instance works on trunk actually, but the way to
get it to work on this branch I think is to make the heap optimizer
aware of the setfield_gc's produced by forcing p22 and then have the
heap optimizer remove the getfield_gc_pure. Using the pure operations
optimizer here is not straight forwars as there is no
getfield_gc_pure(p22).

In test_misc i17 is passes at two places of the jumpargs. This
indicates that I have refrained from specializing this loop to the
fact that these two boxes are equal (which might not be the case at
the end of some bridge). Instead the single box is duplicated at the
end of the loop. To do that a new box has to be introduced and the
pure operation removal algorithm will only link the int_add operations
to one of them. This would be fixable by recursivly duplicating all
potential operations in the short preamble that have arguments that
have been duplicated. But I'm not sure how good an idea that is...

-- 
Håkan Ardö