I discussed multi-core software synthesis briefly with Miller
Puckette, author of Pure Data, at the ICMC on Friday.

It seems multi-core support in Pure Data is minimal and hard to
improve. A separate Pure Data process is actually spawned for each
concurrent object, and inlet/outlet ports for concurrent objects
therefore are special, using pipes. I should check on SuperCollider
and Max.

I'm examining the ParCS branch in Csound CVS, and it looks like Csound
may have the potential to get this right.

I wonder if the granularity of threading in ParCS is not too small.
Right now nobody is going to have more than 4 or at most 8 cores. It
seems to me that most Csound orchestras will have several instruments
with multiple instances. In such cases instrument instances are a
better level of granularity than opcode instances. However, the ParCS
branch does seem to have the right logical design for concurrent
opcode instances, it generates a directed acyclical graph of opcode
instances implemented with an adjacency matrix, and synchronizes
global variables.

The prototype concurrent Csound created by Steven Yi and myself,
simple though it is, is potentially much better than anything that
Pure Data is likely to do. I do not know about SuperCollider or
Max/MSP. Adding critical sections to API calls, which would involve
little effort, would vastly enlarge the cases in which this version
could safely be used.

But the ParCS code, if completed and working, has a better design and
may be better in practice than what Steven and I were doing. It is
certainly the right general approach for dozens or hundreds of cores,
because with concurrent opcode instances you can use many more threads
than with concurrent instrument instances.

So here are my questions:

(1) Is the ParCS branch actually working?

(2) What are its limitations?

(3) Does it work only with the new parser? (I would guess so).

(4) What would be the pros and cons of replacing pthreads with OpenMP
in the ParCS code? One of the pros would be considerably simpler code.

Regards,
Mike

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

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

This appears to be what is happening, or part of it anyway, in SuperCollider:

http://lac.linuxaudio.org/2010/papers/32.pdf

If I'm not mistaken, the ideas are somewhat similar to the ParCS
design. But it's absurd that they didn't implement off-line rendering
(i.e. non-real-time rendering to a soundfile)...

Regards,
Mike

On Sun, Jun 6, 2010 at 3:32 PM, Michael Gogins  wrote:
> I discussed multi-core software synthesis briefly with Miller
> Puckette, author of Pure Data, at the ICMC on Friday.
>
> It seems multi-core support in Pure Data is minimal and hard to
> improve. A separate Pure Data process is actually spawned for each
> concurrent object, and inlet/outlet ports for concurrent objects
> therefore are special, using pipes. I should check on SuperCollider
> and Max.
>
> I'm examining the ParCS branch in Csound CVS, and it looks like Csound
> may have the potential to get this right.
>
> I wonder if the granularity of threading in ParCS is not too small.
> Right now nobody is going to have more than 4 or at most 8 cores. It
> seems to me that most Csound orchestras will have several instruments
> with multiple instances. In such cases instrument instances are a
> better level of granularity than opcode instances. However, the ParCS
> branch does seem to have the right logical design for concurrent
> opcode instances, it generates a directed acyclical graph of opcode
> instances implemented with an adjacency matrix, and synchronizes
> global variables.
>
> The prototype concurrent Csound created by Steven Yi and myself,
> simple though it is, is potentially much better than anything that
> Pure Data is likely to do. I do not know about SuperCollider or
> Max/MSP. Adding critical sections to API calls, which would involve
> little effort, would vastly enlarge the cases in which this version
> could safely be used.
>
> But the ParCS code, if completed and working, has a better design and
> may be better in practice than what Steven and I were doing. It is
> certainly the right general approach for dozens or hundreds of cores,
> because with concurrent opcode instances you can use many more threads
> than with concurrent instrument instances.
>
> So here are my questions:
>
> (1) Is the ParCS branch actually working?
>
> (2) What are its limitations?
>
> (3) Does it work only with the new parser? (I would guess so).
>
> (4) What would be the pros and cons of replacing pthreads with OpenMP
> in the ParCS code? One of the pros would be considerably simpler code.
>
> Regards,
> Mike
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>



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

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Note that as far as I know this is SuperCollider Lang-compatible,but  
it's not supercollider itself. It seems to be either a fork or a  
completely separate project. I am not sure how mainstream this is  
likely to become.

Victor

On 6 Jun 2010, at 20:40, Michael Gogins wrote:

