On Tuesday, 3 November 2015 16:46:39 UTC+1, Nathan Woods wrote: > > My use case for Sympy code generation is somewhat different from most, it > seems. I'm primarily interested in numerical quadrature on a grid, which > means a LOT of evaluations of similar functions. I'm only using lambdify > currently, because the compile-time associated with codegen is worse than > the Python call-back overhead. The real gotcha for me is that I need to do > a complete Solve-Generate-Integrate loop many, many times, so the > performance of the generation step matters a lot. >
Interesting. If you are only doing numerical (double precision) evaluations and are only using the lambdified expressions once, symengine should be quite a bit faster. I wrote this shim which makes symengine.Lambdify work like sympy.lambdify: https://gist.github.com/anonymous/7c6d7a5e80e1e5f6b39e You can try to see if you see a speed up. > > Nathan Woods > > On Friday, October 30, 2015 at 3:33:19 PM UTC-6, Aaron Meurer wrote: >> >> I would also love to hear from those of you who are using SymPy to do >> code generation or would like to use SymPy to do code generation, what >> is your wishlist for SymPy? What do you wish it could do that it can't >> do or what do you wish it could do better? >> >> Aaron Meurer >> >> On Fri, Oct 30, 2015 at 4:23 PM, Anthony Scopatz <[email protected]> >> wrote: >> > Hello All, >> > >> > As many of you probably know, earlier this month Aaron joined my >> research >> > group at the University of South Carolina. He'll be working on adding / >> > improving SymPy's capabilities with respect to being an optimizing >> compiler. >> > >> > There are more details about this vision below, but right now we are in >> the >> > process of doing a literature review of sorts, and trying to figure out >> what >> > (SymPy-specific) is out there. What has been done already. Aaron et al, >> have >> > started putting together a page on the wiki that compiles some of this >> > information. We'd really appreciate it if you know of anything that is >> not >> > on this page if you could let us know. >> > >> > We also would be grateful if you could let us know (publicly or >> privately) >> > about any use cases that you might have for a symbolic optimizing >> compiler. >> > There are many examples where different folks have done various pieces >> of >> > this (chemreac, dengo, pydy, some stuff in pyne), but these examples >> tend to >> > be domain specific. This effort is supposed to target a general >> scientific >> > computing audience, and to do that we want to have as many possible >> > scenarios in mind at the outset. >> > >> > And of course, we'd love it if other folks dived in and helped us put >> this >> > thing together :). >> > >> > Thanks a million! >> > Be Well >> > Anthony >> > >> > Vision >> > ------------ >> > Essentially, what we want to build is an optimizing compiler for >> symbolic >> > mathematical expressions in order to solve simple equations, ODEs, >> PDEs, and >> > perhaps more. This compiler should be able to produce very fast code, >> though >> > the compiler itself may be expensive. >> > >> > Ultimately, it is easy to imagine a number of backend targets, such as >> C, >> > Fortran, LLVM IR, Cython, pure Python, etc. It is also easy to imagine >> a >> > couple of meaningful frontends - SymPy objects (for starters) and LaTeX >> > (which could then be parsed into SymPy). >> > >> > We are aiming to have an optimization pipeline that is highly >> customizable >> > (but with sensible defaults). This would allow folks to tailor the >> result to >> > their problem or add their own problem-specific optimizations. There >> are >> > likely different levels to this (such as on an expression vs at full >> > function scope). Some initial elements of this pipeline might include >> CSE, >> > simple rule-based rewriting (like a/b/c -> a/(b*c) or a*exp(b*x) -> >> > A*2^(B*x)), and replacing non-analytic sub-expressions with approximate >> > expansions (taylor, pade, chebychev, etc) out to an order computed >> based on >> > floating point precision. >> > >> > That said, we aren't the only ones thinking in this area. The chemora >> > (http://arxiv.org/pdf/1410.1764.pdf, h/t Matt Turk) code does >> something like >> > the vision above but using Mathematica, for HPC applications only, and >> with >> > an astrophysical bent. >> > >> > I think a tool like this is important because it allows the exploration >> of >> > more scientific models more quickly and with a higher degree of >> > verification. The current workflow for most scientific modeling is to >> come >> > up with a mathematical representation of the problem, a human then >> > translates that into a programming language of choice, they may or may >> not >> > test this translation, and then execution of that model. This compiler >> aims >> > to get rid of the time-constrained human in those middle steps. It >> won't >> > tell you if the model is right or not, but you'll sure be able to pump >> out a >> > whole lot more models :). >> > >> > >> > -- >> > >> > Asst. Prof. Anthony Scopatz >> > Nuclear Engineering Program >> > Mechanical Engineering Dept. >> > University of South Carolina >> > [email protected] >> > Office: (803) 777-7629 >> > Cell: (512) 827-8239 >> > Check my calendar >> > >> > -- >> > 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. >> > To view this discussion on the web visit >> > >> https://groups.google.com/d/msgid/sympy/CAPk-6T453AxDYt1UCmBj_7vrzr_HikC2U03UP%2Bzz5_RtDA9NDA%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 http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/8ba71ffb-600a-4e85-abb3-8d47c5bd9daf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
