New xcos blocks executing scilab primitive functions

classic Classic list List threaded Threaded
8 messages Options
ericgernot ericgernot
Reply | Threaded
Open this post in threaded view
|

New xcos blocks executing scilab primitive functions

Hi,

I am new to scilab, and I am not a developper, but I fear I may become one
because of Scilab :-;
I am on windows 7 /64, and installed some recent versions.

I created a physic model (chemical process with compositions, streams, etc.)
from a script and used xcos to solve it, only using Sci_func blocks calling
my functions (so that it is easily portable to other scilab versions). It
works as desired, so now I want to speed it up.

After all the possible improvements from vectorization, I decided to convert
30% of my scifunc into superblocks, giving a 30% speedup boost to the model.
I could have written these in c/c++ also, but I suspect it would have taken
longer (for me)

My remaining scifunc blocks are using some scilab gateways such as fsolve,
diag, etc, thus the conversion is not as straighforward.

I tried to convert it in c using the scilab 2 c toolbox, this is great for
all operations exept scilab gateways.

I had a look at how to create a new block, how the c-block work, and finally
how existing blocks are coded in c++.

If I understand well, the possibilities are
1. copy the c++ primitive function code in a c-block, it will not work
because it is not c, and because I don't know which libraries should be
included. By the way, where can I put them so that the compiler finds them ?
2. use scilab API from a xcos c-block and send jobs. Will it really skip the
interpreter ?
3. create a new block as a user (from within scilab). But you can't use c++
can you ? So I have to write or find c equivalent of scilab primitives, this
is a pity !
4. create a new block source code, and compile a new version of scilab with
the new block. I suppose that the same problem exists: converting to c
scilab primitives ?

So this raised a few questions:
 - In the block source code, why not call scilab built in functions in c/c++
(not the gateway), only passing them the block arguments / parameters,
instead of pasting the code there. That would ease the creation of new
blocks isn't it ?
 - can users call these built in functions in their custom blocks (e.g.
c-block) ? (I mean without invoking the parser etc., without linking already
linked libraries, etc.)

I suppose that many users ran through these problems.
Thank you very mucn
Regards,
Eric




--
Sent from: http://mailinglists.scilab.org/Scilab-developers-Mailing-Lists-Archives-f2574944.html
_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
Clément David-3 Clément David-3
Reply | Threaded
Open this post in threaded view
|

Re: New xcos blocks executing scilab primitive functions

Hi Eric and welcome :)

Nice to have some power users (and maybe futur developers) using big Xcos models, Xcos in 6.0.x have
some issues only visible on big diagrams and we currently do not spend too much time benchmarking
it.
 
About the scifunc vs Superbloc vs C++ implementation speedup, the clear winner there would be C/C++
if (and only if) there is no event management (either discrete or zero-crossing) to perform. Zero
crossing detection is hard to implement even for small sub-systems and discrete events are only easy
for synchronous subsystem. Superblocs are straightforward to implement and manage very complex
events / continuous states intrication in a clean manner however they can be confusing to maintains
(for exemple if you want to preserve the same behavior across different blocks). Scifunc are in-
between to me in term of implementation however very poor in term of performance (and not optimized
at all).

You could use the scicos_block4 API (the default one) in C or C++ ; if you take a look at our source
code there is only a few in C++ but they can be easily converted to. About the libraries, I did not
get it, do you want to link to different libraries ? The xcos_toolbox_skeleton and ilib_for_build()
flags are working well.

To call Scilab script within the sciblk2 [1] and sciblk4 [2] blocks we are indeed using the Scilab
C++ API, the performance overhead is quiet clear as we are currently allocating Scilab types::Double
 or a types::MList through createblklist() for each output on each simulation step. This does an
extra allocation (for the Scilab datatype) and a copy (for the data copy to scilab) whereas in C/C++
 the data are passed by reference to the shared buffers. We clearly have to do better there ; maybe
by allocating only once (at Initialization time) or passing types:: views to the shared buffers.
There is a test case within xcos_toolbox_skeleton which switch the implementation of a NOOP block
(that compute nothing) between Scilab and C depending on a parameter in Scilab.

[1]: http://cgit.scilab.org/scilab/tree/scilab/modules/scicos/src/cpp/sciblk2.cpp#n57
[2]: http://cgit.scilab.org/scilab/tree/scilab/modules/scicos/src/cpp/sciblk4.cpp#n217

As a conclusion, yes you can call C++ functions from blocks and Scilab blocks issues comes from a
slow implementation of C->Scilab calls not from the Scilab code interpretation.

NB: yes this a known problem and some users already reports that but no one is currently working on
that.

Thanks,

--
Clément

Le vendredi 06 avril 2018 à 05:47 -0700, ericgernot a écrit :

> Hi,
>
> I am new to scilab, and I am not a developper, but I fear I may become one
> because of Scilab :-;
> I am on windows 7 /64, and installed some recent versions.
>
> I created a physic model (chemical process with compositions, streams, etc.)
> from a script and used xcos to solve it, only using Sci_func blocks calling
> my functions (so that it is easily portable to other scilab versions). It
> works as desired, so now I want to speed it up.
>
> After all the possible improvements from vectorization, I decided to convert
> 30% of my scifunc into superblocks, giving a 30% speedup boost to the model.
> I could have written these in c/c++ also, but I suspect it would have taken
> longer (for me)
>
> My remaining scifunc blocks are using some scilab gateways such as fsolve,
> diag, etc, thus the conversion is not as straighforward.
>
> I tried to convert it in c using the scilab 2 c toolbox, this is great for
> all operations exept scilab gateways.
>
> I had a look at how to create a new block, how the c-block work, and finally
> how existing blocks are coded in c++.
>
> If I understand well, the possibilities are
> 1. copy the c++ primitive function code in a c-block, it will not work
> because it is not c, and because I don't know which libraries should be
> included. By the way, where can I put them so that the compiler finds them ?
> 2. use scilab API from a xcos c-block and send jobs. Will it really skip the
> interpreter ?
> 3. create a new block as a user (from within scilab). But you can't use c++
> can you ? So I have to write or find c equivalent of scilab primitives, this
> is a pity !
> 4. create a new block source code, and compile a new version of scilab with
> the new block. I suppose that the same problem exists: converting to c
> scilab primitives ?
>
> So this raised a few questions:
>  - In the block source code, why not call scilab built in functions in c/c++
> (not the gateway), only passing them the block arguments / parameters,
> instead of pasting the code there. That would ease the creation of new
> blocks isn't it ?
>  - can users call these built in functions in their custom blocks (e.g.
> c-block) ? (I mean without invoking the parser etc., without linking already
> linked libraries, etc.)
>
> I suppose that many users ran through these problems.
> Thank you very mucn
> Regards,
> Eric
>
>
>
>
> --
> Sent from: http://mailinglists.scilab.org/Scilab-developers-Mailing-Lists-Archives-f2574944.html
> _______________________________________________
> dev mailing list
> [hidden email]
> http://lists.scilab.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
ericgernot ericgernot
Reply | Threaded
Open this post in threaded view
|

Re: New xcos blocks executing scilab primitive functions

Hello Clement,

 

Thank you for this very clear answer.

How does Scilab Gateways work? When we tap enter after entering the command line on the prompt, let's say to call a primitive, does the gateway also need the API ?

Or is there a more direct way to do so ?

 

Regarding my questions on the libraries.

Well, let's say I am a simple user of scilab, with no code development tools installed.

Editing a c-block, seeing the #include math.h line was a bit scary, because I thought "this will require that I have put the math.h file at the good place on my computer".

So I insert nothing in the code, click "ok" and the compilation is succesful. 

Now after running Scilab 2 c toolbox on my custom code, a number of subdirectories with multiple files were created in my custom directory. I suppose if I want this scilab 2 c created code running in the c-block, I have to put these files where the block can access them at compilation time.

Same if I created the code on my own. That is why I asked where the c-block compiler looks to find the files, or how do we configure this, as users.

 

Best regards,

Eric

 

 

 

 

> Message du 09/04/18 09:37

