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
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.


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



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

Reply via email to