Csound Csound-dev Csound-tekno Search About

[Cs-dev] optimizing the new parser

Date2011-11-19 18:01
FromJohn 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

Date2011-11-19 18:03
Fromjpff@cs.bath.ac.uk
SubjectRe: [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

Date2011-11-20 00:44
FromJustin Glenn Smith
SubjectRe: [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

Date2011-11-21 10:47
FromJohn Lato
SubjectRe: [Cs-dev] optimizing the new parser
On Sun, Nov 20, 2011 at 12:44 AM, Justin Glenn Smith
 wrote:
> 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.

I think creating such a list would be necessary to enable this
transformation.  I think it's also necessary for CSE, as functional
opcodes would be eligible for such elimination but others may not.  I
often have multiple random-ish opcodes with the same inputs for
example.  I still don't have a good sense if it's likely to be
worthwhile however.

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