[pypy-dev] Benchmarks

[Maciej Fijalkowski]

On Sun, Jul 24, 2011 at 10:12 AM, Armin Rigo <arigo at tunes.org> wrote:
> Hi all,
>
> On Fri, Jul 15, 2011 at 1:44 PM, Armin Rigo <arigo at tunes.org> wrote:
>> On Fri, Jul 15, 2011 at 10:45 AM, Antonio Cuni <anto.cuni at 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