> De : "Clément David" <[hidden email]>
> A : "[hidden email]" <[hidden email]>
> Copie à :
> Objet : Re: [Scilab-Dev] New xcos blocks executing scilab primitive functions
>
> Hi Eric and welcome :)
>
> Nice to have some power users (and maybe futur developers) using big Xcos models, Xcos in 6.0.x have
> some issues only visible on big diagrams and we currently do not spend too much time benchmarking
> it.
>
> About the scifunc vs Superbloc vs C++ implementation speedup, the clear winner there would be C/C++
> if (and only if) there is no event management (either discrete or zero-crossing) to perform. Zero
> crossing detection is hard to implement even for small sub-systems and discrete events are only easy
> for synchronous subsystem. Superblocs are straightforward to implement and manage very complex
> events / continuous states intrication in a clean manner however they can be confusing to maintains
> (for exemple if you want to preserve the same behavior across different blocks). Scifunc are in-
> between to me in term of implementation however very poor in term of performance (and not optimized
> at all).
>
> You could use the scicos_block4 API (the default one) in C or C++ ; if you take a look at our source
> code there is only a few in C++ but they can be easily converted to. About the libraries, I did not
> get it, do you want to link to different libraries ? The xcos_toolbox_skeleton and ilib_for_build()
> flags are working well.
>
> To call Scilab script within the sciblk2 [1] and sciblk4 [2] blocks we are indeed using the Scilab
> C++ API, the performance overhead is quiet clear as we are currently allocating Scilab types::Double
> or a types::MList through createblklist() for each output on each simulation step. This does an
> extra allocation (for the Scilab datatype) and a copy (for the data copy to scilab) whereas in C/C++
> the data are passed by reference to the shared buffers. We clearly have to do better there ; maybe
> by allocating only once (at Initialization time) or passing types:: views to the shared buffers.
> There is a test case within xcos_toolbox_skeleton which switch the implementation of a NOOP block
> (that compute nothing) between Scilab and C depending on a parameter in Scilab.
>
> [1]: http://cgit.scilab.org/scilab/tree/scilab/modules/scicos/src/cpp/sciblk2.cpp#n57
> [2]: http://cgit.scilab.org/scilab/tree/scilab/modules/scicos/src/cpp/sciblk4.cpp#n217
>
> As a conclusion, yes you can call C++ functions from blocks and Scilab blocks issues comes from a
> slow implementation of C->Scilab calls not from the Scilab code interpretation.
>
> NB: yes this a known problem and some users already reports that but no one is currently working on
> that.
>
> Thanks,
>
> --
> Clément
>
> Le vendredi 06 avril 2018 à 05:47 -0700, ericgernot a écrit :
> > Hi,
> >
> > I am new to scilab, and I am not a developper, but I fear I may become one
> > because of Scilab :-;
> > I am on windows 7 /64, and installed some recent versions.
> >
> > I created a physic model (chemical process with compositions, streams, etc.)
> > from a script and used xcos to solve it, only using Sci_func blocks calling
> > my functions (so that it is easily portable to other scilab versions). It
> > works as desired, so now I want to speed it up.
> >
> > After all the possible improvements from vectorization, I decided to convert
> > 30% of my scifunc into superblocks, giving a 30% speedup boost to the model.
> > I could have written these in c/c++ also, but I suspect it would have taken
> > longer (for me)
> >
> > My remaining scifunc blocks are using some scilab gateways such as fsolve,
> > diag, etc, thus the conversion is not as straighforward.
> >
> > I tried to convert it in c using the scilab 2 c toolbox, this is great for
> > all operations exept scilab gateways.
> >
> > I had a look at how to create a new block, how the c-block work, and finally
> > how existing blocks are coded in c++.
> >
> > If I understand well, the possibilities are
> > 1. copy the c++ primitive function code in a c-block, it will not work
> > because it is not c, and because I don't know which libraries should be
> > included. By the way, where can I put them so that the compiler finds them ?
> > 2. use scilab API from a xcos c-block and send jobs. Will it really skip the
> > interpreter ?
> > 3. create a new block as a user (from within scilab). But you can't use c++
> > can you ? So I have to write or find c equivalent of scilab primitives, this
> > is a pity !
> > 4. create a new block source code, and compile a new version of scilab with
> > the new block. I suppose that the same problem exists: converting to c
> > scilab primitives ?
> >
> > So this raised a few questions:
> > - In the block source code, why not call scilab built in functions in c/c++
> > (not the gateway), only passing them the block arguments / parameters,
> > instead of pasting the code there. That would ease the creation of new
> > blocks isn't it ?
> > - can users call these built in functions in their custom blocks (e.g.
> > c-block) ? (I mean without invoking the parser etc., without linking already
> > linked libraries, etc.)
> >
> > I suppose that many users ran through these problems.
> > Thank you very mucn
> > Regards,
> > Eric
> >
> >
> >
> >
> > --
> > Sent from: http://mailinglists.scilab.org/Scilab-developers-Mailing-Lists-Archives-f2574944.html
> > _______________________________________________
> > dev mailing list
> > [hidden email]
> > http://lists.scilab.org/mailman/listinfo/dev _______________________________________________ dev mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
Clément David-3 Clément David-3
Reply | Threaded
Open this post in threaded view
|

Re: New xcos blocks executing scilab primitive functions

Hello Eric,

As described in some guides [1][2], the interpreter will call a gateway passing values using the C++
/ C object-oriented / C stack-oriented APIs depending how you declared it. On the gateway you are
free to do whatever you want with the data.

[1]: https://wiki.scilab.org/howto/Create%20a%20toolbox#Gateway
[2]: https://wiki.scilab.org/Developers

However for Xcos, the story is a bit different as the blocks will be called by a simulator (ODE /
IDA solver) not an interpreter ; the API is different and called scicos_block4 ; using a C-block you
have to describe the interface and write some code using the data passed as arguments.

Note: Scilab2C is a  toolbox which might (or might not) follow Scilab coding conventions.

--
Clément


Le lundi 09 avril 2018 à 12:33 +0200, Eric GERNOT a écrit :

> Hello Clement,
>  
> Thank you for this very clear answer.
> How does Scilab Gateways work? When we tap enter after entering the command line on the prompt,
> let's say to call a primitive, does the gateway also need the API ?
> Or is there a more direct way to do so ?
>  
> Regarding my questions on the libraries.
> Well, let's say I am a simple user of scilab, with no code development tools installed.
> Editing a c-block, seeing the #include math.h line was a bit scary, because I thought "this will
> require that I have put the math.h file at the good place on my computer".
> So I insert nothing in the code, click "ok" and the compilation is succesful.
> Now after running Scilab 2 c toolbox on my custom code, a number of subdirectories with multiple
> files were created in my custom directory. I suppose if I want this scilab 2 c created code
> running in the c-block, I have to put these files where the block can access them at compilation
> time.
> Same if I created the code on my own. That is why I asked where the c-block compiler looks to find
> the files, or how do we configure this, as users.
>  
> Best regards,
> Eric
>  
>  
>  
>  
> > > Message du 09/04/18 09:37
> > > De : "Clément David" <[hidden email]>
> > > A : "[hidden email]" <[hidden email]>
> > > Copie à :
> > > Objet : Re: [Scilab-Dev] New xcos blocks executing scilab primitive functions
> > >
> > > Hi Eric and welcome :)
> > >
> > > Nice to have some power users (and maybe futur developers) using big Xcos models, Xcos in
> > 6.0.x have
> > > some issues only visible on big diagrams and we currently do not spend too much time
> > benchmarking
> > > it.
> > >
> > > About the scifunc vs Superbloc vs C++ implementation speedup, the clear winner there would be
> > C/C++
> > > if (and only if) there is no event management (either discrete or zero-crossing) to perform.
> > Zero
> > > crossing detection is hard to implement even for small sub-systems and discrete events are
> > only easy
> > > for synchronous subsystem. Superblocs are straightforward to implement and manage very complex
> > > events / continuous states intrication in a clean manner however they can be confusing to
> > maintains
> > > (for exemple if you want to preserve the same behavior across different blocks). Scifunc are
> > in-
> > > between to me in term of implementation however very poor in term of performance (and not
> > optimized
> > > at all).
> > >
> > > You could use the scicos_block4 API (the default one) in C or C++ ; if you take a look at our
> > source
> > > code there is only a few in C++ but they can be easily converted to. About the libraries, I
> > did not
> > > get it, do you want to link to different libraries ? The xcos_toolbox_skeleton and
> > ilib_for_build()
> > > flags are working well.
> > >
> > > To call Scilab script within the sciblk2 [1] and sciblk4 [2] blocks we are indeed using the
> > Scilab
> > > C++ API, the performance overhead is quiet clear as we are currently allocating Scilab
> > types::Double
> > > or a types::MList through createblklist() for each output on each simulation step. This does
> > an
> > > extra allocation (for the Scilab datatype) and a copy (for the data copy to scilab) whereas in
> > C/C++
> > > the data are passed by reference to the shared buffers. We clearly have to do better there ;
> > maybe
> > > by allocating only once (at Initialization time) or passing types:: views to the shared
> > buffers.
> > > There is a test case within xcos_toolbox_skeleton which switch the implementation of a NOOP
> > block
> > > (that compute nothing) between Scilab and C depending on a parameter in Scilab.
> > >
> > > [1]: http://cgit.scilab.org/scilab/tree/scilab/modules/scicos/src/cpp/sciblk2.cpp#n57
> > > [2]: http://cgit.scilab.org/scilab/tree/scilab/modules/scicos/src/cpp/sciblk4.cpp#n217
> > >
> > > As a conclusion, yes you can call C++ functions from blocks and Scilab blocks issues comes
> > from a
> > > slow implementation of C->Scilab calls not from the Scilab code interpretation.
> > >
> > > NB: yes this a known problem and some users already reports that but no one is currently
> > working on
> > > that.
> > >
> > > Thanks,
> > >
> > > --
> > > Clément
> > >
> > > Le vendredi 06 avril 2018 à 05:47 -0700, ericgernot a écrit :
> > > > Hi,
> > > >
> > > > I am new to scilab, and I am not a developper, but I fear I may become one
> > > > because of Scilab :-;
> > > > I am on windows 7 /64, and installed some recent versions.
> > > >
> > > > I created a physic model (chemical process with compositions, streams, etc.)
> > > > from a script and used xcos to solve it, only using Sci_func blocks calling
> > > > my functions (so that it is easily portable to other scilab versions). It
> > > > works as desired, so now I want to speed it up.
> > > >
> > > > After all the possible improvements from vectorization, I decided to convert
> > > > 30% of my scifunc into superblocks, giving a 30% speedup boost to the model.
> > > > I could have written these in c/c++ also, but I suspect it would have taken
> > > > longer (for me)
> > > >
> > > > My remaining scifunc blocks are using some scilab gateways such as fsolve,
> > > > diag, etc, thus the conversion is not as straighforward.
> > > >
> > > > I tried to convert it in c using the scilab 2 c toolbox, this is great for
> > > > all operations exept scilab gateways.
> > > >
> > > > I had a look at how to create a new block, how the c-block work, and finally
> > > > how existing blocks are coded in c++.
> > > >
> > > > If I understand well, the possibilities are
> > > > 1. copy the c++ primitive function code in a c-block, it will not work
> > > > because it is not c, and because I don't know which libraries should be
> > > > included. By the way, where can I put them so that the compiler finds them ?
> > > > 2. use scilab API from a xcos c-block and send jobs. Will it really skip the
> > > > interpreter ?
> > > > 3. create a new block as a user (from within scilab). But you can't use c++
> > > > can you ? So I have to write or find c equivalent of scilab primitives, this
> > > > is a pity !
> > > > 4. create a new block source code, and compile a new version of scilab with
> > > > the new block. I suppose that the same problem exists: converting to c
> > > > scilab primitives ?
> > > >
> > > > So this raised a few questions:
> > > > - In the block source code, why not call scilab built in functions in c/c++
> > > > (not the gateway), only passing them the block arguments / parameters,
> > > > instead of pasting the code there. That would ease the creation of new
> > > > blocks isn't it ?
> > > > - can users call these built in functions in their custom blocks (e.g.
> > > > c-block) ? (I mean without invoking the parser etc., without linking already
> > > > linked libraries, etc.)
> > > >
> > > > I suppose that many users ran through these problems.
> > > > Thank you very mucn
> > > > Regards,
> > > > Eric
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Sent from: http://mailinglists.scilab.org/Scilab-developers-Mailing-Lists-Archives-f2574944.
> > html
> > > > _______________________________________________
> > > > dev mailing list
> > > > [hidden email]
> > > > http://lists.scilab.org/mailman/listinfo/dev _______________________________________________
> > dev mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/dev
>
> _______________________________________________
> dev mailing list
> [hidden email]
> http://lists.scilab.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
ericgernot ericgernot
Reply | Threaded
Open this post in threaded view
|

