Hi Laura, On 28 March 2014 10:48, Laura Creighton <lac@openend.se> wrote:

Ah, thank you. I actually thought we had found the odd example where a better gc beat CPython performance even when the jit was off. I am completely wrong about this? Or is it just that it is so rare it doesn't matter?

Ah, no, you are correct, sorry. Running "gcbench.py" we see a different behavior than CPython. This benchmark runs 7 tests which, on CPython, take from 0.9 increasing to 3.5 seconds each; and on PyPy (without the JIT) it increases from 1.7 to 1.9 seconds only. The last three of these 7 tests are slower on CPython. I'm unsure if we ever had a precise explanation for why. In general it's one of the only examples we have. It seems to show that even CPython is, most of the time, not making demands on its GC that exceed what reference counting is good for. (There might be other cases that could appear in big applications, like creating tons and tons of cyclic garbage, but we don't really know, I think.) A bientôt, Armin.

Hi Laura, On 28 March 2014 10:48, Laura Creighton <lac@openend.se> wrote:

Ah, thank you. I actually thought we had found the odd example where a better gc beat CPython performance even when the jit was off. I am completely wrong about this? Or is it just that it is so rare it doesn't matter?

Ah, no, you are correct, sorry. Running "gcbench.py" we see a different behavior than CPython. This benchmark runs 7 tests which, on CPython, take from 0.9 increasing to 3.5 seconds each; and on PyPy (without the JIT) it increases from 1.7 to 1.9 seconds only. The last three of these 7 tests are slower on CPython. I'm unsure if we ever had a precise explanation for why. In general it's one of the only examples we have. It seems to show that even CPython is, most of the time, not making demands on its GC that exceed what reference counting is good for. (There might be other cases that could appear in big applications, like creating tons and tons of cyclic garbage, but we don't really know, I think.) A bientôt, Armin.