On Wed, Mar 21, 2012 at 4:32 PM, Aaron Meurer <[email protected]> wrote: > On Wed, Mar 21, 2012 at 3:10 PM, Andy Ray Terrel <[email protected]> > 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?
No, unladen swallow was a grander project to make all of python go fast. This is much smaller with the notion of providing support for more complex functions than currently allowed to be implemented in numpy's ufuncs. AFAIK, unladen swallow has been completely defunded. It had some early improvements but hit some fundamental bottlenecks and never realized the gains it wanted to find. -- Andy > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>> 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 [email protected]. >>>>> To unsubscribe from this group, send email to >>>>> [email protected]. >>>>> 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 [email protected]. >>>> To unsubscribe from this group, send email to >>>> [email protected]. >>>> 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 [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> 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 [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
