On Wed, Aug 10, 2011 at 5:27 PM, Alex Gaynor <alex.gay...@gmail.com> wrote: > > > On Wed, Aug 10, 2011 at 8:06 AM, Maciej Fijalkowski <fij...@gmail.com> > wrote: >> >> On Wed, Aug 10, 2011 at 4:43 PM, Hakan Ardo <ha...@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@python.org >> > http://mail.python.org/mailman/listinfo/pypy-dev >> > >> _______________________________________________ >> pypy-dev mailing list >> pypy-dev@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ö _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
