Le mercredi 21 mars 2012 à 08:36 -0700, Matthew Rocklin a écrit : > I think you're right that rebuilding everything that goes into a > compiler is far too much work for a GSoC student (or really this whole > community). I think that Andy is suggesting more local edits - surface > level only. Lets just walk through the code and see what > simplifications we can make using SymPy that gcc couldn't know about. > We'll leave the actual compilation to gcc/gfortran/javac/etc.... > I doubt there's much that can be done while strictly preserving the semantics of the language (addition and multiplication of floats aren't associative). OTOH, if we assume that the programmer wanted to use infinite-precision real numbers, we can probably do some useful transformations, but that might fail badly if the programmer actually dealt with floating-point pitfalls.
I think we need a real-world use-case to clarify the goals. > > If we encounter something like a for loop we probably ignore it and > just look at what we can do to the expressions inside. We don't need > to understand all of the code, we're just trying to improve small > pieces of it. I'd guess that most useful optimisations would require moving stuff in and out of for loops. > > I don't think that code compilation should be a project though, I > think that parsing should be. I think that Andy's idea becomes > feasible once SymPy can read other code. Andy's idea is only one > possible result of this though. A good parsing module could make SymPy > useful in a lot of new ways. There are already lots of parsing libraries. I don't think it's a good idea to reinvent the wheel. > Later today I'll put code parsing on the ideas page (if someone > doesn't beat me to it). > > On Wed, Mar 21, 2012 at 2:26 AM, Joachim Durchholz <j...@durchholz.org> > wrote: > Am 20.03.2012 18:35, schrieb Andy Ray Terrel: > > Well I was thinking more of taking a piece of c code, > but it could be > take a python function, grab the code object and > manipulate that. > > What I really want is to play around with symbolic > code optimizations > and since we have quite a few tools to go from > symbolics to code, it > seems easy to do simple things in the other > directions. > > > Real (non-toy) code contains extra stuff for handling error > conditions, optimizing memory usage, etc. > Extracting the real logic from all that sounds like it would > be really, really hard. > > The other question is: what do you want to optimize for? > Space? Time? Code size? > What's your execution model - number of subroutine calls? > Number of operator calls? How do you estimate the number of > rounds spent in a loop (or the depth of a recursive call)? How > do you estimate the size of data structures created? How do > you determine how long some data structure will live? > > Not all of the questions are relevant for all optimization > goals. > This is going to be a good GSoC project if a goal is found > that does not require answers to the ultra-hard questions. So > the project should not be "optimize C functions" (that's a > task for multiple lifetimes), but something more specific. > With an implementation strategy, and an eye towards why this > isn't going to require solving the halting problem or > similarly hard things. > > > > I realize > this isn't super well formed but after seeing a number > of these > symbolic executor papers, I think it is probably a > good way to go. > > > I haven't seen these papers. If they pick specific things that > don't require doing hard stuff, this could be fun. > Extra points if it is going to make SymPy more useful. > > > > > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
