My suggestions, the ones I think the most useful first:

(1) Implement multi-threading using OpenMP throughout Csound.

(2) Embed Lua (LuaJIT, on x86 architectures) in Csound, and enable
writing not only opcodes, but also instrument definitions, in this
dynamic, high-level language.

(3) Redo the VST stuff without the VST SDK, so that we can distribute
vst4cs and CsoundVST on SourceForge.

(4) Add DBus opcodes to Csound (DBus is used by at least some
implementations of Jack and is a lightweight, high-performance message
bus).

(5) Develop a library of high-quality instrument definitions,
especially band-limited and physically modeled instruments, that can
be #included in orchestras and interface via the bus and the
signalflowgraph opcodes.

Thanks,
Mike





On Wed, Mar 10, 2010 at 10:08 AM, Victor Lazzarini
 wrote:
> Hi everyone,
> we have two days to develop this ideas page:
> http://socghop.appspot.com/document/show/user/csound_2010/csound_2010_ideas
> please help with ideas and improvements to it. I think we could add some
> short descriptions to each item.
> Victor
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thanks. Of these, two raise some concerns, at least from me:

(1)-> there is already a substantial work on automatic parallelism  
that John ffitch was developing, using pthreads.
We should finish that before thinking of using OpenMP, which is an  
interesting possibility, but we need to be
careful. Also we will need to think at what level the parallelism will  
take place. I think the level of instrument, which
John's work was aimed at, gives the correct granularity

(2)-> I'm worried of adding another dependency to Csound. If this  
could be done in a modular way, so that the
Lua connection is optional, I am fine with it.

Victor

On 10 Mar 2010, at 15:19, Michael Gogins wrote:

> My suggestions, the ones I think the most useful first:
>
> (1) Implement multi-threading using OpenMP throughout Csound.
>
> (2) Embed Lua (LuaJIT, on x86 architectures) in Csound, and enable
> writing not only opcodes, but also instrument definitions, in this
> dynamic, high-level language.
>
> (3) Redo the VST stuff without the VST SDK, so that we can distribute
> vst4cs and CsoundVST on SourceForge.
>
> (4) Add DBus opcodes to Csound (DBus is used by at least some
> implementations of Jack and is a lightweight, high-performance message
> bus).
>
> (5) Develop a library of high-quality instrument definitions,
> especially band-limited and physically modeled instruments, that can
> be #included in orchestras and interface via the bus and the
> signalflowgraph opcodes.
>
> Thanks,
> Mike
>
>
>
>
>
> On Wed, Mar 10, 2010 at 10:08 AM, Victor Lazzarini
>  wrote:
>> Hi everyone,
>> we have two days to develop this ideas page:
>> http://socghop.appspot.com/document/show/user/csound_2010/csound_2010_ideas
>> please help with ideas and improvements to it. I think we could add  
>> some
>> short descriptions to each item.
>> Victor
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>
>
>
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I too have reservations about Lua embedded into Csound.  I'd rather
csound be used by Lua than have it be within the core itself.

If the engine changes are done correctly, one should be able to
programmatically create an instrument in any language via the API.

On Wed, Mar 10, 2010 at 10:33 AM, Victor Lazzarini
 wrote:
> Thanks. Of these, two raise some concerns, at least from me:
>
> (1)-> there is already a substantial work on automatic parallelism
> that John ffitch was developing, using pthreads.
> We should finish that before thinking of using OpenMP, which is an
> interesting possibility, but we need to be
> careful. Also we will need to think at what level the parallelism will
> take place. I think the level of instrument, which
> John's work was aimed at, gives the correct granularity
>
> (2)-> I'm worried of adding another dependency to Csound. If this
> could be done in a modular way, so that the
> Lua connection is optional, I am fine with it.
>
> Victor
>
> On 10 Mar 2010, at 15:19, Michael Gogins wrote:
>
>> My suggestions, the ones I think the most useful first:
>>
>> (1) Implement multi-threading using OpenMP throughout Csound.
>>
>> (2) Embed Lua (LuaJIT, on x86 architectures) in Csound, and enable
>> writing not only opcodes, but also instrument definitions, in this
>> dynamic, high-level language.
>>
>> (3) Redo the VST stuff without the VST SDK, so that we can distribute
>> vst4cs and CsoundVST on SourceForge.
>>
>> (4) Add DBus opcodes to Csound (DBus is used by at least some
>> implementations of Jack and is a lightweight, high-performance message
>> bus).
>>
>> (5) Develop a library of high-quality instrument definitions,
>> especially band-limited and physically modeled instruments, that can
>> be #included in orchestras and interface via the bus and the
>> signalflowgraph opcodes.
>>
>> Thanks,
>> Mike
>>
>>
>>
>>
>>
>> On Wed, Mar 10, 2010 at 10:08 AM, Victor Lazzarini
>>  wrote:
>>> Hi everyone,
>>> we have two days to develop this ideas page:
>>> http://socghop.appspot.com/document/show/user/csound_2010/csound_2010_ideas
>>> please help with ideas and improvements to it. I think we could add
>>> some
>>> short descriptions to each item.
>>> Victor
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I was going to try to modify the ideas page but couldn't see how to do
it. For the new parser, there's a stub function that should get
implemented for optimization of the parse tree before compilation.This
would be for things like constant folding, dead code elimination,
inlining of constant i-rate variables. We should look at static-single
assignment (SSA) as a basis before performing optimizations.

For engine work, I'd like to see easy instrument reloading by changing
the role of the parser a bit: csound->Compile() could be run 1-many
times and each definition in ORC could potentially replace a previous
definition.  It would be ideal to allow sending over just an instr
definition to replace a current one, for example.


On Wed, Mar 10, 2010 at 12:00 PM, Steven Yi  wrote:
> I too have reservations about Lua embedded into Csound.  I'd rather
> csound be used by Lua than have it be within the core itself.
>
> If the engine changes are done correctly, one should be able to
> programmatically create an instrument in any language via the API.
>
> On Wed, Mar 10, 2010 at 10:33 AM, Victor Lazzarini
>  wrote:
>> Thanks. Of these, two raise some concerns, at least from me:
>>
>> (1)-> there is already a substantial work on automatic parallelism
>> that John ffitch was developing, using pthreads.
>> We should finish that before thinking of using OpenMP, which is an
>> interesting possibility, but we need to be
>> careful. Also we will need to think at what level the parallelism will
>> take place. I think the level of instrument, which
>> John's work was aimed at, gives the correct granularity
>>
>> (2)-> I'm worried of adding another dependency to Csound. If this
>> could be done in a modular way, so that the
>> Lua connection is optional, I am fine with it.
>>
>> Victor
>>
>> On 10 Mar 2010, at 15:19, Michael Gogins wrote:
>>
>>> My suggestions, the ones I think the most useful first:
>>>
>>> (1) Implement multi-threading using OpenMP throughout Csound.
>>>
>>> (2) Embed Lua (LuaJIT, on x86 architectures) in Csound, and enable
>>> writing not only opcodes, but also instrument definitions, in this
>>> dynamic, high-level language.
>>>
>>> (3) Redo the VST stuff without the VST SDK, so that we can distribute
>>> vst4cs and CsoundVST on SourceForge.
>>>
>>> (4) Add DBus opcodes to Csound (DBus is used by at least some
>>> implementations of Jack and is a lightweight, high-performance message
>>> bus).
>>>
>>> (5) Develop a library of high-quality instrument definitions,
>>> especially band-limited and physically modeled instruments, that can
>>> be #included in orchestras and interface via the bus and the
>>> signalflowgraph opcodes.
>>>
>>> Thanks,
>>> Mike
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Mar 10, 2010 at 10:08 AM, Victor Lazzarini
>>>  wrote:
>>>> Hi everyone,
>>>> we have two days to develop this ideas page:
>>>> http://socghop.appspot.com/document/show/user/csound_2010/csound_2010_ideas
>>>> please help with ideas and improvements to it. I think we could add
>>>> some
>>>> short descriptions to each item.
>>>> Victor
>>>> ------------------------------------------------------------------------------
>>>> Download Intel® Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

You can't. Send me a list and I'll put it up. I'll try to incorporate  
these ideas.

Victor
On 10 Mar 2010, at 17:12, Steven Yi wrote:

