|Bill Allombert on Wed, 05 Jul 2017 18:44:35 +0200|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|Re: gcopy_avma() is wasting stack memory compared to gcopy()|
On Tue, Jul 04, 2017 at 10:43:44AM +0200, Bill Allombert wrote: > On Tue, Jul 04, 2017 at 08:11:54AM +0200, Karim Belabas wrote: > > * Jens Schmidt [2017-07-04 07:47]: > > > Hello PARI developer. > > > > > > PARI Library Guide (PDF) writes: "GEN gcopy_avma(GEN x, pari_sp *AVMA) > > > return a copy of x as from gcopy, except that we pretend that initially > > > avma is *AVMA, and that *AVMA is updated accordingly (so that the total > > > size of x is the difference between the two successive values of *AVMA)." > > > I noticed that gcopy_avma() needs more memory (~ 20%-30%) than gcopy() > > > to create a copy of a GEN object if GEN is of non recursive type, e.g. > > > t_POL or t_SER. Therefore I've written a shot test function to dissect > > > the PARI stack. > > > > The difference is due to gen_0: gcopy is allowed to keep (or create) pointers > > to "universal objects", which need not be copied, whereas gcopy_avma is > > a low-level function that was used to serialize objects out of a PARI > > session and thus makes a deep copy of everything. It makes a huge > > difference for sparse structures. > > > > I am not sure a gcopy_avma with the above semantic [which has never been > > documented] is useful anymore, it does not seem to be used in the PARI > > sources any longer; it is present twice: in gclone (where it's > > definitely not needed) and in the pthread interface (where I *believe* > > at this point that it's not needed). I'll investigate. > > gcopy_avma is needed for pthread.c, but not with this semantic, since > the threads share the universal constants, but not the same PARI stack. I have just found that gcopy_avma in pthread.c was causing problem because it does not handle stack overflow. ? default(threadsize,"1M") ? my(P=polmodular(101));pareval(vector(10,i,()->P*Mod(1,101))) *** polmodular: Warning: increasing stack size to 16000000. *** polmodular: Warning: increasing stack size to 32000000. *** Warning: increasing stack size to 64000000. *** at top-level: my(P=polmodular(101));pareval(vector(10,i,()-> *** ^------------------------ *** pareval: bug in PARI/GP (Segmentation Fault), please report. So we need something better. Cheers, Bill.