Re: New xcos blocks executing scilab primitive functions

Clément,

 

Would it be different if we had to create a X_cos block executing a single Scilab expression (block output = RHS (block input, t, state derivative)) ?

 

I noted that the actual Scifunc Block is very powerful and educational thus to me it should not be changed.

 

Also I started suspecting that, although Scifunc blocks alone are slow compared to c or already provided blocks, they may not always be the bottleneck in the context of a specific calculation.

I have to compare a few things and look at how many times each block is called by each solver.

 

Regards,  

Eric

 

 

 

> Message du 09/04/18 15:27

> De : "Clément David" <[hidden email]>
> A : "[hidden email]" <[hidden email]>
> Copie à :
> Objet : Re: [Scilab-Dev] New xcos blocks executing scilab primitive functions
>
> Hello Eric,
>
> As described in some guides [1][2], the interpreter will call a gateway passing values using the C++
> / C object-oriented / C stack-oriented APIs depending how you declared it. On the gateway you are
> free to do whatever you want with the data.
>
> [1]: https://wiki.scilab.org/howto/Create%20a%20toolbox#Gateway
> [2]: https://wiki.scilab.org/Developers
>
> However for Xcos, the story is a bit different as the blocks will be called by a simulator (ODE /
> IDA solver) not an interpreter ; the API is different and called scicos_block4 ; using a C-block you
> have to describe the interface and write some code using the data passed as arguments.
>
> Note: Scilab2C is a toolbox which might (or might not) follow Scilab coding conventions.
>
> --
> Clément
>
>
> Le lundi 09 avril 2018 à 12:33 +0200, Eric GERNOT a écrit :
> > Hello Clement,
> >
> > Thank you for this very clear answer.
> > How does Scilab Gateways work? When we tap enter after entering the command line on the prompt,
> > let's say to call a primitive, does the gateway also need the API ?
> > Or is there a more direct way to do so ?
> >
> > Regarding my questions on the libraries.
> > Well, let's say I am a simple user of scilab, with no code development tools installed.
> > Editing a c-block, seeing the #include math.h line was a bit scary, because I thought "this will
> > require that I have put the math.h file at the good place on my computer".
> > So I insert nothing in the code, click "ok" and the compilation is succesful.
> > Now after running Scilab 2 c toolbox on my custom code, a number of subdirectories with multiple
> > files were created in my custom directory. I suppose if I want this scilab 2 c created code
> > running in the c-block, I have to put these files where the block can access them at compilation
> > time.
> > Same if I created the code on my own. That is why I asked where the c-block compiler looks to find
> > the files, or how do we configure this, as users.
> >
> > Best regards,
> > Eric
> >
> >
> >
> >
> > > > Message du 09/04/18 09:37
> > > > De : "Clément David" <[hidden email]>
> > > > A : "[hidden email]" <[hidden email]>
> > > > Copie à :
> > > > Objet : Re: [Scilab-Dev] New xcos blocks executing scilab primitive functions
> > > >
> > > > Hi Eric and welcome :)
> > > >
> > > > Nice to have some power users (and maybe futur developers) using big Xcos models, Xcos in
> > > 6.0.x have
> > > > some issues only visible on big diagrams and we currently do not spend too much time
> > > benchmarking
> > > > it.
> > > >
> > > > About the scifunc vs Superbloc vs C++ implementation speedup, the clear winner there would be
> > > C/C++
> > > > if (and only if) there is no event management (either discrete or zero-crossing) to perform.
> > > Zero
> > > > crossing detection is hard to implement even for small sub-systems and discrete events are
> > > only easy
> > > > for synchronous subsystem. Superblocs are straightforward to implement and manage very complex
> > > > events / continuous states intrication in a clean manner however they can be confusing to
> > > maintains
> > > > (for exemple if you want to preserve the same behavior across different blocks). Scifunc are
> > > in-
> > > > between to me in term of implementation however very poor in term of performance (and not
> > > optimized
> > > > at all).
> > > >
> > > > You could use the scicos_block4 API (the default one) in C or C++ ; if you take a look at our
> > > source
> > > > code there is only a few in C++ but they can be easily converted to. About the libraries, I
> > > did not
> > > > get it, do you want to link to different libraries ? The xcos_toolbox_skeleton and
> > > ilib_for_build()
> > > > flags are working well.
> > > >
> > > > To call Scilab script within the sciblk2 [1] and sciblk4 [2] blocks we are indeed using the
> > > Scilab
> > > > C++ API, the performance overhead is quiet clear as we are currently allocating Scilab
> > > types::Double
> > > > or a types::MList through createblklist() for each output on each simulation step. This does
> > > an
> > > > extra allocation (for the Scilab datatype) and a copy (for the data copy to scilab) whereas in
> > > C/C++
> > > > the data are passed by reference to the shared buffers. We clearly have to do better there ;
> > > maybe
> > > > by allocating only once (at Initialization time) or passing types:: views to the shared
> > > buffers.
> > > > There is a test case within xcos_toolbox_skeleton which switch the implementation of a NOOP
> > > block
> > > > (that compute nothing) between Scilab and C depending on a parameter in Scilab.
> > > >
> > > > [1]: http://cgit.scilab.org/scilab/tree/scilab/modules/scicos/src/cpp/sciblk2.cpp#n57
> > > > [2]: http://cgit.scilab.org/scilab/tree/scilab/modules/scicos/src/cpp/sciblk4.cpp#n217
> > > >
> > > > As a conclusion, yes you can call C++ functions from blocks and Scilab blocks issues comes
> > > from a
> > > > slow implementation of C->Scilab calls not from the Scilab code interpretation.
> > > >
> > > > NB: yes this a known problem and some users already reports that but no one is currently
> > > working on
> > > > that.
> > > >
> > > > Thanks,
> > > >
> > > > --
> > > > Clément
> > > >
> > > > Le vendredi 06 avril 2018 à 05:47 -0700, ericgernot a écrit :
> > > > > Hi,
> > > > >
> > > > > I am new to scilab, and I am not a developper, but I fear I may become one
> > > > > because of Scilab :-;
> > > > > I am on windows 7 /64, and installed some recent versions.
> > > > >
> > > > > I created a physic model (chemical process with compositions, streams, etc.)
> > > > > from a script and used xcos to solve it, only using Sci_func blocks calling
> > > > > my functions (so that it is easily portable to other scilab versions). It
> > > > > works as desired, so now I want to speed it up.
> > > > >
> > > > > After all the possible improvements from vectorization, I decided to convert
> > > > > 30% of my scifunc into superblocks, giving a 30% speedup boost to the model.
> > > > > I could have written these in c/c++ also, but I suspect it would have taken
> > > > > longer (for me)
> > > > >
> > > > > My remaining scifunc blocks are using some scilab gateways such as fsolve,
> > > > > diag, etc, thus the conversion is not as straighforward.
> > > > >
> > > > > I tried to convert it in c using the scilab 2 c toolbox, this is great for
> > > > > all operations exept scilab gateways.
> > > > >
> > > > > I had a look at how to create a new block, how the c-block work, and finally
> > > > > how existing blocks are coded in c++.
> > > > >
> > > > > If I understand well, the possibilities are
> > > > > 1. copy the c++ primitive function code in a c-block, it will not work
> > > > > because it is not c, and because I don't know which libraries should be
> > > > > included. By the way, where can I put them so that the compiler finds them ?
> > > > > 2. use scilab API from a xcos c-block and send jobs. Will it really skip the
> > > > > interpreter ?
> > > > > 3. create a new block as a user (from within scilab). But you can't use c++
> > > > > can you ? So I have to write or find c equivalent of scilab primitives, this
> > > > > is a pity !
> > > > > 4. create a new block source code, and compile a new version of scilab with
> > > > > the new block. I suppose that the same problem exists: converting to c
> > > > > scilab primitives ?
> > > > >
> > > > > So this raised a few questions:
> > > > > - In the block source code, why not call scilab built in functions in c/c++
> > > > > (not the gateway), only passing them the block arguments / parameters,
> > > > > instead of pasting the code there. That would ease the creation of new
> > > > > blocks isn't it ?
> > > > > - can users call these built in functions in their custom blocks (e.g.
> > > > > c-block) ? (I mean without invoking the parser etc., without linking already
> > > > > linked libraries, etc.)
> > > > >
> > > > > I suppose that many users ran through these problems.
> > > > > Thank you very mucn
> > > > > Regards,
> > > > > Eric
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Sent from: http://mailinglists.scilab.org/Scilab-developers-Mailing-Lists-Archives-f2574944.
> > > html
> > > > > _______________________________________________
> > > > > dev mailing list
> > > > > [hidden email]
> > > > > http://lists.scilab.org/mailman/listinfo/dev _______________________________________________
> > > dev mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/dev
> >
> > _______________________________________________
> > dev mailing list
> > [hidden email]
> > http://lists.scilab.org/mailman/listinfo/dev _______________________________________________ dev mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
ericgernot ericgernot
Reply | Threaded
Open this post in threaded view
|

Re: New xcos blocks executing scilab primitive functions

Here are a few comparisons with 3 scifunc_block (the clock has a period of 1s):

1) computation of two 100 x 100 matrix and attribution of the second 100 x 100 matrix to the output port

2) computation of two scalar and attribution of one to the output port

3) computation of two 100 x 100 matrix, and attribution of a scalar to the output port.

 

(I prefer tic/toc vs timer because it is directly related to the actuel time the user waits).

 

For comparison, I also tested the following scripts in scilab, that do the same as 1) and 2).

The recorded times are +/-

1)  1.5 s (xcos) and 0.7 s (scilab)

2)  0.3 s (xcos) and 0.02 s (scilab)

3)  1.5 s (xcos)

 

As you can see, whether the large data are transfered to the output port or not does not dramatically change the computation time, and it resemble the script computation time (may be specific to this case though).

Does it mean that also Scilab reallocate memory through createblklist() at each new script instruction ?(that was what I thought)

Or is it because scifunc_block store the results of each instruction ?

 