> I was going to try to modify the ideas page but couldn't see how to do
> it. For the new parser, there's a stub function that should get
> implemented for optimization of the parse tree before compilation.This
> would be for things like constant folding, dead code elimination,
> inlining of constant i-rate variables. We should look at static-single
> assignment (SSA) as a basis before performing optimizations.
>
> For engine work, I'd like to see easy instrument reloading by changing
> the role of the parser a bit: csound->Compile() could be run 1-many
> times and each definition in ORC could potentially replace a previous
> definition.  It would be ideal to allow sending over just an instr
> definition to replace a current one, for example.
>
>
> On Wed, Mar 10, 2010 at 12:00 PM, Steven Yi   
> wrote:
>> I too have reservations about Lua embedded into Csound.  I'd rather
>> csound be used by Lua than have it be within the core itself.
>>
>> If the engine changes are done correctly, one should be able to
>> programmatically create an instrument in any language via the API.
>>
>> On Wed, Mar 10, 2010 at 10:33 AM, Victor Lazzarini
>>  wrote:
>>> Thanks. Of these, two raise some concerns, at least from me:
>>>
>>> (1)-> there is already a substantial work on automatic parallelism
>>> that John ffitch was developing, using pthreads.
>>> We should finish that before thinking of using OpenMP, which is an
>>> interesting possibility, but we need to be
>>> careful. Also we will need to think at what level the parallelism  
>>> will
>>> take place. I think the level of instrument, which
>>> John's work was aimed at, gives the correct granularity
>>>
>>> (2)-> I'm worried of adding another dependency to Csound. If this
>>> could be done in a modular way, so that the
>>> Lua connection is optional, I am fine with it.
>>>
>>> Victor
>>>
>>> On 10 Mar 2010, at 15:19, Michael Gogins wrote:
>>>
>>>> My suggestions, the ones I think the most useful first:
>>>>
>>>> (1) Implement multi-threading using OpenMP throughout Csound.
>>>>
>>>> (2) Embed Lua (LuaJIT, on x86 architectures) in Csound, and enable
>>>> writing not only opcodes, but also instrument definitions, in this
>>>> dynamic, high-level language.
>>>>
>>>> (3) Redo the VST stuff without the VST SDK, so that we can  
>>>> distribute
>>>> vst4cs and CsoundVST on SourceForge.
>>>>
>>>> (4) Add DBus opcodes to Csound (DBus is used by at least some
>>>> implementations of Jack and is a lightweight, high-performance  
>>>> message
>>>> bus).
>>>>
>>>> (5) Develop a library of high-quality instrument definitions,
>>>> especially band-limited and physically modeled instruments, that  
>>>> can
>>>> be #included in orchestras and interface via the bus and the
>>>> signalflowgraph opcodes.
>>>>
>>>> Thanks,
>>>> Mike
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Mar 10, 2010 at 10:08 AM, Victor Lazzarini
>>>>  wrote:
>>>>> Hi everyone,
>>>>> we have two days to develop this ideas page:
>>>>> http://socghop.appspot.com/document/show/user/csound_2010/csound_2010_ideas
>>>>> please help with ideas and improvements to it. I think we could  
>>>>> add
>>>>> some
>>>>> short descriptions to each item.
>>>>> Victor
>>>>> ------------------------------------------------------------------------------
>>>>> Download Intel® Parallel Studio Eval
>>>>> Try the new software tools for yourself. Speed compiling, find  
>>>>> bugs
>>>>> proactively, and fine-tune applications for parallel performance.
>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://www.michael-gogins.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download Intel® Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Okay, well the issues I emailed just now are the primary ones I can
think of.  Many thanks for organizing this!

On Wed, Mar 10, 2010 at 12:18 PM, Victor Lazzarini
 wrote:
> You can't. Send me a list and I'll put it up. I'll try to incorporate
> these ideas.
>
> Victor
> On 10 Mar 2010, at 17:12, Steven Yi wrote:
>
>> I was going to try to modify the ideas page but couldn't see how to do
>> it. For the new parser, there's a stub function that should get
>> implemented for optimization of the parse tree before compilation.This
>> would be for things like constant folding, dead code elimination,
>> inlining of constant i-rate variables. We should look at static-single
>> assignment (SSA) as a basis before performing optimizations.
>>
>> For engine work, I'd like to see easy instrument reloading by changing
>> the role of the parser a bit: csound->Compile() could be run 1-many
>> times and each definition in ORC could potentially replace a previous
>> definition.  It would be ideal to allow sending over just an instr
>> definition to replace a current one, for example.
>>
>>
>> On Wed, Mar 10, 2010 at 12:00 PM, Steven Yi 
>> wrote:
>>> I too have reservations about Lua embedded into Csound.  I'd rather
>>> csound be used by Lua than have it be within the core itself.
>>>
>>> If the engine changes are done correctly, one should be able to
>>> programmatically create an instrument in any language via the API.
>>>
>>> On Wed, Mar 10, 2010 at 10:33 AM, Victor Lazzarini
>>>  wrote:
>>>> Thanks. Of these, two raise some concerns, at least from me:
>>>>
>>>> (1)-> there is already a substantial work on automatic parallelism
>>>> that John ffitch was developing, using pthreads.
>>>> We should finish that before thinking of using OpenMP, which is an
>>>> interesting possibility, but we need to be
>>>> careful. Also we will need to think at what level the parallelism
>>>> will
>>>> take place. I think the level of instrument, which
>>>> John's work was aimed at, gives the correct granularity
>>>>
>>>> (2)-> I'm worried of adding another dependency to Csound. If this
>>>> could be done in a modular way, so that the
>>>> Lua connection is optional, I am fine with it.
>>>>
>>>> Victor
>>>>
>>>> On 10 Mar 2010, at 15:19, Michael Gogins wrote:
>>>>
>>>>> My suggestions, the ones I think the most useful first:
>>>>>
>>>>> (1) Implement multi-threading using OpenMP throughout Csound.
>>>>>
>>>>> (2) Embed Lua (LuaJIT, on x86 architectures) in Csound, and enable
>>>>> writing not only opcodes, but also instrument definitions, in this
>>>>> dynamic, high-level language.
>>>>>
>>>>> (3) Redo the VST stuff without the VST SDK, so that we can
>>>>> distribute
>>>>> vst4cs and CsoundVST on SourceForge.
>>>>>
>>>>> (4) Add DBus opcodes to Csound (DBus is used by at least some
>>>>> implementations of Jack and is a lightweight, high-performance
>>>>> message
>>>>> bus).
>>>>>
>>>>> (5) Develop a library of high-quality instrument definitions,
>>>>> especially band-limited and physically modeled instruments, that
>>>>> can
>>>>> be #included in orchestras and interface via the bus and the
>>>>> signalflowgraph opcodes.
>>>>>
>>>>> Thanks,
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 10, 2010 at 10:08 AM, Victor Lazzarini
>>>>>  wrote:
>>>>>> Hi everyone,
>>>>>> we have two days to develop this ideas page:
>>>>>> http://socghop.appspot.com/document/show/user/csound_2010/csound_2010_ideas
>>>>>> please help with ideas and improvements to it. I think we could
>>>>>> add
>>>>>> some
>>>>>> short descriptions to each item.
>>>>>> Victor
>>>>>> ------------------------------------------------------------------------------
>>>>>> Download Intel® Parallel Studio Eval
>>>>>> Try the new software tools for yourself. Speed compiling, find
>>>>>> bugs
>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://www.michael-gogins.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Download Intel® Parallel Studio Eval
>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>> proactively, and fine-tune applications for parallel performance.
>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download Intel® Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I have incorporated Steven and John's  ideas as well as Michael's.  
Please let me know what you think of the current set as shown in the  
ideas page and the way I organised them.

John: what nonpow2 opcodes do you mean (to finish)?

Victor

On 10 Mar 2010, at 17:24, Steven Yi wrote:

> Okay, well the issues I emailed just now are the primary ones I can
> think of.  Many thanks for organizing this!
>
> On Wed, Mar 10, 2010 at 12:18 PM, Victor Lazzarini
>  wrote:
>> You can't. Send me a list and I'll put it up. I'll try to incorporate
>> these ideas.
>>
>> Victor
>> On 10 Mar 2010, at 17:12, Steven Yi wrote:
>>
>>> I was going to try to modify the ideas page but couldn't see how  
>>> to do
>>> it. For the new parser, there's a stub function that should get
>>> implemented for optimization of the parse tree before  
>>> compilation.This
>>> would be for things like constant folding, dead code elimination,
>>> inlining of constant i-rate variables. We should look at static- 
>>> single
>>> assignment (SSA) as a basis before performing optimizations.
>>>
>>> For engine work, I'd like to see easy instrument reloading by  
>>> changing
>>> the role of the parser a bit: csound->Compile() could be run 1-many
>>> times and each definition in ORC could potentially replace a  
>>> previous
>>> definition.  It would be ideal to allow sending over just an instr
>>> definition to replace a current one, for example.
>>>
>>>
>>> On Wed, Mar 10, 2010 at 12:00 PM, Steven Yi 
>>> wrote:
>>>> I too have reservations about Lua embedded into Csound.  I'd rather
>>>> csound be used by Lua than have it be within the core itself.
>>>>
>>>> If the engine changes are done correctly, one should be able to
>>>> programmatically create an instrument in any language via the API.
>>>>
>>>> On Wed, Mar 10, 2010 at 10:33 AM, Victor Lazzarini
>>>>  wrote:
>>>>> Thanks. Of these, two raise some concerns, at least from me:
>>>>>
>>>>> (1)-> there is already a substantial work on automatic parallelism
>>>>> that John ffitch was developing, using pthreads.
>>>>> We should finish that before thinking of using OpenMP, which is an
>>>>> interesting possibility, but we need to be
>>>>> careful. Also we will need to think at what level the parallelism
>>>>> will
>>>>> take place. I think the level of instrument, which
>>>>> John's work was aimed at, gives the correct granularity
>>>>>
>>>>> (2)-> I'm worried of adding another dependency to Csound. If this
>>>>> could be done in a modular way, so that the
>>>>> Lua connection is optional, I am fine with it.
>>>>>
>>>>> Victor
>>>>>
>>>>> On 10 Mar 2010, at 15:19, Michael Gogins wrote:
>>>>>
>>>>>> My suggestions, the ones I think the most useful first:
>>>>>>
>>>>>> (1) Implement multi-threading using OpenMP throughout Csound.
>>>>>>
>>>>>> (2) Embed Lua (LuaJIT, on x86 architectures) in Csound, and  
>>>>>> enable
>>>>>> writing not only opcodes, but also instrument definitions, in  
>>>>>> this
>>>>>> dynamic, high-level language.
>>>>>>
>>>>>> (3) Redo the VST stuff without the VST SDK, so that we can
>>>>>> distribute
>>>>>> vst4cs and CsoundVST on SourceForge.
>>>>>>
>>>>>> (4) Add DBus opcodes to Csound (DBus is used by at least some
>>>>>> implementations of Jack and is a lightweight, high-performance
>>>>>> message
>>>>>> bus).
>>>>>>
>>>>>> (5) Develop a library of high-quality instrument definitions,
>>>>>> especially band-limited and physically modeled instruments, that
>>>>>> can
>>>>>> be #included in orchestras and interface via the bus and the
>>>>>> signalflowgraph opcodes.
>>>>>>
>>>>>> Thanks,
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 10, 2010 at 10:08 AM, Victor Lazzarini
>>>>>>  wrote:
>>>>>>> Hi everyone,
>>>>>>> we have two days to develop this ideas page:
>>>>>>> http://socghop.appspot.com/document/show/user/csound_2010/csound_2010_ideas
>>>>>>> please help with ideas and improvements to it. I think we could
>>>>>>> add
>>>>>>> some
>>>>>>> short descriptions to each item.
>>>>>>> Victor
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>> Try the new software tools for yourself. Speed compiling, find
>>>>>>> bugs
>>>>>>> proactively, and fine-tune applications for parallel  
>>>>>>> performance.
>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Michael Gogins
>>>>>> Irreducible Productions
>>>>>> http://www.michael-gogins.com
>>>>>> Michael dot Gogins at gmail dot com
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Download Intel® Parallel Studio Eval
>>>>>> Try the new software tools for yourself. Speed compiling, find  
>>>>>> bugs
>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Download Intel® Parallel Studio Eval
>>>>> Try the new software tools for yourself. Speed compiling, find  
>>>>> bugs
>>>>> proactively, and fine-tune applications for parallel performance.
>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I can't seem to be able to update the page right now, so my changes  
are not there yet.
On 10 Mar 2010, at 19:25, Victor Lazzarini wrote:

> I have incorporated Steven and John's  ideas as well as Michael's.
> Please let me know what you think of the current set as shown in the
> ideas page and the way I organised them.
>
> John: what nonpow2 opcodes do you mean (to finish)?
>
> Victor
>
> On 10 Mar 2010, at 17:24, Steven Yi wrote:
>
>> Okay, well the issues I emailed just now are the primary ones I can
>> think of.  Many thanks for organizing this!
>>
>> On Wed, Mar 10, 2010 at 12:18 PM, Victor Lazzarini
>>  wrote:
>>> You can't. Send me a list and I'll put it up. I'll try to  
>>> incorporate
>>> these ideas.
>>>
>>> Victor
>>> On 10 Mar 2010, at 17:12, Steven Yi wrote:
>>>
>>>> I was going to try to modify the ideas page but couldn't see how
>>>> to do
>>>> it. For the new parser, there's a stub function that should get
>>>> implemented for optimization of the parse tree before
>>>> compilation.This
>>>> would be for things like constant folding, dead code elimination,
>>>> inlining of constant i-rate variables. We should look at static-
>>>> single
>>>> assignment (SSA) as a basis before performing optimizations.
>>>>
>>>> For engine work, I'd like to see easy instrument reloading by
>>>> changing
>>>> the role of the parser a bit: csound->Compile() could be run 1-many
>>>> times and each definition in ORC could potentially replace a
>>>> previous
>>>> definition.  It would be ideal to allow sending over just an instr
>>>> definition to replace a current one, for example.
>>>>
>>>>
>>>> On Wed, Mar 10, 2010 at 12:00 PM, Steven Yi 
>>>> wrote:
>>>>> I too have reservations about Lua embedded into Csound.  I'd  
>>>>> rather
>>>>> csound be used by Lua than have it be within the core itself.
>>>>>
>>>>> If the engine changes are done correctly, one should be able to
>>>>> programmatically create an instrument in any language via the API.
>>>>>
>>>>> On Wed, Mar 10, 2010 at 10:33 AM, Victor Lazzarini
>>>>>  wrote:
>>>>>> Thanks. Of these, two raise some concerns, at least from me:
>>>>>>
>>>>>> (1)-> there is already a substantial work on automatic  
>>>>>> parallelism
>>>>>> that John ffitch was developing, using pthreads.
>>>>>> We should finish that before thinking of using OpenMP, which is  
>>>>>> an
>>>>>> interesting possibility, but we need to be
>>>>>> careful. Also we will need to think at what level the parallelism
>>>>>> will
>>>>>> take place. I think the level of instrument, which
>>>>>> John's work was aimed at, gives the correct granularity
>>>>>>
>>>>>> (2)-> I'm worried of adding another dependency to Csound. If this
>>>>>> could be done in a modular way, so that the
>>>>>> Lua connection is optional, I am fine with it.
>>>>>>
>>>>>> Victor
>>>>>>
>>>>>> On 10 Mar 2010, at 15:19, Michael Gogins wrote:
>>>>>>
>>>>>>> My suggestions, the ones I think the most useful first:
>>>>>>>
>>>>>>> (1) Implement multi-threading using OpenMP throughout Csound.
>>>>>>>
>>>>>>> (2) Embed Lua (LuaJIT, on x86 architectures) in Csound, and
>>>>>>> enable
>>>>>>> writing not only opcodes, but also instrument definitions, in
>>>>>>> this
>>>>>>> dynamic, high-level language.
>>>>>>>
>>>>>>> (3) Redo the VST stuff without the VST SDK, so that we can
>>>>>>> distribute
>>>>>>> vst4cs and CsoundVST on SourceForge.
>>>>>>>
>>>>>>> (4) Add DBus opcodes to Csound (DBus is used by at least some
>>>>>>> implementations of Jack and is a lightweight, high-performance
>>>>>>> message
>>>>>>> bus).
>>>>>>>
>>>>>>> (5) Develop a library of high-quality instrument definitions,
>>>>>>> especially band-limited and physically modeled instruments, that
>>>>>>> can
>>>>>>> be #included in orchestras and interface via the bus and the
>>>>>>> signalflowgraph opcodes.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Mike
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 10, 2010 at 10:08 AM, Victor Lazzarini
>>>>>>>  wrote:
>>>>>>>> Hi everyone,
>>>>>>>> we have two days to develop this ideas page:
>>>>>>>> http://socghop.appspot.com/document/show/user/csound_2010/csound_2010_ideas
>>>>>>>> please help with ideas and improvements to it. I think we could
>>>>>>>> add
>>>>>>>> some
>>>>>>>> short descriptions to each item.
>>>>>>>> Victor
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>>> Try the new software tools for yourself. Speed compiling, find
>>>>>>>> bugs
>>>>>>>> proactively, and fine-tune applications for parallel
>>>>>>>> performance.
>>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>>> _______________________________________________
>>>>>>>> Csound-devel mailing list
>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Michael Gogins
>>>>>>> Irreducible Productions
>>>>>>> http://www.michael-gogins.com
>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>> Try the new software tools for yourself. Speed compiling, find
>>>>>>> bugs
>>>>>>> proactively, and fine-tune applications for parallel  
>>>>>>> performance.
>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Download Intel® Parallel Studio Eval
>>>>>> Try the new software tools for yourself. Speed compiling, find
>>>>>> bugs
>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download Intel® Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

About OpenMP, this is available in mature C/C++ compilers and can, in
practice, be considered a part of the language. In my own work, I find
it easier to get threading right with OpenMP than with pthreads.

About the level of granularity in parallelizing Csound, it is easy to
be unclear. Are you talking about parallelizing opcode internals, or
instrument internals (i.e. running opcodes in parallel), or the
performance loop (running instruments in parallel)?

In Csound, I think it only makes sense, at least at first, to analyze
the list of instruments and determine which ones are not feeding each
other and then parallelize that. That's kperf-level parallelization.
Steven Yi wrote a first stab at this which works in some cases. Is
that the same level as John's work?

About Lua, I do appreciate your concern about additional dependencies.
In fact, I think that as it stands, Csound has too many bolt-ons which
are degrading reliability and maintainability. However, Lua already is
part of the build system, for the Lua interface. So, if one already is
producing the Lua wrappers, embedding Lua would not in fact introduce
any additional dependency.  Frankly, this would be easier to use than
using Lua to operate the API to create instruments.

Regards,
Mike

