|Bill Allombert on Tue, 20 Jan 2015 21:32:38 +0100|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|Re: Stack size bugs and parisizemax|
On Tue, Jan 20, 2015 at 04:31:16PM +0100, Jeroen Demeyer wrote: > Hello pari-dev, > > At the atelier you mentioned that it shouldn't hurt to set a small > parisize but a large parisizemax. In the light of this, bugs where > some computation is much slower with a small parisize are more > serious. > > I think there should be some general solution to this problem which > takes into account the value of parisizemax. The idea should be: do > not collect garbage too often if instead we can increase parisize. Hello Jeroen, The purpose of parisizemax was to allow to have a nearly unlimited stack (limited only by the available hardware) without increasing the actual memory usage (in the sense that the final stack size will be close to the minimum stack size for which the computation would have succeed, up to a factor of two). It is possible that we are no quite there yet. > For this reason, I'm not completely happy with > 25b0af6b8510e5b2feaa0d47fababa2fd25921e0. My proposal would be: if > parisize < parisizemax, then call gerepileall() at most once per > outer loop iteration. I assume you would still like to call gerepileall() when parisize reaches parisizemax, otherwise you will get a stack overflow. Your proposed change would cause the stack to fill up quickly to parisizemax even for computation that could be done with the default stack with a minor slow down. Thus, it is close to the behaviour you would get by setting parisize=parisizemax from the start. Cheers, Bill.