I don't see why Scilab is faster with the scalar.

 

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAgUAAAEeCAIAAACVB/GfAAAgAElEQVR4nO3deXATZ5o/8Hc3B9RsUr/Z2lAJldpaZndqKsnOYUXIgYxqzaayM2R2NslmfRKPZG/MEWPANpdkyYaJfJCCCpMq2CWBGMdbvrATQmV2QmxjyLHB2GAbHPBt2ZDEsiX5kJOYxJP0749utVpSW5Iltfpt+H7KBa/e9+23u5+W+1FLetuEAQAAYBgi9wYAAAAVkA8AAIBhkA8AAICFfAAAAAyDfAAAACzkAwAAYBjkAwAAYJFz584FaEYrWtGKVrTeJq24PgAAAIZBPgAAABbyAQAAMAzyAQAAsJAPAACAYZAPAACAhXwAAAAMg3wAAAAs5AMAAGCYyOcnz8/PG43G559/PisrawOt9Hr9Cy+80NnZGcoe0dmKOEertb+/Py8vLzc3NwYByc7ONhgM4+Pj1EYDrWgViuj6YH5+/re//W1NTU0H9d57773ExMTt27dHsr9yQZyjpb+/f926dR988EHMAvLxxx9v2rTJbrfLvesAwUWUD4xGY21tbadyZGRkHD16NFqxixnEOVry8/M//PDD4Dtw8WLn4cMd69dffPzxi3/7txfvuOMiIRcJufiDH1z82c8u/fu/dxQXd4YyTmdnZ2fnxx9/vGfPHrl3HSC4iPKBXq/vUpSOjo5Vq1ZFK3YxgzhHy9atW4Ns+p/+1KHXX7z33ouPPNKh13fs39/17rudFy6wjZ3vv995+HDHpk2XHnvs0pIll375y87Dh7suXQoaEIvFIveuAwQXUT7YsGHDZaXRarXRil3MIM7RsmnTpoU2uKutreM///PSkiUdzzzT9c47wffwgw86Nm++dN99HatWdVVUBO6L6wNQhIjywYsvvtitNAkJCVEKXewgztGyUCSvnD176ec/v/SP/3jl5MlF7eaVixe7Cgou3ntvZ1pa94ULC3VDPgBFiCgfZGdnf6o0dJ6nAkOco0U0kleqqi7dd19Xdvanly+Ht7Pdf/pTxy9+0fHQQ93nzol2QD4ARYg0H1xVGjrPU4EhztHiH8nu6uqL9957Zd++yHe5S6e7dN99n/7xj/5NyAegCBHlg82bN19TGjrPU4EhztHiE8mrZ89e+uu/vnLgQLT2uisz8+K99149fdqnHvkAFCGifJCTk9MbUM9rScQjznC6J3D/BcfpeS0pznC6J9DiofTp7e2l8zwVmDDOFIZUFJ1x9nrGXr3a8YtfXNmwIYy9C+DKhg0dP/1pz+XLwkrkA1CEiOYn5+Tk9AXUezSZJB8N3CcUvY3GuDhjY29vhH36+vri4uLC3l+5WoVxpjCkouiMszCSV154oeOnP+29ciWMvQvk2rXOuLju7GxhXUZGBoXRQCtafUR0fbBly5b+gPqOJpPko8KaRqNKZWz0KfcdTeZe7yYf7e/v72s0qpKTk901fX2NRhUhhBCVsbGvTzgUCdbHH52vWwMTxpnCkCooznwke5uaLi1Z0nv69GL3i3f69Ol//dd/PXXqlH+T/+C4PgBFiDQfDATUfyzF896GqqCpv7+/qUDFFviS+/+BgYFjKSTlWH9/U4GKpBzr7+/v5yqEfbiRPeMs2EcUneepwIRxpjCkCoozH8muf/7ny889F8Z+sT755JMHHniAEPIv//Ivoh0uP/dc1+OP8w+RD0ARIsoHW7duHQposDyFpJT7VJanqEzNg4PNJlVKOddHQGVqHmw2qVSm5sHBQb7k/t9r8GaTSrCQaB9/dJ6nAhPGmcKQKijObCQHWlouLVky0NISxn4NDQ11d3f/7Gc/I4QsWbKkoaFBtM9AS8vFO+7ob2xkHyIfgCJElA+2bds2HNBQeSpJLRetLE8lqeVDon2GzphUKtOZoaEhvuT+32sQklo+NDQ0VJ5KxPuIovM8FZgwzhSGVEFxZiN5bdeuK7/6VRg7xXriiSfYnHn48OEA3a786ldX8/PZMvIBKEKk+cAa0HBFKkmt8K0crkhVp6aqUyuGh61W63CLWU3U5pbh4eEWs5qkVgwPt5jVbAVfcv/vP/JwRSoh4n1E0XmeCkwYZwpDqqA4s5HseuSRvv/6rzB2ymq16nQ6NhkUFBQE7tn32mudP/kJW0Y+AEWIKB/k5uaOBGStSBO+cZFWYWXrK9IISasQ6ZZWMTIyYj1bqFYXnrVarZ5SRRohRF141sqNYOWXSUtLIyStQqSPKDrPU4EJ40xhSBUU59zc3OGOjkt33jnc3h5g499///1/+7d/e//9933qi4qK2AilpqYODg4GjoBwRcgHoAgR5YO8vLzrSkPneSowxDla8vLyht56q3PFisAb/9xzzxFC7rzzTpPJNDw8zFYeP358yZIlhBCtVstXBtb5D/8wWF19/fp15ANQhEjzwQ2lofM8FRjiHC15eXkDr756ZfXqwBvf3Nz86KOPspcCP/7xjx955JG77777L//yL9mHV69eDTEIV1avHnjllRs3biAfgCJElA/y8/M/Uxo6z1OBIc7Rkp+fP/DKK1efeSaUXTCbzXfffTchhP2XEPIXf/EXb7/9duhBuPrMM/1lZZ999hnyAShCRPOT8/PzP1caOufNIs4xi+TgwYNXn3kmxL04dOjQX/3VX/Gf1jzwwAMNDQ2hB+HqM88M7Nv3+eefY34yWhXRGtH1wfbt28eUhs7XrYEhztGyffv24UOHuh9/PMS96Ojo+MEPfnDHHXew+eCee+7p6OgIPQjdjz8+9Ic/jI2N4foAFCGifLBjxw6b0tB5ngoMcY6WHTt2jJ461fWjH4W+I//7v//78MMP33nnnT/60Y/efvvtRQWh68c/HjlxwmazIR+AIkSaD8YDstmq01e+dN5ms51/aeXKl87bbIH7BxqHpFeHu7gQneepwIRxliiktup09iVwenVENZTHeceOHWM9PZfuvPOL7u7w4hY64YqQD0ARIsoHO3funAhovNWi0Vhax8cDdwsyyHiNjhBCdDWRjcOi8zwVmDDOUoR0fLxGRzSW1vHxVouG6GrGx8OroT/ObCSv/PSnI2+8EUkAQzH65puXH3qILSMfgCJElA927drlCKhYQwghRFN84YJFw/2r02nYurpirtDmcDjsddy0T6KrE45gt7cVa3R19jod0dXZ7YFXFwo6z1OBCeMsRUjtbcUaTXGb3W7nS2HV0B9nNpJDhYXXfvObyJ9LgV37zW8GjUa2jHwAihBpPnAG5Ggv1miK2x0OttDWVqwhmuJ2h6NdUGDrNcXtDofT6azTE32dw3ccB1vtWx8GOs9TgQnjLEVI2SJbz9WGVUN/nNlIjl+8eGnJkvGLFyN/Oi1k/OLFS3feaWttZR8iH4AiRJQPdu/ePRmQs71EoylpdzrZQlt7sfChp75OL7wHg6ak3Xcc5wk90Z9wOgOvLhR0nqcCE8ZZipCyRbaeqw2rhv4485G89utf961bF/nTaSF969ZdTUjgHyIfgCJEmg+mAppsL4mPL2mfnGQLbd4PPfUn9ERfH2icyXo90ddPTgZeXSjoPE8FJoyzFCH1LMuXwqqhP858JCcuXbq0ZMlEW1vkzyh/E21tPoMjH4AiRJQPDAbDTEDTHWXx8WUd09Ns4dKlUuFDr3rCPyYZDdO+40w3ZJCMhmnf+jDQeZ4KTBhnKUI6Pd2QwXbm+k6HV0N/nIWRHNq6tVulmnY6I39SCU2Nj1/5yU+Gd+4UViIfgCJEND/ZaDS6ApqZacgkhMSXdbBnq46y+PiyzpmZmU6/QkMm99ZGZsMC42Q2zMwEXl0o6Jw3G3qcJQop3zmzIaIayuPsFcnJyU81muH8/MifVELD+fmfajTTExPCSsxPRqsiWiO6PjAajbNKQ+fr1sAQ52jxieRkb2/n3/zN58ePR2uvRwoLLz/44PTIiE89rg9AESLKBwUFBV8qDZ3nqcAQ52jxj6S9paXj//2/L44di3yXrdu3X37wQccnn/g3IR+AIkSUD0wm09dKQ+d5KjDEOVpEI+k8d67r/vtHTaavXK7wdnZmYKD3qac+ffTR6e5u0Q7IB6AIkeaDOaWh8zwVGOIcLQtFcnZk5Gp8/KePPjp18eKidvOrqanPXnml6/77Rw2Gr2dnF+qGfACKEFE+MJvNN5WGzvNUYIhztASI5NfT06M7d3YsXTr4u9/NXL4cdAe/+vzz63v2XH7wwd4nnpj68MPAnZEPQBEiygdbt279Rmm0Wm20YhcziHO0mM3mwJv9ZX//SF5e5w9/eFWtHt25c6KmZvbatZtffcW2fnX9uvO9927s3dv7xBMdS5f2PvGE8913+dYAkA9AESKdjzY4ODivHEeOHKmsrIxW7GIGcY6WkpKSULb/27m5yT/+cTQ/v+eXv+z84Q8vEsL+XH7ggZ5f/nIkO3vijTdu2u2hB8Risci96wDBRZQPRkdHN2zY8GeF6O3tXbVqVbQCF0uIc7S88sor09PTMQ7IzMwM8gEoQkT5gGEYk8m0efPm2dnZ7+h2/PjxVatW2Wy2qEQt9hDnqJidnTWbzU6nM2YBcblce/bssdvtcu86QHARzU9mW2trazUajVarTfAWFxeXsDD/1sm772YI8fkZW7r03LJlEY6s1Wr5ty+omg24qFbEOSqts7Oz+/fvLysr2+MnIyPDp2b2nnv8YzX1wx9efeSRoMvu2bPHYrFYLBa73U5tNNCKVqFIrw+iqbTU/3ePKS1l6uvl3rJbC+IcOsQKbic05QOGYZYv9/rFW7OGycpi5ufl3qxbDuIcOsQKbhuU5QOfl2N4ISYRxDl0R48yd9zhiZXFwjQ1yb1NAJKgLB8wgpdjeCEmKcQ5dA89xMVq5UqmoACxglsVffmAf+mKF62SQpxDd+AAF6uXX0as4BZGXz5g3C9d8aJVaohz6P7u7xhCmOxsxApuYVTmA/alK16ISQ1xDt3hwwwhzP/8j9zbASAhKvMBwzCE4IVYLCDOoUOs4FZHcT6AGECcQ4dYwa0uCvOTpWgN/LtH5zYrsRVxDr0VsULrLd9K60sevBaLDcQ5dIgV3Opoeorff7/IvQFWrGASE+XeslsL4hwe5AM64fkcPTQ9xXGvmNhAnMODfEAnnwnkeD5HgLKnOO4VExuIcxiQD6j18MN4PkcFZU9x3FcnNhDnMCAfUKuyEs/nqKDvKY776sQG4rxYyAdhGxtjrFbu5/x55uxZ7qemhjl+nPspK2P27OF+Nm1iMjK4n7VrmTVruJ+HHmJWrOB+7ruPewKzfvITPJ8jR99THPfViQ3EOTR7niN7/8PvZ+9eubcrqqQ4Xy9d6nnB/sADnvpVqzz9U1M94xgMnvH/+789633vPc/29PR4ttPnT87V1uL5HDn68gHDMMuXMwkJSPKSQ5xDsPc/CFPl+xPrfKDE8/XcXExDxDDMww/j+RwhKvNBaSmzdi2SvOQQ5xAEygezs57Tn9XKfPSR+Jn6+HHGYhE/WScmek6+Wi3z4x/fyudrqVVW4vkcoZDmJ8/Pz1+4cCEnJ2f9+vUbYuLagw9uysqKwYqef/55vV4/NDQk3N/A0ZCuFXGmsFU0H3Cn6Xvu4U/Tcw88wGi14mfqjIyR3/1O/GRdX8+cPdv1hz8wZ88yH33EDAz4n68piYbNZjt48GBGRkYMni1hi9nzOQx6vT4pKamoqGjOOxNTcnxZwa8PvvzyS4vFkpKS8s4771y6Fb3zzjvPPvvsiy++GDQUkkKc6UTF+0WympqaKi8v37hx46uvvtra2toBESgvL09MTDxy5IjcR1VckHwwPz9fXFycnZ0tdxglt2HDBhlPVYgzpe6/Xzwf/Pzncm9ZjNhsttzc3P3793dC9Lz88suJVE6fDpIPLly4kJqaKnf0YuSf/umfRkZGYhN3xFmWOC9aaal4PkhNlXvLYmFqaio3N/fkyZNdEG0nT55MSkqS+wj7CpIPtm3b9u6778oduhiR8QghztTae++9ewnZSwhDyF5C9q5YsffRR/cWFcm9XbFQUVFx4MCByyANi8Vy6NAhuQ+ylyD5YNOmTXIHLaa0Wm1s4o44yxLncNyuc7knJiY2btzYDVJ68skn52j6ohfygZeEhISYhB1xlifOYbot53IfOnToyJEjn4KUjh07VkTTtWaQfPDiiy9euZ3IdZ5CnKl2W87lzsrKunLlylWQGFXXysHzgdxXVDElYz6Qe9djSmH5gLkd53JnZ2dfA+kpKR9kZ2fLfUUVU3KdpxBn2h04wPzud8y778q9HbGTk5PTG5qe04Y44hFnOB3igr7j9LyWFGc43dPTc9oQF2c43dMT3jjKQtXvQpD5ydnZ2XJfTsVUXFxcgGhIN1cQcY5inOfn541G4/PPP58V1amq0Z37qtfrX3jhhc7Ozsj3V6LWnJycvtD0Nhrj4oyNvb0h9pd6HGWR65wTzvzk2+08JeP1gdy7HlPSxXl+fv63v/1tTU2N3BPvgnvvvfcSExO3b98uUSgitGXLlv7Q9DUaVSpjY1+ff00fX2o0qpKTk9kriOSjnm7cRUXy673uByrj+4KFCFfXyPX3HqSv72gyST4qWLXi0HV9ELh58+bNcr+9FlNyHRvEOVqMRmNtba3cU+4WISMj4+jRoxJFIxJbtmwZCE1/U4GKf7dIVdDU39/fVKBiC3ypqUBFUo719/f3H0vxFFQFTf0DAwNcI79UU4FKVdDYaFR59/QfJMQtpJnC8kHP7UTGfCD3rseUdHHW6/Vyz7dbnI6OjlWrVkkUjUhs3bp1KDSDzSaVytQ8OOhfM8iXFq4RWarZpFKZmt5IISnlbFN5CkkpFxkkxC2kmZLyQeifKd0a5Do2iHO0bNiwQe7JFYtG1TdMeNu2bRsOzdAZk0plOjM05F8zNFSeSlSmM0OCGncpwFJnTCqVqbk8haSWs03lqSS1XGSQELeQZgrLB3J/3BJTMuYDuXc9pqSLsxK/uUvVGYG3bds2a2iGW8xqtblleNirhqRWDA8Pt5jVRG1uGeb7CEoVqURtbhm2Wq1s8cwZE9fSYlazD9lB3D39BwlxC2lG1dEPkg9C/0zp1iDXsUGco0WJ39yl6ozAy83NHQmN9WyhWl141moVVlakEUIIUaelsW3uPnyJW5D72CGtwmq1WivSCCHqwpYWM78Q3yxckWC4ijSSVuG9amW566679u7dO0/HvJbg+UDuj1tiSsZ8IPeux5Sk+UDuL08tGp35IC8v7zpIj014y5cvpyErIB94QT6IDenirMRvalGbD26A9AQz+eTPCkHywdatWwcXb6BZ8P0zQlQFzWEMMjg4ODDwRoqqoHlgYKC5QKUqaB4YCG+c0Mn1m4k4R4sSP5mnMx/k5+d/BtIjfmTMCkHmJ4f+nTMh/2+ShSda44ROrrmCiHO0IqnET+apmqHKy8/P/xyk558P1qxZ8/TTT69duzb2Rz/438MJ4xtUAb9/Jvi2WWpqKhsA97fKhs6Y3C94U98YbOYeqEzNzZ6FuNfCpjNcf+9Bhoa4b6aFsdnD8n33C3GOFiV+Mk/n9cH27dvHQHo+maC0tDQrK6u+vl6e64PAzaF/50xouMWs5ndR8AWylmFBif9G2nBFqve3yqxWK9fILxXg+2fegyj0u1+Ic7Qo8ZMYOvPBjh07bCA9SjIBK0g+CP07Z0L+3z8T+aLYwjUiS50tVKsLWypSSVoF28R9y0zsS2yRkOs3E3GOlvDeeZMXtflgnFbnX1q58qXzbNlmq04n6dU2G/ewOp09w6ZXL1gjtNjFbbbq9JUvnRf057fE3VF8RQtZunQpDZmAFft8UJFGbsfzFOIsJF2cw3vnTV505oOdO3dOUGm81aLR1XDl8RodIYToasbH3Q81ltbx8VaLhuhqxsf9a7yGCmvx8RqdxtI6MTHRatFodDqLTkc0lvPV6URX4x7Ed0UBLFu2jIZMwAqeD0YXb+RcoVpdeG5kxKuGpL05MjJyrlBN1IXnRvg+gtKbaURdeG5kdHSULZ496245V6hmH7KDuHv6DxLG1grJmA8Q56gI7503edGZD3bt2uUIWVuxhnttrKsL2kdT3OZwOOxtxRqdTue9lL1OJxzHbvcMzC7lcDjqdJriNru7VVdnr9MRXZ3dzo2pKW6z2+18ya+G356wF3cvaOd2ynuX7YIBQ0HV0Q+SD8KbkzL6QZFaXfTB6KiwslIwX7Hog1G+D1/iFuSOflrl6OjoaGUaIURddO5cIb8Q3yxckWC4yjSSVum96tDJNVcQcV6sZcuWiY6w0JWW9WzhNyRtXGwiq/Vs4Tfsn8MkhFEXfma1LlQZYCifSmtFGrcsUU8Fu5yi6ozA27VrlzM0jvZijaa43eFwOOr0RF/H/i+gr3M42os1bJOjTk80xe0+Nfo6h4Mfx+l0clV1eqKvczqdnj7ugmftghq+v/8IfI3vxoe1eHuxhtspfR271Xw9u78hhs7pdFJ19IPnA7mna8QU+/SN/fd/EefFWmgE0cw6Olr5JSEMSbOLJbDRyjQmrTKUSpY9TWQoYeXoB0XfEPU0m3or0xZaL4+qMwJv9+7dkyFztpfwr+NL2p0iHU7oif4EWz6hJ/oTTmd7iUZT0u50ekonvLKIpqTdM6x7Wb6vZ2QnN574WvxqfDcsrMXZrVgoGqIrWghVRz9IPrjd5qQIn46xzAqI82LjvNAI/pl1rEjNEPLNunXfkHX269f9k5N9Hfmm6MNQKm/cuHG9ch2jVvsMJVrJNV2v/Iqopz8UWS+PqjMCb/fu3VOhmazXE6Kvn5ycnKzXk/iS9snJeu/rg/rJyXo90dez/ev1RF8/OdleEh/PnlPdJUEfr/HbS+L5cdx9Pa2T3HhcT58x/Wp8Bw9rcfbBQgEJ3OqDqqMfPB/IPV0jpoif2GQFxHmxcRYdobS0NDc31yf32CorbTdu3PhozzdknePGDZ/WGzc+mlGrZz66EbTSXb/O4T2UaKVn7XvUjHqPza9eiKozAs9gMMyEZrohg2Q0cAUSX9YxLdKnoyyeZDRMT09PN2SQ+LKO6emOsvj4so7paU+poyyebXL3Zv9jR3Av1pBBMhqmPasQ1ngN7r867wUjWZxdRjQIoq0BUHX0g8xPxnkqNnMFEWc2zvw79iH8iIyg1+v//u//XnSNn32891vyvPOzz3zrP/ufr8nKb1eyg650ffzZQpWff/75+N6V3+792Gco0Ur3Gr0WXwid85ONRqMrNDMzDZnsMcjMzCQks2FGtFtnWTzXq2HG5XLNdJbFx5d1zszMuEsul4sfiWQ2sEvxFSS+rHNmxuVyNWRynQVrz2yY4Wo829IgXuPbf5GLu1yumZnOsnjPIjx+U+PLOkMMncvlouroB7k+2L59+xe3E5/zS8y+F4w4LzbOoiO8++67eXl5orNAv/i/339Lnp/64gux+pWz//fF2NjYF19UfU2en/riC/HKL6q+Xvn7Ca6VG0q00mv8qucZsXohql4h8gwGwyyVXF374jPfimSEtzIz33K5wt+AtzLj93VFsgFCVB394Pkg7HnYShT7TIA4hxfnhUZYaFbt2Ce//5akT42NBZgpOjZWNUdWzn4yJlo5lU7mqsZ8hhKtDDqmD6rOCLz8/PwvadW177HH9nWFt+zsbNe+fW+HverZ2bczH9vXNTsb9gg+qPrreEHyQXhz1sfGqtJX/v6TsbGxT36/cuXvP1ngl9DdyHUOY0VRJ9dcwejeG2BsrCqdpFctENIwAh71IxV5nFesWCE6wkKzam3nX/qWpE/ZAk0ctdmq58jKL8/b/CtnP6ma83vH6usqkcq5apHFfcb0QWc+WL9+vcvl+hqkNDc3p7B8EMKMa5HfvZWCKd0L9kmv5sqCOd/ykmuuYBTvDWDj5td7puD7dgjh6Pj2j/aRijzOiYmJoiMsNKt2vNUyT3TTfrNGx2t0jLt+vNUyr7E4x8dFKwMPJawMvLg/OvPB66+/furUqTmQUlVVVVFRkdyH2iNIPghvzrqF/c6wxnL+/EsajaV1nJ3tzeJmctfoNJZW7pdknJ2BHvIMb+nI9ZsZXpzZqfRs2T1Jno3kgjPmPUeCn4TvfsR1iMmRki7OC82qtbcVzxOdyz1r1KUj8+75rlPFGvere08H0UrRoUQrAyxO+QxVoezs7JsgpdWrV8/Nzcl9nD0kyQfjrRZPGtBYztuq2XuATExMuO8C4nvCYk8zEZ5lIqesfCC4ywpX4uoF4eVu0EIE53jh0fG5SYu7MCHxkZI0H4Q+NZQS1OaD2traqqqqb0AaZrP58OHDch9kL8HzgX3xJi5YNBrLhYkJttDayj3078DXsBVhrCu6ZMwHYWztxMQFi4boaid84jkxUasjulpBeL2W4o9OrY7oatlKbgG/4yLRkZIuzouaVUsJavMBwzDp6end3d3zEG0tLS3PPvus3IfXV5B8sKh7WgmvnbmbQLUVazTFFy5Y2If+HfgatiKMdUWXXL+Z4cXZwd7/S1fnEz3hHbU8Nwhjrw/qBLfoqtPxt+LiFvA7LhIdKUnzQYjzQulBcz5gGCYlJeXNN9/8M0TJd999Zzabk5KS5D6wIoLngzCufz33t2pnzybcHayc7B2juBqvm1KJ3moq9mTMB+FtMHt3MI1mwTt8iSwiPDo+txhzxOhISRfn0GfV0oPyfMAwTGVl5VNPPVVbW3vz5s3vIFzff/99bW3t6tWraXubiBdkfnJ4V9/cjak0JW3txdwtqzy3u+JuHXVC77nvldPZXqLh6uUl11zBSN7laC/R8LfcYglv0eWPPzrtTuHtwtzHIiZHSro4hz6rlh5UzVAN0Hrw4EGtVpuQkJCQkBAXF5ewMLT6t2q1Wq1WazAYfD5Apuf4MkGvD6R7N5Y9sXDlE/oANwuMpQSZXqmFHWf+3pDRjYPXKiQ4UtLF2Wg0RmviaMzI9awD8BE8H0j3tqnnrobeNyyUkYz5IIyt5e4iKXZLyOiK+pGSLs4FBQXRmjgaM8gHQIkg+cBgMEzfTuT6zUSco8VkMsk953TRkA+AEsHzgcchsRUAABEhSURBVNwftsWUjPlA7l2PKUnzgdxzThcN+QAoESQfKPHTuUjI9ZuJOEeL2WyWe87poiEfACWC5wO5P2yLKRnzgdy7HlPSxXnr1q1yTztdNKruaAa3syD5QImfzkVCrnyAOEfL7t27BwcH5Z58ughHjhyprKyUKBoAi4J84AX5IDaki/Po6OiGDRvknoIaqt7e3lWrVkkUCoDFCp4PvrqdyJgP5N71mJI0ziaTafPmzbOzs3JPRw3i+PHjq1atstls0oUCYFGCzE9W4rf3IiHXTFHEObpxrq2t1Wg0/GTamM1BDb1Vq9XybxNRNUMVrbdza5DrAyV+ey8Scl0fIM4AILsg+UCJ396LhFznKcQZAGQXPB/I/WW8mJIxH8i96zGFfABAoeDvF8l96ogpGd8vknvXYwr5AIBCQfJBbm7ut7cTuWYGIc4AILsg+SAnJ6e3t1fuKTsxcv78ebn+aBHiDACyC5IPRkdHMzMz5Z61EyMqlWpkZCQ2cUecZYkzAAQQJB8wDLNz5868vDy55+5I7plnnnnhhRdiEHHEWd44A8BCgucDhmG2bdv261//uru7+/tbUVtbm0qlouEkhTgDgIyCzE/mW0dGRpKSkmSczylRq1arTUpK4t++kH2uIOKMVrSiVa7WkK4PAADglod8AAAADIN8AAAALOQDAABgGOQDAABgIR8AAADDIB8AAAAL+QAAABgG+QAAAFihzk9GK1rRila03tqtuD4AAACGQT4AAAAW8gEAADAM8gEAALCQDwAAgGGQDwAAgIV8AAAADIN8AAAALOQDAABgGMxPRita0YpWtLJwfQAAAAyDfAAAynb//Qwhvj8rVjCJiXJvmfIgHwCAkpWWiuSD0lKmvl7uLVMe5AMAULjly72SwZo1TFYWMz8v92YpD/IBACiczyUCLg7ChXwAAMrHXyLg4iACyAcAoHz8JQIuDiKAfAAAt4Tly5mEBFwcRAL5AABuCaWlzNq1uDiIBOYnoxWtaA3earPZDh48mJGRsYFi1x58cFNWltxbIU6v1yclJRUVFc3NzVF4fFm4PgCAQKampsrLyzdu3Pjqq6+2trZ2QATKy8sTExOPHDki91EVh3wAAAuy2Wy5ubn79+/vhOh5+eWXE6mcPo18AADipqamcnNzT5482QXRdvLkyaSkJLmPsC/kAwAQV1FRceDAgcsgDYvFcujQIbkPshfkAwAQMTExsXHjxm6Q0pNPPunz8bK8kA8AQMShQ4eOHDnyKUjp2LFjRUVFch9qD+QDABCRlZV15cqVqyAxrVYr96H2QD4AABHZ2dnXQHrIBwBAu5ycnN7Y6jltiCMecYbTYY7T81pSnOF0T0/PaUNcnOF0T09UNzPKEhIS5D7UHpifjFa0olVETk5OX2z1Nhrj4oyNvb2UjBMbcXFx9Bx9XB8AgIgtW7b0x1Zfo1GlMjb29fnX9PGlRqMqOTmZvYJIPurpxl1UJL/e636gMr4vWIhwdY1cf+9B+vqOJpPko4JVxwxd1wdybwAA0GjLli0DsdXfVKDi3y1SFTT19/c3FajYAl9qKlCRlGP9/f39x1I8BVVBU//AwADXyC/VVKBSFTQ2GlXePf0HifGeCiEfAADttm7dOhRbg80mlcrUPDjoXzPIlxauEVmq2aRSmZreSCEp5WxTeQpJKRcZJMZ7KoR8AAC027Zt23BsDZ0xqVSmM0ND/jVDQ+WpRGU6MySocZcCLHXGpFKZmstTSGo521SeSlLLRQaJ8Z4KIR8AAO22bdtmja3hFrNabW4ZHvaqIakVw8PDLWY1UZtbhvk+glJFKlGbW4atVitbPHPGxLW0mNXsQ3YQd0//QWK8p0LIBwBAu9zc3JHYsp4tVKsLz1qtwsqKNEIIIeq0NLbN3YcvcQtyHzukVVitVmtFGiFEXdjSYuYX4puFKxIMV5FG0iq8Vx0bd9111969e+fp+JtuyAcAICIvL+86SI9NVMuXL6chKyAfAICIvLy8GyA9wQw8+bMC8gEAiMjPz/8MpEf8yJgVMD8ZrWhFq4j8/PzPQXr++WDNmjVPP/302rVrY3/0cX0AACK2b98+BtLzyQSlpaVZWVn19fXyXB/EfpUAQL8dO3bYQHqUZAIW8gEAiNixY8c4rWy26nSSXm2zcQ+r01e+dJ4tV6dzr7XTq23ybeAiLF26lIZMwEI+AAARO3funKDS+HiNjhBCdDXj4xMTE60WjUans+h0RGM5X51OdDXuPlwHyi1btoyGTMBCPgAAEbt27XLEXFuxhnt5r6sT7WC3txVrdHX2Oh3R1dntnqW8+9u9O9AM85MBgHa7du1yxpajvVijKW53OByOOj3R17H/C+jrHFxPdwduKX0duyjb2l6sEXamHPIBANBu9+7dkzHnbC9xXyBoStqdC3ZzntAT/Qnngh0mJyfZHhJsY5QhHwAA7Xbv3j0VW5P1ekL09ZOTk5P1ehJf0j45We99fVA/yfWcrNcTff3kZIDR2kvi40vaY7LhEUE+AADaGQyGmdiabsggGQ1cgcSXdUwv2JPtOu3bgR9hZmaG7SHd1kYLXfmAzrmRaEUrWuVtNRqNrtiamWnIZC8EMjMzCclsmAnYM7NhRqSDewgSX9Yp5cZGDf5+MgDQzmAwzIL06Lo+kHsDAIBG+fn5X4L0tFqt3IfaA/kAAESsX7/e5XJ9DVKam5tDPgAA2r3++uunTp2aAylVVVUVFRXJfag9kA8AQFx2dvZNkNLq1avn5ubkPs4eyAcAIK62traqquobkIbZbD58+LDcB9kL8gEALCg9Pb27u3seoq2lpeXZZ5+V+/D6Qj4AgEBSUlLefPPNP0OUfPfdd2azOSkpSe4DKwL5AACCqKysfOqpp2pra2/evPkdhOv777+vra1dvXo1bW8T8TA/Ga1oRWtIrQcPHtRqtQkJCQkJCXFxcQkLQ6t/q1ar1Wq1BoPB5wNkeo4vg+sDAABgIR8AAADDIB8AAAAL+QAAABgG+QAAAFjIBwAAwDDIBwAAwEI+AAAAhkE+AAAAFuYnoxWtaEUrWhkG1wcAAMBCPgAAJbv/foYQ358VK5jERLm3THmQDwBAyUpLRfJBaSlTXy/3likP8gEAKNzy5V7JYM0aJiuLmZ+Xe7OUB/kAABTO5xIBFwfhQj4AAOXjLxFwcRAB5AMAUD7+EgEXBxFAPgCAW8Ly5UxCAi4OIoF8AAC3hNJSZu1aXBxEAvOT0YpWtAZvtdlsBw8ezMjI2ECxaw8+uCkrS+6tEKfX65OSkoqKivD3kwFAqaampsrLyzdu3Pjqq6+2trZ2QATKy8sTExOPHDki91EVh3wAAAuy2Wy5ubn79+/vhOh5+eWXE6mcPo18AADipqamcnNzT5482QXRdvLkyaSkJLmPsC/kAwAQV1FRceDAgcsgDYvFcujQIbkPshfkAwAQMTExsXHjxm6Q0pNPPunz8bK8kA8AQMShQ4eOHDnyKUjp2LFjRUVFch9qD+QDABCRlZV15cqVqyAxrVYr96H2QD4AABHZ2dnXQHrIBwBAu5ycnN7Q9Jw2xBGPOMPpEBf0HafntaQ4w+menp7Thrg4w+menvDGUZaEhAS5D7UH5iejFa1oFZGTk9MXmt5GY1ycsbG3N8T+Uo+jLHFxcfQcfVwfAICILVu29Iemr9GoUhkb+/r8a/r4UqNRlZyczF5BJB/1dOMuKpJf73U/UBnfFyxEuLpGrr/3IH19R5NJ8lHBqhWHrusDuTcAAGi0ZcuWgdD0NxWo+HeLVAVN/f39TQUqtsCXmgpUJOVYf39//7EUT0FV0NQ/MDDANfJLNRWoVAWNjUaVd0//QULcQpohHwAA7bZu3ToUmsFmk0plah4c9K8Z5EsL14gs1WxSqUxNb6SQlHK2qTyFpJSLDBLiFtIM+QAAaLdt27bh0AydMalUpjNDQ/41Q0PlqURlOjMkqHGXAix1xqRSmZrLU0hqOdtUnkpSy0UGCXELaYZ8AAC027ZtmzU0wy1mtdrcMjzsVUNSK4aHh1vMaqI2twzzfQSlilSiNrcMW61WtnjmjIlraTGr2YfsIO6e/oOEuIU0Qz4AANrl5uaOhMZ6tlCtLjxrtQorK9IIIYSo09LYNncfvsQtyH3skFZhtVqtFWmEEHVhS4uZX4hvFq5IMFxFGkmr8F61stx111179+6dp+NvuiEfAICIvLy86yA9NuEtX76chqyAfAAAIvLy8m6A9AQz+eTPCsgHACAiPz//M5Ae8SNjVsD8ZLSiFa0i8vPzPwfp+eeDNWvWPP3002vXro390cf1AQCI2L59+xhIzycTlJaWZmVl1dfXy3N9EPtVAgD9duzYYQPpUZIJWMgHACBix44d47Q6/9LKlS+dZ8s2W3U6Sa+22biH1ensGTa9esEaocUubrNVp6986bygP78l7o7iK1rI0qVLacgELOQDABCxc+fOCSqNt1o0uhquPF6jI4QQXc34uPuhxtI6Pt5q0RBdzfi4f43XUGEtPl6j01haJyYmWi0ajU5n0emIxnK+Op3oatyD+K4ogGXLltGQCVjIBwAgYteuXY6QtRVruNfGurqgfTTFbQ6Hw95WrNHpdN5L2et0wnHsds/A7FIOh6NOpylus7tbdXX2Oh3R1dnt3Jia4ja73c6X/Gr47Ql7cfeCdm6nvHfZLhgwFJifDAC027VrlzM0jvZijaa43eFwOOr0RF/H/i+gr3M42os1bJOjTk80xe0+Nfo6h4Mfx+l0clV1eqKvczqdnj7ugmftghq+v/8IfI3vxoe1eHuxhtspfR271Xw9u78hhs7pdCIfAADtdu/ePRkyZ3sJ/zq+pN0p0uGEnuhPsOUTeqI/4XS2l2g0Je1Op6d0wiuLaEraPcO6l+X7ekZ2cuOJr8WvxnfDwlqc3YqFoiG6ooUgHwAA7Xbv3j0Vmsl6PSH6+snJycl6PYkvaZ+crPe+PqifnKzXE309279eT/T1k5PtJfHx7DnVXRL08Rq/vSSeH8fd19M6yY3H9fQZ06/Gd/CwFmcfLBSQwK0+kA8AgHYGg2EmNNMNGSSjgSuQ+LKOaZE+HWXxJKNhenp6uiGDxJd1TE93lMXHl3VMT3tKHWXxbJO7N/sfO4J7sYYMktEw7VmFsMZrcP/VeS8YyeLsMqJBEG0NgK58QOfcSLSiFa3ythqNRldoZmYaMtkLgczMTEIyG2ZEu3WWxXO9GmZcLtdMZ1l8fFnnzMyMu+RyufiRSGYDuxRfQeLLOmdmXC5XQybXWbD2zIYZrsazLQ3iNb79F7m4y+Wameksi/cswuM3Nb6sM8TQuVwu/P1kAKCdwWCYpZKra1985luRjPBWZuZbLlf4G/BWZvy+rkg2QIiu6wO5NwAAaJSfn/8lrbr2PfbYvq7wlp2d7dq37+2wVz07+3bmY/u6ZmfDHsGHVquV+1B7IB8AgIj169e7XK6vQUpzc3PIBwBAu9dff/3UqVNzIKWqqqqioiK5D7UH8gEAiMvOzr4JUlq9evXc3Jzcx9kD+QAAxNXW1lZVVX0D0jCbzYcPH5b7IHtBPgCABaWnp3d3d89DtLW0tDz77LNyH15fyAcAEEhKSsqbb775Z4iS7777zmw2JyUlyX1gRSAfAEAQlZWVTz31VG1t7c2bN7+DcH3//fe1tbWrV6+m7W0iHuYnoxWtaA2p9eDBg1qtNiEhISEhIS4uLmFhaPVv1Wq1Wq3WYDD4fIBMz/FlcH0AAAAs5AMAAGAY5AMAAGAhHwAAAMMgHwAAAAv5AAAAGAb5AAAAWMgHAADAMMgHAADAwvxktKIVrWhFK8Pg+gAAAFjIBwAAwDDIBwAAwEI+AAAAhkE+AAAAFvIBAAAwDPIBAACw/j/LE5Vy7nR+hgAAAABJRU5ErkJgggA=" />

 

