On Wed, Mar 21, 2012 at 3:10 PM, Andy Ray Terrel <andy.ter...@gmail.com> wrote: > I would like to play more with the LLVM implementation. Check out > https://github.com/ContinuumIO/numba
Cool. Is that related to the unladen swallow project? Aaron Meurer > > Some points I see coming up: > > * REAL codes are layered and have hot loops in them. I would only > target the small hot loops that get run a lot. (Such as a ufunc for > numpy.) > * In general, we should probably branch off our code tools and update > them. Currently they are spread around a bit and somewhat > un-advertised. > * Precision and stability problems are hard (as in I know theses that > have tried and failed to address some of these issues), I would just > tell people to make sure anything produced by us should be tested > thoroughly and assume infinite precision. > * The first ideas that come to mind is doing better CSE (which could > be also combined with this idea), constant folding, loop lifting, > perhaps some unrolling and jamming. We can also rearrange to minimize > memory access and if we are very ambitious vectorize (or generate > CUDA/OPENCL/ISPC code). > > It looks like there is enough interest for me to go find a > bibliography for this project. > > -- Andy > > On Wed, Mar 21, 2012 at 2:47 PM, Aaron Meurer <asmeu...@gmail.com> wrote: >> I wonder if we can take advantage of the low-level interpretation from >> a compiler to make the parsing easier, for example, LLVM's >> intermediate language. I haven't really studied that much, so I don't >> know if it would really be useful or not. >> >> Aaron Meurer >> >> On Wed, Mar 21, 2012 at 9:36 AM, Matthew Rocklin <mrock...@gmail.com> wrote: >>> 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+unsubscr...@googlegroups.com. >>>> For more options, visit this group at >>>> 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. >> >> -- >> 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. >> > > -- > 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. > -- 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.
