[Python-Dev] Re: ... gcmodule.c,2.9,2.10
Sun, 3 Sep 2000 00:06:41 +0200 (CEST)
Tim Peters wrote:
> There's not going to be consensus on this, as the threshold is a crude
> handle on a complex problem.
Hehe. Tim gets philosophic again <wink>
> In cases like this, the geometric mean of the extreme positions is
> always the best guess <0.8 wink>:
> >>> import math
> >>> math.sqrt(5000 * 100)
> So 9 times out of 10 we can run it with a threshold of 707, and 1 out of 10
> with 708 <wink>.
> Tuning strategies for gc *can* get as complex as OS scheduling algorithms,
> and for the same reasons: you're in the business of predicting the future
> based on just a few neurons keeping track of gross summaries of what
> happened before.
Right on target, Tim! It is well known that the recent past is the best
approximation of the near future and that the past as a whole is the only
approximation we have at our disposal of the long-term future. If you add
to that axioms like "memory management schemes influence the OS long-term
scheduler", "the 50% rule applies for all allocation strategies", etc.,
it is clear that if we want to approach the optimum, we definitely need
to adjust the collection frequency according to some proportional scheme.
But even without saying this, your argument about dynamic GC thresholds
is enough to put Neil into a state of deep depression regarding the
current GC API <0.9 wink>.
Now let's be pragmatic: it is clear that the garbage collector will
make it for 2.0 -- be it enabled or disabled by default. So let's stick
to a compromise: 500 for the beta, 1000 for the final release. This
somewhat complies to your geometric calculus which mainly aims at
balancing the expressed opinions. It certainly isn't fond regarding
any existing theory or practice, and we all realized that despite the
impressive math.sqrt() <wink>.
Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252