tic()
for i = [1:1:10000]
    a=ones(100,100)*3
    b=ones(100,100)*3
end
disp(toc())


tic() for i = [1:1:10000] a=1*3 b=1*3 end disp(toc())

 

 

> Message du 10/04/18 10:31
> De : "Eric GERNOT" <[hidden email]>
> A : "List dedicated to the development of Scilab" <[hidden email]>
> Copie à :
> Objet : Re: [Scilab-Dev] New xcos blocks executing scilab primitive functions
>
>

> Clément,

>  

>

>

Would it be different if we had to create a X_cos block executing a single Scilab expression (block output = RHS (block input, t, state derivative)) ?

 

I noted that the actual Scifunc Block is very powerful and educational thus to me it should not be changed.

 

Also I started suspecting that, although Scifunc blocks alone are slow compared to c or already provided blocks, they may not always be the bottleneck in the context of a specific calculation.

I have to compare a few things and look at how many times each block is called by each solver.

 

> Regards,  

Eric

>  

>  

>  

> Message du 09/04/18 15:27

> De : "Clément David" <[hidden email]>
> A : "[hidden email]" <[hidden email]>
> Copie à :
> Objet : Re: [Scilab-Dev] New xcos blocks executing scilab primitive functions
>
> Hello Eric,
>
> As described in some guides [1][2], the interpreter will call a gateway passing values using the C++
> / C object-oriented / C stack-oriented APIs depending how you declared it. On the gateway you are
> free to do whatever you want with the data.
>
> [1]: https://wiki.scilab.org/howto/Create%20a%20toolbox#Gateway
> [2]: https://wiki.scilab.org/Developers
>
> However for Xcos, the story is a bit different as the blocks will be called by a simulator (ODE /
> IDA solver) not an interpreter ; the API is different and called scicos_block4 ; using a C-block you
> have to describe the interface and write some code using the data passed as arguments.
>
> Note: Scilab2C is a toolbox which might (or might not) follow Scilab coding conventions.
>
> --
> Clément
>
>
> Le lundi 09 avril 2018 à 12:33 +0200, Eric GERNOT a écrit :
> > Hello Clement,
> >
> > Thank you for this very clear answer.
> > How does Scilab Gateways work? When we tap enter after entering the command line on the prompt,
> > let's say to call a primitive, does the gateway also need the API ?
> > Or is there a more direct way to do so ?
> >
> > Regarding my questions on the libraries.
> > Well, let's say I am a simple user of scilab, with no code development tools installed.
> > Editing a c-block, seeing the #include math.h line was a bit scary, because I thought "this will
> > require that I have put the math.h file at the good place on my computer".
> > So I insert nothing in the code, click "ok" and the compilation is succesful.
> > Now after running Scilab 2 c toolbox on my custom code, a number of subdirectories with multiple
> > files were created in my custom directory. I suppose if I want this scilab 2 c created code
> > running in the c-block, I have to put these files where the block can access them at compilation
> > time.
> > Same if I created the code on my own. That is why I asked where the c-block compiler looks to find
> > the files, or how do we configure this, as users.
> >
> > Best regards,
> > Eric
> >
> >
> >
> >
> > > > Message du 09/04/18 09:37
> > > > De : "Clément David" <[hidden email]>
> > > > A : "[hidden email]" <[hidden email]>
> > > > Copie à :
> > > > Objet : Re: [Scilab-Dev] New xcos blocks executing scilab primitive functions
> > > >
> > > > Hi Eric and welcome :)
> > > >
> > > > Nice to have some power users (and maybe futur developers) using big Xcos models, Xcos in
> > > 6.0.x have
> > > > some issues only visible on big diagrams and we currently do not spend too much time
> > > benchmarking
> > > > it.
> > > >
> > > > About the scifunc vs Superbloc vs C++ implementation speedup, the clear winner there would be
> > > C/C++
> > > > if (and only if) there is no event management (either discrete or zero-crossing) to perform.
> > > Zero
> > > > crossing detection is hard to implement even for small sub-systems and discrete events are
> > > only easy
> > > > for synchronous subsystem. Superblocs are straightforward to implement and manage very complex
> > > > events / continuous states intrication in a clean manner however they can be confusing to
> > > maintains
> > > > (for exemple if you want to preserve the same behavior across different blocks). Scifunc are
> > > in-
> > > > between to me in term of implementation however very poor in term of performance (and not
> > > optimized
> > > > at all).
> > > >
> > > > You could use the scicos_block4 API (the default one) in C or C++ ; if you take a look at our
> > > source
> > > > code there is only a few in C++ but they can be easily converted to. About the libraries, I
> > > did not
> > > > get it, do you want to link to different libraries ? The xcos_toolbox_skeleton and
> > > ilib_for_build()
> > > > flags are working well.
> > > >
> > > > To call Scilab script within the sciblk2 [1] and sciblk4 [2] blocks we are indeed using the
> > > Scilab
> > > > C++ API, the performance overhead is quiet clear as we are currently allocating Scilab
> > > types::Double
> > > > or a types::MList through createblklist() for each output on each simulation step. This does
> > > an
> > > > extra allocation (for the Scilab datatype) and a copy (for the data copy to scilab) whereas in
> > > C/C++
> > > > the data are passed by reference to the shared buffers. We clearly have to do better there ;
> > > maybe
> > > > by allocating only once (at Initialization time) or passing types:: views to the shared
> > > buffers.
> > > > There is a test case within xcos_toolbox_skeleton which switch the implementation of a NOOP
> > > block
> > > > (that compute nothing) between Scilab and C depending on a parameter in Scilab.
> > > >
> > > > [1]: http://cgit.scilab.org/scilab/tree/scilab/modules/scicos/src/cpp/sciblk2.cpp#n57
> > > > [2]: http://cgit.scilab.org/scilab/tree/scilab/modules/scicos/src/cpp/sciblk4.cpp#n217
> > > >
> > > > As a conclusion, yes you can call C++ functions from blocks and Scilab blocks issues comes
> > > from a
> > > > slow implementation of C->Scilab calls not from the Scilab code interpretation.
> > > >
> > > > NB: yes this a known problem and some users already reports that but no one is currently
> > > working on
> > > > that.
> > > >
> > > > Thanks,
> > > >
> > > > --
> > > > Clément
> > > >
> > > > Le vendredi 06 avril 2018 à 05:47 -0700, ericgernot a écrit :
> > > > > Hi,
> > > > >
> > > > > I am new to scilab, and I am not a developper, but I fear I may become one
> > > > > because of Scilab :-;
> > > > > I am on windows 7 /64, and installed some recent versions.
> > > > >
> > > > > I created a physic model (chemical process with compositions, streams, etc.)
> > > > > from a script and used xcos to solve it, only using Sci_func blocks calling
> > > > > my functions (so that it is easily portable to other scilab versions). It
> > > > > works as desired, so now I want to speed it up.
> > > > >
> > > > > After all the possible improvements from vectorization, I decided to convert
> > > > > 30% of my scifunc into superblocks, giving a 30% speedup boost to the model.
> > > > > I could have written these in c/c++ also, but I suspect it would have taken
> > > > > longer (for me)
> > > > >
> > > > > My remaining scifunc blocks are using some scilab gateways such as fsolve,
> > > > > diag, etc, thus the conversion is not as straighforward.
> > > > >
> > > > > I tried to convert it in c using the scilab 2 c toolbox, this is great for
> > > > > all operations exept scilab gateways.
> > > > >
> > > > > I had a look at how to create a new block, how the c-block work, and finally
> > > > > how existing blocks are coded in c++.
> > > > >
> > > > > If I understand well, the possibilities are
> > > > > 1. copy the c++ primitive function code in a c-block, it will not work
> > > > > because it is not c, and because I don't know which libraries should be
> > > > > included. By the way, where can I put them so that the compiler finds them ?
> > > > > 2. use scilab API from a xcos c-block and send jobs. Will it really skip the
> > > > > interpreter ?
> > > > > 3. create a new block as a user (from within scilab). But you can't use c++
> > > > > can you ? So I have to write or find c equivalent of scilab primitives, this
> > > > > is a pity !
> > > > > 4. create a new block source code, and compile a new version of scilab with
> > > > > the new block. I suppose that the same problem exists: converting to c
> > > > > scilab primitives ?
> > > > >
> > > > > So this raised a few questions:
> > > > > - In the block source code, why not call scilab built in functions in c/c++
> > > > > (not the gateway), only passing them the block arguments / parameters,
> > > > > instead of pasting the code there. That would ease the creation of new
> > > > > blocks isn't it ?
> > > > > - can users call these built in functions in their custom blocks (e.g.
> > > > > c-block) ? (I mean without invoking the parser etc., without linking already
> > > > > linked libraries, etc.)
> > > > >
> > > > > I suppose that many users ran through these problems.
> > > > > Thank you very mucn
> > > > > Regards,
> > > > > Eric
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Sent from: http://mailinglists.scilab.org/Scilab-developers-Mailing-Lists-Archives-f2574944.
> > > html
> > > > > _______________________________________________
> > > > > dev mailing list
> > > > > [hidden email]
> > > > > http://lists.scilab.org/mailman/listinfo/dev _______________________________________________
> > > dev mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/dev
> >
> > _______________________________________________
> > dev mailing list
> > [hidden email]
> > http://lists.scilab.org/mailman/listinfo/dev _______________________________________________ dev mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/dev


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