> This appears to be what is happening, or part of it anyway, in  
> SuperCollider:
>
> http://lac.linuxaudio.org/2010/papers/32.pdf
>
> If I'm not mistaken, the ideas are somewhat similar to the ParCS
> design. But it's absurd that they didn't implement off-line rendering
> (i.e. non-real-time rendering to a soundfile)...
>
> Regards,
> Mike
>
> On Sun, Jun 6, 2010 at 3:32 PM, Michael Gogins  > wrote:
>> I discussed multi-core software synthesis briefly with Miller
>> Puckette, author of Pure Data, at the ICMC on Friday.
>>
>> It seems multi-core support in Pure Data is minimal and hard to
>> improve. A separate Pure Data process is actually spawned for each
>> concurrent object, and inlet/outlet ports for concurrent objects
>> therefore are special, using pipes. I should check on SuperCollider
>> and Max.
>>
>> I'm examining the ParCS branch in Csound CVS, and it looks like  
>> Csound
>> may have the potential to get this right.
>>
>> I wonder if the granularity of threading in ParCS is not too small.
>> Right now nobody is going to have more than 4 or at most 8 cores. It
>> seems to me that most Csound orchestras will have several instruments
>> with multiple instances. In such cases instrument instances are a
>> better level of granularity than opcode instances. However, the ParCS
>> branch does seem to have the right logical design for concurrent
>> opcode instances, it generates a directed acyclical graph of opcode
>> instances implemented with an adjacency matrix, and synchronizes
>> global variables.
>>
>> The prototype concurrent Csound created by Steven Yi and myself,
>> simple though it is, is potentially much better than anything that
>> Pure Data is likely to do. I do not know about SuperCollider or
>> Max/MSP. Adding critical sections to API calls, which would involve
>> little effort, would vastly enlarge the cases in which this version
>> could safely be used.
>>
>> But the ParCS code, if completed and working, has a better design and
>> may be better in practice than what Steven and I were doing. It is
>> certainly the right general approach for dozens or hundreds of cores,
>> because with concurrent opcode instances you can use many more  
>> threads
>> than with concurrent instrument instances.
>>
>> So here are my questions:
>>
>> (1) Is the ParCS branch actually working?
>>
>> (2) What are its limitations?
>>
>> (3) Does it work only with the new parser? (I would guess so).
>>
>> (4) What would be the pros and cons of replacing pthreads with OpenMP
>> in the ParCS code? One of the pros would be considerably simpler  
>> code.
>>
>> Regards,
>> Mike
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>
>
>
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Using Nabble, I see that there is active discussion by SuperCollider
developers on merging SuperNova into SuperCollider. These are LEAD
developers. I would say there is a very good chance it will happen
this year or next.

Exciting!

Regards,
Mike

On Sun, Jun 6, 2010 at 3:52 PM, Victor Lazzarini
 wrote:
