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 <shiksharawa...@gmail.com> 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 <shiksharawa...@gmail.com> > 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 <shiksharawa...@gmail.com> >> 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 <moorepa...@gmail.com> 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 <asmeu...@gmail.com> 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 >>>>> <oscar.j.benja...@gmail.com> wrote: >>>>> > >>>>> > (Replying on-list) >>>>> > >>>>> > On Thu, 14 Mar 2019 at 20:37, Alan Bromborsky <abrombo...@gmail.com> >>>>> > 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 sympy+unsubscr...@googlegroups.com. >>>>> > To post to this group, send email to sympy@googlegroups.com. >>>>> > 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 sympy+unsubscr...@googlegroups.com. >>>>> To post to this group, send email to sympy@googlegroups.com. >>>>> 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 sympy+unsubscr...@googlegroups.com. >>>> To post to this group, send email to sympy@googlegroups.com. >>>> 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 sympy+unsubscr...@googlegroups.com. > To post to this group, send email to sympy@googlegroups.com. > 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. 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.
