We have a benchmark repository that is run periodically: https://github.com/sympy/sympy_benchmarks
I recommend starting there. You can find a number of regressions that can be investigated. Jason moorepants.info +01 530-601-9791 On Wed, Mar 27, 2019 at 5:17 PM Aaron Meurer <[email protected]> wrote: > I agree with Oscar. I would also add that it's usually not trivial to > determine where the bottlenecks are in SymPy. So I would write more > about how you intend to profile the code. > > Perhaps it would be useful to take an existing thing that is slow in > SymPy (you can use the performance issue label as a guide, or find > something yourself, > > https://github.com/sympy/sympy/issues?q=is%3Aopen+is%3Aissue+label%3APerformance > ), > and try to fix the performance, documenting how you went about finding > the bottleneck and fixing it. This can be used as a case study in your > application. > > Also I would note that currently the benchmarking infrastructure for > SymPy is quite bad (basically nonexistent). See > > https://github.com/sympy/sympy/wiki/GSoC-2019-Ideas#benchmarks-and-performance > . > It's fine if you do not want to work on that specifically, but you > should note that you will be running the benchmarks on your own > computer to find performance regressions. Not all performance issues > are regressions either (some things have always been slow), so you > should consider absolute numbers as well as relative numbers. > > Aaron Meurer > > On Wed, Mar 27, 2019 at 5:11 PM Oscar Benjamin > <[email protected]> wrote: > > > > This looks like good work to do. I don't know how these applications > > are evaluated but my thought if I was reviewing this would be that it > > seems quite vague. This would probably be a more enticing proposal if > > it had some specific suggestions of changes that would speed things > > up. > > > > I can tell you now what is slow in the ODE module: currently even for > > the simplest ODEs all matching code is run for all the possible > > methods even after a suitable method has been found. It would be much > > better to identify the most immediately usable solver and then use > > that without matching all the others. This needs a refactor of the > > module though and a redesign of the basic approach used by dsolve. I > > want that to happen as an ultimate goal but I would like to see better > > test coverage first. > > > > On Wed, 27 Mar 2019 at 09:56, Shiksha Rawat <[email protected]> > wrote: > > > > > > > https://github.com/sympy/sympy/wiki/GSoC-2019-Application-SHIKSHA-RAWAT-:-Benchmarks-and-performance > > > > > > I have designed a proposal for Benchmarks and Perfromance idea, though > it is not complete yet. > > > > > > Can Jason Moore, Aaron and Oscar please review that and suggest > changes? > > > > > > > > > On Tue, Mar 19, 2019 at 11:53 PM Shiksha Rawat < > [email protected]> wrote: > > >> > > >> I did further digging on the idea mentioned by Jason Moore. > > >> > > >> Figuring out the main bottlenecks for sympy : The best way to figure > out these bottlenecks would be to designing a typical problem for each > module for example mass spring damper for physics and computing time taken > by sympy to give the output.If it is greater then expected than or a > predefined threshold than analyzing the codebase of that module for > possible changes to decrease computation time. And the results of > predefined benchmarks could also be used. > > >> > > >> Creating benchmarks : > https://media.readthedocs.org/pdf/asv/v0.1.1/asv.pdf > > >> I think this documentation could come in handy for creating the > benchmarks. The requirement of a particular benchmark could be made on the > basis of the bottlenecks which we will figure out. > > >> > > >> Improving performance: I think the best way to improve performance > would be cleaning up the codebase first and then making changes in the > algorithms used according to the requirements. > > >> > > >> Future Scope: Figuring out a method by which each PR also has to give > information about the time the modules related to that PR will take to give > output of problems associated with that module. (those mentioned in > figuring out the bottlenecks point). > > >> > > >> I might be wrong about the ideas mentioned above. So I want > suggestions from the mentors. > > >> > > >> Thanks. > > >> > > >> On Fri, Mar 15, 2019 at 9:48 PM Shiksha Rawat < > [email protected]> wrote: > > >>> > > >>> I am really interested in taking up that idea. Can you suggest where > or how should I start from because up till now I was just focusing on the > physics module and benchmarks related to it? > > >>> I am still trying to find how could we optimize matrix operations. > > >>> > > >>> > > >>> On Fri, Mar 15, 2019 at 8:46 PM Jason Moore <[email protected]> > wrote: > > >>>> > > >>>> The mechanics speedup idea is really just a narrow version of the > profiling and benchmarking idea (focuses on just a couple of packages). > Maybe a proposal that focuses on figuring out the main bottlenecks for > sympy, creating benchmarks for them, and then improving performance is a > good proposal idea that will ultimately help all the packages. I'm happy to > support and mentor on that idea if someone wants to submit. > > >>>> > > >>>> Jason > > >>>> moorepants.info > > >>>> +01 530-601-9791 > > >>>> > > >>>> > > >>>> On Thu, Mar 14, 2019 at 2:19 PM Aaron Meurer <[email protected]> > wrote: > > >>>>> > > >>>>> I agree. The biggest challenge with symbolic matrices is expression > > >>>>> blow up. In some cases it is unavoidable, for instance, symbolic > > >>>>> eigenvalues/eigenvectors use the symbolic solutions to polynomials, > > >>>>> which are complicated in the general case for n > 2. > > >>>>> > > >>>>> One thing I meant by "overhead" is that if the type of a matrix's > > >>>>> entries is known to all be rational numbers, for instance, we can > > >>>>> operate directly on those numbers, ideally using fast number types > > >>>>> like gmpy.mpq. If they are all rational functions, we can use > > >>>>> polynomial algorithms that operate on rational functions. These > always > > >>>>> keep rational functions in canonical form, and the zero equivalence > > >>>>> testing becomes literally "expr == 0" (no simplification required). > > >>>>> These can be more efficient than general symbolic manipulation. > > >>>>> > > >>>>> This is how the polys module is structured. See > > >>>>> https://docs.sympy.org/latest/modules/polys/internals.html. It > would > > >>>>> be nice to have a similar structure in the matrices, where a matrix > > >>>>> can have a ground domain (or type) associated with its underlying > > >>>>> data. > > >>>>> > > >>>>> Aaron Meurer > > >>>>> > > >>>>> On Thu, Mar 14, 2019 at 2:52 PM Oscar Benjamin > > >>>>> <[email protected]> wrote: > > >>>>> > > > >>>>> > (Replying on-list) > > >>>>> > > > >>>>> > On Thu, 14 Mar 2019 at 20:37, Alan Bromborsky < > [email protected]> wrote: > > >>>>> > > > > >>>>> > > Since most pc these days have multiple cores and threads what > not use > > >>>>> > > parallel algorithyms. For honesty I must state I have a > vested interest > > >>>>> > > since I have a pc with a threadripper cpu with 16 cores and 32 > threads. > > >>>>> > > > >>>>> > Parallel algorithms can offer improvement. Your 16 cores might > amount > > >>>>> > to a 10x speed up if used well for this kind of thing. The > > >>>>> > double-threading probably can't be exploited in CPython. > > >>>>> > > > >>>>> > However I think that many of the things that SymPy is slow for > have > > >>>>> > *really* bad asymptotic performance: think O(N!) rather than > O(N^2). > > >>>>> > Many orders of magnitude improvements can be made by spotting > these > > >>>>> > where more efficient methods are possible. It's not hard in a > CAS to > > >>>>> > accidentally generate enormous expressions and end up > simplifying them > > >>>>> > down again. This leads to many situations where it would be > vastly > > >>>>> > more efficient to somehow take a more direct route. > > >>>>> > > > >>>>> > -- > > >>>>> > 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 https://groups.google.com/group/sympy. > > >>>>> > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAHVvXxTeAGZUv1kdtKCvBRodMZPyX5jHh76G0M49VshwMziJZA%40mail.gmail.com > . > > >>>>> > For more options, visit https://groups.google.com/d/optout. > > >>>>> > > >>>>> -- > > >>>>> 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 https://groups.google.com/group/sympy. > > >>>>> To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAKgW%3D6JGfKjgHP3EaoX%3DXW_SMfnbGOZgi9LLJoUT3Ty7%3Dutd%2BA%40mail.gmail.com > . > > >>>>> For more options, visit https://groups.google.com/d/optout. > > >>>> > > >>>> -- > > >>>> 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 https://groups.google.com/group/sympy. > > >>>> To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAP7f1AiMm_i%2BJBLBnv3_xzG_8Czag10DWvAUfiAhe-QUzUANiw%40mail.gmail.com > . > > >>>> For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > > 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 https://groups.google.com/group/sympy. > > > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAKVsmS7P3w9nL%2BA9UJOnpZ4oBmc7UjGUdVjpmcFyog%2B5QwuP5g%40mail.gmail.com > . > > > For more options, visit https://groups.google.com/d/optout. > > > > -- > > 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 https://groups.google.com/group/sympy. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAHVvXxRXE%2BF%2BWVk2pY%2Bsbzem6ZTG6QrDZXh24qPtYnjdojoDmA%40mail.gmail.com > . > > For more options, visit https://groups.google.com/d/optout. > > -- > 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 https://groups.google.com/group/sympy. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAKgW%3D6LZLd0kEcLGurCvmAZihW2E4dEiXx_LXQc3nKhXpFA3gA%40mail.gmail.com > . > For more options, visit https://groups.google.com/d/optout. > -- 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 https://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAP7f1Aj2yffQDWJH47ox3UvQUSfj_VPKgef-2b1P0FVGZqi-Mg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
