Clément,
Would it be different if we had to create a X_cos block executing a single
Scilab expression (block output = RHS (block input, t, state derivative)) ?
I noted that the actual Scifunc Block is very powerful and educational thus to
me it should not be changed.
Also I started suspecting that, although Scifunc blocks alone are slow compared
to c or already provided blocks, they may not always be the bottleneck in the
context of a specific calculation.
I have to compare a few things and look at how many times each block is called
by each solver.
Regards,
Eric
> Message du 09/04/18 15:27
> De : "Clément David"
> A : "dev@lists.scilab.org"
> Copie à :
> Objet : Re: [Scilab-Dev] New xcos blocks executing scilab primitive functions
>
> 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"
> > > > A : "dev@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@lists.scilab.org
> > > > > http://lists.scilab.org/mailman/listinfo/dev
> > > > > _______________________________________________
> > > 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
> > _______________________________________________ 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