_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
ericgernot ericgernot
Reply | Threaded
Open this post in threaded view
|

Re: New xcos blocks executing scilab primitive functions

In reply to this post by ericgernot

Hi Clément,

 

I hope you may help me spare some tests !

 

Regarding Scifunc blocks, in sciblk4, createblklist() uses vartosci(..) to reshape the inptr, yet it does only copy the adresses in a new table of pointers, not the actual data, isn't it? Do you thing this address copying is the time consumming operation ?

 

I found 2 stranges things:

1) vartosci(..) creates a List with appends in a for loop, and the data is stored in a vector m_plData. That means each time the vector capacity is reached, it "reallocates it in order to grow in size when new elements are inserted, which implies allocating a new array and moving all elements to it".

Is a memory allocation strategy defined somewhere in Scilab for TList, List and Typed_list.

 

2) createblklist(...) creates a TList whose values are also stored in a vector container m_plData, which is also dynamically allocated and may be recreated each time capacity is reached, by the append method.

 

Thus, in sciblk4, could we call static types::InternalType* pIT = createblklist(...) and in.push_back(pIT) only when flag is on initialization, so that all Lists are created once and only updated at each iteration ? Would it help ? That would require to rewrite vartosci() and createblklist() with a iterator approach instead of append.

 

Regards,

