Re: handling several substacks ?

[Karim Belabas <Karim.Belabas@math.u-bordeaux.fr>]

* 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]
`