On Thu, Mar 14, 2013 at 12:34 AM, Aaron Meurer <[email protected]> wrote: > This validates what I've often said, which is that if you use the > right algorithms and the right data structures, then Python can be > just as fast as a compiled alternative (especially since "the right > data structures" usually means fast built-in data structures). > > To me, right now, there a four main things that can make SymPy slow (in order: > > - expand > - slow matrices/linear algebra > - slow polys (esp. in highly multivariate situations) > - the core > > expand() is the worst. If we can make that faster, then all of SymPy > will feel zippier. > > Slow linear algebra is responsible for slow solve(), but also for slow > integrate(), since heurisch() basically hangs here. I'm not sure where > else it is used (other than in the matrices themselves, obviously). > > For slow polys, this rarely makes things slow, but it serves as a > barrier to make things faster, since if you rewrite an algorithm using > the polys, it makes it slower whenever the polynomials have more than > a few variables (this is what happened with heurisch). > > Whenever I find myself breaking a long computation, I'd say 70% of the > time it is in expand somewhere and 60% of the time it is in the polys.
Can you write examples of expressions for expand() that are slow? When I did benchmarks of expand() about 2 years ago, of expressions like (x+y+z+1)^20, I noticed that the main expansion is done using multinomial_coefficients(), which is very fast (it can be made maybe 2x or so faster in C, but not 100x). However, 95% of time is spent in creating the symbolic expression from the coefficients. Which is why I am experimenting with a C++ core, to see how fast one can get. > > The core I would say is actually not too slow, at least compared to > these other things, but since it is used everywhere, even marginal > speedups can add up. > > Your work (I'm assuming) will fix point 3, and your continuing work > will fix point 2. Do you have any plans to fix point 1 (expand)? > > For point 4 of course the best way forward is to remove the old > assumptions. In my opinion, though, speed is the least concern in the > core. Bigger issues are how to better manage canonicalization and how > to deal with global vs. local assumptions. Mateusz and I discussed this last few days (I visited him in Wroclaw) and I think we both agreed that a good idea is for me (or others) to finish the experimental C++ core (https://github.com/certik/csympy) so that we can run some benchmarks and play with several things like hashes and canonicalization and at the same time keep working sympy (assumptions as you wrote, and other things). The general idea is to have an API, so that we can keep sympy in pure Python by default, but if needed, be able to use a faster C++ core for the raw symbolics. One thing is to decouple the core a little bit more from the rest of sympy, which should happen anyway. In general, I think it's quite amazing how fast Python actually is, that sympy can compete very well with for example Maxima, if the right data structures and algorithms are used. So I think it's a good idea to keep sympy in pure Python. But have an optional C++ core is something that I feel is necessary, if nothing, at least to have an idea of how fast one can get. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