Eric

 

 

 

> Message du 09/04/18 09:37
> De : "Clément David" <[hidden email]>
> A : "[hidden email]" <[hidden email]>
> Copie à :
> Objet : Re: [Scilab-Dev] New xcos blocks executing scilab primitive functions
>


> To call Scilab script within the sciblk2 [1] and sciblk4 [2] blocks we are indeed using the Scilab
> C++ API, the performance overhead is quiet clear as we are currently allocating Scilab types::Double
> or a types::MList through createblklist() for each output on each simulation step.


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

Re: New xcos blocks executing scilab primitive functions

Hello Eric, (answered inline)

> Regarding Scifunc blocks, in sciblk4, createblklist() uses vartosci(..) to reshape the inptr, yet
> it does only copy the adresses in a new table of pointers, not the actual data, isn't it? Do you
> thing this address copying is the time consumming operation ?

Yep exactly, allocating the ScilabList and ScilabDouble scalars for each inputs and on each time
step is a big overhead comparing to passing pointers around as in the C interface.
 
> I found 2 stranges things:
> 1) vartosci(..) creates a List with appends in a for loop, and the data is stored in a vector
> m_plData. That means each time the vector capacity is reached, it "reallocates it in order to grow
> in size when new elements are inserted, which implies allocating a new array and moving all
> elements to it".
> Is a memory allocation strategy defined somewhere in Scilab for TList, List and Typed_list.

