Karim Belabas on Wed, 05 Feb 2014 15:34:04 +0100 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: handling several substacks ? |
* Bill Allombert [2014-02-05 13:12]: [...] > > But thay have a much better worse case behaviour: in "desperation mode, > > when too little memory was available to start with, low_stack will be > > triggered frequently; in the worse case, each scalar operation triggers > > a gerepilecopy of the full array... > > But this assumes there is extra memory available for the clone, > in which case it would be possible to use a larger stack. Sure. The problem is that a function taken in isolation has no way of dealing with that with the current "fixed-size stack" model. The true problems arise in situations such as fun_1() -> fun_2() -> ... -> fun_k() where all functions in the call stack rely on "random GC", i.e. if(low_stack()). Any of the fun_i() *could* collect garbage and leave more breathing space for the deeper calls, but all the actual GC occurs in fun_k in desperation mode. In principle, it would be doable to trigger GC in any of the intermediate functions at appropriate levels, esp. when the size of involved objects is controlled. But this is rarely done in practice. With a *huge* stack size, we are dead if desperation GC occurs in fun_k. With a smaller stack (thus more memory available for clones) we can survive. This is mostly a concern in linear algebra routines over infinite fields or over Z, hnfspec called from bnfinit being a notorious example. We need to experiment with your parisizemax / pari_mainstack branches (dynamic stack size increase) ... Cheers, K.B. -- Karim Belabas, IMB (UMR 5251) Tel: (+33) (0)5 40 00 26 17 Universite Bordeaux 1 Fax: (+33) (0)5 40 00 69 50 351, cours de la Liberation http://www.math.u-bordeaux1.fr/~kbelabas/ F-33405 Talence (France) http://pari.math.u-bordeaux1.fr/ [PARI/GP] `