> Note that as far as I know this is SuperCollider Lang-compatible,but
> it's not supercollider itself. It seems to be either a fork or a
> completely separate project. I am not sure how mainstream this is
> likely to become.
>
> Victor
>
> On 6 Jun 2010, at 20:40, Michael Gogins wrote:
>
>> This appears to be what is happening, or part of it anyway, in
>> SuperCollider:
>>
>> http://lac.linuxaudio.org/2010/papers/32.pdf
>>
>> If I'm not mistaken, the ideas are somewhat similar to the ParCS
>> design. But it's absurd that they didn't implement off-line rendering
>> (i.e. non-real-time rendering to a soundfile)...
>>
>> Regards,
>> Mike
>>
>> On Sun, Jun 6, 2010 at 3:32 PM, Michael Gogins > > wrote:
>>> I discussed multi-core software synthesis briefly with Miller
>>> Puckette, author of Pure Data, at the ICMC on Friday.
>>>
>>> It seems multi-core support in Pure Data is minimal and hard to
>>> improve. A separate Pure Data process is actually spawned for each
>>> concurrent object, and inlet/outlet ports for concurrent objects
>>> therefore are special, using pipes. I should check on SuperCollider
>>> and Max.
>>>
>>> I'm examining the ParCS branch in Csound CVS, and it looks like
>>> Csound
>>> may have the potential to get this right.
>>>
>>> I wonder if the granularity of threading in ParCS is not too small.
>>> Right now nobody is going to have more than 4 or at most 8 cores. It
>>> seems to me that most Csound orchestras will have several instruments
>>> with multiple instances. In such cases instrument instances are a
>>> better level of granularity than opcode instances. However, the ParCS
>>> branch does seem to have the right logical design for concurrent
>>> opcode instances, it generates a directed acyclical graph of opcode
>>> instances implemented with an adjacency matrix, and synchronizes
>>> global variables.
>>>
>>> The prototype concurrent Csound created by Steven Yi and myself,
>>> simple though it is, is potentially much better than anything that
>>> Pure Data is likely to do. I do not know about SuperCollider or
>>> Max/MSP. Adding critical sections to API calls, which would involve
>>> little effort, would vastly enlarge the cases in which this version
>>> could safely be used.
>>>
>>> But the ParCS code, if completed and working, has a better design and
>>> may be better in practice than what Steven and I were doing. It is
>>> certainly the right general approach for dozens or hundreds of cores,
>>> because with concurrent opcode instances you can use many more
>>> threads
>>> than with concurrent instrument instances.
>>>
>>> So here are my questions:
>>>
>>> (1) Is the ParCS branch actually working?
>>>
>>> (2) What are its limitations?
>>>
>>> (3) Does it work only with the new parser? (I would guess so).
>>>
>>> (4) What would be the pros and cons of replacing pthreads with OpenMP
>>> in the ParCS code? One of the pros would be considerably simpler
>>> code.
>>>
>>> Regards,
>>> Mike
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> 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

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On 6 Jun 2010, at 20:32, Michael Gogins wrote:

> I discussed multi-core software synthesis briefly with Miller
> Puckette, author of Pure Data, at the ICMC on Friday.
>
> It seems multi-core support in Pure Data is minimal and hard to
> improve. A separate Pure Data process is actually spawned for each
> concurrent object, and inlet/outlet ports for concurrent objects
> therefore are special, using pipes. I should check on SuperCollider
> and Max.
>

Hello,

Max has multithreading but it is not done automatically. The user has  
to put the object inside a poly~ I think. No idea about SC3.

> I'm examining the ParCS branch in Csound CVS, and it looks like Csound
> may have the potential to get this right.
>
> I wonder if the granularity of threading in ParCS is not too small.
> Right now nobody is going to have more than 4 or at most 8 cores. It
> seems to me that most Csound orchestras will have several instruments
> with multiple instances. In such cases instrument instances are a
> better level of granularity than opcode instances. However, the ParCS
> branch does seem to have the right logical design for concurrent
> opcode instances, it generates a directed acyclical graph of opcode
> instances implemented with an adjacency matrix, and synchronizes
> global variables.
>

I don't know about the technicalities but as a user who only does  
sound processing in csound I hardly ever use more than one instant of  
an instrument. I would really welcome multithreading on the single  
instrument level. For example when using two instances of a pvs opcode  
to do stereo processing.

Thanks

Peiman

> The prototype concurrent Csound created by Steven Yi and myself,
> simple though it is, is potentially much better than anything that
> Pure Data is likely to do. I do not know about SuperCollider or
> Max/MSP. Adding critical sections to API calls, which would involve
> little effort, would vastly enlarge the cases in which this version
> could safely be used.
>
> But the ParCS code, if completed and working, has a better design and
> may be better in practice than what Steven and I were doing. It is
> certainly the right general approach for dozens or hundreds of cores,
> because with concurrent opcode instances you can use many more threads
> than with concurrent instrument instances.
>
> So here are my questions:
>
> (1) Is the ParCS branch actually working?
>
> (2) What are its limitations?
>
> (3) Does it work only with the new parser? (I would guess so).
>
> (4) What would be the pros and cons of replacing pthreads with OpenMP
> in the ParCS code? One of the pros would be considerably simpler code.
>
> Regards,
> Mike
>
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

P.S. you can use Supernova with SClang, you basically just have to
assign the synth engine in SClang from the Supernova constructor. In
other words it's a drop-in replacement.

Mike