On Wed, Mar 10, 2010 at 12:24 PM, Steven Yi  wrote:
> Okay, well the issues I emailed just now are the primary ones I can
> think of.  Many thanks for organizing this!
>
> On Wed, Mar 10, 2010 at 12:18 PM, Victor Lazzarini
>  wrote:
>> You can't. Send me a list and I'll put it up. I'll try to incorporate
>> these ideas.
>>
>> Victor
>> On 10 Mar 2010, at 17:12, Steven Yi wrote:
>>
>>> I was going to try to modify the ideas page but couldn't see how to do
>>> it. For the new parser, there's a stub function that should get
>>> implemented for optimization of the parse tree before compilation.This
>>> would be for things like constant folding, dead code elimination,
>>> inlining of constant i-rate variables. We should look at static-single
>>> assignment (SSA) as a basis before performing optimizations.
>>>
>>> For engine work, I'd like to see easy instrument reloading by changing
>>> the role of the parser a bit: csound->Compile() could be run 1-many
>>> times and each definition in ORC could potentially replace a previous
>>> definition.  It would be ideal to allow sending over just an instr
>>> definition to replace a current one, for example.
>>>
>>>
>>> On Wed, Mar 10, 2010 at 12:00 PM, Steven Yi 
>>> wrote:
>>>> I too have reservations about Lua embedded into Csound.  I'd rather
>>>> csound be used by Lua than have it be within the core itself.
>>>>
>>>> If the engine changes are done correctly, one should be able to
>>>> programmatically create an instrument in any language via the API.
>>>>
>>>> On Wed, Mar 10, 2010 at 10:33 AM, Victor Lazzarini
>>>>  wrote:
>>>>> Thanks. Of these, two raise some concerns, at least from me:
>>>>>
>>>>> (1)-> there is already a substantial work on automatic parallelism
>>>>> that John ffitch was developing, using pthreads.
>>>>> We should finish that before thinking of using OpenMP, which is an
>>>>> interesting possibility, but we need to be
>>>>> careful. Also we will need to think at what level the parallelism
>>>>> will
>>>>> take place. I think the level of instrument, which
>>>>> John's work was aimed at, gives the correct granularity
>>>>>
>>>>> (2)-> I'm worried of adding another dependency to Csound. If this
>>>>> could be done in a modular way, so that the
>>>>> Lua connection is optional, I am fine with it.
>>>>>
>>>>> Victor
>>>>>
>>>>> On 10 Mar 2010, at 15:19, Michael Gogins wrote:
>>>>>
>>>>>> My suggestions, the ones I think the most useful first:
>>>>>>
>>>>>> (1) Implement multi-threading using OpenMP throughout Csound.
>>>>>>
>>>>>> (2) Embed Lua (LuaJIT, on x86 architectures) in Csound, and enable
>>>>>> writing not only opcodes, but also instrument definitions, in this
>>>>>> dynamic, high-level language.
>>>>>>
>>>>>> (3) Redo the VST stuff without the VST SDK, so that we can
>>>>>> distribute
>>>>>> vst4cs and CsoundVST on SourceForge.
>>>>>>
>>>>>> (4) Add DBus opcodes to Csound (DBus is used by at least some
>>>>>> implementations of Jack and is a lightweight, high-performance
>>>>>> message
>>>>>> bus).
>>>>>>
>>>>>> (5) Develop a library of high-quality instrument definitions,
>>>>>> especially band-limited and physically modeled instruments, that
>>>>>> can
>>>>>> be #included in orchestras and interface via the bus and the
>>>>>> signalflowgraph opcodes.
>>>>>>
>>>>>> Thanks,
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 10, 2010 at 10:08 AM, Victor Lazzarini
>>>>>>  wrote:
>>>>>>> Hi everyone,
>>>>>>> we have two days to develop this ideas page:
>>>>>>> http://socghop.appspot.com/document/show/user/csound_2010/csound_2010_ideas
>>>>>>> please help with ideas and improvements to it. I think we could
>>>>>>> add
>>>>>>> some
>>>>>>> short descriptions to each item.
>>>>>>> Victor
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>> Try the new software tools for yourself. Speed compiling, find
>>>>>>> bugs
>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Michael Gogins
>>>>>> Irreducible Productions
>>>>>> http://www.michael-gogins.com
>>>>>> Michael dot Gogins at gmail dot com
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Download Intel® Parallel Studio Eval
>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Download Intel® Parallel Studio Eval
>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>> proactively, and fine-tune applications for parallel performance.
>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

To note, I had done some analysis on per-instrument versus finer
grained per-opcode level parallelization.  I don't remember all of
what I had found, but what's sticking out to me is that to match
csound's current non-parallel behavior, you have to always wait for
all instances of an instrument to render before moving on to the next
instrument. I'm not sure if that's valid with sufficient analysis, but
the amount of analysis required would be very great to know if an
opcode internally reads, writes, or read/writes to a shared resource.
At the time I think I estimated that really the only best option would
be to parallelize per-instrument and to do it by running all instances
of an instrument before moving to the next instrument.  I'd be happy
to be wrong though.

On Wed, Mar 10, 2010 at 2:34 PM, Michael Gogins
 wrote:
> About OpenMP, this is available in mature C/C++ compilers and can, in
> practice, be considered a part of the language. In my own work, I find
> it easier to get threading right with OpenMP than with pthreads.
>
> About the level of granularity in parallelizing Csound, it is easy to
> be unclear. Are you talking about parallelizing opcode internals, or
> instrument internals (i.e. running opcodes in parallel), or the
> performance loop (running instruments in parallel)?
>
> In Csound, I think it only makes sense, at least at first, to analyze
> the list of instruments and determine which ones are not feeding each
> other and then parallelize that. That's kperf-level parallelization.
> Steven Yi wrote a first stab at this which works in some cases. Is
> that the same level as John's work?
>
> About Lua, I do appreciate your concern about additional dependencies.
> In fact, I think that as it stands, Csound has too many bolt-ons which
> are degrading reliability and maintainability. However, Lua already is
> part of the build system, for the Lua interface. So, if one already is
> producing the Lua wrappers, embedding Lua would not in fact introduce
> any additional dependency.  Frankly, this would be easier to use than
> using Lua to operate the API to create instruments.
>
> Regards,
> Mike
>
> On Wed, Mar 10, 2010 at 12:24 PM, Steven Yi  wrote:
>> Okay, well the issues I emailed just now are the primary ones I can
>> think of.  Many thanks for organizing this!
>>
>> On Wed, Mar 10, 2010 at 12:18 PM, Victor Lazzarini
>>  wrote:
>>> You can't. Send me a list and I'll put it up. I'll try to incorporate
>>> these ideas.
>>>
>>> Victor
>>> On 10 Mar 2010, at 17:12, Steven Yi wrote:
>>>
>>>> I was going to try to modify the ideas page but couldn't see how to do
>>>> it. For the new parser, there's a stub function that should get
>>>> implemented for optimization of the parse tree before compilation.This
>>>> would be for things like constant folding, dead code elimination,
>>>> inlining of constant i-rate variables. We should look at static-single
>>>> assignment (SSA) as a basis before performing optimizations.
>>>>
>>>> For engine work, I'd like to see easy instrument reloading by changing
>>>> the role of the parser a bit: csound->Compile() could be run 1-many
>>>> times and each definition in ORC could potentially replace a previous
>>>> definition.  It would be ideal to allow sending over just an instr
>>>> definition to replace a current one, for example.
>>>>
>>>>
>>>> On Wed, Mar 10, 2010 at 12:00 PM, Steven Yi 
>>>> wrote:
>>>>> I too have reservations about Lua embedded into Csound.  I'd rather
>>>>> csound be used by Lua than have it be within the core itself.
>>>>>
>>>>> If the engine changes are done correctly, one should be able to
>>>>> programmatically create an instrument in any language via the API.
>>>>>
>>>>> On Wed, Mar 10, 2010 at 10:33 AM, Victor Lazzarini
>>>>>  wrote:
>>>>>> Thanks. Of these, two raise some concerns, at least from me:
>>>>>>
>>>>>> (1)-> there is already a substantial work on automatic parallelism
>>>>>> that John ffitch was developing, using pthreads.
>>>>>> We should finish that before thinking of using OpenMP, which is an
>>>>>> interesting possibility, but we need to be
>>>>>> careful. Also we will need to think at what level the parallelism
>>>>>> will
>>>>>> take place. I think the level of instrument, which
>>>>>> John's work was aimed at, gives the correct granularity
>>>>>>
>>>>>> (2)-> I'm worried of adding another dependency to Csound. If this
>>>>>> could be done in a modular way, so that the
>>>>>> Lua connection is optional, I am fine with it.
>>>>>>
>>>>>> Victor
>>>>>>
>>>>>> On 10 Mar 2010, at 15:19, Michael Gogins wrote:
>>>>>>
>>>>>>> My suggestions, the ones I think the most useful first:
>>>>>>>
>>>>>>> (1) Implement multi-threading using OpenMP throughout Csound.
>>>>>>>
>>>>>>> (2) Embed Lua (LuaJIT, on x86 architectures) in Csound, and enable
>>>>>>> writing not only opcodes, but also instrument definitions, in this
>>>>>>> dynamic, high-level language.
>>>>>>>
>>>>>>> (3) Redo the VST stuff without the VST SDK, so that we can
>>>>>>> distribute
>>>>>>> vst4cs and CsoundVST on SourceForge.
>>>>>>>
>>>>>>> (4) Add DBus opcodes to Csound (DBus is used by at least some
>>>>>>> implementations of Jack and is a lightweight, high-performance
>>>>>>> message
>>>>>>> bus).
>>>>>>>
>>>>>>> (5) Develop a library of high-quality instrument definitions,
>>>>>>> especially band-limited and physically modeled instruments, that
>>>>>>> can
>>>>>>> be #included in orchestras and interface via the bus and the
>>>>>>> signalflowgraph opcodes.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Mike
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 10, 2010 at 10:08 AM, Victor Lazzarini
>>>>>>>  wrote:
>>>>>>>> Hi everyone,
>>>>>>>> we have two days to develop this ideas page:
>>>>>>>> http://socghop.appspot.com/document/show/user/csound_2010/csound_2010_ideas
>>>>>>>> please help with ideas and improvements to it. I think we could
>>>>>>>> add
>>>>>>>> some
>>>>>>>> short descriptions to each item.
>>>>>>>> Victor
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>>> Try the new software tools for yourself. Speed compiling, find
>>>>>>>> bugs
>>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>>> _______________________________________________
>>>>>>>> Csound-devel mailing list
>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Michael Gogins
>>>>>>> Irreducible Productions
>>>>>>> http://www.michael-gogins.com
>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Download Intel® Parallel Studio Eval
>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download Intel® Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

