From sgougeon at free.fr Thu Feb 1 00:23:24 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 1 Feb 2018 00:23:24 +0100 Subject: [Scilab-Dev] Disturbing changes on CodeReview In-Reply-To: References: Message-ID: <2dd3121b-aa88-bf33-f4e5-f47ec459d476@free.fr> Le 31/01/2018 ? 20:45, Samuel Gougeon a ?crit : > > * When we review files in diff mode, the edit icon switching the > diff mode into the edit one at the top of the diff page no longer > works: it yields an error page. > After some work, this proves to occur only for files whose names start with "%", which is a special character for URLs. So, it is likely a bug in CodeReview itself, not in the Scilab infrastructure (unless managing "%" in filenames is configurable in CodeReview). Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Thu Feb 1 14:59:54 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 1 Feb 2018 14:59:54 +0100 Subject: [Scilab-Dev] Disturbing changes on CodeReview In-Reply-To: References: Message-ID: <69d3ad05-f0cd-d526-700a-09d20edd946d@free.fr> Le 31/01/2018 ? 20:45, Samuel Gougeon a ?crit : > Hello devs, > > I noticed some changes on the CodeReview interface since this week: > > * The download menu of a commit no longer lists parametrized GIT > commands to fetchout, cherrypick and push the commit. It is now > limited to the Patch-File and Archive rows. This is true whatever > is the web browser (observed with FF, Chrome, Safari) > They are now restored! Thank you. Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Thu Feb 1 16:12:57 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 1 Feb 2018 16:12:57 +0100 Subject: [Scilab-Dev] Specific errors numbers: true removal becoming a unique flag, or ghosty ones? Message-ID: <3baf5d8e-e410-0f29-8d6d-34667790dc45@free.fr> Dear ESI-Scilab devs, Errors numbers are announced as removed in Scilab 6. Yet, some related features are still active, for instance: --> error(123) error: Wrong type for input argument #1: string expected. // OK --> error(123, "message") // Is this syntax intended to be kept? message --> [t, n] = lasterror() n = 123. t = message --> execstr("error(456, ""message"")", "errcatch") ans = 456. It looks a bit hard to removed the 2nd lasterror() output, because this would shift last ones (max 4 argouts), and so trigger back-compatibility issues for nothing. But for lasterror() as for execstr(), the question is, noticeably to be able to update the documentation in a relevant and reliable way: Are specific errors numbers planned to still be possible --then, what for? --, or will a unique 10000 error number be used as a filling output for lasterror() and as a simple output flag for execstr()? There is also the case of the 999 error number heavily used in the hard code. If 2 distinct error numbers are kept as "standard" flags, i guess that the distinct meaning of each of them shall be explained.. Looking forward to reading you Best regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Thu Feb 1 18:20:30 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 1 Feb 2018 18:20:30 +0100 Subject: [Scilab-Dev] xget("fpf") xset("fpf") => gca().ticks_format(4)? Message-ID: <9affd59f-cd70-8bc9-0c4c-fea3dfa277ea@free.fr> Please follow up the discussion on the devs@ list only. Dear devs and users, xset() and xget() are obsolete since Scilab 5.0. Yet, they still remain in Scilab 6.0 due to the xget("fpf") and xset("fpf") syntaxes that still have no replacement. These syntaxes respectively gets and sets the floating point C-like format of numbers to be labeled on level curves, as rendered by xstring() within contouring functions like contour2d() : https://help.scilab.org/docs/6.0.0/en_US/contour2d.html The gca().ticks_format property was added in Scilab 5.5.0 and is now available. It is currently a vector of 3 strings being C-like formats specifications for the labels of the x, y, and z axes. So, i am wondering about the possibility to *replace the xget("fpf") and xset("fpf") with a fourth component gca().ticks_format(4) *(to be implemented). Levels are (always?) about z, so in one hand it could be useless to implement .ticks_format(4) instead of using .ticks_format(3) that is already available. In another hand, the special value " " (blank) is presently used in contouring functions to cancel labeling, without canceling labels on the Z axis when contours are drawn in a 3D plot instead of a flat one. Since, in Scilab itself, xget("fpf") and xset("fpf") are used only in leveling macros, *another solution *would be to * simply remove xget("fpf") and xset("fpf") * improve xnumb() in order to make it self-adaptable in term of display format according to values. o i already use and may provide such a version (as well to display complex numbers with their imaginary parts). A SEP may be prepared. o possibly add a formating option. But this is not mandatory if a self-adapting version is available in Scilab. * make contour(), contour2d() and contourf() using xnumb() instead of xstring(). This is trivial. Possibly add a labelling option to them (but it's not mandatory) As a side question, adding a C-like format option to xstring() would be useful as well. The xstring() code already gets such a format from xget("fpf"). It would then be provided as a direct input, instead of from this former environmental variable. I hope that Scilab will, ASAP, actually and properly get rid of these xget() and xset() functions. May this contribution help to this purpose? Best regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From Clement.David at esi-group.com Tue Feb 6 17:42:12 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Tue, 6 Feb 2018 16:42:12 +0000 Subject: [Scilab-Dev] Disturbing changes on CodeReview In-Reply-To: <2dd3121b-aa88-bf33-f4e5-f47ec459d476@free.fr> References: <2dd3121b-aa88-bf33-f4e5-f47ec459d476@free.fr> Message-ID: <1517935331.2145.36.camel@esi-group.com> Hello Samuel, Great notice ! This issue arise when the codereview server it out of disk space. This is a notifiable behavior that might be fixed in more recent Gerrit version. You can continue working on the patchset by using gerrit tools [1] or by crafting the cherry-pick URL by hand. [1]: https://gerrit-review.googlesource.com/Documentation/cmd-cherry-pick.html Thanks, -- Cl?ment Le jeudi 01 f?vrier 2018 ? 00:23 +0100, Samuel Gougeon a ?crit : > Le 31/01/2018 ? 20:45, Samuel Gougeon a ?crit : > > When we review files in diff mode, the edit icon switching the diff mode into the edit one at > > the top of the diff page no longer works: it yields an error page. > > After some work, this proves to occur only for files whose names start with "%", which is a > special character for URLs. > So, it is likely a bug in CodeReview itself, not in the Scilab infrastructure (unless managing "%" > in filenames is configurable in CodeReview). > > Samuel > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From sgougeon at free.fr Sat Feb 10 16:52:53 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Sat, 10 Feb 2018 16:52:53 +0100 Subject: [Scilab-Dev] getscilabkeywords() troubles Message-ID: <1b86a743-04eb-e64f-d4bf-0c879d72df49@free.fr> Dear ESI devs, getscilabkeywords() ignores many Xcos macros, even public ones like scicos_diagram(), etc. This came with Scilab 5.0 :( While working on it, i noted that the /scicos_autolib/ and /scicos_utilslib/ libraries are loaded at Scilab startup, while /scicos_scicoslib/ isn't. Question 1 : is there a reason for this exception? Still about getscilabkeywords() : It registers the xcos/macros with other Scilab macros, in getscilabkeywords()(4) instead of getscilabkeywords()(5). Question 2 : Could we move them in the right 5th bin? This is not a back-compatible proposal. So i let you decide. Best regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From Clement.David at esi-group.com Mon Feb 12 10:59:51 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Mon, 12 Feb 2018 09:59:51 +0000 Subject: [Scilab-Dev] getscilabkeywords() troubles In-Reply-To: <1b86a743-04eb-e64f-d4bf-0c879d72df49@free.fr> References: <1b86a743-04eb-e64f-d4bf-0c879d72df49@free.fr> Message-ID: <1518429590.14137.25.camel@esi-group.com> Hello Samuel, Xcos / Scicos internal libs (both Scilab and natives) are loaded on demand; not at Scilab startup. This has been done to hide Scicos internals (aka scicos_scicoslib) and Xcos blocks from Scilab users and reduce Scilab "reserved" names. The Xcos / Scicos entry points (in scicos_autolib and scicos_utilslib) are correctly listed in getscilabkeywords() and on call they will load the internal libs on demand. FYI a similar behavior is implemented for atoms internal functions. For documented functions (like scicos_diagram()) this is a miss, the Scicos API which let the users define their own blocks is supposed to be public and documented ! -- Cl?ment Le samedi 10 f?vrier 2018 ? 16:52 +0100, Samuel Gougeon a ?crit : > Dear ESI devs, > > getscilabkeywords() ignores many Xcos macros, even public ones like scicos_diagram(), etc. > This came with Scilab 5.0 :( > > While working on it, i noted that the scicos_autolib and scicos_utilslib libraries are loaded at > Scilab startup, while scicos_scicoslib isn't. > > Question 1 : is there a reason for this exception? > > Still about getscilabkeywords() : It registers the xcos/macros with other Scilab macros, > in getscilabkeywords()(4) instead of getscilabkeywords()(5). > > Question 2 : Could we move them in the right 5th bin? This is not a back-compatible proposal. So i > let you decide. > > Best regards > Samuel > > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From stephane.mottelet at utc.fr Tue Feb 13 16:45:41 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Tue, 13 Feb 2018 16:45:41 +0100 Subject: [Scilab-Dev] Evolution of Scilab API Message-ID: <88636831-656c-4037-6ad1-5cafe31a0003@utc.fr> Hello, I am a bit puzzled by the evolution of Scilab api since Scilab 5.x versions. I have understood that the old stack system has dissapeared, but now I am very confused because it seems that two different ways of interfacing C code do exist. For example #include "api_scilab.h" #include #include #include "Scierror.h" int fun(char *fname, void *pvApiCtx) or #include "api_scilab.h" #include #include #include "Scierror.h" int fun(scilabEnv env, int nin, scilabVar* in, int nopt, scilabOpt opt, int nout, scilabVar* out) Is the first snipplet of code above considered as obsolete ? Thanks for help S. -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet From arvid at softube.com Tue Feb 13 19:10:52 2018 From: arvid at softube.com (=?iso-8859-1?Q?Arvid_Ros=E9n?=) Date: Tue, 13 Feb 2018 18:10:52 +0000 Subject: [Scilab-Dev] Evolution of Scilab API In-Reply-To: <88636831-656c-4037-6ad1-5cafe31a0003@utc.fr> References: <88636831-656c-4037-6ad1-5cafe31a0003@utc.fr> Message-ID: I'm also interested in knowing this since I need to port a bunch of libraries from scilab 4/5 to version 6. The documentation is a bit confusing in this area. A tiny example with minimalistic code and a Makefile showing best practices for C and C++ in scilab 6 would be great! Cheers, Arvid H?mta Outlook f?r iOS ________________________________ From: dev on behalf of St?phane Mottelet Sent: Tuesday, February 13, 2018 4:45:41 PM To: List dedicated to development questions Subject: [Scilab-Dev] Evolution of Scilab API Hello, I am a bit puzzled by the evolution of Scilab api since Scilab 5.x versions. I have understood that the old stack system has dissapeared, but now I am very confused because it seems that two different ways of interfacing C code do exist. For example #include "api_scilab.h" #include #include #include "Scierror.h" int fun(char *fname, void *pvApiCtx) or #include "api_scilab.h" #include #include #include "Scierror.h" int fun(scilabEnv env, int nin, scilabVar* in, int nopt, scilabOpt opt, int nout, scilabVar* out) Is the first snipplet of code above considered as obsolete ? Thanks for help S. -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet _______________________________________________ dev mailing list dev at lists.scilab.org http://lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine.elias at scilab-enterprises.com Wed Feb 14 09:45:44 2018 From: antoine.elias at scilab-enterprises.com (Antoine ELIAS) Date: Wed, 14 Feb 2018 09:45:44 +0100 Subject: [Scilab-Dev] Evolution of Scilab API In-Reply-To: References: <88636831-656c-4037-6ad1-5cafe31a0003@utc.fr> Message-ID: <286525f4-67a3-dfba-d3f1-2f1dab5bec9d@scilab-enterprises.com> Hello, First one ( API 1 ) was write to be "compatible" between Scilab 5 and Scilab 6. ( except last arg, int -> void*, sorry about that ) So in Scilab 6 we reproduce stack behavior ( Top, Rhs, LhsVar(x) = y), but that produce lot of copy, move of data). The second ( API 2 ) is the nearest from internal memory of Scilab 6. @St?phane: Both API can be used, we don't plan to remove API 1. @Arvid: Did you take a look of SCI/contrib/toolbox_skeleton/sci_gateway/c ? (http://cgit.scilab.org/scilab/tree/scilab/contrib/toolbox_skeleton/sci_gateway/c?h=6.0.0) I wrote same gateways with API 1 and API 2. Regards, Antoine Le 13/02/2018 ? 19:10, Arvid Ros?n a ?crit?: > I?m also interested in knowing this since I need to port a bunch of > libraries from scilab 4/5 to version 6. > The documentation is a bit confusing in this area. > > A tiny example with minimalistic code and a Makefile showing best > practices for C and C++ in scilab 6 would be great! > > Cheers, > Arvid > > H?mta Outlook f?r iOS > ------------------------------------------------------------------------ > *From:* dev on behalf of St?phane > Mottelet > *Sent:* Tuesday, February 13, 2018 4:45:41 PM > *To:* List dedicated to development questions > *Subject:* [Scilab-Dev] Evolution of Scilab API > Hello, > > I am a bit puzzled by the evolution of Scilab api since Scilab 5.x > versions. I have understood that the old stack system has dissapeared, > but now I am very confused because it seems that two different ways of > interfacing C code do exist. For example > > #include "api_scilab.h" > #include > #include > #include "Scierror.h" > int fun(char *fname, void *pvApiCtx) > > or > > #include "api_scilab.h" > #include > #include > #include "Scierror.h" > int fun(scilabEnv env, int nin, scilabVar* in, int nopt, scilabOpt opt, > int nout, scilabVar* out) > > Is the first snipplet of code above considered as obsolete ? > > Thanks for help > > S. > > > -- > St?phane Mottelet > Ing?nieur de recherche > EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable > D?partement G?nie des Proc?d?s Industriels > Sorbonne Universit?s - Universit? de Technologie de Compi?gne > CS 60319, 60203 Compi?gne cedex > Tel : +33(0)344234688 > http://www.utc.fr/~mottelet > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From Clement.David at esi-group.com Thu Feb 15 16:30:10 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Thu, 15 Feb 2018 15:30:10 +0000 Subject: [Scilab-Dev] Scilab 6.0.1 is out Message-ID: <1518708608.2380.6.camel@esi-group.com> Dear Scilab developers, Thanks to our collective work including your work, we released Scilab 6.0.1! This is a revision of 6.0.0 including bug fixes and avoiding some regression. It is supposed to be fully compatible with 6.0.0 but please report bugs if this is not the case. If user feedbacks are good and reported bugs have low criticality, we will focus on 6.1.0 for the next months; please update your git branches before pushing new commits! For the upcoming features, we took a look at your inputs on the Scilab 6.0.0 ML thread and wish to implement some of them. Help us build them and have a great 6.1.0 version by coding your own functionalities! If you have trouble setting up your dev. environment or need help understanding the code, ask us. For the next releases, we also wish to drastically change the macOS binary to be more Apple compatible (Binary signature, clean Java embedding, etc...) however we need support from the community. Are you interested in helping us ? providing knowledge, patches and testing binaries? For the complete list of changes and bugs fixed, please take a look at the [CHANGES](https://help.scilab.org/CHANGES) file. Thanks for your involvement, -- Cl?ment From stephane.mottelet at utc.fr Thu Feb 15 16:50:46 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Thu, 15 Feb 2018 16:50:46 +0100 Subject: [Scilab-Dev] BLAS use in Scilab In-Reply-To: <1518649368521-0.post@n3.nabble.com> References: <1518615338745-0.post@n3.nabble.com> <46fbee01-dbcf-104b-aa1f-d9c6d2bd32b1@utc.fr> <1518631624856-0.post@n3.nabble.com> <20180214181500.Horde.6noFgwETGwdsbK9FITULam6@webmail.utc.fr> <20180214200352.Horde.lsHYFRpjelt8p_GJ1NTzzuQ@webmail.utc.fr> <1518648613976-0.post@n3.nabble.com> <1518649368521-0.post@n3.nabble.com> Message-ID: <293ab011-7dba-c3a1-6b7c-b9815a339555@utc.fr> Hello all, Following the recent discussion with fujimoto, I discovered that Scilab does not (seem to) fully use SIMD operation in? BLAS as it should. Besides the bottlenecks of its code, there are also many operations of the kind scalar*matrix Althoug this operation is correctly delegated to the DSCAL BLAS function (can be seen in C function iMultiRealMatrixByRealMatrix in modules/ast/src/c/operations/matrix_multiplication.c) : > int iMultiRealScalarByRealMatrix( > ??? double _dblReal1, > ??? double *_pdblReal2,?? ?int _iRows2, int _iCols2, > ??? double *_pdblRealOut) > { > ??? int iOne?? ?= 1; > ??? int iSize2?? ?= _iRows2 * _iCols2; > > ??? C2F(dcopy)(&iSize2, _pdblReal2, &iOne, _pdblRealOut, &iOne); > ??? C2F(dscal)(&iSize2, &_dblReal1, _pdblRealOut, &iOne); > ??? return 0; > } in the code below the product "A*1" is likely using only one processor core, as seen on the cpu usage graph and on the elapsed time, A=rand(20000,20000); tic; for i=1:10; A*1; end; toc ?ans? = ?? 25.596843 but this second piece of code is more than 8 times faster and uses 100% of the cpu, ONE=ones(20000,1); tic; for i=1:10; A*ONE; end; toc ?ans? = ?? 2.938314 with roughly the same number of multiplications. This second computation is delegated to DGEMM (C<-alpha*A*B + beta*C, here with alpha=1 and beta=0) > int iMultiRealMatrixByRealMatrix( > ??? double *_pdblReal1,?? ?int _iRows1, int _iCols1, > ??? double *_pdblReal2,?? ?int _iRows2, int _iCols2, > ??? double *_pdblRealOut) > { > ??? double dblOne?? ??? ?= 1; > ??? double dblZero?? ??? ?= 0; > > ??? C2F(dgemm)("n", "n", &_iRows1, &_iCols2, &_iCols1, &dblOne, > ?????????????? _pdblReal1 , &_iRows1 , > ?????????????? _pdblReal2, &_iRows2, &dblZero, > ?????????????? _pdblRealOut , &_iRows1); > ??? return 0; > } Maybe my intuition is wrong, but I have the feeling that using dgemm with alpha=0 will be faster than dscal. I plan to test this by making a quick and dirty code linked to Scilab so my question to devs is : which are the #includes to add on top of the source (C) to be able to call dgemm and dscal ? Thanks for your help S. -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet From antoine.elias at scilab-enterprises.com Thu Feb 15 17:11:05 2018 From: antoine.elias at scilab-enterprises.com (Antoine ELIAS) Date: Thu, 15 Feb 2018 17:11:05 +0100 Subject: [Scilab-Dev] BLAS use in Scilab In-Reply-To: <293ab011-7dba-c3a1-6b7c-b9815a339555@utc.fr> References: <1518615338745-0.post@n3.nabble.com> <46fbee01-dbcf-104b-aa1f-d9c6d2bd32b1@utc.fr> <1518631624856-0.post@n3.nabble.com> <20180214181500.Horde.6noFgwETGwdsbK9FITULam6@webmail.utc.fr> <20180214200352.Horde.lsHYFRpjelt8p_GJ1NTzzuQ@webmail.utc.fr> <1518648613976-0.post@n3.nabble.com> <1518649368521-0.post@n3.nabble.com> <293ab011-7dba-c3a1-6b7c-b9815a339555@utc.fr> Message-ID: <3daebae7-eba4-a32c-5e1e-c403ece6f5fa@scilab-enterprises.com> Hello St?phane, Interesting ... In release, we don't ship the header of BLAS/LAPACK functions. But you can define them in your C file as extern. ( and let the linker do his job ) extern int C2F(dgemm) (char *_pstTransA, char *_pstTransB, int *_piN, int *_piM, int *_piK, double *_pdblAlpha, double *_pdblA, int *_piLdA, ?????????????????????? double *_pdblB, int *_piLdB, double *_pdblBeta, double *_pdblC, int *_piLdC); and extern int C2F(dscal) (int *_iSize, double *_pdblVal, double *_pdblDest, int *_iInc); Others BLAS/LAPACK prototypes can be found at http://cgit.scilab.org/scilab/tree/scilab/modules/elementary_functions/includes/elem_common.h?h=6.0 Regards, Antoine Le 15/02/2018 ? 16:50, St?phane Mottelet a ?crit?: > Hello all, > > Following the recent discussion with fujimoto, I discovered that > Scilab does not (seem to) fully use SIMD operation in? BLAS as it > should. Besides the bottlenecks of its code, there are also many > operations of the kind > > scalar*matrix > > Althoug this operation is correctly delegated to the DSCAL BLAS > function (can be seen in C function iMultiRealMatrixByRealMatrix in > modules/ast/src/c/operations/matrix_multiplication.c) : > >> int iMultiRealScalarByRealMatrix( >> ??? double _dblReal1, >> ??? double *_pdblReal2,?? ?int _iRows2, int _iCols2, >> ??? double *_pdblRealOut) >> { >> ??? int iOne?? ?= 1; >> ??? int iSize2?? ?= _iRows2 * _iCols2; >> >> ??? C2F(dcopy)(&iSize2, _pdblReal2, &iOne, _pdblRealOut, &iOne); >> ??? C2F(dscal)(&iSize2, &_dblReal1, _pdblRealOut, &iOne); >> ??? return 0; >> } > in the code below the product "A*1" is likely using only one processor > core, as seen on the cpu usage graph and on the elapsed time, > > A=rand(20000,20000); > tic; for i=1:10; A*1; end; toc > > ?ans? = > > ?? 25.596843 > > but this second piece of code is more than 8 times faster and uses > 100% of the cpu, > > ONE=ones(20000,1); > tic; for i=1:10; A*ONE; end; toc > > ?ans? = > > ?? 2.938314 > > with roughly the same number of multiplications. This second > computation is delegated to DGEMM (C<-alpha*A*B + beta*C, here with > alpha=1 and beta=0) > >> int iMultiRealMatrixByRealMatrix( >> ??? double *_pdblReal1,?? ?int _iRows1, int _iCols1, >> ??? double *_pdblReal2,?? ?int _iRows2, int _iCols2, >> ??? double *_pdblRealOut) >> { >> ??? double dblOne?? ??? ?= 1; >> ??? double dblZero?? ??? ?= 0; >> >> ??? C2F(dgemm)("n", "n", &_iRows1, &_iCols2, &_iCols1, &dblOne, >> ?????????????? _pdblReal1 , &_iRows1 , >> ?????????????? _pdblReal2, &_iRows2, &dblZero, >> ?????????????? _pdblRealOut , &_iRows1); >> ??? return 0; >> } > Maybe my intuition is wrong, but I have the feeling that using dgemm > with alpha=0 will be faster than dscal. I plan to test this by making > a quick and dirty code linked to Scilab so my question to devs is : > which are the #includes to add on top of the source (C) to be able to > call dgemm and dscal ? > > Thanks for your help > > S. > > From stephane.mottelet at utc.fr Thu Feb 15 17:17:06 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Thu, 15 Feb 2018 17:17:06 +0100 Subject: [Scilab-Dev] Scilab 6.0.1 is out In-Reply-To: <1518708608.2380.6.camel@esi-group.com> References: <1518708608.2380.6.camel@esi-group.com> Message-ID: Le 15/02/2018 ? 16:30, Cl?ment David a ?crit?: > Dear Scilab developers, > > Thanks to our collective work including your work, we released Scilab 6.0.1! This is a revision of > 6.0.0 including bug fixes and avoiding some regression. It is supposed to be fully compatible with > 6.0.0 but please report bugs if this is not the case. > > If user feedbacks are good and reported bugs have low criticality, we will focus on 6.1.0 for the > next months; please update your git branches before pushing new commits! For the upcoming features, > we took a look at your inputs on the Scilab 6.0.0 ML thread and wish to implement some of them. Help > us build them and have a great 6.1.0 version by coding your own functionalities! If you have trouble > setting up your dev. environment or need help understanding the code, ask us. > > For the next releases, we also wish to drastically change the macOS binary to be more Apple > compatible (Binary signature, clean Java embedding, etc...) however we need support from the > community. Are you interested in helping us ? providing knowledge, patches and testing binaries? > > For the complete list of changes and bugs fixed, please take a look at the > [CHANGES](https://help.scilab.org/CHANGES) file. > > Thanks for your involvement, > > -- > Cl?ment > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev Hello Cl?ment, Under High Sierra Scilab windows are flashing when they are resized, this is awfull ! Downgrading libnativewindow_macosx.jnilib libnativewindow_awt.jnilib at the state they were for Scilab 5.5.1 solves the problem (see my 2018-02-14 update at http://www.utc.fr/~mottelet/Darwin/). Maybe there exists a less "experimental" way of solving the problem, but doing this works like a charm ! S. -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet From Clement.David at esi-group.com Thu Feb 15 17:36:46 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Thu, 15 Feb 2018 16:36:46 +0000 Subject: [Scilab-Dev] Scilab 6.0.1 is out In-Reply-To: References: <1518708608.2380.6.camel@esi-group.com> Message-ID: <1518712605.2380.12.camel@esi-group.com> Le jeudi 15 f?vrier 2018 ? 17:17 +0100, St?phane Mottelet a ?crit : > Le 15/02/2018 ? 16:30, Cl?ment David a ?crit : > > Dear Scilab developers, > > > > Thanks to our collective work including your work, we released Scilab 6.0.1! This is a revision > > of > > 6.0.0 including bug fixes and avoiding some regression. It is supposed to be fully compatible > > with > > 6.0.0 but please report bugs if this is not the case. > > > > If user feedbacks are good and reported bugs have low criticality, we will focus on 6.1.0 for > > the > > next months; please update your git branches before pushing new commits! For the upcoming > > features, > > we took a look at your inputs on the Scilab 6.0.0 ML thread and wish to implement some of them. > > Help > > us build them and have a great 6.1.0 version by coding your own functionalities! If you have > > trouble > > setting up your dev. environment or need help understanding the code, ask us. > > > > For the next releases, we also wish to drastically change the macOS binary to be more Apple > > compatible (Binary signature, clean Java embedding, etc...) however we need support from the > > community. Are you interested in helping us ? providing knowledge, patches and testing binaries? > > > > For the complete list of changes and bugs fixed, please take a look at the > > [CHANGES](https://help.scilab.org/CHANGES) file. > > > > Thanks for your involvement, > > > > -- > > Cl?ment > > _______________________________________________ > > dev mailing list > > dev at lists.scilab.org > > http://lists.scilab.org/mailman/listinfo/dev > > Hello Cl?ment, > > Under High Sierra Scilab windows are flashing when they are resized, > this is awfull ! Downgrading > > libnativewindow_macosx.jnilib > libnativewindow_awt.jnilib > > at the state they were for Scilab 5.5.1 solves the problem (see my > 2018-02-14 update at http://www.utc.fr/~mottelet/Darwin/). Maybe there > exists a less "experimental" way of solving the problem, but doing this > works like a charm ! Hello St?phane, Thanks for the information, libjogl2 might also need to be upgraded (rather than downgraded) on the master branch [1] to fix a lot of bugs and issues. Maybe providing binaries built on High Sierra might improve the situation. [1]: https://codereview.scilab.org/#/c/17530/ -- Cl?ment From stephane.mottelet at utc.fr Thu Feb 15 17:46:50 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Thu, 15 Feb 2018 17:46:50 +0100 Subject: [Scilab-Dev] Scilab 6.0.1 is out In-Reply-To: <1518712605.2380.12.camel@esi-group.com> References: <1518708608.2380.6.camel@esi-group.com> <1518712605.2380.12.camel@esi-group.com> Message-ID: <02119f1b-81d5-97ac-cd61-9f8338c3eb44@utc.fr> Le 15/02/2018 ? 17:36, Cl?ment David a ?crit?: > Le jeudi 15 f?vrier 2018 ? 17:17 +0100, St?phane Mottelet a ?crit : >> Le 15/02/2018 ? 16:30, Cl?ment David a ?crit : >>> Dear Scilab developers, >>> >>> Thanks to our collective work including your work, we released Scilab 6.0.1! This is a revision >>> of >>> 6.0.0 including bug fixes and avoiding some regression. It is supposed to be fully compatible >>> with >>> 6.0.0 but please report bugs if this is not the case. >>> >>> If user feedbacks are good and reported bugs have low criticality, we will focus on 6.1.0 for >>> the >>> next months; please update your git branches before pushing new commits! For the upcoming >>> features, >>> we took a look at your inputs on the Scilab 6.0.0 ML thread and wish to implement some of them. >>> Help >>> us build them and have a great 6.1.0 version by coding your own functionalities! If you have >>> trouble >>> setting up your dev. environment or need help understanding the code, ask us. >>> >>> For the next releases, we also wish to drastically change the macOS binary to be more Apple >>> compatible (Binary signature, clean Java embedding, etc...) however we need support from the >>> community. Are you interested in helping us ? providing knowledge, patches and testing binaries? >>> >>> For the complete list of changes and bugs fixed, please take a look at the >>> [CHANGES](https://help.scilab.org/CHANGES) file. >>> >>> Thanks for your involvement, >>> >>> -- >>> Cl?ment >>> _______________________________________________ >>> dev mailing list >>> dev at lists.scilab.org >>> http://lists.scilab.org/mailman/listinfo/dev >> Hello Cl?ment, >> >> Under High Sierra Scilab windows are flashing when they are resized, >> this is awfull ! Downgrading >> >> libnativewindow_macosx.jnilib >> libnativewindow_awt.jnilib >> >> at the state they were for Scilab 5.5.1 solves the problem (see my >> 2018-02-14 update at http://www.utc.fr/~mottelet/Darwin/). Maybe there >> exists a less "experimental" way of solving the problem, but doing this >> works like a charm ! > Hello St?phane, > > Thanks for the information, libjogl2 might also need to be upgraded (rather than downgraded) on the > master branch [1] to fix a lot of bugs and issues. Maybe providing binaries built on High Sierra > might improve the situation. > > [1]: https://codereview.scilab.org/#/c/17530/ > > -- > Cl?ment > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev After testing the downgrade also improves the resize under Sierra, which was also flashing but only on window decorations. S. -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet From stephane.mottelet at utc.fr Fri Feb 16 17:00:35 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Fri, 16 Feb 2018 17:00:35 +0100 Subject: [Scilab-Dev] ilib_build documentation incomplete for new scilab api Message-ID: <91356b51-fdd6-8699-5c82-2274e17fc5ad@utc.fr> Hello, ilib_build documentation omits to precise that in ilib_build(lib_name,table,files,libs [,makename,ldflags,cflags,fflags,ismex, cc]) 'table' has to be 3 column matrix if you want to use the latest api_scilab. In "Getting started with API_Scilab" I finally understood that "csi6" means : "C code with new scilab 6 api" ! It should be precised in the page and I suppose that other strings are supported, maybe 'csi5' ? S. -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet From stephane.mottelet at utc.fr Mon Feb 19 19:15:34 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Mon, 19 Feb 2018 19:15:34 +0100 Subject: [Scilab-Dev] BLAS use in Scilab In-Reply-To: <3daebae7-eba4-a32c-5e1e-c403ece6f5fa@scilab-enterprises.com> References: <1518615338745-0.post@n3.nabble.com> <46fbee01-dbcf-104b-aa1f-d9c6d2bd32b1@utc.fr> <1518631624856-0.post@n3.nabble.com> <20180214181500.Horde.6noFgwETGwdsbK9FITULam6@webmail.utc.fr> <20180214200352.Horde.lsHYFRpjelt8p_GJ1NTzzuQ@webmail.utc.fr> <1518648613976-0.post@n3.nabble.com> <1518649368521-0.post@n3.nabble.com> <293ab011-7dba-c3a1-6b7c-b9815a339555@utc.fr> <3daebae7-eba4-a32c-5e1e-c403ece6f5fa@scilab-enterprises.com> Message-ID: <1553ecbc-2120-9236-3e8e-b32eb09811e4@utc.fr> Hello, After some tests, for the intended use (multiply a matrix by a scalar), dgemm is not faster that dscal, but in the C code of "iMultiRealScalarByRealMatrix", the part which takes the most of the CPU time is the call to "dcopy". For example, on my machine, for a 10000x10000 matrix, the call to dcopy takes 540 milliseconds and the call to dscal 193 milliseconds. Continuing my explorations today, I tried to see how Scilab expressions such as Y+2*X are parsed and executed. To this purpose I have written an interface (daxpy.sci and daxpy.c attached) to the BLAS function "daxpy" which does "y<-y+a*x" and a script comparing the above expression to daxpy(2,X,Y) for two 10000x10000 matrices. Here are the results (MacBook air core i7 at 1,7GHz): ?daxpy(2,X,Y) ?(dcopy: 582 ms) ?(daxpy: 211 ms) ?elapsed time: 793 ms ?Y+2*X ?elapsed time: 1574 ms Considered the above value, the explanation is that in "Y+2*X" there are *two* copies of a 10000x10000 matrix instead of only one in "daxpy(2,X,Y)". In "Y+2*X+3*Z" there will be three copies, although there could be only one if daxpy was used twice. I am not blaming Scilab here, I am just blaming "vectorization", which can be inefficient when large objects are used. That's why explicits loops can sometimes be faster than vectorized operations in Matlab or Julia (which both use JIT compilation). S. Le 15/02/2018 ? 17:11, Antoine ELIAS a ?crit?: > Hello St?phane, > > Interesting ... > > In release, we don't ship the header of BLAS/LAPACK functions. > But you can define them in your C file as extern. ( and let the linker > do his job ) > > extern int C2F(dgemm) (char *_pstTransA, char *_pstTransB, int *_piN, > int *_piM, int *_piK, double *_pdblAlpha, double *_pdblA, int *_piLdA, > ?????????????????????? double *_pdblB, int *_piLdB, double *_pdblBeta, > double *_pdblC, int *_piLdC); > and > > extern int C2F(dscal) (int *_iSize, double *_pdblVal, double > *_pdblDest, int *_iInc); > > Others BLAS/LAPACK prototypes can be found at > http://cgit.scilab.org/scilab/tree/scilab/modules/elementary_functions/includes/elem_common.h?h=6.0 > > Regards, > Antoine > Le 15/02/2018 ? 16:50, St?phane Mottelet a ?crit?: >> Hello all, >> >> Following the recent discussion with fujimoto, I discovered that >> Scilab does not (seem to) fully use SIMD operation in? BLAS as it >> should. Besides the bottlenecks of its code, there are also many >> operations of the kind >> >> scalar*matrix >> >> Althoug this operation is correctly delegated to the DSCAL BLAS >> function (can be seen in C function iMultiRealMatrixByRealMatrix in >> modules/ast/src/c/operations/matrix_multiplication.c) : >> >>> int iMultiRealScalarByRealMatrix( >>> ??? double _dblReal1, >>> ??? double *_pdblReal2,?? ?int _iRows2, int _iCols2, >>> ??? double *_pdblRealOut) >>> { >>> ??? int iOne?? ?= 1; >>> ??? int iSize2?? ?= _iRows2 * _iCols2; >>> >>> ??? C2F(dcopy)(&iSize2, _pdblReal2, &iOne, _pdblRealOut, &iOne); >>> ??? C2F(dscal)(&iSize2, &_dblReal1, _pdblRealOut, &iOne); >>> ??? return 0; >>> } >> in the code below the product "A*1" is likely using only one >> processor core, as seen on the cpu usage graph and on the elapsed time, >> >> A=rand(20000,20000); >> tic; for i=1:10; A*1; end; toc >> >> ?ans? = >> >> ?? 25.596843 >> >> but this second piece of code is more than 8 times faster and uses >> 100% of the cpu, >> >> ONE=ones(20000,1); >> tic; for i=1:10; A*ONE; end; toc >> >> ?ans? = >> >> ?? 2.938314 >> >> with roughly the same number of multiplications. This second >> computation is delegated to DGEMM (C<-alpha*A*B + beta*C, here with >> alpha=1 and beta=0) >> >>> int iMultiRealMatrixByRealMatrix( >>> ??? double *_pdblReal1,?? ?int _iRows1, int _iCols1, >>> ??? double *_pdblReal2,?? ?int _iRows2, int _iCols2, >>> ??? double *_pdblRealOut) >>> { >>> ??? double dblOne?? ??? ?= 1; >>> ??? double dblZero?? ??? ?= 0; >>> >>> ??? C2F(dgemm)("n", "n", &_iRows1, &_iCols2, &_iCols1, &dblOne, >>> ?????????????? _pdblReal1 , &_iRows1 , >>> ?????????????? _pdblReal2, &_iRows2, &dblZero, >>> ?????????????? _pdblRealOut , &_iRows1); >>> ??? return 0; >>> } >> Maybe my intuition is wrong, but I have the feeling that using dgemm >> with alpha=0 will be faster than dscal. I plan to test this by making >> a quick and dirty code linked to Scilab so my question to devs is : >> which are the #includes to add on top of the source (C) to be able to >> call dgemm and dscal ? >> >> Thanks for your help >> >> S. >> >> > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- #include "api_scilab.h" #include "Scierror.h" #include "localization.h" #include "machine.h" #include extern int F2C(dcopy)(int *, double *, int *, double *, int *); extern int C2F(daxpy) (int *, double *, double *, int *, double *, int *); uint64_t system_current_time_millis() { #if defined(_WIN32) || defined(_WIN64) struct _timeb timebuffer; _ftime(&timebuffer); return (uint64_t)(((timebuffer.time * 1000) + timebuffer.millitm)); #else struct timeb timebuffer; ftime(&timebuffer); return (uint64_t)(((timebuffer.time * 1000) + timebuffer.millitm)); #endif } static const char fname[] = "daxpy"; /* ==================================================================== */ int sci_daxpy(scilabEnv env, int nin, scilabVar* in, int nopt, scilabOpt* opt, int nout, scilabVar* out) { int i = 0; int rowAlpha = 0; int colAlpha = 0; int rowX = 0; int colX = 0; int rowY = 0; int colY = 0; int iOne = 1; int iZero = 0; double dblZero = 0; int size; double* alpha = NULL; double* Y = NULL; double* X = NULL; double* Z = NULL; uint64_t T1,T2; if (nin != 3) { Scierror(77, _("%s: Wrong number of input argument(s): %d expected.\n"), fname, 3); return 1; } if (scilab_isDouble(env, in[0]) == 0 || scilab_isMatrix2d(env, in[0]) == 0 || scilab_isComplex(env, in[0]) == 1) { Scierror(999, _("%s: wrong type for input argument #%d: a real scalar expected.\n"), fname, 1); return 1; } if (scilab_isDouble(env, in[1]) == 0 || scilab_isMatrix2d(env, in[1]) == 0) { Scierror(999, _("%s: wrong type for input argument #%d: a real matrix expected.\n"), fname, 2); return 1; } if (scilab_isDouble(env, in[2]) == 0 || scilab_isMatrix2d(env, in[2]) == 0) { Scierror(999, _("%s: wrong type for input argument #%d: a real matrix expected.\n"), fname, 3); return 1; } scilab_getDim2d(env, in[0], &rowAlpha, &colAlpha); scilab_getDim2d(env, in[1], &rowX, &colX); scilab_getDim2d(env, in[2], &rowY, &colY); if (rowAlpha*colAlpha != 1) { Scierror(999, _("%s: Wrong size for input arguments: first argument must be a scalar.\n"), fname); return 1; } if ((rowX != rowY) || (colX != colY)) { Scierror(999, _("%s: Wrong size for input arguments: second and third argument must have the same dimensions.\n"), fname); return 1; } scilab_getDoubleArray(env, in[0], &alpha); scilab_getDoubleArray(env, in[1], &X); scilab_getDoubleArray(env, in[2], &Y); out[0] = scilab_createDoubleMatrix2d(env, rowX, colX, 0); scilab_getDoubleArray(env, out[0], &Z); size=(rowX*colX); T1=system_current_time_millis(); F2C(dcopy)(&size, Y, &iOne, Z, &iOne); T2=system_current_time_millis(); sciprint(" (dcopy: %u ms)\n",T2-T1); T1=T2; F2C(daxpy)(&size, alpha, X, &iOne, Z, &iOne); T2=system_current_time_millis(); sciprint(" (daxpy: %u ms)\n",T2-T1); return 0; } -------------- next part -------------- cd(get_absolute_file_path(("daxpy.sci"))) ulink files=["daxpy.c"]; ilib_build('mult_lib',['daxpy','sci_daxpy','csci6'],files,[]); // "csi6" -> new Scilab 6 API exec loader.sce X=rand(10000,10000); Y=rand(10000,10000); disp("daxpy(2,X,Y)") tic; daxpy(2,X,Y); disp(sprintf("elapsed time: %d ms",toc()*1000)) disp("Y+2*X") tic; Y+2*X; disp(sprintf("elapsed time: %d ms",toc()*1000)) From stephane.mottelet at utc.fr Tue Feb 20 11:57:00 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Tue, 20 Feb 2018 11:57:00 +0100 Subject: [Scilab-Dev] BLAS use in Scilab In-Reply-To: <1553ecbc-2120-9236-3e8e-b32eb09811e4@utc.fr> References: <1518615338745-0.post@n3.nabble.com> <46fbee01-dbcf-104b-aa1f-d9c6d2bd32b1@utc.fr> <1518631624856-0.post@n3.nabble.com> <20180214181500.Horde.6noFgwETGwdsbK9FITULam6@webmail.utc.fr> <20180214200352.Horde.lsHYFRpjelt8p_GJ1NTzzuQ@webmail.utc.fr> <1518648613976-0.post@n3.nabble.com> <1518649368521-0.post@n3.nabble.com> <293ab011-7dba-c3a1-6b7c-b9815a339555@utc.fr> <3daebae7-eba4-a32c-5e1e-c403ece6f5fa@scilab-enterprises.com> <1553ecbc-2120-9236-3e8e-b32eb09811e4@utc.fr> Message-ID: Hello, Continuing on this subject, Hello, I discovered that the new Scilab API allows to modify input parameters of a function (in-place assignment), e.g. I have modified the previous daxpy such that the expression daxpy(2,X,Y) has no output but formally does "Y+=2*X" if such an operator would exist in Scilab. In this case there is no matrix copy at all, hence no memory overhead. Was it possible to do this with the previous API ? S. Le 19/02/2018 ? 19:15, St?phane Mottelet a ?crit?: > Hello, > > After some tests, for the intended use (multiply a matrix by a > scalar), dgemm is not faster that dscal, but in the C code of > "iMultiRealScalarByRealMatrix", the part which takes the most of the > CPU time is the call to "dcopy". For example, on my machine,? for a > 10000x10000 matrix, the call to dcopy takes 540 milliseconds and the > call to dscal 193 milliseconds. Continuing my explorations today, I > tried to see how Scilab expressions such as > > Y+2*X > > are parsed and executed. To this purpose I have written an interface > (daxpy.sci and daxpy.c attached) to the BLAS function "daxpy" which > does "y<-y+a*x" and a script comparing the above expression to > > daxpy(2,X,Y) > > for two 10000x10000 matrices. Here are the results (MacBook air core > i7 at 1,7GHz): > > ?daxpy(2,X,Y) > ?(dcopy: 582 ms) > ?(daxpy: 211 ms) > > ?elapsed time: 793 ms > > ?Y+2*X > > ?elapsed time: 1574 ms > > Considered the above value, the explanation is that in "Y+2*X" there > are *two* copies of a 10000x10000 matrix instead of only one in > "daxpy(2,X,Y)". In "Y+2*X+3*Z" there will be three copies, although > there could be only one if daxpy was used twice. > > I am not blaming Scilab here, I am just blaming "vectorization", which > can be inefficient when large objects are used. That's why explicits > loops can sometimes be faster than vectorized operations in Matlab or > Julia (which both use JIT compilation). > > S. > > > Le 15/02/2018 ? 17:11, Antoine ELIAS a ?crit?: >> Hello St?phane, >> >> Interesting ... >> >> In release, we don't ship the header of BLAS/LAPACK functions. >> But you can define them in your C file as extern. ( and let the >> linker do his job ) >> >> extern int C2F(dgemm) (char *_pstTransA, char *_pstTransB, int *_piN, >> int *_piM, int *_piK, double *_pdblAlpha, double *_pdblA, int *_piLdA, >> ?????????????????????? double *_pdblB, int *_piLdB, double >> *_pdblBeta, double *_pdblC, int *_piLdC); >> and >> >> extern int C2F(dscal) (int *_iSize, double *_pdblVal, double >> *_pdblDest, int *_iInc); >> >> Others BLAS/LAPACK prototypes can be found at >> http://cgit.scilab.org/scilab/tree/scilab/modules/elementary_functions/includes/elem_common.h?h=6.0 >> >> Regards, >> Antoine >> Le 15/02/2018 ? 16:50, St?phane Mottelet a ?crit?: >>> Hello all, >>> >>> Following the recent discussion with fujimoto, I discovered that >>> Scilab does not (seem to) fully use SIMD operation in BLAS as it >>> should. Besides the bottlenecks of its code, there are also many >>> operations of the kind >>> >>> scalar*matrix >>> >>> Althoug this operation is correctly delegated to the DSCAL BLAS >>> function (can be seen in C function iMultiRealMatrixByRealMatrix in >>> modules/ast/src/c/operations/matrix_multiplication.c) : >>> >>>> int iMultiRealScalarByRealMatrix( >>>> ??? double _dblReal1, >>>> ??? double *_pdblReal2,?? ?int _iRows2, int _iCols2, >>>> ??? double *_pdblRealOut) >>>> { >>>> ??? int iOne?? ?= 1; >>>> ??? int iSize2?? ?= _iRows2 * _iCols2; >>>> >>>> ??? C2F(dcopy)(&iSize2, _pdblReal2, &iOne, _pdblRealOut, &iOne); >>>> ??? C2F(dscal)(&iSize2, &_dblReal1, _pdblRealOut, &iOne); >>>> ??? return 0; >>>> } >>> in the code below the product "A*1" is likely using only one >>> processor core, as seen on the cpu usage graph and on the elapsed time, >>> >>> A=rand(20000,20000); >>> tic; for i=1:10; A*1; end; toc >>> >>> ?ans? = >>> >>> ?? 25.596843 >>> >>> but this second piece of code is more than 8 times faster and uses >>> 100% of the cpu, >>> >>> ONE=ones(20000,1); >>> tic; for i=1:10; A*ONE; end; toc >>> >>> ?ans? = >>> >>> ?? 2.938314 >>> >>> with roughly the same number of multiplications. This second >>> computation is delegated to DGEMM (C<-alpha*A*B + beta*C, here with >>> alpha=1 and beta=0) >>> >>>> int iMultiRealMatrixByRealMatrix( >>>> ??? double *_pdblReal1,?? ?int _iRows1, int _iCols1, >>>> ??? double *_pdblReal2,?? ?int _iRows2, int _iCols2, >>>> ??? double *_pdblRealOut) >>>> { >>>> ??? double dblOne?? ??? ?= 1; >>>> ??? double dblZero?? ??? ?= 0; >>>> >>>> ??? C2F(dgemm)("n", "n", &_iRows1, &_iCols2, &_iCols1, &dblOne, >>>> ?????????????? _pdblReal1 , &_iRows1 , >>>> ?????????????? _pdblReal2, &_iRows2, &dblZero, >>>> ?????????????? _pdblRealOut , &_iRows1); >>>> ??? return 0; >>>> } >>> Maybe my intuition is wrong, but I have the feeling that using dgemm >>> with alpha=0 will be faster than dscal. I plan to test this by >>> making a quick and dirty code linked to Scilab so my question to >>> devs is : which are the #includes to add on top of the source (C) to >>> be able to call dgemm and dscal ? >>> >>> Thanks for your help >>> >>> S. >>> >>> >> >> _______________________________________________ >> dev mailing list >> dev at lists.scilab.org >> http://lists.scilab.org/mailman/listinfo/dev > > > -- > St?phane Mottelet > Ing?nieur de recherche > EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable > D?partement G?nie des Proc?d?s Industriels > Sorbonne Universit?s - Universit? de Technologie de Compi?gne > CS 60319, 60203 Compi?gne cedex > Tel : +33(0)344234688 > http://www.utc.fr/~mottelet > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet -------------- next part -------------- An HTML attachment was scrubbed... URL: From badshah400 at gmail.com Wed Feb 21 13:19:30 2018 From: badshah400 at gmail.com (Atri Bhattacharya) Date: Wed, 21 Feb 2018 13:19:30 +0100 Subject: [Scilab-Dev] Scilab GUI and adv-cli fail to launch with java 9 Message-ID: <1519215570.4587.14.camel@gmail.com> Hi, After several patches to fix building against java 9, I have been finally able to get scilab 6.0.1 building on openSUSE Tumbleweed. However, during run time, I now see a ClassNotFoundError, as follows: -------------------- :~> SCIVERBOSE=1 scilab SCILABBIN : scilab-bin DISABLE_JAVA_DETECTION : 0 SCILAB_MODE : gui OS : Linux MODEL : x86_64 IS_SCILAB_BINARY : 0 Using specified vm: /usr/lib64/jvm/java JAVA_HOME : /usr/lib64/jvm/java SCI : /usr/share/scilab/ SCIBIN : /usr/bin/scilab-bin PATH : /usr/share/scilab/:/usr/share/scilab//bin:/usr/bin:/home/badshah400/bin :/usr/local/bin:/usr/bin:/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin CLASSPATH : /usr/share/scilab//modules/core/jar/org.scilab.modules.core.jar EGL_DRIVER : LD_LIBRARY_PATH : /usr/lib64/jvm/java/lib/:/usr/lib64/jvm/java/lib/server/:/usr/lib64/jvm /java/lib/native_threads/ DOCBOOK : /usr/share/xml/docbook/stylesheet/nwalsh/current/ WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.scilab.modules.jvm.LibraryPath (file:/usr/share/scilab/modules/jvm/jar/org.scilab.modules.jvm.jar) to field java.lang.ClassLoader.sys_paths WARNING: Please consider reporting this to the maintainers of org.scilab.modules.jvm.LibraryPath WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release Could not access to the Main Scilab Class: Exception in thread "main" java.lang.NoClassDefFoundError: org/scilab/modules/core/Scilab Caused by: java.lang.ClassNotFoundException: org.scilab.modules.core.Scilab at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClass Loader.java:582) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Cla ssLoaders.java:185) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496) Scilab cannot create Scilab Java Main-Class (we have not been able to find the main Scilab class. Check if the Scilab and thirdparty packages are available). -------------- All patches are available at [1], and also documented on http://bugzilla.scilab.org/show_bug.cgi?id=15328 where unfortunately, I have not seen the needle move much over the recent days. Scilab does work with java 1.8.0 (have to adapt the JRE paths appropriately in bin/scilab); however, as soon as java 9 is used the above error is manifested. If someone can help fix this issue, that will be very helpful. openSUSE uses Java 9 by default now, which means as of now scilab is badly broken -- only scilab-cli works -- on openSUSE Tumbleweed and soon to be released Leap 15.0. Unless Scilab's compatibility issues are fixed, we will have to drop it from the distro unfortunately. Thanks and best wishes. [1] https://build.opensuse.org/package/show/home:badshah400:branches:science/scilab -- Atri Bhattacharya Wed 21 Feb 13:18:49 CET 2018 Sent from openSUSE Tumbleweed on my laptop. From Clement.David at esi-group.com Wed Feb 21 16:25:55 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Wed, 21 Feb 2018 15:25:55 +0000 Subject: [Scilab-Dev] Scilab GUI and adv-cli fail to launch with java 9 In-Reply-To: <1519215570.4587.14.camel@gmail.com> References: <1519215570.4587.14.camel@gmail.com> Message-ID: <1519226754.2211.18.camel@esi-group.com> Hello Atri, Thanks for your work on porting Scilab to jdk9 ; this NoClassDefFoundError usually comes from a mis- compilation check the jar content and be sure to load it correctly. About the patches, I just started to review them and will push them on the 6.0 branch after fixing the build on my machine; please continue your great work, keeping the patches as small as possible. -- Clement Le mercredi 21 f?vrier 2018 ? 13:19 +0100, Atri Bhattacharya a ?crit : > Hi, > After several patches to fix building against java 9, I have been > finally able to get scilab 6.0.1 building on openSUSE Tumbleweed. > However, during run time, I now see a ClassNotFoundError, as follows: > -------------------- > :~> SCIVERBOSE=1 scilab > SCILABBIN : scilab-bin > DISABLE_JAVA_DETECTION : 0 > SCILAB_MODE : gui > OS : Linux > MODEL : x86_64 > IS_SCILAB_BINARY : 0 > Using specified vm: /usr/lib64/jvm/java > JAVA_HOME : /usr/lib64/jvm/java > SCI : /usr/share/scilab/ > SCIBIN : /usr/bin/scilab-bin > PATH : > /usr/share/scilab/:/usr/share/scilab//bin:/usr/bin:/home/badshah400/bin > :/usr/local/bin:/usr/bin:/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin > CLASSPATH : > /usr/share/scilab//modules/core/jar/org.scilab.modules.core.jar > EGL_DRIVER : > LD_LIBRARY_PATH : > /usr/lib64/jvm/java/lib/:/usr/lib64/jvm/java/lib/server/:/usr/lib64/jvm > /java/lib/native_threads/ > DOCBOOK : /usr/share/xml/docbook/stylesheet/nwalsh/current/ > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by > org.scilab.modules.jvm.LibraryPath > (file:/usr/share/scilab/modules/jvm/jar/org.scilab.modules.jvm.jar) to > field java.lang.ClassLoader.sys_paths > WARNING: Please consider reporting this to the maintainers of > org.scilab.modules.jvm.LibraryPath > WARNING: Use --illegal-access=warn to enable warnings of further > illegal reflective access operations > WARNING: All illegal access operations will be denied in a future > release > Could not access to the Main Scilab Class: > Exception in thread "main" java.lang.NoClassDefFoundError: > org/scilab/modules/core/Scilab > Caused by: java.lang.ClassNotFoundException: > org.scilab.modules.core.Scilab > at > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClass > Loader.java:582) > at > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Cla > ssLoaders.java:185) > at > java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496) > > Scilab cannot create Scilab Java Main-Class (we have not been able to > find the main Scilab class. Check if the Scilab and thirdparty packages > are available). > -------------- > > All patches are available at [1], and also documented on > http://bugzilla.scilab.org/show_bug.cgi?id=15328 > where unfortunately, I have not seen the needle move much over the > recent days. > > Scilab does work with java 1.8.0 (have to adapt the JRE paths > appropriately in bin/scilab); however, as soon as java 9 is used the > above error is manifested. If someone can help fix this issue, that > will be very helpful. > > openSUSE uses Java 9 by default now, which means as of now scilab is > badly broken -- only scilab-cli works -- on openSUSE Tumbleweed and > soon to be released Leap 15.0. Unless Scilab's compatibility issues are > fixed, we will have to drop it from the distro unfortunately. > > Thanks and best wishes. > > [1] https://build.opensuse.org/package/show/home:badshah400:branches:science/scilab > From badshah400 at gmail.com Thu Feb 22 13:39:13 2018 From: badshah400 at gmail.com (Atri Bhattacharya) Date: Thu, 22 Feb 2018 13:39:13 +0100 Subject: [Scilab-Dev] Scilab GUI and adv-cli fail to launch with java 9 In-Reply-To: <1519226754.2211.18.camel@esi-group.com> References: <1519215570.4587.14.camel@gmail.com> <1519226754.2211.18.camel@esi-group.com> Message-ID: <1519303153.18295.7.camel@gmail.com> Dear Cl?ment, On Wed, 2018-02-21 at 15:25 +0000, Cl?ment David wrote: > Hello Atri, > > Thanks for your work on porting Scilab to jdk9 ; You are welcome. It's mostly based on self-interest: I use scilab regularly (mostly on the command line though) on openSUSE Tumbleweed. > this NoClassDefFoundError usually comes from a mis- > compilation check the jar content and be sure to load it correctly. I think the jar content looks ok. I think it's some incompatibility between jdk 8 and 9 that prevents the classpath from being correctly used. The same binary works with jdk 8 (even though it is compiled against jdk 9) once the jre paths in the scilab script are appropriately adapted; but it doesn't with jdk 9. > About the patches, I just > started to review them and will push them on the 6.0 branch after > fixing the build on my machine; Many thanks. It will be great if these patches are upstreamed; it would certainly reduce my work (I maintain Scilab packages for openSUSE) during version upgrades. Best wishes. > Le mercredi 21 f?vrier 2018 ? 13:19 +0100, Atri Bhattacharya a ?crit > : > > Hi, > > After several patches to fix building against java 9, I have been > > finally able to get scilab 6.0.1 building on openSUSE Tumbleweed. > > However, during run time, I now see a ClassNotFoundError, as > > follows: > > -------------------- > > :~> SCIVERBOSE=1 scilab > > SCILABBIN : scilab-bin > > DISABLE_JAVA_DETECTION : 0 > > SCILAB_MODE : gui > > OS : Linux > > MODEL : x86_64 > > IS_SCILAB_BINARY : 0 > > Using specified vm: /usr/lib64/jvm/java > > JAVA_HOME : /usr/lib64/jvm/java > > SCI : /usr/share/scilab/ > > SCIBIN : /usr/bin/scilab-bin > > PATH : > > /usr/share/scilab/:/usr/share/scilab//bin:/usr/bin:/home/badshah400 > > /bin > > :/usr/local/bin:/usr/bin:/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin > > CLASSPATH : > > /usr/share/scilab//modules/core/jar/org.scilab.modules.core.jar > > EGL_DRIVER : > > LD_LIBRARY_PATH : > > /usr/lib64/jvm/java/lib/:/usr/lib64/jvm/java/lib/server/:/usr/lib64 > > /jvm > > /java/lib/native_threads/ > > DOCBOOK : /usr/share/xml/docbook/stylesheet/nwalsh/current/ > > WARNING: An illegal reflective access operation has occurred > > WARNING: Illegal reflective access by > > org.scilab.modules.jvm.LibraryPath > > (file:/usr/share/scilab/modules/jvm/jar/org.scilab.modules.jvm.jar) > > to > > field java.lang.ClassLoader.sys_paths > > WARNING: Please consider reporting this to the maintainers of > > org.scilab.modules.jvm.LibraryPath > > WARNING: Use --illegal-access=warn to enable warnings of further > > illegal reflective access operations > > WARNING: All illegal access operations will be denied in a future > > release > > Could not access to the Main Scilab Class: > > Exception in thread "main" java.lang.NoClassDefFoundError: > > org/scilab/modules/core/Scilab > > Caused by: java.lang.ClassNotFoundException: > > org.scilab.modules.core.Scilab > > at > > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinC > > lass > > Loader.java:582) > > at > > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass > > (Cla > > ssLoaders.java:185) > > at > > java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496) > > > > Scilab cannot create Scilab Java Main-Class (we have not been able > > to > > find the main Scilab class. Check if the Scilab and thirdparty > > packages > > are available). > > -------------- > > > > All patches are available at [1], and also documented on > > http://bugzilla.scilab.org/show_bug.cgi?id=15328 > > where unfortunately, I have not seen the needle move much over the > > recent days. > > > > Scilab does work with java 1.8.0 (have to adapt the JRE paths > > appropriately in bin/scilab); however, as soon as java 9 is used > > the > > above error is manifested. If someone can help fix this issue, that > > will be very helpful. > > > > openSUSE uses Java 9 by default now, which means as of now scilab > > is > > badly broken -- only scilab-cli works -- on openSUSE Tumbleweed and > > soon to be released Leap 15.0. Unless Scilab's compatibility issues > > are > > fixed, we will have to drop it from the distro unfortunately. > > > > Thanks and best wishes. > > > > [1] https://build.opensuse.org/package/show/home:badshah400:branche > > s:science/scilab > > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -- Atri Bhattacharya Thu 22 Feb 12:28:07 CET 2018 Sent from openSUSE Tumbleweed on my laptop. From stephane.mottelet at utc.fr Thu Feb 22 14:18:49 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Thu, 22 Feb 2018 14:18:49 +0100 Subject: [Scilab-Dev] BLAS use in Scilab In-Reply-To: References: <1518615338745-0.post@n3.nabble.com> <46fbee01-dbcf-104b-aa1f-d9c6d2bd32b1@utc.fr> <1518631624856-0.post@n3.nabble.com> <20180214181500.Horde.6noFgwETGwdsbK9FITULam6@webmail.utc.fr> <20180214200352.Horde.lsHYFRpjelt8p_GJ1NTzzuQ@webmail.utc.fr> <1518648613976-0.post@n3.nabble.com> <1518649368521-0.post@n3.nabble.com> <293ab011-7dba-c3a1-6b7c-b9815a339555@utc.fr> <3daebae7-eba4-a32c-5e1e-c403ece6f5fa@scilab-enterprises.com> <1553ecbc-2120-9236-3e8e-b32eb09811e4@utc.fr> Message-ID: <6d82edc6-3a68-f7e3-d5b1-755db10ebac9@utc.fr> Really, nobody knows ? S. Le 20/02/2018 ? 11:57, St?phane Mottelet a ?crit?: > Hello, > > Continuing on this subject, Hello, I discovered that the new Scilab > API allows to modify input parameters of a function (in-place > assignment), e.g. I have modified the previous daxpy such that the > expression > > daxpy(2,X,Y) > > has no output but formally does "Y+=2*X" if such an operator would > exist in Scilab. In this case there is no matrix copy at all, hence no > memory overhead. > > Was it possible to do this with the previous API ? > > S. > > Le 19/02/2018 ? 19:15, St?phane Mottelet a ?crit?: >> Hello, >> >> After some tests, for the intended use (multiply a matrix by a >> scalar), dgemm is not faster that dscal, but in the C code of >> "iMultiRealScalarByRealMatrix", the part which takes the most of the >> CPU time is the call to "dcopy". For example, on my machine,? for a >> 10000x10000 matrix, the call to dcopy takes 540 milliseconds and the >> call to dscal 193 milliseconds. Continuing my explorations today, I >> tried to see how Scilab expressions such as >> >> Y+2*X >> >> are parsed and executed. To this purpose I have written an interface >> (daxpy.sci and daxpy.c attached) to the BLAS function "daxpy" which >> does "y<-y+a*x" and a script comparing the above expression to >> >> daxpy(2,X,Y) >> >> for two 10000x10000 matrices. Here are the results (MacBook air core >> i7 at 1,7GHz): >> >> ?daxpy(2,X,Y) >> ?(dcopy: 582 ms) >> ?(daxpy: 211 ms) >> >> ?elapsed time: 793 ms >> >> ?Y+2*X >> >> ?elapsed time: 1574 ms >> >> Considered the above value, the explanation is that in "Y+2*X" there >> are *two* copies of a 10000x10000 matrix instead of only one in >> "daxpy(2,X,Y)". In "Y+2*X+3*Z" there will be three copies, although >> there could be only one if daxpy was used twice. >> >> I am not blaming Scilab here, I am just blaming "vectorization", >> which can be inefficient when large objects are used. That's why >> explicits loops can sometimes be faster than vectorized operations in >> Matlab or Julia (which both use JIT compilation). >> >> S. >> >> >> Le 15/02/2018 ? 17:11, Antoine ELIAS a ?crit?: >>> Hello St?phane, >>> >>> Interesting ... >>> >>> In release, we don't ship the header of BLAS/LAPACK functions. >>> But you can define them in your C file as extern. ( and let the >>> linker do his job ) >>> >>> extern int C2F(dgemm) (char *_pstTransA, char *_pstTransB, int >>> *_piN, int *_piM, int *_piK, double *_pdblAlpha, double *_pdblA, int >>> *_piLdA, >>> ?????????????????????? double *_pdblB, int *_piLdB, double >>> *_pdblBeta, double *_pdblC, int *_piLdC); >>> and >>> >>> extern int C2F(dscal) (int *_iSize, double *_pdblVal, double >>> *_pdblDest, int *_iInc); >>> >>> Others BLAS/LAPACK prototypes can be found at >>> http://cgit.scilab.org/scilab/tree/scilab/modules/elementary_functions/includes/elem_common.h?h=6.0 >>> >>> Regards, >>> Antoine >>> Le 15/02/2018 ? 16:50, St?phane Mottelet a ?crit?: >>>> Hello all, >>>> >>>> Following the recent discussion with fujimoto, I discovered that >>>> Scilab does not (seem to) fully use SIMD operation in BLAS as it >>>> should. Besides the bottlenecks of its code, there are also many >>>> operations of the kind >>>> >>>> scalar*matrix >>>> >>>> Althoug this operation is correctly delegated to the DSCAL BLAS >>>> function (can be seen in C function iMultiRealMatrixByRealMatrix in >>>> modules/ast/src/c/operations/matrix_multiplication.c) : >>>> >>>>> int iMultiRealScalarByRealMatrix( >>>>> ??? double _dblReal1, >>>>> ??? double *_pdblReal2,?? ?int _iRows2, int _iCols2, >>>>> ??? double *_pdblRealOut) >>>>> { >>>>> ??? int iOne?? ?= 1; >>>>> ??? int iSize2?? ?= _iRows2 * _iCols2; >>>>> >>>>> ??? C2F(dcopy)(&iSize2, _pdblReal2, &iOne, _pdblRealOut, &iOne); >>>>> ??? C2F(dscal)(&iSize2, &_dblReal1, _pdblRealOut, &iOne); >>>>> ??? return 0; >>>>> } >>>> in the code below the product "A*1" is likely using only one >>>> processor core, as seen on the cpu usage graph and on the elapsed >>>> time, >>>> >>>> A=rand(20000,20000); >>>> tic; for i=1:10; A*1; end; toc >>>> >>>> ?ans? = >>>> >>>> ?? 25.596843 >>>> >>>> but this second piece of code is more than 8 times faster and uses >>>> 100% of the cpu, >>>> >>>> ONE=ones(20000,1); >>>> tic; for i=1:10; A*ONE; end; toc >>>> >>>> ?ans? = >>>> >>>> ?? 2.938314 >>>> >>>> with roughly the same number of multiplications. This second >>>> computation is delegated to DGEMM (C<-alpha*A*B + beta*C, here with >>>> alpha=1 and beta=0) >>>> >>>>> int iMultiRealMatrixByRealMatrix( >>>>> ??? double *_pdblReal1,?? ?int _iRows1, int _iCols1, >>>>> ??? double *_pdblReal2,?? ?int _iRows2, int _iCols2, >>>>> ??? double *_pdblRealOut) >>>>> { >>>>> ??? double dblOne?? ??? ?= 1; >>>>> ??? double dblZero?? ??? ?= 0; >>>>> >>>>> ??? C2F(dgemm)("n", "n", &_iRows1, &_iCols2, &_iCols1, &dblOne, >>>>> ?????????????? _pdblReal1 , &_iRows1 , >>>>> ?????????????? _pdblReal2, &_iRows2, &dblZero, >>>>> ?????????????? _pdblRealOut , &_iRows1); >>>>> ??? return 0; >>>>> } >>>> Maybe my intuition is wrong, but I have the feeling that using >>>> dgemm with alpha=0 will be faster than dscal. I plan to test this >>>> by making a quick and dirty code linked to Scilab so my question to >>>> devs is : which are the #includes to add on top of the source (C) >>>> to be able to call dgemm and dscal ? >>>> >>>> Thanks for your help >>>> >>>> S. >>>> >>>> >>> >>> _______________________________________________ >>> dev mailing list >>> dev at lists.scilab.org >>> http://lists.scilab.org/mailman/listinfo/dev >> >> >> -- >> St?phane Mottelet >> Ing?nieur de recherche >> EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable >> D?partement G?nie des Proc?d?s Industriels >> Sorbonne Universit?s - Universit? de Technologie de Compi?gne >> CS 60319, 60203 Compi?gne cedex >> Tel : +33(0)344234688 >> http://www.utc.fr/~mottelet >> >> >> _______________________________________________ >> dev mailing list >> dev at lists.scilab.org >> http://lists.scilab.org/mailman/listinfo/dev > > > -- > St?phane Mottelet > Ing?nieur de recherche > EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable > D?partement G?nie des Proc?d?s Industriels > Sorbonne Universit?s - Universit? de Technologie de Compi?gne > CS 60319, 60203 Compi?gne cedex > Tel : +33(0)344234688 > http://www.utc.fr/~mottelet > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet -------------- next part -------------- An HTML attachment was scrubbed... URL: From johanwesselink23 at gmail.com Thu Feb 22 14:39:02 2018 From: johanwesselink23 at gmail.com (Johan Wesselink) Date: Thu, 22 Feb 2018 10:39:02 -0300 Subject: [Scilab-Dev] Fwd: Contributing to SciLab In-Reply-To: References: Message-ID: Hi, I would like to introduce myself. On this moment iI have some spare time to commit to SciLAB. I used it extensively and was very pleased when version 6.0 arrived. However, this version has some very annoying bugs. Especially in xcos. One option is to complain about this. But I prefer to try and fix some of these bugs. I would like to work a little on xcos. I already reported a bug on bugzilla, but until now did not see any response to that. This is a simple bug in which creating levels of hierarchy will lead to a crash. This only happens by three or more levels. I reported it and made a patch for it. http://bugzilla.scilab.org/show_bug.cgi?id=15156 Due to the nature of this bug it is hard to write a test for it. I will have a look into generating xcos diagrams from within a scripts. Hopefully I will find a way to make a scripts that provokes the error. Further I tried to build the newest version (git master). But there are many problems with the modules scirendrerer and gui. The reason for this is that in jogl2 version 2.3.2 the name space javax.media was replaced with com.jogamp. After some searching and reading I noticed that most distributions fix this problem by patching the necessary java files. Therefor I would like to start a discussion to port this patch into the repository of Scilab. I know this is not my place, but I think it is necessary to speak about this. It is very interesting to look at the really well structured and build code of Scilab. It is a joy to work with and look at. I hope that I can make some contributions to the source and improve the overall user experience. Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From badshah400 at gmail.com Thu Feb 22 18:57:45 2018 From: badshah400 at gmail.com (Atri Bhattacharya) Date: Thu, 22 Feb 2018 18:57:45 +0100 Subject: [Scilab-Dev] Scilab GUI and adv-cli fail to launch with java 9 In-Reply-To: <1519303153.18295.7.camel@gmail.com> References: <1519215570.4587.14.camel@gmail.com> <1519226754.2211.18.camel@esi-group.com> <1519303153.18295.7.camel@gmail.com> Message-ID: Apparently the problem is this (from JDK 9 Release Notes[1]): The application class loader is no longer an instance of > java.net.URLClassLoader (an implementation detail that was never > specified in previous releases). Code that assumes that > ClassLoader::getSytemClassLoader returns a URLClassLoader object will > need to be updated. Note that Java SE and the JDK do not provide an API for > applications or libraries to dynamically augment the class path at run-time. Consequently, the functions and in `modules/jvm/src/java/org/scilab/modules/jvm/ClassPath.java` fail because of the casting of ClassLoader to URLClassLoader. None of the class paths actually gets passed to the main code, and all hell ensues. I could get around this by manually passing paths to all the necessary *.jar files to _JAVA_OPTIONS. There is likely a better way, but so far it beats me. Cheers. [1] http://www.oracle.com/technetwork/java/javase/9-relnote-issues-3704069.html On 22 February 2018 at 13:39, Atri Bhattacharya wrote: > Dear Cl?ment, > > On Wed, 2018-02-21 at 15:25 +0000, Cl?ment David wrote: > > Hello Atri, > > > > Thanks for your work on porting Scilab to jdk9 ; > > You are welcome. It's mostly based on self-interest: I use scilab > regularly (mostly on the command line though) on openSUSE Tumbleweed. > > > this NoClassDefFoundError usually comes from a mis- > > compilation check the jar content and be sure to load it correctly. > > I think the jar content looks ok. I think it's some incompatibility > between jdk 8 and 9 that prevents the classpath from being correctly > used. The same binary works with jdk 8 (even though it is compiled > against jdk 9) once the jre paths in the scilab script are > appropriately adapted; but it doesn't with jdk 9. > > > About the patches, I just > > started to review them and will push them on the 6.0 branch after > > fixing the build on my machine; > > Many thanks. It will be great if these patches are upstreamed; it would > certainly reduce my work (I maintain Scilab packages for openSUSE) > during version upgrades. > > Best wishes. > > > > Le mercredi 21 f?vrier 2018 ? 13:19 +0100, Atri Bhattacharya a ?crit > > : > > > Hi, > > > After several patches to fix building against java 9, I have been > > > finally able to get scilab 6.0.1 building on openSUSE Tumbleweed. > > > However, during run time, I now see a ClassNotFoundError, as > > > follows: > > > -------------------- > > > :~> SCIVERBOSE=1 scilab > > > SCILABBIN : scilab-bin > > > DISABLE_JAVA_DETECTION : 0 > > > SCILAB_MODE : gui > > > OS : Linux > > > MODEL : x86_64 > > > IS_SCILAB_BINARY : 0 > > > Using specified vm: /usr/lib64/jvm/java > > > JAVA_HOME : /usr/lib64/jvm/java > > > SCI : /usr/share/scilab/ > > > SCIBIN : /usr/bin/scilab-bin > > > PATH : > > > /usr/share/scilab/:/usr/share/scilab//bin:/usr/bin:/home/badshah400 > > > /bin > > > :/usr/local/bin:/usr/bin:/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin > > > CLASSPATH : > > > /usr/share/scilab//modules/core/jar/org.scilab.modules.core.jar > > > EGL_DRIVER : > > > LD_LIBRARY_PATH : > > > /usr/lib64/jvm/java/lib/:/usr/lib64/jvm/java/lib/server/:/usr/lib64 > > > /jvm > > > /java/lib/native_threads/ > > > DOCBOOK : /usr/share/xml/docbook/stylesheet/nwalsh/current/ > > > WARNING: An illegal reflective access operation has occurred > > > WARNING: Illegal reflective access by > > > org.scilab.modules.jvm.LibraryPath > > > (file:/usr/share/scilab/modules/jvm/jar/org.scilab.modules.jvm.jar) > > > to > > > field java.lang.ClassLoader.sys_paths > > > WARNING: Please consider reporting this to the maintainers of > > > org.scilab.modules.jvm.LibraryPath > > > WARNING: Use --illegal-access=warn to enable warnings of further > > > illegal reflective access operations > > > WARNING: All illegal access operations will be denied in a future > > > release > > > Could not access to the Main Scilab Class: > > > Exception in thread "main" java.lang.NoClassDefFoundError: > > > org/scilab/modules/core/Scilab > > > Caused by: java.lang.ClassNotFoundException: > > > org.scilab.modules.core.Scilab > > > at > > > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinC > > > lass > > > Loader.java:582) > > > at > > > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass > > > (Cla > > > ssLoaders.java:185) > > > at > > > java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496) > > > > > > Scilab cannot create Scilab Java Main-Class (we have not been able > > > to > > > find the main Scilab class. Check if the Scilab and thirdparty > > > packages > > > are available). > > > -------------- > > > > > > All patches are available at [1], and also documented on > > > http://bugzilla.scilab.org/show_bug.cgi?id=15328 > > > where unfortunately, I have not seen the needle move much over the > > > recent days. > > > > > > Scilab does work with java 1.8.0 (have to adapt the JRE paths > > > appropriately in bin/scilab); however, as soon as java 9 is used > > > the > > > above error is manifested. If someone can help fix this issue, that > > > will be very helpful. > > > > > > openSUSE uses Java 9 by default now, which means as of now scilab > > > is > > > badly broken -- only scilab-cli works -- on openSUSE Tumbleweed and > > > soon to be released Leap 15.0. Unless Scilab's compatibility issues > > > are > > > fixed, we will have to drop it from the distro unfortunately. > > > > > > Thanks and best wishes. > > > > > > [1] https://build.opensuse.org/package/show/home:badshah400:branche > > > s:science/scilab > > > > > > > _______________________________________________ > > dev mailing list > > dev at lists.scilab.org > > http://lists.scilab.org/mailman/listinfo/dev > -- > Atri Bhattacharya > Thu 22 Feb 12:28:07 CET 2018 > > Sent from openSUSE Tumbleweed on my laptop. > -- Atri -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Fri Feb 23 18:17:06 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Fri, 23 Feb 2018 18:17:06 +0100 Subject: [Scilab-Dev] Scifunction equivalent in Scilab 6 API ? Message-ID: <253620fd-06d1-727e-d096-6804287fa92b@utc.fr> Hello, Currently trying to port a Scilab interface to Scilab 6 standards, I did try to find the equivalent of the deprecated Scifunction ? What is the new function and where is documented ? Thanks in advance S. -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet From johanwesselink23 at gmail.com Fri Feb 23 18:29:22 2018 From: johanwesselink23 at gmail.com (Johan Wesselink) Date: Fri, 23 Feb 2018 14:29:22 -0300 Subject: [Scilab-Dev] Scifunction equivalent in Scilab 6 API ? In-Reply-To: <253620fd-06d1-727e-d096-6804287fa92b@utc.fr> References: <253620fd-06d1-727e-d096-6804287fa92b@utc.fr> Message-ID: Hi, Check the older version from Scilab 5.5.2 The example in the documentation can be found at: https://help.scilab.org/docs/5.5.2/en_US/api_scilab_getting_started.html For the new version Scilab 6.0.1 The same example, but adapted for the new API can be found at https://help.scilab.org/docs/6.0.1/en_US/api_scilab_getting_started.html It looks to me that they are quiet different. The 6.0 API is more closely to the matlab interface mex-file. (If I remember it correctly, was some years ago I used matlab) Also you needs less code to realize the same interface. Overall for me it looks a lot cleaner. But that's just my impression. What I understood from it is, that you can also use the old interface. Many old function such as plot still use this style API. Happy coding. 2018-02-23 14:17 GMT-03:00 St?phane Mottelet : > Hello, > > Currently trying to port a Scilab interface to Scilab 6 standards, I did > try to find the equivalent of the deprecated Scifunction ? What is the new > function and where is documented ? > > Thanks in advance > > S. > > -- > St?phane Mottelet > Ing?nieur de recherche > EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable > D?partement G?nie des Proc?d?s Industriels > Sorbonne Universit?s - Universit? de Technologie de Compi?gne > CS 60319, 60203 Compi?gne cedex > Tel : +33(0)344234688 > http://www.utc.fr/~mottelet > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johanwesselink23 at gmail.com Fri Feb 23 20:04:25 2018 From: johanwesselink23 at gmail.com (Johan Wesselink) Date: Fri, 23 Feb 2018 16:04:25 -0300 Subject: [Scilab-Dev] Contributing to SciLab In-Reply-To: References: Message-ID: I actually closed the bug. It is resolved in version 6.0.0 and higher. However, for a long time a broken version of scilab was distributed that had a non working xcos. At least working with hierarchy wasn't possible. I still think that mixing the new jogl2 namespace functionality upstream is a good idea. 2018-02-22 10:39 GMT-03:00 Johan Wesselink : > > Hi, > > I would like to introduce myself. > > On this moment iI have some spare time to commit to SciLAB. > > I used it extensively and was very pleased when version 6.0 arrived. > However, this version has some very annoying bugs. Especially in xcos. > One option is to complain about this. But I prefer to try and fix some of > these bugs. > > I would like to work a little on xcos. I already reported a bug on > bugzilla, but > until now did not see any response to that. This is a simple bug in which > creating levels of hierarchy will lead to a crash. This only happens by > three or more levels. > I reported it and made a patch for it. > http://bugzilla.scilab.org/show_bug.cgi?id=15156 > Due to the nature of this bug it is hard to write a test for it. I will > have a look into generating xcos diagrams from within a scripts. Hopefully > I will find a way to make a scripts that provokes the error. > > Further I tried to build the newest version (git master). But there are > many problems with the modules scirendrerer and gui. The reason for this is > that in jogl2 version 2.3.2 the name space javax.media was replaced with > com.jogamp. After some searching and reading I noticed that most > distributions fix this problem by patching the necessary java files. > Therefor I would like to start a discussion to port this patch into the > repository of Scilab. I know this is not my place, but I think it is > necessary to speak about this. > > It is very interesting to look at the really well structured and build > code of Scilab. It is a joy to work with and look at. > > I hope that I can make some contributions to the source and improve the > overall user experience. > > Johan > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From badshah400 at gmail.com Sat Feb 24 00:09:39 2018 From: badshah400 at gmail.com (badshah400 at gmail.com) Date: Sat, 24 Feb 2018 00:09:39 +0100 Subject: [Scilab-Dev] Scilab GUI and adv-cli fail to launch with java 9 In-Reply-To: References: <1519215570.4587.14.camel@gmail.com> <1519226754.2211.18.camel@esi-group.com> <1519303153.18295.7.camel@gmail.com> Message-ID: <1519427379.18595.20.camel@gmail.com> Update: I managed to get scilab 6.0.1 working full and proper with java 9, albeit by making use of rather hackish means. Here is what I did: 1. Neutered the addURL and getClassPath functions (modules/jvm/src/java/org/scilab/modules/jvm/ClassPath.java) so that they don't throw typecasting exceptions during conversion from ClassLoader to URLClassLoader. A java expert (i.e. the opposite of me) may be able to adapt these functions properly so that on-demand loading of jars still works, thus nullifying the need for point 3 below. 2. Add jaf to etc/classpath.xml[.in] as the java.se.ee version of java.activation module is obsoleted. Since it is still needed for the xmlto* functions used during building the documentation, one adds an external jaf implementation (e.g. geronimo, gnu, etc.) to the required jars. I have implemented this completely in the autotools way, so configure checks for it like all other required jars and so on. 3. This is the ugly hack: I read all the jar classpaths in etc/classpath.xml and pass them all via the -Djava.class.path argument to the env variable _JAVA_OPTIONS. I also pass the appropriate library paths from etc/librarypath.xml to _JAVA_OPTIONS by using -Djava.library.path. The corresponding env variable _JAVA_OPTIONS is set in the bin/scilab script. Classpaths to all mandatorily and on-demand required jars are consequently loaded right during scilab startup, and scilab thereafter works perfectly (so far, from my tests). In case frontloading all classpaths in this manner is acceptable going forwards, I can obviously adapt my implementation of point 3 in an autotools way, by running automake over bin/scilab.in to generate bin/scilab. For now, I simply hack the bin/scilab script by using some sed tricks after running make in the spec file. The appropriate patch is [1], and the spec file is [2]. I would be really grateful for any comments, reviews, and suggestions. Cheerio. [1] https://build.opensuse.org/package/view_file/home:badshah400:branches:science/scilab/scilab-java9-ClassLoader.patch?expand=1 [2] https://build.opensuse.org/package/view_file/home:badshah400:branches:science/scilab/scilab.spec?expand=1 On Thu, 2018-02-22 at 18:57 +0100, Atri Bhattacharya wrote: > Apparently the problem is this (from JDK 9 Release Notes[1]): > > > The application class loader is no longer an instance of > > java.net.URLClassLoader (an implementation detail that was never > > specified in previous releases). Code that assumes that > > ClassLoader::getSytemClassLoader returns a URLClassLoader object > > will need to be updated. Note that Java SE and the JDK do not > > provide an API for applications or libraries to dynamically augment > > the class path at run-time. > > Consequently, the functions and in > `modules/jvm/src/java/org/scilab/modules/jvm/ClassPath.java` fail > because of the casting of ClassLoader to URLClassLoader. None of the > class paths actually gets passed to the main code, and all hell > ensues. I could get around this by manually passing paths to all the > necessary *.jar files to _JAVA_OPTIONS. There is likely a better way, > but so far it beats me. > > Cheers. > > [1] http://www.oracle.com/technetwork/java/javase/9-relnote-issues-37 > 04069.html > > > On 22 February 2018 at 13:39, Atri Bhattacharya > wrote: > > Dear Cl?ment, > > > > On Wed, 2018-02-21 at 15:25 +0000, Cl?ment David wrote: > > > Hello Atri, > > > > > > Thanks for your work on porting Scilab to jdk9 ; > > > > You are welcome. It's mostly based on self-interest: I use scilab > > regularly (mostly on the command line though) on openSUSE > > Tumbleweed. > > > > > this NoClassDefFoundError usually comes from a mis- > > > compilation check the jar content and be sure to load it > > correctly. > > > > I think the jar content looks ok. I think it's some incompatibility > > between jdk 8 and 9 that prevents the classpath from being > > correctly > > used. The same binary works with jdk 8 (even though it is compiled > > against jdk 9) once the jre paths in the scilab script are > > appropriately adapted; but it doesn't with jdk 9. > > > > > About the patches, I just > > > started to review them and will push them on the 6.0 branch after > > > fixing the build on my machine; > > > > Many thanks. It will be great if these patches are upstreamed; it > > would > > certainly reduce my work (I maintain Scilab packages for openSUSE) > > during version upgrades. > > > > Best wishes. > > > > > > > Le mercredi 21 f?vrier 2018 ? 13:19 +0100, Atri Bhattacharya a > > ?crit > > > : > > > > Hi, > > > > After several patches to fix building against java 9, I have > > been > > > > finally able to get scilab 6.0.1 building on openSUSE > > Tumbleweed. > > > > However, during run time, I now see a ClassNotFoundError, as > > > > follows: > > > > -------------------- > > > > :~> SCIVERBOSE=1 scilab > > > > SCILABBIN : scilab-bin > > > > DISABLE_JAVA_DETECTION : 0 > > > > SCILAB_MODE : gui > > > > OS : Linux > > > > MODEL : x86_64 > > > > IS_SCILAB_BINARY : 0 > > > > Using specified vm: /usr/lib64/jvm/java > > > > JAVA_HOME : /usr/lib64/jvm/java > > > > SCI : /usr/share/scilab/ > > > > SCIBIN : /usr/bin/scilab-bin > > > > PATH : > > > > > > /usr/share/scilab/:/usr/share/scilab//bin:/usr/bin:/home/badshah400 > > > > /bin > > > > > > :/usr/local/bin:/usr/bin:/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin > > > > CLASSPATH : > > > > /usr/share/scilab//modules/core/jar/org.scilab.modules.core.jar > > > > EGL_DRIVER : > > > > LD_LIBRARY_PATH : > > > > > > /usr/lib64/jvm/java/lib/:/usr/lib64/jvm/java/lib/server/:/usr/lib64 > > > > /jvm > > > > /java/lib/native_threads/ > > > > DOCBOOK : /usr/share/xml/docbook/stylesheet/nwalsh/current/ > > > > WARNING: An illegal reflective access operation has occurred > > > > WARNING: Illegal reflective access by > > > > org.scilab.modules.jvm.LibraryPath > > > > > > (file:/usr/share/scilab/modules/jvm/jar/org.scilab.modules.jvm.jar) > > > > to > > > > field java.lang.ClassLoader.sys_paths > > > > WARNING: Please consider reporting this to the maintainers of > > > > org.scilab.modules.jvm.LibraryPath > > > > WARNING: Use --illegal-access=warn to enable warnings of > > further > > > > illegal reflective access operations > > > > WARNING: All illegal access operations will be denied in a > > future > > > > release > > > > Could not access to the Main Scilab Class: > > > > Exception in thread "main" java.lang.NoClassDefFoundError: > > > > org/scilab/modules/core/Scilab > > > > Caused by: java.lang.ClassNotFoundException: > > > > org.scilab.modules.core.Scilab > > > > at > > > > > > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinC > > > > lass > > > > Loader.java:582) > > > > at > > > > > > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass > > > > (Cla > > > > ssLoaders.java:185) > > > > at > > > > java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496) > > > > > > > > Scilab cannot create Scilab Java Main-Class (we have not been > > able > > > > to > > > > find the main Scilab class. Check if the Scilab and thirdparty > > > > packages > > > > are available). > > > > -------------- > > > > > > > > All patches are available at [1], and also documented on > > > > http://bugzilla.scilab.org/show_bug.cgi?id=15328 > > > > where unfortunately, I have not seen the needle move much over > > the > > > > recent days. > > > > > > > > Scilab does work with java 1.8.0 (have to adapt the JRE paths > > > > appropriately in bin/scilab); however, as soon as java 9 is > > used > > > > the > > > > above error is manifested. If someone can help fix this issue, > > that > > > > will be very helpful. > > > > > > > > openSUSE uses Java 9 by default now, which means as of now > > scilab > > > > is > > > > badly broken -- only scilab-cli works -- on openSUSE Tumbleweed > > and > > > > soon to be released Leap 15.0. Unless Scilab's compatibility > > issues > > > > are > > > > fixed, we will have to drop it from the distro unfortunately. > > > > > > > > Thanks and best wishes. > > > > > > > > [1] https://build.opensuse.org/package/show/home:badshah400:bra > > nche > > > > s:science/scilab > > > > > > > > > > _______________________________________________ > > > dev mailing list > > > dev at lists.scilab.org > > > http://lists.scilab.org/mailman/listinfo/dev > > -- > > Atri Bhattacharya > > Thu 22 Feb 12:28:07 CET 2018 > > > > Sent from openSUSE Tumbleweed on my laptop. > > > From Clement.David at esi-group.com Mon Feb 26 12:36:33 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Mon, 26 Feb 2018 11:36:33 +0000 Subject: [Scilab-Dev] BLAS use in Scilab In-Reply-To: <6d82edc6-3a68-f7e3-d5b1-755db10ebac9@utc.fr> References: <1518615338745-0.post@n3.nabble.com> <46fbee01-dbcf-104b-aa1f-d9c6d2bd32b1@utc.fr> <1518631624856-0.post@n3.nabble.com> <20180214181500.Horde.6noFgwETGwdsbK9FITULam6@webmail.utc.fr> <20180214200352.Horde.lsHYFRpjelt8p_GJ1NTzzuQ@webmail.utc.fr> <1518648613976-0.post@n3.nabble.com> <1518649368521-0.post@n3.nabble.com> <293ab011-7dba-c3a1-6b7c-b9815a339555@utc.fr> <3daebae7-eba4-a32c-5e1e-c403ece6f5fa@scilab-enterprises.com> <1553ecbc-2120-9236-3e8e-b32eb09811e4@utc.fr> <6d82edc6-3a68-f7e3-d5b1-755db10ebac9@utc.fr> Message-ID: <1519644991.2211.54.camel@esi-group.com> Hello St?phane, AFAIK, as in the old interface the new C++ one allow you to get pointers to the raw double* values and so allow you to write anything to the inputs. However this kind of behavior is considered a bug as from the user point of view (eg. Scilab beginners) each assignation is supposed to have inputs (unmodified data) and outputs (computed data). Note: about the += operator, this is indeed a way to tell the user that the argument is modified in place with a specific + operation. Thanks, -- Cl?ment Le jeudi 22 f?vrier 2018 ? 14:18 +0100, St?phane Mottelet a ?crit : > Really, nobody knows ? > > S. > > Le 20/02/2018 ? 11:57, St?phane Mottelet a ?crit : > > Hello, > > > > Continuing on this subject, Hello, I discovered that the new Scilab API allows to modify input > > parameters of a function (in-place assignment), e.g. I have modified the previous daxpy such > > that the expression > > > > daxpy(2,X,Y) > > > > has no output but formally does "Y+=2*X" if such an operator would exist in Scilab. In this case > > there is no matrix copy at all, hence no memory overhead. > > > > Was it possible to do this with the previous API ? > > > > S. > > > > Le 19/02/2018 ? 19:15, St?phane Mottelet a ?crit : > > > Hello, > > > > > > After some tests, for the intended use (multiply a matrix by a scalar), dgemm is not faster > > > that dscal, but in the C code of "iMultiRealScalarByRealMatrix", the part which takes the most > > > of the CPU time is the call to "dcopy". For example, on my machine, for a 10000x10000 matrix, > > > the call to dcopy takes 540 milliseconds and the call to dscal 193 milliseconds. Continuing my > > > explorations today, I tried to see how Scilab expressions such as > > > > > > Y+2*X > > > > > > are parsed and executed. To this purpose I have written an interface (daxpy.sci and daxpy.c > > > attached) to the BLAS function "daxpy" which does "y<-y+a*x" and a script comparing the above > > > expression to > > > > > > daxpy(2,X,Y) > > > > > > for two 10000x10000 matrices. Here are the results (MacBook air core i7 at 1,7GHz): > > > > > > daxpy(2,X,Y) > > > (dcopy: 582 ms) > > > (daxpy: 211 ms) > > > > > > elapsed time: 793 ms > > > > > > Y+2*X > > > > > > elapsed time: 1574 ms > > > > > > Considered the above value, the explanation is that in "Y+2*X" there are *two* copies of a > > > 10000x10000 matrix instead of only one in "daxpy(2,X,Y)". In "Y+2*X+3*Z" there will be three > > > copies, although there could be only one if daxpy was used twice. > > > > > > I am not blaming Scilab here, I am just blaming "vectorization", which can be inefficient when > > > large objects are used. That's why explicits loops can sometimes be faster than > > > vectorized operations in Matlab or Julia (which both use JIT compilation). > > > > > > S. > > > > > > > > > Le 15/02/2018 ? 17:11, Antoine ELIAS a ?crit : > > > > Hello St?phane, > > > > > > > > Interesting ... > > > > > > > > In release, we don't ship the header of BLAS/LAPACK functions. > > > > But you can define them in your C file as extern. ( and let the linker do his job ) > > > > > > > > extern int C2F(dgemm) (char *_pstTransA, char *_pstTransB, int *_piN, int *_piM, int *_piK, > > > > double *_pdblAlpha, double *_pdblA, int *_piLdA, > > > > double *_pdblB, int *_piLdB, double *_pdblBeta, double *_pdblC, int > > > > *_piLdC); > > > > and > > > > > > > > extern int C2F(dscal) (int *_iSize, double *_pdblVal, double *_pdblDest, int *_iInc); > > > > > > > > Others BLAS/LAPACK prototypes can be found at http://cgit.scilab.org/scilab/tree/scilab/modu > > > > les/elementary_functions/includes/elem_common.h?h=6.0 > > > > > > > > Regards, > > > > Antoine > > > > Le 15/02/2018 ? 16:50, St?phane Mottelet a ?crit : > > > > > Hello all, > > > > > > > > > > Following the recent discussion with fujimoto, I discovered that Scilab does not (seem to) > > > > > fully use SIMD operation in BLAS as it should. Besides the bottlenecks of its code, there > > > > > are also many operations of the kind > > > > > > > > > > scalar*matrix > > > > > > > > > > Althoug this operation is correctly delegated to the DSCAL BLAS function (can be seen in C > > > > > function iMultiRealMatrixByRealMatrix in > > > > > modules/ast/src/c/operations/matrix_multiplication.c) : > > > > > > > > > > > int iMultiRealScalarByRealMatrix( > > > > > > double _dblReal1, > > > > > > double *_pdblReal2, int _iRows2, int _iCols2, > > > > > > double *_pdblRealOut) > > > > > > { > > > > > > int iOne = 1; > > > > > > int iSize2 = _iRows2 * _iCols2; > > > > > > > > > > > > C2F(dcopy)(&iSize2, _pdblReal2, &iOne, _pdblRealOut, &iOne); > > > > > > C2F(dscal)(&iSize2, &_dblReal1, _pdblRealOut, &iOne); > > > > > > return 0; > > > > > > } > > > > > in the code below the product "A*1" is likely using only one processor core, as seen on > > > > > the cpu usage graph and on the elapsed time, > > > > > > > > > > A=rand(20000,20000); > > > > > tic; for i=1:10; A*1; end; toc > > > > > > > > > > ans = > > > > > > > > > > 25.596843 > > > > > > > > > > but this second piece of code is more than 8 times faster and uses 100% of the cpu, > > > > > > > > > > ONE=ones(20000,1); > > > > > tic; for i=1:10; A*ONE; end; toc > > > > > > > > > > ans = > > > > > > > > > > 2.938314 > > > > > > > > > > with roughly the same number of multiplications. This second computation is delegated to > > > > > DGEMM (C<-alpha*A*B + beta*C, here with alpha=1 and beta=0) > > > > > > > > > > > int iMultiRealMatrixByRealMatrix( > > > > > > double *_pdblReal1, int _iRows1, int _iCols1, > > > > > > double *_pdblReal2, int _iRows2, int _iCols2, > > > > > > double *_pdblRealOut) > > > > > > { > > > > > > double dblOne = 1; > > > > > > double dblZero = 0; > > > > > > > > > > > > C2F(dgemm)("n", "n", &_iRows1, &_iCols2, &_iCols1, &dblOne, > > > > > > _pdblReal1 , &_iRows1 , > > > > > > _pdblReal2, &_iRows2, &dblZero, > > > > > > _pdblRealOut , &_iRows1); > > > > > > return 0; > > > > > > } > > > > > Maybe my intuition is wrong, but I have the feeling that using dgemm with alpha=0 will be > > > > > faster than dscal. I plan to test this by making a quick and dirty code linked to Scilab > > > > > so my question to devs is : which are the #includes to add on top of the source (C) to be > > > > > able to call dgemm and dscal ? > > > > > > > > > > Thanks for your help > > > > > > > > > > S. > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > dev mailing list > > > > dev at lists.scilab.org > > > > http://lists.scilab.org/mailman/listinfo/dev > > > > > > > > > > > > _______________________________________________ > > > dev mailing list > > > dev at lists.scilab.org > > > http://lists.scilab.org/mailman/listinfo/dev > > > > -- > > St?phane Mottelet > > Ing?nieur de recherche > > EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable > > D?partement G?nie des Proc?d?s Industriels > > Sorbonne Universit?s - Universit? de Technologie de Compi?gne > > CS 60319, 60203 Compi?gne cedex > > Tel : +33(0)344234688 > > http://www.utc.fr/~mottelet > > > > > > _______________________________________________ > > dev mailing list > > dev at lists.scilab.org > > http://lists.scilab.org/mailman/listinfo/dev > > -- > St?phane Mottelet > Ing?nieur de recherche > EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable > D?partement G?nie des Proc?d?s Industriels > Sorbonne Universit?s - Universit? de Technologie de Compi?gne > CS 60319, 60203 Compi?gne cedex > Tel : +33(0)344234688 > http://www.utc.fr/~mottelet > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From stephane.mottelet at utc.fr Mon Feb 26 13:48:18 2018 From: stephane.mottelet at utc.fr (stephane.mottelet at utc.fr) Date: Mon, 26 Feb 2018 12:48:18 +0000 Subject: [Scilab-Dev] BLAS use in Scilab In-Reply-To: <1519644991.2211.54.camel@esi-group.com> References: <1518615338745-0.post@n3.nabble.com> <46fbee01-dbcf-104b-aa1f-d9c6d2bd32b1@utc.fr> <1518631624856-0.post@n3.nabble.com> <20180214181500.Horde.6noFgwETGwdsbK9FITULam6@webmail.utc.fr> <20180214200352.Horde.lsHYFRpjelt8p_GJ1NTzzuQ@webmail.utc.fr> <1518648613976-0.post@n3.nabble.com> <1518649368521-0.post@n3.nabble.com> <293ab011-7dba-c3a1-6b7c-b9815a339555@utc.fr> <3daebae7-eba4-a32c-5e1e-c403ece6f5fa@scilab-enterprises.com> <1553ecbc-2120-9236-3e8e-b32eb09811e4@utc.fr> <6d82edc6-3a68-f7e3-d5b1-755db10ebac9@utc.fr> <1519644991.2211.54.camel@esi-group.com> Message-ID: <20180226124818.Horde.Mpa4z6OJhq2u5P6XAe-m3nw@webmail.utc.fr> Hello, Thank you for your answer. Would it have an interest to implement such an operator (and, as a consequence, open a kind of Pandora's box..) ? S. Quoting Cl?ment David : > Hello St?phane, > > AFAIK, as in the old interface the new C++ one allow you to get > pointers to the raw double* values > and so allow you to write anything to the inputs. However this kind > of behavior is considered a bug > as from the user point of view (eg. Scilab beginners) each > assignation is supposed to have inputs > (unmodified data) and outputs (computed data). > > Note: about the += operator, this is indeed a way to tell the user > that the argument is modified in > place with a specific + operation. > > Thanks, > > -- > Cl?ment > > Le jeudi 22 f?vrier 2018 ? 14:18 +0100, St?phane Mottelet a ?crit : >> Really, nobody knows ? >> >> S. >> >> Le 20/02/2018 ? 11:57, St?phane Mottelet a ?crit : >> Hello, >> >> Continuing on this subject, Hello, I discovered that the new Scilab >> API allows to modify input >> parameters of a function (in-place assignment), e.g. I have >> modified the previous daxpy such >> that the expression >> >> daxpy(2,X,Y) >> >> has no output but formally does "Y+=2*X" if such an operator would >> exist in Scilab. In this case >> there is no matrix copy at all, hence no memory overhead. >> >> Was it possible to do this with the previous API ? >> >> S. >> >> Le 19/02/2018 ? 19:15, St?phane Mottelet a ?crit : >>> Hello, >>> >>> After some tests, for the intended use (multiply a matrix by a >>> scalar), dgemm is not faster >>> that dscal, but in the C code of "iMultiRealScalarByRealMatrix", >>> the part which takes the most >>> of the CPU time is the call to "dcopy". For example, on my >>> machine,? for a 10000x10000 matrix, >>> the call to dcopy takes 540 milliseconds and the call to dscal 193 >>> milliseconds. Continuing my >>> explorations today, I tried to see how Scilab expressions such as >>> >>> Y+2*X >>> >>> are parsed and executed. To this purpose I have written an >>> interface (daxpy.sci and daxpy.c >>> attached) to the BLAS function "daxpy" which does "y<-y+a*x" and a >>> script comparing the above >>> expression to >>> >>> daxpy(2,X,Y) >>> >>> for two 10000x10000 matrices. Here are the results (MacBook air >>> core i7 at 1,7GHz): >>> >>> ? daxpy(2,X,Y) >>> ? (dcopy: 582 ms) >>> ? (daxpy: 211 ms) >>> >>> ? elapsed time: 793 ms >>> >>> ? Y+2*X >>> >>> ? elapsed time: 1574 ms >>> >>> Considered the above value, the explanation is that in "Y+2*X" >>> there are *two* copies of a >>> 10000x10000 matrix instead of only one in "daxpy(2,X,Y)". In >>> "Y+2*X+3*Z" there will be three >>> copies, although there could be only one if daxpy was used twice. >>> >>> I am not blaming Scilab here, I am just blaming "vectorization", >>> which can be inefficient when >>> large objects? ? ? ? ? ?are used. That's why explicits loops can >>> sometimes be faster than >>> vectorized operations in Matlab or Julia (which both use JIT compilation). >>> >>> S. >>> >>> >>> Le 15/02/2018 ? 17:11, Antoine ELIAS a ?crit : >>> > Hello St?phane, >>> > >>> > Interesting ... >>> > >>> > In release, we don't ship the header of BLAS/LAPACK functions. >>> > But you can define them in your C file as extern. ( and let the >>> linker do his job ) >>> > >>> > extern int C2F(dgemm) (char *_pstTransA, char *_pstTransB, int >>> *_piN, int *_piM, int *_piK, >>> > double *_pdblAlpha, double *_pdblA, int *_piLdA, >>> >? ? ? ? ? ? ? ? ? ? ? ? double *_pdblB, int *_piLdB, double >>> *_pdblBeta, double *_pdblC, int >>> > *_piLdC); >>> > and >>> > >>> > extern int C2F(dscal) (int *_iSize, double *_pdblVal, double >>> *_pdblDest, int *_iInc); >>> > >>> > Others BLAS/LAPACK prototypes can be found at >>> http://cgit.scilab.org/scilab/tree/scilab/modu >>> > les/elementary_functions/includes/elem_common.h?h=6.0 >>> > >>> > Regards, >>> > Antoine >>> > Le 15/02/2018 ? 16:50, St?phane Mottelet a ?crit : >>> > > Hello all, >>> > > >>> > > Following the recent discussion with fujimoto, I discovered >>> that Scilab does not (seem to) >>> > > fully use SIMD operation in? BLAS as it should. Besides the >>> bottlenecks of its code, there >>> > > are also many operations of the kind >>> > > >>> > > scalar*matrix >>> > > >>> > > Althoug this operation is correctly delegated to the DSCAL >>> BLAS function (can be seen in C >>> > > function iMultiRealMatrixByRealMatrix in >>> > > modules/ast/src/c/operations/matrix_multiplication.c) : >>> > > >>> > > > int iMultiRealScalarByRealMatrix( >>> > > >? ? ?double _dblReal1, >>> > > >? ? ?double *_pdblReal2,? ? int _iRows2, int _iCols2, >>> > > >? ? ?double *_pdblRealOut) >>> > > > { >>> > > >? ? ?int iOne? ? = 1; >>> > > >? ? ?int iSize2? ? = _iRows2 * _iCols2; >>> > > > >>> > > >? ? ?C2F(dcopy)(&iSize2, _pdblReal2, &iOne, _pdblRealOut, &iOne); >>> > > >? ? ?C2F(dscal)(&iSize2, &_dblReal1, _pdblRealOut, &iOne); >>> > > >? ? ?return 0; >>> > > > } >>> > >? in the code below the product "A*1" is likely using only one >>> processor core, as seen on >>> > > the cpu usage graph and on the elapsed time, >>> > > >>> > > A=rand(20000,20000); >>> > > tic; for i=1:10; A*1; end; toc >>> > > >>> > >? ans? = >>> > > >>> > >? ? 25.596843 >>> > > >>> > > but this second piece of code is more than 8 times faster and >>> uses 100% of the cpu, >>> > > >>> > > ONE=ones(20000,1); >>> > > tic; for i=1:10; A*ONE; end; toc >>> > > >>> > >? ans? = >>> > > >>> > >? ? 2.938314 >>> > > >>> > > with roughly the same number of multiplications. This second >>> computation is delegated to >>> > > DGEMM (C<-alpha*A*B + beta*C, here with alpha=1 and beta=0) >>> > > >>> > > > int iMultiRealMatrixByRealMatrix( >>> > > >? ? ?double *_pdblReal1,? ? int _iRows1, int _iCols1, >>> > > >? ? ?double *_pdblReal2,? ? int _iRows2, int _iCols2, >>> > > >? ? ?double *_pdblRealOut) >>> > > > { >>> > > >? ? ?double dblOne? ? ? ? = 1; >>> > > >? ? ?double dblZero? ? ? ? = 0; >>> > > > >>> > > >? ? ?C2F(dgemm)("n", "n", &_iRows1, &_iCols2, &_iCols1, &dblOne, >>> > > >? ? ? ? ? ? ? ? _pdblReal1 , &_iRows1 , >>> > > >? ? ? ? ? ? ? ? _pdblReal2, &_iRows2, &dblZero, >>> > > >? ? ? ? ? ? ? ? _pdblRealOut , &_iRows1); >>> > > >? ? ?return 0; >>> > > > } >>> > >? Maybe my intuition is wrong, but I have the feeling that >>> using dgemm with alpha=0 will be >>> > > faster than dscal. I plan to test this by making a quick and >>> dirty code linked to Scilab >>> > > so my question to devs is : which are the #includes to add on >>> top of the source (C) to be >>> > > able to call dgemm and dscal ? >>> > > >>> > > Thanks for your help >>> > > >>> > > S. >>> > > >>> > > >>> > >>> > _______________________________________________ >>> > dev mailing list >>> > dev at lists.scilab.org >>> > http://lists.scilab.org/mailman/listinfo/dev >>> >>> >>> >>> _______________________________________________ >>> dev mailing list >>> dev at lists.scilab.org >>> http://lists.scilab.org/mailman/listinfo/dev >> >> -- >> St?phane Mottelet >> Ing?nieur de recherche >> EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable >> D?partement G?nie des Proc?d?s Industriels >> Sorbonne Universit?s - Universit? de Technologie de Compi?gne >> CS 60319, 60203 Compi?gne cedex >> Tel : +33(0)344234688 >> http://www.utc.fr/~mottelet >> >> _______________________________________________ >> dev mailing list >> dev at lists.scilab.org >> http://lists.scilab.org/mailman/listinfo/dev >> >> -- >> St?phane Mottelet >> Ing?nieur de recherche >> EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable >> D?partement G?nie des Proc?d?s Industriels >> Sorbonne Universit?s - Universit? de Technologie de Compi?gne >> CS 60319, 60203 Compi?gne cedex >> Tel : +33(0)344234688 >> http://www.utc.fr/~mottelet >> _______________________________________________ >> dev mailing list >> dev at lists.scilab.org >> http://lists.scilab.org/mailman/listinfo/dev > > _______________________________________________ > dev mailing list > dev at lists.scilab.orghttp://lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Mon Feb 26 13:57:49 2018 From: stephane.mottelet at utc.fr (stephane.mottelet at utc.fr) Date: Mon, 26 Feb 2018 12:57:49 +0000 Subject: [Scilab-Dev] scilab-master builld help In-Reply-To: <1519644991.2211.54.camel@esi-group.com> References: <1518615338745-0.post@n3.nabble.com> <46fbee01-dbcf-104b-aa1f-d9c6d2bd32b1@utc.fr> <1518631624856-0.post@n3.nabble.com> <20180214181500.Horde.6noFgwETGwdsbK9FITULam6@webmail.utc.fr> <20180214200352.Horde.lsHYFRpjelt8p_GJ1NTzzuQ@webmail.utc.fr> <1518648613976-0.post@n3.nabble.com> <1518649368521-0.post@n3.nabble.com> <293ab011-7dba-c3a1-6b7c-b9815a339555@utc.fr> <3daebae7-eba4-a32c-5e1e-c403ece6f5fa@scilab-enterprises.com> <1553ecbc-2120-9236-3e8e-b32eb09811e4@utc.fr> <6d82edc6-3a68-f7e3-d5b1-755db10ebac9@utc.fr> <1519644991.2211.54.camel@esi-group.com> Message-ID: <20180226125749.Horde.s50snQQBN8UmaQyQmE1RDx8@webmail.utc.fr> Hello, I just built scilab-master on a Ubuntu 17.10 box and I realized that the help pages are not built. Is there a flag at configure time ? I saw a -disable-build-help but? not relevant here... S. -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Mon Feb 26 14:56:33 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Mon, 26 Feb 2018 14:56:33 +0100 Subject: [Scilab-Dev] scilab-master builld help In-Reply-To: <20180226125749.Horde.s50snQQBN8UmaQyQmE1RDx8@webmail.utc.fr> References: <1518615338745-0.post@n3.nabble.com> <46fbee01-dbcf-104b-aa1f-d9c6d2bd32b1@utc.fr> <1518631624856-0.post@n3.nabble.com> <20180214181500.Horde.6noFgwETGwdsbK9FITULam6@webmail.utc.fr> <20180214200352.Horde.lsHYFRpjelt8p_GJ1NTzzuQ@webmail.utc.fr> <1518648613976-0.post@n3.nabble.com> <1518649368521-0.post@n3.nabble.com> <293ab011-7dba-c3a1-6b7c-b9815a339555@utc.fr> <3daebae7-eba4-a32c-5e1e-c403ece6f5fa@scilab-enterprises.com> <1553ecbc-2120-9236-3e8e-b32eb09811e4@utc.fr> <6d82edc6-3a68-f7e3-d5b1-755db10ebac9@utc.fr> <1519644991.2211.54.camel@esi-group.com> <20180226125749.Horde.s50snQQBN8UmaQyQmE1RDx8@webmail.utc.fr> Message-ID: ok, got it: make doc Sorry for having decreased (again) the S/N ratio... S. Le 26/02/2018 ? 13:57, stephane.mottelet at utc.fr a ?crit?: > > Hello, > > I just built scilab-master on a Ubuntu 17.10 box and I realized that > the help pages are not built. Is there a flag at configure time ? I > saw a -disable-build-help but? not relevant here... > > S. > > -- > St?phane Mottelet > Ing?nieur de recherche > EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable > D?partement G?nie des Proc?d?s Industriels > Sorbonne Universit?s - Universit? de Technologie de Compi?gne > CS 60319, 60203 Compi?gne cedex > Tel : +33(0)344234688 > http://www.utc.fr/~mottelet > > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Mon Feb 26 19:51:08 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Mon, 26 Feb 2018 19:51:08 +0100 Subject: [Scilab-Dev] Disturbing changes on CodeReview In-Reply-To: <1517935331.2145.36.camel@esi-group.com> References: <2dd3121b-aa88-bf33-f4e5-f47ec459d476@free.fr> <1517935331.2145.36.camel@esi-group.com> Message-ID: Hello Cl?ment, > Le jeudi 01 f?vrier 2018 ? 00:23 +0100, Samuel Gougeon a ?crit : >> Le 31/01/2018 ? 20:45, Samuel Gougeon a ?crit : >>> When we review files in diff mode, the edit icon switching the diff mode into the edit one at >>> the top of the diff page no longer works: it yields an error page. >> >> After some work, this proves to occur only for files whose names start with "%", which is a >> special character for URLs. >> So, it is likely a bug in CodeReview itself, not in the Scilab infrastructure (unless managing "%" >> in filenames is configurable in CodeReview). >> >> Samuel Le 06/02/2018 ? 17:42, Cl?ment David a ?crit : > Hello Samuel, > > Great notice ! This issue arise when the codereview server it out of disk space. This is a > notifiable behavior that might be fixed in more recent Gerrit version. You can continue working on > the patchset by using gerrit tools [1] or by crafting the cherry-pick URL by hand. > > [1]: https://gerrit-review.googlesource.com/Documentation/cmd-cherry-pick.html > The issue is really a Gerrit one, not a disk space issue on the server. For instance, if we go here: https://codereview.scilab.org/19781 (before being merged ;) and we click on the *%*s_k_i.sci file in the list while we are in Editing mode ("Done Editing" flag), then it's OK : the file is properly edited in the Gerrit editor. Now, let's * quit the Edition mode * click on the same file in the list, to view its diff * At the top of its diff (also according to your Gerrit Preferences), click on the "Edit" icon * Then, we get an error : /Not Found//: The page you requested was not found, or you do not have permission to view this page./ Actually, the "%" character of the file name is correctly protected in the first case (we get %2525s_k_i_sci in the URL), but not enough protected in the second way. I don't know if this issue is reported in the Gerrit bug tracker (if any). Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hepboggpdebbmllh.png Type: image/png Size: 12006 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gomlcnpiapiibhbp.png Type: image/png Size: 15106 bytes Desc: not available URL: From johanwesselink23 at gmail.com Mon Feb 26 20:00:47 2018 From: johanwesselink23 at gmail.com (Johan Wesselink) Date: Mon, 26 Feb 2018 16:00:47 -0300 Subject: [Scilab-Dev] Tag for 6.0.1 missing? Message-ID: I checked out the latest git repository complete. I performed a full clone when I do a "git tag" I see all tags currently listed on the website except for 6.0.1. However, if I get the MD5 sum from the site and use it to go to the source I get an 6.0.1 version. In short what am I doing wrong? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Mon Feb 26 20:23:08 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Mon, 26 Feb 2018 20:23:08 +0100 Subject: [Scilab-Dev] Tag for 6.0.1 missing? In-Reply-To: References: Message-ID: <4e6448d3-753d-eee8-0014-673c61fa7f3c@free.fr> Le 26/02/2018 ? 20:00, Johan Wesselink a ?crit : > I checked out the latest git repository complete. > > I performed a full clone when I do a "git tag" I see all tags currently > listed on the website except for 6.0.1. > > However, if I get the MD5 sum from the site and use it to go to the source > I get an 6.0.1 version. > > In short what am I doing wrong? I have it in the list. Did you try /git fetch/ after the checkout? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Clement.David at esi-group.com Tue Feb 27 09:54:09 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Tue, 27 Feb 2018 08:54:09 +0000 Subject: [Scilab-Dev] Tag for 6.0.1 missing? In-Reply-To: <4e6448d3-753d-eee8-0014-673c61fa7f3c@free.fr> References: <4e6448d3-753d-eee8-0014-673c61fa7f3c@free.fr> Message-ID: <1519721647.2211.58.camel@esi-group.com> Hello, Seems to be listed on http://cgit.scilab.org/scilab/tag/?h=6.0.1 but not on https://github.com/scilab/scilab/tags ; I will repush it to github. Thanks for the info, -- Cl?ment Le lundi 26 f?vrier 2018 ? 20:23 +0100, Samuel Gougeon a ?crit : > Le 26/02/2018 ? 20:00, Johan Wesselink a ?crit : > > I checked out the latest git repository complete. > > > > I performed a full clone when I do a "git tag" I see all tags currently > > listed on the website except for 6.0.1. > > > > However, if I get the MD5 sum from the site and use it to go to the source > > I get an 6.0.1 version. > > > > In short what am I doing wrong? > > I have it in the list. > Did you try git fetch after the checkout? > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From johanwesselink23 at gmail.com Tue Feb 27 12:19:58 2018 From: johanwesselink23 at gmail.com (Johan Wesselink) Date: Tue, 27 Feb 2018 08:19:58 -0300 Subject: [Scilab-Dev] Tag for 6.0.1 missing? In-Reply-To: <1519721647.2211.58.camel@esi-group.com> References: <4e6448d3-753d-eee8-0014-673c61fa7f3c@free.fr> <1519721647.2211.58.camel@esi-group.com> Message-ID: Little bit more info. I did a git clone git://git.scilab.org/scilab That gave a repository with all the tags. The one I used up till now is https://github.com/scilab/scilab.git Tested the later one. It now has the missing tag. Many thanks. 2018-02-27 5:54 GMT-03:00 Cl?ment David : > Hello, > > Seems to be listed on http://cgit.scilab.org/scilab/tag/?h=6.0.1 but not > on > https://github.com/scilab/scilab/tags ; I will repush it to github. > > Thanks for the info, > > -- > Cl?ment > > Le lundi 26 f?vrier 2018 ? 20:23 +0100, Samuel Gougeon a ?crit : > > Le 26/02/2018 ? 20:00, Johan Wesselink a ?crit : > > > I checked out the latest git repository complete. > > > > > > I performed a full clone when I do a "git tag" I see all tags currently > > > listed on the website except for 6.0.1. > > > > > > However, if I get the MD5 sum from the site and use it to go to the > source > > > I get an 6.0.1 version. > > > > > > In short what am I doing wrong? > > > > I have it in the list. > > Did you try git fetch after the checkout? > > > > _______________________________________________ > > dev mailing list > > dev at lists.scilab.org > > http://lists.scilab.org/mailman/listinfo/dev > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Tue Feb 27 14:00:42 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Tue, 27 Feb 2018 14:00:42 +0100 Subject: [Scilab-Dev] BLAS use in Scilab In-Reply-To: <1519644991.2211.54.camel@esi-group.com> References: <1518615338745-0.post@n3.nabble.com> <46fbee01-dbcf-104b-aa1f-d9c6d2bd32b1@utc.fr> <1518631624856-0.post@n3.nabble.com> <20180214181500.Horde.6noFgwETGwdsbK9FITULam6@webmail.utc.fr> <20180214200352.Horde.lsHYFRpjelt8p_GJ1NTzzuQ@webmail.utc.fr> <1518648613976-0.post@n3.nabble.com> <1518649368521-0.post@n3.nabble.com> <293ab011-7dba-c3a1-6b7c-b9815a339555@utc.fr> <3daebae7-eba4-a32c-5e1e-c403ece6f5fa@scilab-enterprises.com> <1553ecbc-2120-9236-3e8e-b32eb09811e4@utc.fr> <6d82edc6-3a68-f7e3-d5b1-755db10ebac9@utc.fr> <1519644991.2211.54.camel@esi-group.com> Message-ID: <179ab40f-6855-a96a-437b-9ab4ef055957@utc.fr> Hello Cl?ment, Concerning my other question about the new Scilab API > Currently trying to port a Scilab interface to Scilab 6 standards, I > did try to find the equivalent of the deprecated Scifunction ? What is > the new function and where is documented ? how does one call a scilab function from within a gateway code, since "SciFunction" seems to belong to the past now ? Thanks in advance, St?phane Le 26/02/2018 ? 12:36, Cl?ment David a ?crit?: > Hello St?phane, > > AFAIK, as in the old interface the new C++ one allow you to get pointers to the raw double* values > and so allow you to write anything to the inputs. However this kind of behavior is considered a bug > as from the user point of view (eg. Scilab beginners) each assignation is supposed to have inputs > (unmodified data) and outputs (computed data). > > Note: about the += operator, this is indeed a way to tell the user that the argument is modified in > place with a specific + operation. > > Thanks, > > -- > Cl?ment > > Le jeudi 22 f?vrier 2018 ? 14:18 +0100, St?phane Mottelet a ?crit : >> Really, nobody knows ? >> >> S. >> >> Le 20/02/2018 ? 11:57, St?phane Mottelet a ?crit : >>> Hello, >>> >>> Continuing on this subject, Hello, I discovered that the new Scilab API allows to modify input >>> parameters of a function (in-place assignment), e.g. I have modified the previous daxpy such >>> that the expression >>> >>> daxpy(2,X,Y) >>> >>> has no output but formally does "Y+=2*X" if such an operator would exist in Scilab. In this case >>> there is no matrix copy at all, hence no memory overhead. >>> >>> Was it possible to do this with the previous API ? >>> >>> S. >>> >>> Le 19/02/2018 ? 19:15, St?phane Mottelet a ?crit : >>>> Hello, >>>> >>>> After some tests, for the intended use (multiply a matrix by a scalar), dgemm is not faster >>>> that dscal, but in the C code of "iMultiRealScalarByRealMatrix", the part which takes the most >>>> of the CPU time is the call to "dcopy". For example, on my machine, for a 10000x10000 matrix, >>>> the call to dcopy takes 540 milliseconds and the call to dscal 193 milliseconds. Continuing my >>>> explorations today, I tried to see how Scilab expressions such as >>>> >>>> Y+2*X >>>> >>>> are parsed and executed. To this purpose I have written an interface (daxpy.sci and daxpy.c >>>> attached) to the BLAS function "daxpy" which does "y<-y+a*x" and a script comparing the above >>>> expression to >>>> >>>> daxpy(2,X,Y) >>>> >>>> for two 10000x10000 matrices. Here are the results (MacBook air core i7 at 1,7GHz): >>>> >>>> daxpy(2,X,Y) >>>> (dcopy: 582 ms) >>>> (daxpy: 211 ms) >>>> >>>> elapsed time: 793 ms >>>> >>>> Y+2*X >>>> >>>> elapsed time: 1574 ms >>>> >>>> Considered the above value, the explanation is that in "Y+2*X" there are *two* copies of a >>>> 10000x10000 matrix instead of only one in "daxpy(2,X,Y)". In "Y+2*X+3*Z" there will be three >>>> copies, although there could be only one if daxpy was used twice. >>>> >>>> I am not blaming Scilab here, I am just blaming "vectorization", which can be inefficient when >>>> large objects are used. That's why explicits loops can sometimes be faster than >>>> vectorized operations in Matlab or Julia (which both use JIT compilation). >>>> >>>> S. >>>> >>>> >>>> Le 15/02/2018 ? 17:11, Antoine ELIAS a ?crit : >>>>> Hello St?phane, >>>>> >>>>> Interesting ... >>>>> >>>>> In release, we don't ship the header of BLAS/LAPACK functions. >>>>> But you can define them in your C file as extern. ( and let the linker do his job ) >>>>> >>>>> extern int C2F(dgemm) (char *_pstTransA, char *_pstTransB, int *_piN, int *_piM, int *_piK, >>>>> double *_pdblAlpha, double *_pdblA, int *_piLdA, >>>>> double *_pdblB, int *_piLdB, double *_pdblBeta, double *_pdblC, int >>>>> *_piLdC); >>>>> and >>>>> >>>>> extern int C2F(dscal) (int *_iSize, double *_pdblVal, double *_pdblDest, int *_iInc); >>>>> >>>>> Others BLAS/LAPACK prototypes can be found at http://cgit.scilab.org/scilab/tree/scilab/modu >>>>> les/elementary_functions/includes/elem_common.h?h=6.0 >>>>> >>>>> Regards, >>>>> Antoine >>>>> Le 15/02/2018 ? 16:50, St?phane Mottelet a ?crit : >>>>>> Hello all, >>>>>> >>>>>> Following the recent discussion with fujimoto, I discovered that Scilab does not (seem to) >>>>>> fully use SIMD operation in BLAS as it should. Besides the bottlenecks of its code, there >>>>>> are also many operations of the kind >>>>>> >>>>>> scalar*matrix >>>>>> >>>>>> Althoug this operation is correctly delegated to the DSCAL BLAS function (can be seen in C >>>>>> function iMultiRealMatrixByRealMatrix in >>>>>> modules/ast/src/c/operations/matrix_multiplication.c) : >>>>>> >>>>>>> int iMultiRealScalarByRealMatrix( >>>>>>> double _dblReal1, >>>>>>> double *_pdblReal2, int _iRows2, int _iCols2, >>>>>>> double *_pdblRealOut) >>>>>>> { >>>>>>> int iOne = 1; >>>>>>> int iSize2 = _iRows2 * _iCols2; >>>>>>> >>>>>>> C2F(dcopy)(&iSize2, _pdblReal2, &iOne, _pdblRealOut, &iOne); >>>>>>> C2F(dscal)(&iSize2, &_dblReal1, _pdblRealOut, &iOne); >>>>>>> return 0; >>>>>>> } >>>>>> in the code below the product "A*1" is likely using only one processor core, as seen on >>>>>> the cpu usage graph and on the elapsed time, >>>>>> >>>>>> A=rand(20000,20000); >>>>>> tic; for i=1:10; A*1; end; toc >>>>>> >>>>>> ans = >>>>>> >>>>>> 25.596843 >>>>>> >>>>>> but this second piece of code is more than 8 times faster and uses 100% of the cpu, >>>>>> >>>>>> ONE=ones(20000,1); >>>>>> tic; for i=1:10; A*ONE; end; toc >>>>>> >>>>>> ans = >>>>>> >>>>>> 2.938314 >>>>>> >>>>>> with roughly the same number of multiplications. This second computation is delegated to >>>>>> DGEMM (C<-alpha*A*B + beta*C, here with alpha=1 and beta=0) >>>>>> >>>>>>> int iMultiRealMatrixByRealMatrix( >>>>>>> double *_pdblReal1, int _iRows1, int _iCols1, >>>>>>> double *_pdblReal2, int _iRows2, int _iCols2, >>>>>>> double *_pdblRealOut) >>>>>>> { >>>>>>> double dblOne = 1; >>>>>>> double dblZero = 0; >>>>>>> >>>>>>> C2F(dgemm)("n", "n", &_iRows1, &_iCols2, &_iCols1, &dblOne, >>>>>>> _pdblReal1 , &_iRows1 , >>>>>>> _pdblReal2, &_iRows2, &dblZero, >>>>>>> _pdblRealOut , &_iRows1); >>>>>>> return 0; >>>>>>> } >>>>>> Maybe my intuition is wrong, but I have the feeling that using dgemm with alpha=0 will be >>>>>> faster than dscal. I plan to test this by making a quick and dirty code linked to Scilab >>>>>> so my question to devs is : which are the #includes to add on top of the source (C) to be >>>>>> able to call dgemm and dscal ? >>>>>> >>>>>> Thanks for your help >>>>>> >>>>>> S. >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> dev mailing list >>>>> dev at lists.scilab.org >>>>> http://lists.scilab.org/mailman/listinfo/dev >>>> >>>> >>>> _______________________________________________ >>>> dev mailing list >>>> dev at lists.scilab.org >>>> http://lists.scilab.org/mailman/listinfo/dev >>> -- >>> St?phane Mottelet >>> Ing?nieur de recherche >>> EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable >>> D?partement G?nie des Proc?d?s Industriels >>> Sorbonne Universit?s - Universit? de Technologie de Compi?gne >>> CS 60319, 60203 Compi?gne cedex >>> Tel : +33(0)344234688 >>> http://www.utc.fr/~mottelet >>> >>> >>> _______________________________________________ >>> dev mailing list >>> dev at lists.scilab.org >>> http://lists.scilab.org/mailman/listinfo/dev >> -- >> St?phane Mottelet >> Ing?nieur de recherche >> EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable >> D?partement G?nie des Proc?d?s Industriels >> Sorbonne Universit?s - Universit? de Technologie de Compi?gne >> CS 60319, 60203 Compi?gne cedex >> Tel : +33(0)344234688 >> http://www.utc.fr/~mottelet >> _______________________________________________ >> dev mailing list >> dev at lists.scilab.org >> http://lists.scilab.org/mailman/listinfo/dev > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet From Clement.David at esi-group.com Tue Feb 27 15:10:28 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Tue, 27 Feb 2018 14:10:28 +0000 Subject: [Scilab-Dev] Tag for 6.0.1 missing? In-Reply-To: References: <4e6448d3-753d-eee8-0014-673c61fa7f3c@free.fr> <1519721647.2211.58.camel@esi-group.com> Message-ID: <1519740627.2211.69.camel@esi-group.com> I repushed the tag on https://github.com/scilab/scilab ; this should be fixed now. -- Cl?ment Le mardi 27 f?vrier 2018 ? 08:19 -0300, Johan Wesselink a ?crit : > Little bit more info. > > I did a > git clone git://git.scilab.org/scilab > > That gave a repository with all the tags. > > The one I used up till now is > https://github.com/scilab/scilab.git > > Tested the later one. It now has the missing tag. > > Many thanks. > > > > 2018-02-27 5:54 GMT-03:00 Cl?ment David : > > Hello, > > > > Seems to be listed on http://cgit.scilab.org/scilab/tag/?h=6.0.1 but not on > > https://github.com/scilab/scilab/tags ; I will repush it to github. > > > > Thanks for the info, > > > > -- > > Cl?ment > > > > Le lundi 26 f?vrier 2018 ? 20:23 +0100, Samuel Gougeon a ?crit : > > > Le 26/02/2018 ? 20:00, Johan Wesselink a ?crit : > > > > I checked out the latest git repository complete. > > > > > > > > I performed a full clone when I do a "git tag" I see all tags currently > > > > listed on the website except for 6.0.1. > > > > > > > > However, if I get the MD5 sum from the site and use it to go to the source > > > > I get an 6.0.1 version. > > > > > > > > In short what am I doing wrong? > > > > > > I have it in the list. > > > Did you try git fetch after the checkout? > > > > > > _______________________________________________ > > > dev mailing list > > > dev at lists.scilab.org > > > http://lists.scilab.org/mailman/listinfo/dev > > _______________________________________________ > > dev mailing list > > dev at lists.scilab.org > > http://lists.scilab.org/mailman/listinfo/dev > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From Clement.David at esi-group.com Tue Feb 27 16:52:36 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Tue, 27 Feb 2018 15:52:36 +0000 Subject: [Scilab-Dev] BLAS use in Scilab In-Reply-To: <179ab40f-6855-a96a-437b-9ab4ef055957@utc.fr> References: <1518615338745-0.post@n3.nabble.com> <46fbee01-dbcf-104b-aa1f-d9c6d2bd32b1@utc.fr> <1518631624856-0.post@n3.nabble.com> <20180214181500.Horde.6noFgwETGwdsbK9FITULam6@webmail.utc.fr> <20180214200352.Horde.lsHYFRpjelt8p_GJ1NTzzuQ@webmail.utc.fr> <1518648613976-0.post@n3.nabble.com> <1518649368521-0.post@n3.nabble.com> <293ab011-7dba-c3a1-6b7c-b9815a339555@utc.fr> <3daebae7-eba4-a32c-5e1e-c403ece6f5fa@scilab-enterprises.com> <1553ecbc-2120-9236-3e8e-b32eb09811e4@utc.fr> <6d82edc6-3a68-f7e3-d5b1-755db10ebac9@utc.fr> <1519644991.2211.54.camel@esi-group.com> <179ab40f-6855-a96a-437b-9ab4ef055957@utc.fr> Message-ID: <1519746754.2211.78.camel@esi-group.com> Hello St?phane, > > Currently trying to port a Scilab interface to Scilab 6 standards, I > > did try to find the equivalent of the deprecated Scifunction ? What is > > the new function and where is documented ? > > how does one call a scilab function from within a gateway code, since > "SciFunction" seems to belong to the past now ? For exemple using the cppsci (internal Scilab 6) API, you could use : ``` if (in[iPos]->isCallable()) { types::Callable* pCall = in[iPos]->getAs(); pCall->invoke(...); // will call the function } ``` where: in contains the inputs iPos is the input position of the function argument For more understanding, you could take a look a the sci_ode.cpp and differentialequationfunctions.cpp implementation. Regards, -- Cl?ment