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 >>> <https://groups.google.com/d/msgid/sympy/CAP7f1AiMm_i%2BJBLBnv3_xzG_8Czag10DWvAUfiAhe-QUzUANiw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> 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.
