Quantcast

How Core works ?

classic Classic list List threaded Threaded
3 messages Options
Amanda Osvaldo Amanda Osvaldo
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

How Core works ?

Hi, everbody.

Someone knows the Java VisualVM ?

It's a tool to visualize the internal function of Java Virtual Machine, it's very useful to track how the Java application it's working in real time.

We have something similar for SciLAB ?

For example, we have how to see in real time how the SciLAB's memory management it's working?

For example, we have how to do a real time maptree from the SciLAB's macro memory ?

And we can see, in real time, how user action flows into SciLAB's core in a more dynamic way without activating a C++ code coverage and mining millions of stack logs?

In another words ... we have a SciLAB VisualVM ?


-- Amanda Osvaldo

_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
Clément David-2 Clément David-2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How Core works ?

Hi Amanda,

> Someone knows the Java VisualVM ?

Yes I used it when debugging memory issues in Xcos and other Java coded components. It provides *a
lot* of information about running but requires runtime instrumentation which is not available in
released Scilab build.

> We have something similar for SciLAB ?

We have some "inspector" gateways available in a Scilab debug build which provides
`inspectorShowItem()`, `inspectorGetItem()`, etc... This is not enabled in a released build due to
the overhead.

At runtime in release mode, Scilab 5 `who()` was able to return the size of the allocated data but
this is not implemented yet as this is not clear to us if we should return the size of the allocated
raw data or the size of the Scilab value. For exemple :

a = zeros(10,10);

 1. `a` is 10x10 matrix of double, and thus with size:  10*10*8 bytes.
 2. `a` is an ArrayOf<double> with size : sizeof(types::Double) + 10*10*8 bytes

Both computation are valuable, to determine either the data weight in memory or the memory allocated
by scilab to use them.

Note: currently our Types implementation are heavy due to the added multi-dimensional array ; on my
machine :

(gdb) p sizeof(types::Double)
$1 = 216
(gdb) p sizeof(types::ArrayOf<double>)
$2 = 208
(gdb) p sizeof(types::GenericType)
$3 = 192
(gdb) p sizeof(types::InternalType)
$4 = 40


Thanks for your questions,

--
Clément
_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

who(): how to count used memory

Hi Clément,

Le 22/02/2017 à 09:44, Clément David a écrit :
> .../...
> At runtime in release mode, Scilab 5 `who()` was able to return the size of the allocated data but this is not implemented yet as this is not clear to us if we should return the size of the allocated raw data or the size of the Scilab value. For exemple :
>
> a = zeros(10,10);
>
>   1. `a` is 10x10 matrix of double, and thus with size:  10*10*8 bytes.
>   2. `a` is an ArrayOf<double> with size : sizeof(types::Double) + 10*10*8 bytes
>
> Both computation are valuable, to determine either the data weight in memory or the memory allocated by scilab to use them.

Up to now, the memory used by the container was included in who() results.
Why not allowing both results, and implementing an option to let the
user choosing the counting mode?

IMHO, returning the data memory without the container could become the
default. The relative difference between both gets very small as the
sizes of data increase.
For sparse encodings, the indices locating each non-zero or true value
could be accounted with the values (so not being considered as part of
the container), because the memory used to store indices is proportional
to the number of non-zero values. The container being just the
"structural" remainder.

By the way, it would be much clearer to return the number of bytes
instead of the equivalent number of decimal numbers. This unit (8-bytes
sometimes called a "word" in the help) looks screwy. It is
straightforward to understand it only for decimal numbers (and only with
real values), while bytes are datatype independent.
If back-compatibility is of concern, this could be returned with a new
unit="bytes" option. Otherwise, it could become the default.

HTH
Samuel

_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
Loading...