[Scilab-users] Ways to speed up simple things in Scilab ?

[Stéphane Mottelet]

Hello,

You will find a description of the actual problem which is solved by the 
generated code : http://arxiv.org/pdf/1206.5072v1.pdf
See particularly page 6, where I explain the way the code generation 
works. However, be warned that the code snipplets are quite obsolete, 
since the generated code is now more efficient.

For matrices M_k(v) (the ones the thread is about), Antoine's answer 
give a solution because the element of this matrix are linear 
combinations of the v(i)'s.
But for other matrices, wich are derivatives of the fonctions expressing 
the non-linear system with respect to state or parameters, the terms to 
assemble are non-linear algebraic expressions mixing states and v(i)'s.

S.



Le 24/04/2015 15:19, Brian Bouterse a écrit :
> I don't know much about scilab optimizations, but trying to 
> hand-optimize auto-generated code almost certainly will result in 
> correctness problems. It's likely better to make your improvements in 
> the software that is generating the scilab code. I think the main 
> feature there is to have it generate a vectorized implementation 
> instead of a procedural one (as you have now).
>
> -Brian
>
> On Fri, Apr 24, 2015 at 8:34 AM, Stéphane Mottelet 
> <stephane.mottelet at utc.fr <mailto:stephane.mottelet at utc.fr>> wrote:
>
>     Hello,
>
>     this is not trivial indexing, in fact some terms are linear
>     combination of v's components
>
>     M1_v=[v(17)
>     v(104)
>     v(149)
>     -(v(18)+v(63)+v(103))
>     -(v(18)+v(63)+v(103))
>     v(17)
>     ...
>     v(104)
>     v(149)
>     ]
>
>     How do you take this into account in your proposed method ? These
>     combinations are sums of influxes in a metabolic network, and the
>     code is automatically generated.
>
>
>     S.
>
>
>
>     Le 24/04/2015 13:48, Samuel Gougeon a écrit :
>>     Le 24/04/2015 13:36, Samuel Gougeon a écrit :
>>>     Hello Stephane,
>>>
>>>     You can speed up by a factor larger than 100 just by calling v
>>>     once (or 3 times) instead of ~1000, as shown by this test:
>>
>>     Actually, to be more accurate, the right comparative test is the
>>     following:
>>
>>     function  test2()
>>          v  =  rand(172,1);
>>          p  =  grand(1,839,"unf",1,173)
>>          // Part 1: 1 call to v()
>>          tic()
>>          for  i=1:1000
>>              m1_v  =  v(p)
>>          end
>>          disp(toc())
>>          
>>          // Part 2 : 839 calls to v()
>>          deff("test3()",  "for i=1:1000, M1_v = ["+strcat("v("+string(p)+")")+"], end")
>>          tic()
>>          test3()
>>          disp(toc())
>>     endfunction
>>
>>     In this version, the compilation time used by execstr() is no
>>     longer taken into account.
>>
>>     The results are still explicit:
>>     -->test2()
>>
>>         0.016
>>
>>         0.78
>>
>>     So, a speed-up by ~x 50
>>
>>     Samuel
>>
>>
>>
>>     _______________________________________________
>>     users mailing list
>>     users at lists.scilab.org  <mailto:users at lists.scilab.org>
>>     http://lists.scilab.org/mailman/listinfo/users
>
>
>     _______________________________________________
>     users mailing list
>     users at lists.scilab.org <mailto:users at lists.scilab.org>
>     http://lists.scilab.org/mailman/listinfo/users
>
>
>
>
> -- 
> Brian Bouterse
>
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20150424/429e39cc/attachment.htm>