On Mon, Jul 2, 2012 at 3:24 AM, [email protected] <[email protected]> wrote: >> 6x speedup makes a big difference if you are going to make an >> evaluation thousands or even millions of times. > > In fact, if you do the evaluation thousands or millions of times, the > difference will not be noticeable, because what will take long time is > the evaluation of the array inside numpy.sin, numpy.cos and numpy.add.
Let's label the numpy approach 2), the direct python's math module approach as 1). The approach 2) is only applicable to cases when you know all the points in advance, while the approach 1) can be used in any applications where you need fast evaluations of the expressions, at points that you don't know in advance. Also the approach 2) depends on numpy, while 1) only needs pure Python. > The difference between the two times is what is constant, not their > ratio. > > In [22]: a = sin(x)+cos(x) > > In [23]: b = lambdify(x, a, numpy) > > In [24]: array_short = numpy.linspace(0,10,num=100) > > In [25]: array_long = numpy.linspace(0,10,num=10000) > > In [26]: %timeit a.eval_with_numpy(x, array_short) > 10000 loops, best of 3: 65.9 us per loop > > In [27]: %timeit a.eval_with_numpy(x, array_long) > 1000 loops, best of 3: 1.05 ms per loop > > In [28]: %timeit b(array_short) > 100000 loops, best of 3: 15.7 us per loop > > In [29]: %timeit b(array_long) > 1000 loops, best of 3: 988 us per loop > > As you can see it is a difference a constant of about 40us, not a ratio of 6x. Yes, this is the approach 2). I agree that using lambdify for 2) will not, except special cases, give a big speedup. > > Another argument against the original benchmark: You did not take into > account the call to lambdify itself (in plotting, for example, the > lambdified expression is used only once (the new adaptive sampling > changes this)). The call to lambdify takes about as long as the > evaluation of the long array itself (10000 evaluations). > > Of course, this is only true for numpy, not for python.math and > python.cmath. There one would indeed have 6x slowdown. Yes, that's the case 1). In there lambdify does provide significant speedup. The 6x speedup is only for the simple case sin(x)+cos(x). For complicated expressions, I expect the speedup to be much larger. As another datapoint: the lambdify() was introduced at the time when evalf() did use just Python floats, as far as I know, and it did provide a significant speedup (using the approach 1). > > And all the discussion is about CPython, not something with a JIT like pypy. > > In conclusion, there are some places where playing with closures will > be useful (all the non numpy stuff for instance), however there is no > obvious speed gain in the numpy case. > > Although, I someone wants such a high performance, shouldn't he be > pointed to the autowrap cython and fortran implementations that we > have? This seems like a much cleaner solution (much less hacks). Yes, ultimately, if you want such things to be fast, the best is to use Fortran and you can actually use both 1) and 2) approaches in Fortran. In gfortran, the approach 2) is sometimes faster, probably because the compiler is somehow able to generate faster code, for details, see for example [1]. For heavy array oriented numerics (in double precision), I fully recommend to use Fortran, I use it almost everyday and the code is pretty much as fast as one can ever get, with minimal effort. However, while we can generate Fortran code, compile it and use that for plotting, in many cases it is an overkill and a simple approach 1) or 2) provides enough speed to get the job done. > > Finally, if we implement the eval_with_numpy stuff, this will also > close issue 537 http://code.google.com/p/sympy/issues/detail?id=537 Ondrej [1] http://technicaldiscovery.blogspot.com/2011/07/speeding-up-python-again.html -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
