[Cs-dev] optimizing the new parser
Date | 2011-11-19 18:01 |
From | John Lato |
Subject | [Cs-dev] optimizing the new parser |
Hello, I've recently been looking at adding some optimizations to the csound parser. Steven recently mentioned the possibility of using an SSA representation, which I think would be pretty simple to add. It looks like all that would be necessary is a renaming pass and adding a phi function. SSA would enable some rather aggressive optimizations as to loops, dead code elimination, constant folding, etc. However, would this actually be beneficial? Constant folding and propation could have a big impact, but I'm not sure that most loop optimizations would make much difference since there aren't many loops in most csound code. So, some questions for those who are more familiar with the csound source. Are there any other optimizations that are likely to be very beneficial? Is SSA likely to help much? If people think it's a good idea I can start with SSA, but otherwise I may not bother. Another possibility would be using LLVM as a backend. This would allow for run-time linking optimizations, but at the cost of introducing a (rather large) dependency. I'm also wondering about dead code elimination. In this simple example a1 oscili 1 440 1 a2 oscili 1 550 1 outs a2 a2 the first "oscili" could be eliminated, but that's not generally true for opcodes. Is there a way to tell if an opcode has side effects? Thanks, John L. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
Date | 2011-11-19 18:03 |
From | jpff@cs.bath.ac.uk |
Subject | Re: [Cs-dev] optimizing the new parser |
Well we have constant folding in most cases But feel free to make it better, more general etc. Hello, > > I've recently been looking at adding some optimizations to the csound > parser. Steven recently mentioned the possibility of using an SSA > representation, which I think would be pretty simple to add. It looks > like all that would be necessary is a renaming pass and adding a phi > function. SSA would enable some rather aggressive optimizations as to > loops, dead code elimination, constant folding, etc. > > However, would this actually be beneficial? Constant folding and > propation could have a big impact, but I'm not sure that most loop > optimizations would make much difference since there aren't many loops > in most csound code. > > So, some questions for those who are more familiar with the csound > source. Are there any other optimizations that are likely to be very > beneficial? Is SSA likely to help much? If people think it's a good > idea I can start with SSA, but otherwise I may not bother. Another > possibility would be using LLVM as a backend. This would allow for > run-time linking optimizations, but at the cost of introducing a > (rather large) dependency. > > I'm also wondering about dead code elimination. In this simple example > > a1 oscili 1 440 1 > a2 oscili 1 550 1 > outs a2 a2 > > the first "oscili" could be eliminated, but that's not generally true > for opcodes. Is there a way to tell if an opcode has side effects? > > Thanks, > John L. > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel > > > ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
Date | 2011-11-20 00:44 |
From | Justin Glenn Smith |
Subject | Re: [Cs-dev] optimizing the new parser |
John Lato wrote: ... > > a1 oscili 1 440 1 > a2 oscili 1 550 1 > outs a2 a2 > > the first "oscili" could be eliminated, but that's not generally true > for opcodes. Is there a way to tell if an opcode has side effects? > > Thanks, > John L. We could make a list of opcodes that have no side effects (opcodes that only alter their lhs, no alterations on the rhs and no change to tables or hidden global variables internal to csound). That would be safer than a list of opcodes with side effects. Another good thing could be a list of "functional" or "memoizable" opcodes - ones that will always output the same result given the same input arguments and duration. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
Date | 2011-11-21 10:47 |
From | John Lato |
Subject | Re: [Cs-dev] optimizing the new parser |
On Sun, Nov 20, 2011 at 12:44 AM, Justin Glenn Smith |