[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 |