[Scilab-Dev] New xcos blocks executing scilab primitive functions

Mon Apr 9 12:33:57 CEST 2018

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" 
> A : "dev at lists.scilab.org" 
> 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
> > dev at lists.scilab.org
> > http://lists.scilab.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev at lists.scilab.org http://lists.scilab.org/mailman/listinfo/dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20180409/7381e010/attachment.htm>