On Sun, Jun 6, 2010 at 3:55 PM, Michael Gogins  wrote:
> Using Nabble, I see that there is active discussion by SuperCollider
> developers on merging SuperNova into SuperCollider. These are LEAD
> developers. I would say there is a very good chance it will happen
> this year or next.
>
> Exciting!
>
> Regards,
> Mike
>
> On Sun, Jun 6, 2010 at 3:52 PM, Victor Lazzarini
>  wrote:
>> Note that as far as I know this is SuperCollider Lang-compatible,but
>> it's not supercollider itself. It seems to be either a fork or a
>> completely separate project. I am not sure how mainstream this is
>> likely to become.
>>
>> Victor
>>
>> On 6 Jun 2010, at 20:40, Michael Gogins wrote:
>>
>>> This appears to be what is happening, or part of it anyway, in
>>> SuperCollider:
>>>
>>> http://lac.linuxaudio.org/2010/papers/32.pdf
>>>
>>> If I'm not mistaken, the ideas are somewhat similar to the ParCS
>>> design. But it's absurd that they didn't implement off-line rendering
>>> (i.e. non-real-time rendering to a soundfile)...
>>>
>>> Regards,
>>> Mike
>>>
>>> On Sun, Jun 6, 2010 at 3:32 PM, Michael Gogins >> > wrote:
>>>> I discussed multi-core software synthesis briefly with Miller
>>>> Puckette, author of Pure Data, at the ICMC on Friday.
>>>>
>>>> It seems multi-core support in Pure Data is minimal and hard to
>>>> improve. A separate Pure Data process is actually spawned for each
>>>> concurrent object, and inlet/outlet ports for concurrent objects
>>>> therefore are special, using pipes. I should check on SuperCollider
>>>> and Max.
>>>>
>>>> I'm examining the ParCS branch in Csound CVS, and it looks like
>>>> Csound
>>>> may have the potential to get this right.
>>>>
>>>> I wonder if the granularity of threading in ParCS is not too small.
>>>> Right now nobody is going to have more than 4 or at most 8 cores. It
>>>> seems to me that most Csound orchestras will have several instruments
>>>> with multiple instances. In such cases instrument instances are a
>>>> better level of granularity than opcode instances. However, the ParCS
>>>> branch does seem to have the right logical design for concurrent
>>>> opcode instances, it generates a directed acyclical graph of opcode
>>>> instances implemented with an adjacency matrix, and synchronizes
>>>> global variables.
>>>>
>>>> The prototype concurrent Csound created by Steven Yi and myself,
>>>> simple though it is, is potentially much better than anything that
>>>> Pure Data is likely to do. I do not know about SuperCollider or
>>>> Max/MSP. Adding critical sections to API calls, which would involve
>>>> little effort, would vastly enlarge the cases in which this version
>>>> could safely be used.
>>>>
>>>> But the ParCS code, if completed and working, has a better design and
>>>> may be better in practice than what Steven and I were doing. It is
>>>> certainly the right general approach for dozens or hundreds of cores,
>>>> because with concurrent opcode instances you can use many more
>>>> threads
>>>> than with concurrent instrument instances.
>>>>
>>>> So here are my questions:
>>>>
>>>> (1) Is the ParCS branch actually working?
>>>>
>>>> (2) What are its limitations?
>>>>
>>>> (3) Does it work only with the new parser? (I would guess so).
>>>>
>>>> (4) What would be the pros and cons of replacing pthreads with OpenMP
>>>> in the ParCS code? One of the pros would be considerably simpler
>>>> code.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> --
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://www.michael-gogins.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>> lucky parental unit.  See the prize list and enter to win:
>>> http://p.sf.net/sfu/thinkgeek-promo
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> 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
>



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

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Pure Data uses a poly~ object also. What I do not know is if Max also
spawns a separate instance for each slot in a poly~.

Mike

On Sun, Jun 6, 2010 at 3:57 PM, Peiman Khosravi
 wrote:
