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 : "[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
