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" <[email protected]> > > > A : "[email protected]" <[email protected]> > > > 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 > > > > [email protected] > > > > http://lists.scilab.org/mailman/listinfo/dev > > > > _______________________________________________ > > dev mailing list [email protected] > > http://lists.scilab.org/mailman/listinfo/dev > > _______________________________________________ > dev mailing list > [email protected] > http://lists.scilab.org/mailman/listinfo/dev _______________________________________________ dev mailing list [email protected] http://lists.scilab.org/mailman/listinfo/dev