A bit more formally, what is required is that all dependencies of
functions that run in parallel must be satisfied before they begin
running, and that's it.

For csound, we can assume the input drivers and the score always run
before any instrument instances, and that all instrument instances run
before any output drivers, so we can neglect them. I have a question
about instruments that instantiate other instruments: if the new
instrument is actually created only on the next kperiod, we can forget
about that too; otherwise, not.

That leaves the various busses, the function tables, the zak opcodes,
global variables, and the signal flow graph opcodes as potential
dependencies. Are there more?

I think it's doable to take care of analyzing the dependencies on all
of these, but it requires adding to the implementation of each of
these code for tracking dependencies, and then using tables built by
this new code to decide what can run when and what can run in
parallel. At the same time, the gain from merely being able to run
instances of the same instruments in parallel is probably most of the
gain that could be realized in any case; therefore, I think we should
do only that -- certainly, at first.

But, in addition to doing that, we need to protect the potential
dependencies and global data with mutual exclusion to prevent the
corruption of data. With OpenMP this is simple, you just put all
accesses to these data as either 'atomic' or in 'critical' sections.
It's far, far easier than coding a bunch of mutexes, atomic
operations, and critical sections in pthreads directly.

Also with OpenMP, the kind of code that you did with barriers for
running instances of instruments in parallel is simpler to write (your
code was pretty simple already, I have not looked at John's), and I
think much easier to read and understand.

I'll have to look at John's parallel branch code...

Best,
Mike



On Wed, Mar 10, 2010 at 2:43 PM, Steven Yi  wrote:
> To note, I had done some analysis on per-instrument versus finer
> grained per-opcode level parallelization.  I don't remember all of
> what I had found, but what's sticking out to me is that to match
> csound's current non-parallel behavior, you have to always wait for
> all instances of an instrument to render before moving on to the next
> instrument. I'm not sure if that's valid with sufficient analysis, but
> the amount of analysis required would be very great to know if an
> opcode internally reads, writes, or read/writes to a shared resource.
> At the time I think I estimated that really the only best option would
> be to parallelize per-instrument and to do it by running all instances
> of an instrument before moving to the next instrument.  I'd be happy
> to be wrong though.
>
> On Wed, Mar 10, 2010 at 2:34 PM, Michael Gogins
>  wrote:
>> About OpenMP, this is available in mature C/C++ compilers and can, in
>> practice, be considered a part of the language. In my own work, I find
>> it easier to get threading right with OpenMP than with pthreads.
>>
>> About the level of granularity in parallelizing Csound, it is easy to
>> be unclear. Are you talking about parallelizing opcode internals, or
>> instrument internals (i.e. running opcodes in parallel), or the
>> performance loop (running instruments in parallel)?
>>
>> In Csound, I think it only makes sense, at least at first, to analyze
>> the list of instruments and determine which ones are not feeding each
>> other and then parallelize that. That's kperf-level parallelization.
>> Steven Yi wrote a first stab at this which works in some cases. Is
>> that the same level as John's work?
>>
>> About Lua, I do appreciate your concern about additional dependencies.
>> In fact, I think that as it stands, Csound has too many bolt-ons which
>> are degrading reliability and maintainability. However, Lua already is
>> part of the build system, for the Lua interface. So, if one already is
>> producing the Lua wrappers, embedding Lua would not in fact introduce
>> any additional dependency.  Frankly, this would be easier to use than
>> using Lua to operate the API to create instruments.
>>
>> Regards,
>> Mike
>>
>> On Wed, Mar 10, 2010 at 12:24 PM, Steven Yi  wrote:
>>> Okay, well the issues I emailed just now are the primary ones I can
>>> think of.  Many thanks for organizing this!
>>>
>>> On Wed, Mar 10, 2010 at 12:18 PM, Victor Lazzarini
>>>  wrote:
>>>> You can't. Send me a list and I'll put it up. I'll try to incorporate
>>>> these ideas.
>>>>
>>>> Victor
>>>> On 10 Mar 2010, at 17:12, Steven Yi wrote:
>>>>
>>>>> I was going to try to modify the ideas page but couldn't see how to do
>>>>> it. For the new parser, there's a stub function that should get
>>>>> implemented for optimization of the parse tree before compilation.This
>>>>> would be for things like constant folding, dead code elimination,
>>>>> inlining of constant i-rate variables. We should look at static-single
>>>>> assignment (SSA) as a basis before performing optimizations.
>>>>>
>>>>> For engine work, I'd like to see easy instrument reloading by changing
>>>>> the role of the parser a bit: csound->Compile() could be run 1-many
>>>>> times and each definition in ORC could potentially replace a previous
>>>>> definition.  It would be ideal to allow sending over just an instr
>>>>> definition to replace a current one, for example.
>>>>>
>>>>>
>>>>> On Wed, Mar 10, 2010 at 12:00 PM, Steven Yi 
>>>>> wrote:
>>>>>> I too have reservations about Lua embedded into Csound.  I'd rather
>>>>>> csound be used by Lua than have it be within the core itself.
>>>>>>
>>>>>> If the engine changes are done correctly, one should be able to
>>>>>> programmatically create an instrument in any language via the API.
>>>>>>
>>>>>> On Wed, Mar 10, 2010 at 10:33 AM, Victor Lazzarini
>>>>>>  wrote:
>>>>>>> Thanks. Of these, two raise some concerns, at least from me:
>>>>>>>
>>>>>>> (1)-> there is already a substantial work on automatic parallelism
>>>>>>> that John ffitch was developing, using pthreads.
>>>>>>> We should finish that before thinking of using OpenMP, which is an
>>>>>>> interesting possibility, but we need to be
>>>>>>> careful. Also we will need to think at what level the parallelism
>>>>>>> will
>>>>>>> take place. I think the level of instrument, which
>>>>>>> John's work was aimed at, gives the correct granularity
>>>>>>>
>>>>>>> (2)-> I'm worried of adding another dependency to Csound. If this
>>>>>>> could be done in a modular way, so that the
>>>>>>> Lua connection is optional, I am fine with it.
>>>>>>>
>>>>>>> Victor
>>>>>>>
>>>>>>> On 10 Mar 2010, at 15:19, Michael Gogins wrote:
>>>>>>>
>>>>>>>> My suggestions, the ones I think the most useful first:
>>>>>>>>
>>>>>>>> (1) Implement multi-threading using OpenMP throughout Csound.
>>>>>>>>
>>>>>>>> (2) Embed Lua (LuaJIT, on x86 architectures) in Csound, and enable
>>>>>>>> writing not only opcodes, but also instrument definitions, in this
>>>>>>>> dynamic, high-level language.
>>>>>>>>
>>>>>>>> (3) Redo the VST stuff without the VST SDK, so that we can
>>>>>>>> distribute
>>>>>>>> vst4cs and CsoundVST on SourceForge.
>>>>>>>>
>>>>>>>> (4) Add DBus opcodes to Csound (DBus is used by at least some
>>>>>>>> implementations of Jack and is a lightweight, high-performance
>>>>>>>> message
>>>>>>>> bus).
>>>>>>>>
>>>>>>>> (5) Develop a library of high-quality instrument definitions,
>>>>>>>> especially band-limited and physically modeled instruments, that
>>>>>>>> can
>>>>>>>> be #included in orchestras and interface via the bus and the
>>>>>>>> signalflowgraph opcodes.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Mike
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Mar 10, 2010 at 10:08 AM, Victor Lazzarini
>>>>>>>>  wrote:
>>>>>>>>> Hi everyone,
>>>>>>>>> we have two days to develop this ideas page:
>>>>>>>>> http://socghop.appspot.com/document/show/user/csound_2010/csound_2010_ideas
>>>>>>>>> please help with ideas and improvements to it. I think we could
>>>>>>>>> add
>>>>>>>>> some
>>>>>>>>> short descriptions to each item.
>>>>>>>>> Victor
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>>>> Try the new software tools for yourself. Speed compiling, find
>>>>>>>>> bugs
>>>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>>>> _______________________________________________
>>>>>>>>> Csound-devel mailing list
>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Michael Gogins
>>>>>>>> Irreducible Productions
>>>>>>>> http://www.michael-gogins.com
>>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>>> _______________________________________________
>>>>>>>> Csound-devel mailing list
>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Download Intel® Parallel Studio Eval
>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>> proactively, and fine-tune applications for parallel performance.
>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download Intel® Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Right, but we have to protect blocks of user code too in addition to
low-level code, i.e. a user writes;

if (gi_tables_myinstrument == 0) then
  gi_tables_myinstrument ftgen 0, 0, 65537, 10, 1
  ... other initialization code ...
endif

There needs to be a way to protect this block of code.  I added the
mutex opcodes for this so that the user can determine how the code
should be protected. I didn't see a way for a compiler to
automatically determine if all the code between the read and write can
be protected automatically.

I think using OpenMP or not isn't going to address this issue at least.

On Wed, Mar 10, 2010 at 2:59 PM, Michael Gogins
 wrote:
> A bit more formally, what is required is that all dependencies of
> functions that run in parallel must be satisfied before they begin
> running, and that's it.
>
> For csound, we can assume the input drivers and the score always run
> before any instrument instances, and that all instrument instances run
> before any output drivers, so we can neglect them. I have a question
> about instruments that instantiate other instruments: if the new
> instrument is actually created only on the next kperiod, we can forget
> about that too; otherwise, not.
>
> That leaves the various busses, the function tables, the zak opcodes,
> global variables, and the signal flow graph opcodes as potential
> dependencies. Are there more?
>
> I think it's doable to take care of analyzing the dependencies on all
> of these, but it requires adding to the implementation of each of
> these code for tracking dependencies, and then using tables built by
> this new code to decide what can run when and what can run in
> parallel. At the same time, the gain from merely being able to run
> instances of the same instruments in parallel is probably most of the
> gain that could be realized in any case; therefore, I think we should
> do only that -- certainly, at first.
>
> But, in addition to doing that, we need to protect the potential
> dependencies and global data with mutual exclusion to prevent the
> corruption of data. With OpenMP this is simple, you just put all
> accesses to these data as either 'atomic' or in 'critical' sections.
> It's far, far easier than coding a bunch of mutexes, atomic
> operations, and critical sections in pthreads directly.
>
> Also with OpenMP, the kind of code that you did with barriers for
> running instances of instruments in parallel is simpler to write (your
> code was pretty simple already, I have not looked at John's), and I
> think much easier to read and understand.
>
> I'll have to look at John's parallel branch code...
>
> Best,
> Mike
>
>
>
> On Wed, Mar 10, 2010 at 2:43 PM, Steven Yi  wrote:
>> To note, I had done some analysis on per-instrument versus finer
>> grained per-opcode level parallelization.  I don't remember all of
>> what I had found, but what's sticking out to me is that to match
>> csound's current non-parallel behavior, you have to always wait for
>> all instances of an instrument to render before moving on to the next
>> instrument. I'm not sure if that's valid with sufficient analysis, but
>> the amount of analysis required would be very great to know if an
>> opcode internally reads, writes, or read/writes to a shared resource.
>> At the time I think I estimated that really the only best option would
>> be to parallelize per-instrument and to do it by running all instances
>> of an instrument before moving to the next instrument.  I'd be happy
>> to be wrong though.
>>
>> On Wed, Mar 10, 2010 at 2:34 PM, Michael Gogins
>>  wrote:
>>> About OpenMP, this is available in mature C/C++ compilers and can, in
>>> practice, be considered a part of the language. In my own work, I find
>>> it easier to get threading right with OpenMP than with pthreads.
>>>
>>> About the level of granularity in parallelizing Csound, it is easy to
>>> be unclear. Are you talking about parallelizing opcode internals, or
>>> instrument internals (i.e. running opcodes in parallel), or the
>>> performance loop (running instruments in parallel)?
>>>
>>> In Csound, I think it only makes sense, at least at first, to analyze
>>> the list of instruments and determine which ones are not feeding each
>>> other and then parallelize that. That's kperf-level parallelization.
>>> Steven Yi wrote a first stab at this which works in some cases. Is
>>> that the same level as John's work?
>>>
>>> About Lua, I do appreciate your concern about additional dependencies.
>>> In fact, I think that as it stands, Csound has too many bolt-ons which
>>> are degrading reliability and maintainability. However, Lua already is
>>> part of the build system, for the Lua interface. So, if one already is
>>> producing the Lua wrappers, embedding Lua would not in fact introduce
>>> any additional dependency.  Frankly, this would be easier to use than
>>> using Lua to operate the API to create instruments.
>>>
>>> Regards,
>>> Mike
>>>
>>> On Wed, Mar 10, 2010 at 12:24 PM, Steven Yi  wrote:
>>>> Okay, well the issues I emailed just now are the primary ones I can
>>>> think of.  Many thanks for organizing this!
>>>>
>>>> On Wed, Mar 10, 2010 at 12:18 PM, Victor Lazzarini
>>>>  wrote:
>>>>> You can't. Send me a list and I'll put it up. I'll try to incorporate
>>>>> these ideas.
>>>>>
>>>>> Victor
>>>>> On 10 Mar 2010, at 17:12, Steven Yi wrote:
>>>>>
>>>>>> I was going to try to modify the ideas page but couldn't see how to do
>>>>>> it. For the new parser, there's a stub function that should get
>>>>>> implemented for optimization of the parse tree before compilation.This
>>>>>> would be for things like constant folding, dead code elimination,
>>>>>> inlining of constant i-rate variables. We should look at static-single
>>>>>> assignment (SSA) as a basis before performing optimizations.
>>>>>>
>>>>>> For engine work, I'd like to see easy instrument reloading by changing
>>>>>> the role of the parser a bit: csound->Compile() could be run 1-many
>>>>>> times and each definition in ORC could potentially replace a previous
>>>>>> definition.  It would be ideal to allow sending over just an instr
>>>>>> definition to replace a current one, for example.
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 10, 2010 at 12:00 PM, Steven Yi 
>>>>>> wrote:
>>>>>>> I too have reservations about Lua embedded into Csound.  I'd rather
>>>>>>> csound be used by Lua than have it be within the core itself.
>>>>>>>
>>>>>>> If the engine changes are done correctly, one should be able to
>>>>>>> programmatically create an instrument in any language via the API.
>>>>>>>
>>>>>>> On Wed, Mar 10, 2010 at 10:33 AM, Victor Lazzarini
>>>>>>>  wrote:
>>>>>>>> Thanks. Of these, two raise some concerns, at least from me:
>>>>>>>>
>>>>>>>> (1)-> there is already a substantial work on automatic parallelism
>>>>>>>> that John ffitch was developing, using pthreads.
>>>>>>>> We should finish that before thinking of using OpenMP, which is an
>>>>>>>> interesting possibility, but we need to be
>>>>>>>> careful. Also we will need to think at what level the parallelism
>>>>>>>> will
>>>>>>>> take place. I think the level of instrument, which
>>>>>>>> John's work was aimed at, gives the correct granularity
>>>>>>>>
>>>>>>>> (2)-> I'm worried of adding another dependency to Csound. If this
>>>>>>>> could be done in a modular way, so that the
>>>>>>>> Lua connection is optional, I am fine with it.
>>>>>>>>
>>>>>>>> Victor
>>>>>>>>
>>>>>>>> On 10 Mar 2010, at 15:19, Michael Gogins wrote:
>>>>>>>>
>>>>>>>>> My suggestions, the ones I think the most useful first:
>>>>>>>>>
>>>>>>>>> (1) Implement multi-threading using OpenMP throughout Csound.
>>>>>>>>>
>>>>>>>>> (2) Embed Lua (LuaJIT, on x86 architectures) in Csound, and enable
>>>>>>>>> writing not only opcodes, but also instrument definitions, in this
>>>>>>>>> dynamic, high-level language.
>>>>>>>>>
>>>>>>>>> (3) Redo the VST stuff without the VST SDK, so that we can
>>>>>>>>> distribute
>>>>>>>>> vst4cs and CsoundVST on SourceForge.
>>>>>>>>>
>>>>>>>>> (4) Add DBus opcodes to Csound (DBus is used by at least some
>>>>>>>>> implementations of Jack and is a lightweight, high-performance
>>>>>>>>> message
>>>>>>>>> bus).
>>>>>>>>>
>>>>>>>>> (5) Develop a library of high-quality instrument definitions,
>>>>>>>>> especially band-limited and physically modeled instruments, that
>>>>>>>>> can
>>>>>>>>> be #included in orchestras and interface via the bus and the
>>>>>>>>> signalflowgraph opcodes.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Mike
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Mar 10, 2010 at 10:08 AM, Victor Lazzarini
>>>>>>>>>  wrote:
>>>>>>>>>> Hi everyone,
>>>>>>>>>> we have two days to develop this ideas page:
>>>>>>>>>> http://socghop.appspot.com/document/show/user/csound_2010/csound_2010_ideas
>>>>>>>>>> please help with ideas and improvements to it. I think we could
>>>>>>>>>> add
>>>>>>>>>> some
>>>>>>>>>> short descriptions to each item.
>>>>>>>>>> Victor
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>>>>> Try the new software tools for yourself. Speed compiling, find
>>>>>>>>>> bugs
>>>>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Michael Gogins
>>>>>>>>> Irreducible Productions
>>>>>>>>> http://www.michael-gogins.com
>>>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>>>> _______________________________________________
>>>>>>>>> Csound-devel mailing list
>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>>> _______________________________________________
>>>>>>>> Csound-devel mailing list
>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Download Intel® Parallel Studio Eval
>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Download Intel® Parallel Studio Eval
>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>> proactively, and fine-tune applications for parallel performance.
>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download Intel® Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Of course, you are right.

Best,
Mike

On Wed, Mar 10, 2010 at 3:34 PM, Steven Yi  wrote:
> Right, but we have to protect blocks of user code too in addition to
> low-level code, i.e. a user writes;
>
> if (gi_tables_myinstrument == 0) then
>  gi_tables_myinstrument ftgen 0, 0, 65537, 10, 1
>  ... other initialization code ...
> endif
>
> There needs to be a way to protect this block of code.  I added the
> mutex opcodes for this so that the user can determine how the code
> should be protected. I didn't see a way for a compiler to
> automatically determine if all the code between the read and write can
> be protected automatically.
>
> I think using OpenMP or not isn't going to address this issue at least.
>
> On Wed, Mar 10, 2010 at 2:59 PM, Michael Gogins
>  wrote:
>> A bit more formally, what is required is that all dependencies of
>> functions that run in parallel must be satisfied before they begin
>> running, and that's it.
>>
>> For csound, we can assume the input drivers and the score always run
>> before any instrument instances, and that all instrument instances run
>> before any output drivers, so we can neglect them. I have a question
>> about instruments that instantiate other instruments: if the new
>> instrument is actually created only on the next kperiod, we can forget
>> about that too; otherwise, not.
>>
>> That leaves the various busses, the function tables, the zak opcodes,
>> global variables, and the signal flow graph opcodes as potential
>> dependencies. Are there more?
>>
>> I think it's doable to take care of analyzing the dependencies on all
>> of these, but it requires adding to the implementation of each of
>> these code for tracking dependencies, and then using tables built by
>> this new code to decide what can run when and what can run in
>> parallel. At the same time, the gain from merely being able to run
>> instances of the same instruments in parallel is probably most of the
>> gain that could be realized in any case; therefore, I think we should
>> do only that -- certainly, at first.
>>
>> But, in addition to doing that, we need to protect the potential
>> dependencies and global data with mutual exclusion to prevent the
>> corruption of data. With OpenMP this is simple, you just put all
>> accesses to these data as either 'atomic' or in 'critical' sections.
>> It's far, far easier than coding a bunch of mutexes, atomic
>> operations, and critical sections in pthreads directly.
>>
>> Also with OpenMP, the kind of code that you did with barriers for
>> running instances of instruments in parallel is simpler to write (your
>> code was pretty simple already, I have not looked at John's), and I
>> think much easier to read and understand.
>>
>> I'll have to look at John's parallel branch code...
>>
>> Best,
>> Mike
>>
>>
>>
>> On Wed, Mar 10, 2010 at 2:43 PM, Steven Yi  wrote:
>>> To note, I had done some analysis on per-instrument versus finer
>>> grained per-opcode level parallelization.  I don't remember all of
>>> what I had found, but what's sticking out to me is that to match
>>> csound's current non-parallel behavior, you have to always wait for
>>> all instances of an instrument to render before moving on to the next
>>> instrument. I'm not sure if that's valid with sufficient analysis, but
>>> the amount of analysis required would be very great to know if an
>>> opcode internally reads, writes, or read/writes to a shared resource.
>>> At the time I think I estimated that really the only best option would
>>> be to parallelize per-instrument and to do it by running all instances
>>> of an instrument before moving to the next instrument.  I'd be happy
>>> to be wrong though.
>>>
>>> On Wed, Mar 10, 2010 at 2:34 PM, Michael Gogins
>>>  wrote:
>>>> About OpenMP, this is available in mature C/C++ compilers and can, in
>>>> practice, be considered a part of the language. In my own work, I find
>>>> it easier to get threading right with OpenMP than with pthreads.
>>>>
>>>> About the level of granularity in parallelizing Csound, it is easy to
>>>> be unclear. Are you talking about parallelizing opcode internals, or
>>>> instrument internals (i.e. running opcodes in parallel), or the
>>>> performance loop (running instruments in parallel)?
>>>>
>>>> In Csound, I think it only makes sense, at least at first, to analyze
>>>> the list of instruments and determine which ones are not feeding each
>>>> other and then parallelize that. That's kperf-level parallelization.
>>>> Steven Yi wrote a first stab at this which works in some cases. Is
>>>> that the same level as John's work?
>>>>
>>>> About Lua, I do appreciate your concern about additional dependencies.
>>>> In fact, I think that as it stands, Csound has too many bolt-ons which
>>>> are degrading reliability and maintainability. However, Lua already is
>>>> part of the build system, for the Lua interface. So, if one already is
>>>> producing the Lua wrappers, embedding Lua would not in fact introduce
>>>> any additional dependency.  Frankly, this would be easier to use than
>>>> using Lua to operate the API to create instruments.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> On Wed, Mar 10, 2010 at 12:24 PM, Steven Yi  wrote:
>>>>> Okay, well the issues I emailed just now are the primary ones I can
>>>>> think of.  Many thanks for organizing this!
>>>>>
>>>>> On Wed, Mar 10, 2010 at 12:18 PM, Victor Lazzarini
>>>>>  wrote:
>>>>>> You can't. Send me a list and I'll put it up. I'll try to incorporate
>>>>>> these ideas.
>>>>>>
>>>>>> Victor
>>>>>> On 10 Mar 2010, at 17:12, Steven Yi wrote:
>>>>>>
>>>>>>> I was going to try to modify the ideas page but couldn't see how to do
>>>>>>> it. For the new parser, there's a stub function that should get
>>>>>>> implemented for optimization of the parse tree before compilation.This
>>>>>>> would be for things like constant folding, dead code elimination,
>>>>>>> inlining of constant i-rate variables. We should look at static-single
>>>>>>> assignment (SSA) as a basis before performing optimizations.
>>>>>>>
>>>>>>> For engine work, I'd like to see easy instrument reloading by changing
>>>>>>> the role of the parser a bit: csound->Compile() could be run 1-many
>>>>>>> times and each definition in ORC could potentially replace a previous
>>>>>>> definition.  It would be ideal to allow sending over just an instr
>>>>>>> definition to replace a current one, for example.
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 10, 2010 at 12:00 PM, Steven Yi 
>>>>>>> wrote:
>>>>>>>> I too have reservations about Lua embedded into Csound.  I'd rather
>>>>>>>> csound be used by Lua than have it be within the core itself.
>>>>>>>>
>>>>>>>> If the engine changes are done correctly, one should be able to
>>>>>>>> programmatically create an instrument in any language via the API.
>>>>>>>>
>>>>>>>> On Wed, Mar 10, 2010 at 10:33 AM, Victor Lazzarini
>>>>>>>>  wrote:
>>>>>>>>> Thanks. Of these, two raise some concerns, at least from me:
>>>>>>>>>
>>>>>>>>> (1)-> there is already a substantial work on automatic parallelism
>>>>>>>>> that John ffitch was developing, using pthreads.
>>>>>>>>> We should finish that before thinking of using OpenMP, which is an
>>>>>>>>> interesting possibility, but we need to be
>>>>>>>>> careful. Also we will need to think at what level the parallelism
>>>>>>>>> will
>>>>>>>>> take place. I think the level of instrument, which
>>>>>>>>> John's work was aimed at, gives the correct granularity
>>>>>>>>>
>>>>>>>>> (2)-> I'm worried of adding another dependency to Csound. If this
>>>>>>>>> could be done in a modular way, so that the
>>>>>>>>> Lua connection is optional, I am fine with it.
>>>>>>>>>
>>>>>>>>> Victor
>>>>>>>>>
>>>>>>>>> On 10 Mar 2010, at 15:19, Michael Gogins wrote:
>>>>>>>>>
>>>>>>>>>> My suggestions, the ones I think the most useful first:
>>>>>>>>>>
>>>>>>>>>> (1) Implement multi-threading using OpenMP throughout Csound.
>>>>>>>>>>
>>>>>>>>>> (2) Embed Lua (LuaJIT, on x86 architectures) in Csound, and enable
>>>>>>>>>> writing not only opcodes, but also instrument definitions, in this
>>>>>>>>>> dynamic, high-level language.
>>>>>>>>>>
>>>>>>>>>> (3) Redo the VST stuff without the VST SDK, so that we can
>>>>>>>>>> distribute
>>>>>>>>>> vst4cs and CsoundVST on SourceForge.
>>>>>>>>>>
>>>>>>>>>> (4) Add DBus opcodes to Csound (DBus is used by at least some
>>>>>>>>>> implementations of Jack and is a lightweight, high-performance
>>>>>>>>>> message
>>>>>>>>>> bus).
>>>>>>>>>>
>>>>>>>>>> (5) Develop a library of high-quality instrument definitions,
>>>>>>>>>> especially band-limited and physically modeled instruments, that
>>>>>>>>>> can
>>>>>>>>>> be #included in orchestras and interface via the bus and the
>>>>>>>>>> signalflowgraph opcodes.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Mike
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Mar 10, 2010 at 10:08 AM, Victor Lazzarini
>>>>>>>>>>  wrote:
>>>>>>>>>>> Hi everyone,
>>>>>>>>>>> we have two days to develop this ideas page:
>>>>>>>>>>> http://socghop.appspot.com/document/show/user/csound_2010/csound_2010_ideas
>>>>>>>>>>> please help with ideas and improvements to it. I think we could
>>>>>>>>>>> add
>>>>>>>>>>> some
>>>>>>>>>>> short descriptions to each item.
>>>>>>>>>>> Victor
>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>>>>>> Try the new software tools for yourself. Speed compiling, find
>>>>>>>>>>> bugs
>>>>>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Michael Gogins
>>>>>>>>>> Irreducible Productions
>>>>>>>>>> http://www.michael-gogins.com
>>>>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>>>> _______________________________________________
>>>>>>>>> Csound-devel mailing list
>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Download Intel® Parallel Studio Eval
>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Download Intel® Parallel Studio Eval
>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>> proactively, and fine-tune applications for parallel performance.
>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://www.michael-gogins.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download Intel® Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

To expand a bit... the code will run without crashing if we do as I
suggest, but the data in the table could still be messed up without
your Csound mutexes.

Best,
Mike

On Wed, Mar 10, 2010 at 3:34 PM, Steven Yi  wrote:
> Right, but we have to protect blocks of user code too in addition to
> low-level code, i.e. a user writes;
>
> if (gi_tables_myinstrument == 0) then
>  gi_tables_myinstrument ftgen 0, 0, 65537, 10, 1
>  ... other initialization code ...
> endif
>
> There needs to be a way to protect this block of code.  I added the
> mutex opcodes for this so that the user can determine how the code
> should be protected. I didn't see a way for a compiler to
> automatically determine if all the code between the read and write can
> be protected automatically.
>
> I think using OpenMP or not isn't going to address this issue at least.
>
> On Wed, Mar 10, 2010 at 2:59 PM, Michael Gogins
>  wrote:
>> A bit more formally, what is required is that all dependencies of
>> functions that run in parallel must be satisfied before they begin
>> running, and that's it.
>>
>> For csound, we can assume the input drivers and the score always run
>> before any instrument instances, and that all instrument instances run
>> before any output drivers, so we can neglect them. I have a question
>> about instruments that instantiate other instruments: if the new
>> instrument is actually created only on the next kperiod, we can forget
>> about that too; otherwise, not.
>>
>> That leaves the various busses, the function tables, the zak opcodes,
>> global variables, and the signal flow graph opcodes as potential
>> dependencies. Are there more?
>>
>> I think it's doable to take care of analyzing the dependencies on all
>> of these, but it requires adding to the implementation of each of
>> these code for tracking dependencies, and then using tables built by
>> this new code to decide what can run when and what can run in
>> parallel. At the same time, the gain from merely being able to run
>> instances of the same instruments in parallel is probably most of the
>> gain that could be realized in any case; therefore, I think we should
>> do only that -- certainly, at first.
>>
>> But, in addition to doing that, we need to protect the potential
>> dependencies and global data with mutual exclusion to prevent the
>> corruption of data. With OpenMP this is simple, you just put all
>> accesses to these data as either 'atomic' or in 'critical' sections.
>> It's far, far easier than coding a bunch of mutexes, atomic
>> operations, and critical sections in pthreads directly.
>>
>> Also with OpenMP, the kind of code that you did with barriers for
>> running instances of instruments in parallel is simpler to write (your
>> code was pretty simple already, I have not looked at John's), and I
>> think much easier to read and understand.
>>
>> I'll have to look at John's parallel branch code...
>>
>> Best,
>> Mike
>>
>>
>>
>> On Wed, Mar 10, 2010 at 2:43 PM, Steven Yi  wrote:
>>> To note, I had done some analysis on per-instrument versus finer
>>> grained per-opcode level parallelization.  I don't remember all of
>>> what I had found, but what's sticking out to me is that to match
>>> csound's current non-parallel behavior, you have to always wait for
>>> all instances of an instrument to render before moving on to the next
>>> instrument. I'm not sure if that's valid with sufficient analysis, but
>>> the amount of analysis required would be very great to know if an
>>> opcode internally reads, writes, or read/writes to a shared resource.
>>> At the time I think I estimated that really the only best option would
>>> be to parallelize per-instrument and to do it by running all instances
>>> of an instrument before moving to the next instrument.  I'd be happy
>>> to be wrong though.
>>>
>>> On Wed, Mar 10, 2010 at 2:34 PM, Michael Gogins
>>>  wrote:
>>>> About OpenMP, this is available in mature C/C++ compilers and can, in
>>>> practice, be considered a part of the language. In my own work, I find
>>>> it easier to get threading right with OpenMP than with pthreads.
>>>>
>>>> About the level of granularity in parallelizing Csound, it is easy to
>>>> be unclear. Are you talking about parallelizing opcode internals, or
>>>> instrument internals (i.e. running opcodes in parallel), or the
>>>> performance loop (running instruments in parallel)?
>>>>
>>>> In Csound, I think it only makes sense, at least at first, to analyze
>>>> the list of instruments and determine which ones are not feeding each
>>>> other and then parallelize that. That's kperf-level parallelization.
>>>> Steven Yi wrote a first stab at this which works in some cases. Is
>>>> that the same level as John's work?
>>>>
>>>> About Lua, I do appreciate your concern about additional dependencies.
>>>> In fact, I think that as it stands, Csound has too many bolt-ons which
>>>> are degrading reliability and maintainability. However, Lua already is
>>>> part of the build system, for the Lua interface. So, if one already is
>>>> producing the Lua wrappers, embedding Lua would not in fact introduce
>>>> any additional dependency.  Frankly, this would be easier to use than
>>>> using Lua to operate the API to create instruments.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> On Wed, Mar 10, 2010 at 12:24 PM, Steven Yi  wrote:
>>>>> Okay, well the issues I emailed just now are the primary ones I can
>>>>> think of.  Many thanks for organizing this!
>>>>>
>>>>> On Wed, Mar 10, 2010 at 12:18 PM, Victor Lazzarini
>>>>>  wrote:
>>>>>> You can't. Send me a list and I'll put it up. I'll try to incorporate
>>>>>> these ideas.
>>>>>>
>>>>>> Victor
>>>>>> On 10 Mar 2010, at 17:12, Steven Yi wrote:
>>>>>>
>>>>>>> I was going to try to modify the ideas page but couldn't see how to do
>>>>>>> it. For the new parser, there's a stub function that should get
>>>>>>> implemented for optimization of the parse tree before compilation.This
>>>>>>> would be for things like constant folding, dead code elimination,
>>>>>>> inlining of constant i-rate variables. We should look at static-single
>>>>>>> assignment (SSA) as a basis before performing optimizations.
>>>>>>>
>>>>>>> For engine work, I'd like to see easy instrument reloading by changing
>>>>>>> the role of the parser a bit: csound->Compile() could be run 1-many
>>>>>>> times and each definition in ORC could potentially replace a previous
>>>>>>> definition.  It would be ideal to allow sending over just an instr
>>>>>>> definition to replace a current one, for example.
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 10, 2010 at 12:00 PM, Steven Yi 
>>>>>>> wrote:
>>>>>>>> I too have reservations about Lua embedded into Csound.  I'd rather
>>>>>>>> csound be used by Lua than have it be within the core itself.
>>>>>>>>
>>>>>>>> If the engine changes are done correctly, one should be able to
>>>>>>>> programmatically create an instrument in any language via the API.
>>>>>>>>
>>>>>>>> On Wed, Mar 10, 2010 at 10:33 AM, Victor Lazzarini
>>>>>>>>  wrote:
>>>>>>>>> Thanks. Of these, two raise some concerns, at least from me:
>>>>>>>>>
>>>>>>>>> (1)-> there is already a substantial work on automatic parallelism
>>>>>>>>> that John ffitch was developing, using pthreads.
>>>>>>>>> We should finish that before thinking of using OpenMP, which is an
>>>>>>>>> interesting possibility, but we need to be
>>>>>>>>> careful. Also we will need to think at what level the parallelism
>>>>>>>>> will
>>>>>>>>> take place. I think the level of instrument, which
>>>>>>>>> John's work was aimed at, gives the correct granularity
>>>>>>>>>
>>>>>>>>> (2)-> I'm worried of adding another dependency to Csound. If this
>>>>>>>>> could be done in a modular way, so that the
>>>>>>>>> Lua connection is optional, I am fine with it.
>>>>>>>>>
>>>>>>>>> Victor
>>>>>>>>>
>>>>>>>>> On 10 Mar 2010, at 15:19, Michael Gogins wrote:
>>>>>>>>>
>>>>>>>>>> My suggestions, the ones I think the most useful first:
>>>>>>>>>>
>>>>>>>>>> (1) Implement multi-threading using OpenMP throughout Csound.
>>>>>>>>>>
>>>>>>>>>> (2) Embed Lua (LuaJIT, on x86 architectures) in Csound, and enable
>>>>>>>>>> writing not only opcodes, but also instrument definitions, in this
>>>>>>>>>> dynamic, high-level language.
>>>>>>>>>>
>>>>>>>>>> (3) Redo the VST stuff without the VST SDK, so that we can
>>>>>>>>>> distribute
>>>>>>>>>> vst4cs and CsoundVST on SourceForge.
>>>>>>>>>>
>>>>>>>>>> (4) Add DBus opcodes to Csound (DBus is used by at least some
>>>>>>>>>> implementations of Jack and is a lightweight, high-performance
>>>>>>>>>> message
>>>>>>>>>> bus).
>>>>>>>>>>
>>>>>>>>>> (5) Develop a library of high-quality instrument definitions,
>>>>>>>>>> especially band-limited and physically modeled instruments, that
>>>>>>>>>> can
>>>>>>>>>> be #included in orchestras and interface via the bus and the
>>>>>>>>>> signalflowgraph opcodes.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Mike
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Mar 10, 2010 at 10:08 AM, Victor Lazzarini
>>>>>>>>>>  wrote:
>>>>>>>>>>> Hi everyone,
>>>>>>>>>>> we have two days to develop this ideas page:
>>>>>>>>>>> http://socghop.appspot.com/document/show/user/csound_2010/csound_2010_ideas
>>>>>>>>>>> please help with ideas and improvements to it. I think we could
>>>>>>>>>>> add
>>>>>>>>>>> some
>>>>>>>>>>> short descriptions to each item.
>>>>>>>>>>> Victor
>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>>>>>> Try the new software tools for yourself. Speed compiling, find
>>>>>>>>>>> bugs
>>>>>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Michael Gogins
>>>>>>>>>> Irreducible Productions
>>>>>>>>>> http://www.michael-gogins.com
>>>>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Csound-devel mailing list
>>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>>>> _______________________________________________
>>>>>>>>> Csound-devel mailing list
>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Download Intel® Parallel Studio Eval
>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Download Intel® Parallel Studio Eval
>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>> proactively, and fine-tune applications for parallel performance.
>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://www.michael-gogins.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download Intel® Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net