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@lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@lists.scilab.org http://lists.scilab.org/mailman/listinfo/dev
