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... A bientôt, Armin. _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
