I'll agree that some simple optimizations may be appropriate at the parse tree level (for loop range replacement, which we already do, is a great example). However, none of the examples on the wiki are things I would consider good things to do at the parse tree level. Having a full python interperter around to get around the fact that we don't have decent dependencies is almost certainly not the way to do this. My dislike of parse tree optimizations mainly centers around using it for very complicated things that can be much better served by other algorithms.
On 3/15/08, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > I disagree, I think parse trees are a great place to put many > optimizations--for instance GCC performs many of its optimizations at > that level. > > > - Robert > > > On Mar 15, 2008, at 2:52 AM, Gary Furnish wrote: > > > While I've liked your previous ideas, parse trees are not the correct > > way to do optimizations in my opinion. This would dramatically > > increase Cython compile time by orders of magnitude for one. If we > > really wanted to do this we should build dependency graphs (I'm > > currently working on code that does this for classes) for all > > functions and then use some more standard algorithms. (It is easy to > > optimize your example with graphs, it is significantly more > > complicated using the parse tree). Doing this properly is no small > > undertaking as what you are essentially asking for is a full > > optimizing compiler (without register allocation, granted). > > Furthermore we should probably only attempt this after cython can > > bootstrap itself, as its going to be tough to keep compile times > > reasonable while cython is still written in python. While this task > > is simple to describe, there are thousands of devils in the details. > > I'm hesitant to call this a good idea without someone experienced in > > writing compilers willing to work on it close to full time. > > > > On 3/15/08, Dag Sverre Seljebotn <[EMAIL PROTECTED]> wrote: > >> http://wiki.cython.org/enhancements/inlining > >> > >> As I think this is possible in a one or two week timeframe, I ask > >> of you > >> all to tell me what obvious things I am missing completely and > >> where I did > >> a wrong turn in my reasoning :-) > >> > >> I copy and paste: > >> > >> Why? > >> > >> - It leaves the way open for a hassle-free operator overloading > >> syntax - > >> use the same operator overloading conventions that Python use > >> even for > >> wrapped C library types without worrying about performance. > >> > >> - A convenient tool for doing compile-time calculations and having > >> parametrized code written at compile-time. The creative use C++'s > >> template > >> syntax has gotten over the years should demonstrate that the > >> inlining the > >> GCC compiler does is not sufficient for advanced use cases (see > >> http://ubiety.uwaterloo.ca/~tveldhui/papers/Expression-Templates/ > >> exprtmpl.html, > >> Blitz++ etc., basically using the C++ template system to inline > >> vector > >> multiplications etc. that's written dynamically according to vector > >> sizes). > >> > >> Dag Sverre > >> > >> _______________________________________________ > >> Cython-dev mailing list > >> [email protected] > >> http://codespeak.net/mailman/listinfo/cython-dev > >> > > _______________________________________________ > > Cython-dev mailing list > > [email protected] > > http://codespeak.net/mailman/listinfo/cython-dev > > _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
