Le 04/24/2015 03:19 PM, 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).

I agree with you: scilab is fast with linear algebra and slow for the rest and so far you have not generated your scilab code with scilab strength and weakness in mind. So if you stick with Scilab, you should go for a matrix form (maybe a sparse matrix) or follow Samuel's version.

Cheers,

Antoine


-Brian

On Fri, Apr 24, 2015 at 8:34 AM, Stéphane Mottelet <[email protected] <mailto:[email protected]>> 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
    [email protected]  <mailto:[email protected]>
    http://lists.scilab.org/mailman/listinfo/users


    _______________________________________________
    users mailing list
    [email protected] <mailto:[email protected]>
    http://lists.scilab.org/mailman/listinfo/users




--
Brian Bouterse


_______________________________________________
users mailing list
[email protected]
http://lists.scilab.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected]
http://lists.scilab.org/mailman/listinfo/users

Reply via email to