Hi,
better to ask it here since I suspect that most people won't be much on irc during the next days: I wrote a blog post draft about the gc-disable branch which I have recently merged; it is available on extradoc: https://bitbucket.org/pypy/extradoc/src/extradoc/blog/draft/2018-12-gc-disab...
Reviews, comments and remarks are welcome. I think I'd like to publish it after Christmas.
ciao, Anto
Hi Anto,
Nice post, but I would add a few things (can't edit the post because I'm on the phone only):
- we still do minor connections, don't we? That doesn't become clear in the post at all! So, together with virtuals, all objects with short or predictable life times still get collected.
- I would put a disclaimer saying that this is a pretty specialized use case and most people aren't going to need it.
Happy holidays to everybody!
Carl Friedrich
On December 23, 2018 11:45:15 AM GMT+01:00, Antonio Cuni anto.cuni@gmail.com wrote:
Hi,
better to ask it here since I suspect that most people won't be much on irc during the next days: I wrote a blog post draft about the gc-disable branch which I have recently merged; it is available on extradoc: https://bitbucket.org/pypy/extradoc/src/extradoc/blog/draft/2018-12-gc-disab...
Reviews, comments and remarks are welcome. I think I'd like to publish it after Christmas.
ciao, Anto
Hi Anto,
On Mon, 24 Dec 2018 at 12:45, Carl Friedrich Bolz-Tereick cfbolz@gmx.de wrote:
https://bitbucket.org/pypy/extradoc/src/extradoc/blog/draft/2018-12-gc-disab...
Any clue about why the "purple line" graph, after adding some gc.disable() and gc.collect_step(), is actually 10% faster than the baseline? Is that because "purple" runs the GC when "yellow" would be sleeping waiting for the next input, and you don't count that time in the performance? If so, maybe we could clarify that we don't expect better overall performance by adding some gc.disable() and gc.collect_step() in a program doing just computations---in this case it works because it is reorganizing tasks in such a way that the GC runs at a moment where it is "free".
A bientôt,
Armin.
On Tue, Dec 25, 2018 at 8:59 AM Armin Rigo armin.rigo@gmail.com wrote:
Any clue about why the "purple line" graph, after adding some gc.disable() and gc.collect_step(), is actually 10% faster than the baseline? Is that because "purple" runs the GC when "yellow" would be sleeping waiting for the next input, and you don't count that time in the performance? If so, maybe we could clarify that we don't expect better overall performance by adding some gc.disable() and gc.collect_step() in a program doing just computations---in this case it works because it is reorganizing tasks in such a way that the GC runs at a moment where it is "free".
Yes, that's exactly the reason: the GC still runs, but runs "somewhere else" which is not shown in the graph. I added a paragraph to explain it better, thanks for the suggestion.
Btw, the final blog post has been published here: https://morepypy.blogspot.com/2019/01/pypy-for-low-latency-systems.html
ciao, Anto
Hellos.
Thanks Antonio and everyone. This is a wonderful present! Happy dance.
I've been able to replicate the results with some pygame experiments. Less variance, and the spikes are gone. Additionally I was able to try running the GC in a thread when the GIL is released. This resulted in peak performance increasing by 11%.
Details here: https://renesd.blogspot.com/2019/01/experiments-with-new-low-latency-pypy.ht...
cheers,
participants (4)
-
Antonio Cuni -
Armin Rigo -
Carl Friedrich Bolz-Tereick -
René Dudfield