On Sun, Jul 24, 2011 at 10:12 AM, Armin Rigo <ar...@tunes.org> wrote: > Hi all, > > On Fri, Jul 15, 2011 at 1:44 PM, Armin Rigo <ar...@tunes.org> wrote: >> On Fri, Jul 15, 2011 at 10:45 AM, Antonio Cuni <anto.c...@gmail.com> wrote: >>> I think that armin investigated this, and the outcome was that it's because >>> of >>> the changes we did in the GC during the sprint. Armin, do you confirm? >>> Do we have a solution? >> >> I confirm, and still have no solution. I tried to devise a solution >> (see PYPY_GC_LOSTCARD), which actually helps a bit on this and at >> least one other benchmark, but this particular benchmark is still much >> slower than two weeks ago. > > I found and fixed the bug in 82e5051d55c3 (and, to a less major > extend, in 6b4eb34c6091). I also did 4c0d2555caa8: generate from the > jit backend assembler code to set the GC card bit inline, using just > 4-5 instructions, instead of in the write barrier call. Finally I > reverted PYPY_GC_LOSTCARD because it sounds like a hack and isn't > really compatible with 4c0d2555caa8. All in all it gives good > results. > > I can also confirm that both chaos in 3f7e and go in e911 are randomly > slowed down by jit tracer improvements, and would become fast again > with a smaller --jit trace_limit... >
That probably should be addressed (maybe?) so can we decide we're done with regressions? Cheers, fijal _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
