[Scilab-users] setmemory() <= Re: Reintroducing stacksize on Scilab 6 ? was (Re: multiple element by element between large matrix and vector)

[Samuel Gougeon]

Hello Clément,

Le 28/09/2015 12:01, Clément David a écrit :
> .../...
> So I have a question on your needs for Scilab 6. There is currently no
> more stacksize as all the system's memory is available. To protect
> users, I suggested to re-introduce `stacksize` with a changed behavior
> :
>
>   * M=stacksize(N) : will set N * sizeof(double) bytes available on the
> Scilab datatypes raw memory
>                      will return M the previous sett'ed value
>   * stacksize('max') : will disable any memory restriction
>
> ## Why re-introducing `stacksize` ?
>
> On my Linux system (with 8Go of RAM and some applications started),
> allocating all my memory (like with `zeros(2**30,2**3)`) slow my
> computer down and succeed after a lot of time. Reducing the memory
> available to Scilab using `stacksize` will help user discover algorithm
> or memory issues more rapidly and without swapping most of the other
> applications *by default* .
>
> My point is not to limit the available memory issue but ease language
> usage for new-comers by protect them against typo or mis-design
> algorithms.
>
> Awaiting your opinion,
.
Since the 6.0.0-a1 release, several bugs somewhat linked to memory 
saturation were reported.
After one of them, you are going to allow users to configure the maximal 
recursivity depth.
It will be a useful improvement to avoid memory overflow, but it is not 
sufficient to avoid
saturations. Indeed, not only the number of recursive calls is involved, 
but also the
quantity of additional intermediate memory used by each call, which 
usually depends on
the recursive level reached, etc.
The fact that memory management is changed in Scilab 6 does not kill the 
need to control
the maximal amount of memory to ascribe to each Scilab session, because, 
unfortunately,
operating systems do not always manage the computer ressources in 
processors and
RAM load or interruptions in a relevant or efficient way to avoid 
"burning" a processor.
IMO, this is not a matter of Scilab 5=>6 back compatibility. It is a 
main specific characteristic
of major releases to not be necessarily back-compatible with the 
previous ones.
So, which function with which features ?

* setmemory() would be a better name than stacksize():
    It is converse to getmemory(). It is more explicit and user-oriented.

* it should merge in a whole local intermediate and global memory 
domains, corresponding to
    the former stacksize() and gstacksize().
    This is another reason to not use "stacksize" as function name.

* It should work in Bytes, not in doubles.
    The documentation has always been somewhat confused about unit used 
for amounts of memory,
    mixing "double" with "word" (a word = 8 bytes. not really common for 
users).
    The standard unit is either the bit or the byte. There is no reason 
to stress on the 8-bytes "double".
    Scilab deals with int8, int16, int32, int64, double. By the way, 
"double" is an oldies.
    Amounts of RAM, disk spaces, etc are given in bytes, not in doubles.
    So, let's make setmemory() working in bytes.

* The last question i have in mind is about the Java memory heap that 
can already be configured
    through preferences, and reserved to Scilab usages.
    a) it should be decided whether the memory amount set with 
setmemory() should take the Java
         heap into account or not. IMO, it should include it. Or an 
option should specify it.

    b) Is the amount set for the  java heap reserved for the only Scilab 
session, or is it shared for
         all running scilab sessions? It may be an obvious question for 
a developer, but it is not
         clear for me. It would deserve to be documented.

    c) i think that setmemory() should propose an option to set the java 
heap amount, as a
        shortcut to the preferences, in such a way to be a "single desk" 
for all memory settings
        for scilab.

To be discussed.
Anyway, thanks for your proposal, since yes, a memory setting function 
is still needed.

Best regards
Samuel Gougeon