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....
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 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. 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+unsubscribe@** > googlegroups.com <sympy%2bunsubscr...@googlegroups.com>. > For more options, visit this group at http://groups.google.com/** > group/sympy?hl=en <http://groups.google.com/group/sympy?hl=en>. > > -- 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.
