Re: Compilation: Avoiding inlining

*To*: mathgroup at smc.vnet.net*Subject*: [mg121596] Re: Compilation: Avoiding inlining*From*: DmitryG <einschlag at gmail.com>*Date*: Wed, 21 Sep 2011 05:35:08 -0400 (EDT)*Delivered-to*: l-mathgroup@mail-archive0.wolfram.com*References*: <201109191106.HAA19637@smc.vnet.net> <j59onf$m4$1@smc.vnet.net>

On Sep 20, 6:08 am, Oliver Ruebenkoenig <ruebe... at wolfram.com> wrote: > On Mon, 19 Sep 2011, DmitryG wrote: > > On Sep 17, 6:31 am, DmitryG <einsch... at gmail.com> wrote: > >> Hi Oliver, > > >> thank you for your response! I am interested now in the systems of > >> equations that are non-vectorizable. By mistake, in my first post I > >> have used a system of equations that can be vectorized and this turned > >> the discussion away from the topic. But in my second post, I have a > >> non-vectorizable system of equations. > > >> I have identified three ways to define the system of equations. Below > >> are the results with Mathematica compilation. > > >> 1) > >> (* Definition of the equations *) > >> NN = 1000; > >> F = Function[{t, x}, Table[ -x[[i]] Sin[0.1 t]^2/(1 +100 Sum[x[[i + > >> j]], {j, 1, Min[3, NN - i]}]^2), {i, 1, NN}]]; > > >>>> Evaluation time 24.4983979 - slow execution. No inlining. Compiled code 189 lines independently of NN. Compilation in C gives practically the same speed > > >> 2) > >> (* Definition of the equations *) > >> NN = 1000; > >> F = Function[{t, x}, Table[ Unevaluated[-x[[i]] Sin[0.1 t]^2/(1 +100 > >> Sum[x[[i + j]], {j, 1, Min[3, NN - i]}]^2)], {i, 1, NN}]]; > > >>>> Evaluation time 4.7582721. No inlining. Compiled code 93 lines independently of NN. Compilation in C gives practically the same speed > > >> 3) > >> (* Definition of the equations *) > >> NN = 1000; > >> F = Function[{t, x}, Evaluate[Table[ -x[[i]] Sin[0.1 t]^2/(1 +100 > >> Sum[x[[i + j]], {j, 1, Min[3, NN - i]}]^2), {i, 1, NN}]]]; > > >>>> Evaluation time 1.0680555 - fastest execution. Here we have inlining of the code, the size of the compiled code increases with NN. Compilation in C is impossible. > > >> One can see that there are many different ways with very different > >> results, and it is very important to find the best one - more > >> important than to buy a faster computer;-)) > > >> Does in make sense to introduce F as a compiled function, as you have > >> done in your response? We already make compilation of the RK-4 > >> procedure with F injected into it. > > >> Best, > > >> Dmitry > > > One more way to define the equations: > > > 4) > > (* Definition of the equations *) > > NN = 1000; > > F = Function[{t, x}, Table[ -x[[i]] Sin[0.1 t]^2/(1 +100 > > Evaluate[Sum[x[[i + > > j]], {j, 1, Min[3, NN - i]}]]^2), {i, 1, NN}]]; > > >>> Evaluation time 89.35 - slowest execution!. No inlining. Compiled code 145 lines independently of NN. Compilation in C gives practically the same speed > > > In all the programs above make n=500 steps. > > > To summarize, although, theoretically, with compilation in C > > Mathematica has to be as fast as C, practically it is not. There are > > You can even generate code that is faster than C; in certain problems you > can exploit Mathmatica's symbolic properties. > > > too many variants to define the functions in the RHS of the ODE's and > > That is due to the fact that many ways lead to Rome. Because Mathematica > has a vast reservoir to express ideas you have to understand well which > road you chose. > > > the speeds are very different. So far there is absolutely no advantage > > of C over Mathematica's own compiler. Of all variants, inlining the > > I do not see how that conclusion can be derived from the above. Also, I > have shown in last post, how compilation to "C" increases speed once > more; and I think further speed improvements in the code are possible too. > > You can write very inefficient c code, too. > > > code (that is a bad way of programming) leads to fastest execution. > > Why is inlining bad. Is the inlining of code that a > c compiler does bad? The point is that it is generated code. > > > I still hope that Wolfram will come up with the optimal way to solve > > Could you outline what such an optimal way would look like for you? > > > generic non-vectorizable systems of ODE's with compilation, this can > > be done one time for the whole future life. > > Also, if you have working C code, that seems to do what you want in the > way you want, why do you not just link that into Mathematica? > > So, what are the timings for your c code? > > > > > Dmitry > > Oliver Dear Oliver, The code in your 19 September post solves the problem, avoiding inlining, calls back to Mathematica and making C finally work. Thank you a lot! All preceding versions either inlined a huge explicit code or called back to Mathematica to evaluate equations. In both cases C was unusable. In the latter case execution was long. In your version, both RK4 procedure and equations are compiled, so that calls back to Mathematica are eliminated. Real-life problems usually contain chains of definitions, and it is important that all of them be compiled. If only one of them is left uncompiled, there will be calls back to Mathematica and the program will be slow. I did not understand this at the beginning and, unfortunately, Mathematica's help does not explain this. On my laptop, the execution time is 0.7 with Mathematica compilation (you have the same) and 0.22 with C compilation (you have 0.12). I have Windows 7, Mathematica 8, and Microsoft Visual C++ compiler. Probably Microsoft Visual is not the fastest one. What C compiler do you have? I am going to get Mathematica for the Linux part of my computer and there I have Intel C++ compiler that is much faster. Also I am going to install a C++ compiler on my Mac Pro and test the program there. Now I am trying to rewrite my actual research program in a way that it is fully compiled and avoids calls back to Mathematica. This is not easy because there are a lot of definitions, and currently nothing works. I hope I will be able to accomplish it, and then I will compare the speed with that of the same program written in pure C++ by my colleagues in France. Best, Dmitry

**References**:**Re: Compilation: Avoiding inlining***From:*DmitryG <einschlag@gmail.com>

**Re: boundary conditions**

**Wronskian**

**Re: Compilation: Avoiding inlining**

**Re: Compilation: Avoiding inlining**