>
> On 6 Jun 2010, at 20:32, Michael Gogins wrote:
>
>> I discussed multi-core software synthesis briefly with Miller
>> Puckette, author of Pure Data, at the ICMC on Friday.
>>
>> It seems multi-core support in Pure Data is minimal and hard to
>> improve. A separate Pure Data process is actually spawned for each
>> concurrent object, and inlet/outlet ports for concurrent objects
>> therefore are special, using pipes. I should check on SuperCollider
>> and Max.
>>
>
> Hello,
>
> Max has multithreading but it is not done automatically. The user has
> to put the object inside a poly~ I think. No idea about SC3.
>
>> I'm examining the ParCS branch in Csound CVS, and it looks like Csound
>> may have the potential to get this right.
>>
>> I wonder if the granularity of threading in ParCS is not too small.
>> Right now nobody is going to have more than 4 or at most 8 cores. It
>> seems to me that most Csound orchestras will have several instruments
>> with multiple instances. In such cases instrument instances are a
>> better level of granularity than opcode instances. However, the ParCS
>> branch does seem to have the right logical design for concurrent
>> opcode instances, it generates a directed acyclical graph of opcode
>> instances implemented with an adjacency matrix, and synchronizes
>> global variables.
>>
>
> I don't know about the technicalities but as a user who only does
> sound processing in csound I hardly ever use more than one instant of
> an instrument. I would really welcome multithreading on the single
> instrument level. For example when using two instances of a pvs opcode
> to do stereo processing.
>
> Thanks
>
> Peiman
>
>> The prototype concurrent Csound created by Steven Yi and myself,
>> simple though it is, is potentially much better than anything that
>> Pure Data is likely to do. I do not know about SuperCollider or
>> Max/MSP. Adding critical sections to API calls, which would involve
>> little effort, would vastly enlarge the cases in which this version
>> could safely be used.
>>
>> But the ParCS code, if completed and working, has a better design and
>> may be better in practice than what Steven and I were doing. It is
>> certainly the right general approach for dozens or hundreds of cores,
>> because with concurrent opcode instances you can use many more threads
>> than with concurrent instrument instances.
>>
>> So here are my questions:
>>
>> (1) Is the ParCS branch actually working?
>>
>> (2) What are its limitations?
>>
>> (3) Does it work only with the new parser? (I would guess so).
>>
>> (4) What would be the pros and cons of replacing pthreads with OpenMP
>> in the ParCS code? One of the pros would be considerably simpler code.
>>
>> Regards,
>> Mike
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> 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

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Le 06/06/10 22:11, Michael Gogins a écrit :
> Pure Data uses a poly~ object also. What I do not know is if Max also
> spawns a separate instance for each slot in a poly~.
>
> Mike
>

Actually, relating to multithreading there are three modes for poly~ in 
max/msp:
. no multithreading (all voices in the same thread as the main signal 
processing thread)
. multithreading with manual control over the number of threads
. multithreading with automatic control over the number of threads: in 
the later case, it seems that poly~ creates as many threads as there are 
cores in the machine.

Then there aren't so to speak as many threads as slots in the poly~ 
(except if you specify it).

Then multicore support is still limited in max/msp: it makes only sense 
when there are parallel identical cpu-greedy tasks involved. But 
anything that implies signal and is not in the poly~ remains in a single 
thread.

alexis

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thanks for the clarification. So there can be a thread pool, and all
the poly threads run in one process.

This is almost exactly the same as what Steven Yi and I have done with Csound.

Do you know if there are issues with global objects in poly~ slot patchers?

Regards,
Mike


On Sun, Jun 6, 2010 at 4:33 PM, Alexis Baskind  wrote:
> Le 06/06/10 22:11, Michael Gogins a écrit :
>> Pure Data uses a poly~ object also. What I do not know is if Max also
>> spawns a separate instance for each slot in a poly~.
>>
>> Mike
>>
>
> Actually, relating to multithreading there are three modes for poly~ in
> max/msp:
> . no multithreading (all voices in the same thread as the main signal
> processing thread)
> . multithreading with manual control over the number of threads
> . multithreading with automatic control over the number of threads: in
> the later case, it seems that poly~ creates as many threads as there are
> cores in the machine.
>
> Then there aren't so to speak as many threads as slots in the poly~
> (except if you specify it).
>
> Then multicore support is still limited in max/msp: it makes only sense
> when there are parallel identical cpu-greedy tasks involved. But
> anything that implies signal and is not in the poly~ remains in a single
> thread.
>
> alexis
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> 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

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> Do you know if there are issues with global objects in poly~ slot patchers?

Do you mean global variables ? As far as I know, no. What can be 
considered as global objects in max/msp for instance are send/receive 
busses, and global floats ("var" objects). There use to be troubles with 
send/receives, but before poly~ was multithreaded, and now it seems to 
be solved. But when I use poly~ in max/msp, I almost never use globally 
shared objects, and rely on a pure top/down architecture.

alexis


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net