That part should not be the issue as, after being cached, the TList will not be resized not
reallocated.

> 2) createblklist(...) creates a TList whose values are also stored in a vector container m_plData,
> which is also dynamically allocated and may be recreated each time capacity is reached, by the
> append method.
>  
> Thus, in sciblk4, could we call static types::InternalType* pIT = createblklist(...) and
> in.push_back(pIT) only when flag is on initialization, so that all Lists are created once and only
> updated at each iteration ? Would it help ? That would require to rewrite vartosci() and
> createblklist() with a iterator approach instead of append.

Yep this will slightly increase the performance ; for example, the TList returned by createblklist()
could be stored on the work opaque pointer at the "Initialization" and deleted at the "Ending" phase
(before and after calling the Scilab function).

And then before calling the function, cast the work pointer back to a TList, sync the incomes
(inptr, z and x variables) call the function, sync the outcomes.

Regards,

--
Clément


> > Message du 09/04/18 09:37
> > De : "Clément David" <[hidden email]>
> > A : "[hidden email]" <[hidden email]>
> > Copie à :
> > Objet : Re: [Scilab-Dev] New xcos blocks executing scilab primitive functions
> >
>
>
> > To call Scilab script within the sciblk2 [1] and sciblk4 [2] blocks we are indeed using the
> Scilab
> > C++ API, the performance overhead is quiet clear as we are currently allocating Scilab
> types::Double
> > or a types::MList through createblklist() for each output on each simulation step.
> _______________________________________________
> dev mailing list
> [hidden email]
> http://lists.scilab.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev