parallel processing panel at ICMC

View: New views
20 Messages — Rating Filter:   Alert me  
< Prev | 1 - 2 | Next >

parallel processing panel at ICMC

by Victor Lazzarini :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Some parts of this message have been removed. Learn more about Nabble's security policy.
Hello everyone,
 
just a quick e-mail in relation to the panel at ICMC. John was there and
might add details to these.
 
The overall tone was 'yes it is a good idea; we'll have to do it, but we
don't know how yet.'  I asked the question we wanted to know:
who is doing it? They basically shrugged and said, "well max has
the poly object...", and then someone said that SCSynth could be
run several separate, but unconnected, processes, to what I replied,
so can any other program...
 
The only thing I found useful was to hear the FAUST guy talk about
their multiprocessor output usimg openMP. They also have experience
with their parallel version of Jack.
 
Has anyone looked at OpenMP. Looks dead easy to use, it seems available
across the board for all support platforms (gcc 4.2). Perhaps we can use
that instead of pthreads?
 
But overall, they all seemed clueless. The discussions in this list seemed
to be better informed. The added joke was Miller Puckette saying that with
his three year PC he could run six PVs so he was happy and did not want
to bother with it.
 
Regards
 
Victor
 

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: parallel processing panel at ICMC

by Richard Dobson :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

victor wrote:
..
>  
> The only thing I found useful was to hear the FAUST guy talk about
> their multiprocessor output usimg openMP. They also have experience
> with their parallel version of Jack.
>  

Yes, quite tempted to look at FAUST. Julius Smith says he is
implementing all his dsp examples from his online books using it.

> Has anyone looked at OpenMP.

Am looking at it (but mostly engaged just now in SIMD programming for
the Clearspeed cards); but I only have access to dual-core machines,
which I don't consider adequate for testing such things. Does anyone on
the list have the 8-core Mac Pro?  Outside my budget, sadly.

Looks dead easy to use, it seems available
> across the board for all support platforms (gcc 4.2). Perhaps we can use
> that instead of pthreads?
>  
> But overall, they all seemed clueless. The discussions in this list seemed
> to be better informed. The added joke was Miller Puckette saying that with
> his three year PC he could run six PVs so he was happy and did not want
> to bother with it.
>  

Wot, only six? Not much use for morphing two 5.1 streams. So, no
immediate prospect of a spv~ opcode in PD, then!

Richard Dobson







-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: parallel processing panel at ICMC

by peiman :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I think they have new 8-core Mac Pros at the uni studio, I may be  
able to do some testing there if they let me :-)

Peiman


On 31 Aug 2008, at 23:33, Richard Dobson wrote:

> victor wrote:
> ..
>>
>> The only thing I found useful was to hear the FAUST guy talk about
>> their multiprocessor output usimg openMP. They also have experience
>> with their parallel version of Jack.
>>
>
> Yes, quite tempted to look at FAUST. Julius Smith says he is
> implementing all his dsp examples from his online books using it.
>
>> Has anyone looked at OpenMP.
>
> Am looking at it (but mostly engaged just now in SIMD programming for
> the Clearspeed cards); but I only have access to dual-core machines,
> which I don't consider adequate for testing such things. Does  
> anyone on
> the list have the 8-core Mac Pro?  Outside my budget, sadly.
>
> Looks dead easy to use, it seems available
>> across the board for all support platforms (gcc 4.2). Perhaps we  
>> can use
>> that instead of pthreads?
>>
>> But overall, they all seemed clueless. The discussions in this  
>> list seemed
>> to be better informed. The added joke was Miller Puckette saying  
>> that with
>> his three year PC he could run six PVs so he was happy and did not  
>> want
>> to bother with it.
>>
>
> Wot, only six? Not much use for morphing two 5.1 streams. So, no
> immediate prospect of a spv~ opcode in PD, then!
>
> Richard Dobson
>
>
>
>
>
>
>
> ----------------------------------------------------------------------
> ---
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: parallel processing panel at ICMC

by Steven Yi :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Victor,

Thanks very much for the report!  It seems to me that we would use
OpenMP in the same way as the code we currently have in that we use a
barrier and split work.  We would still need to work on a better work
partitioning system, regardless of a change to OpenMP or not.

I took a further look int OpenMP and it looks pretty nice. However, it
looks like gcc 4.x is only in alpha state for MinGW.  If it works then
that'd be great.

As for replacing pthread, I wonder if that would be appropriate for
the threaded code we have that isn't related to parallelizing code.
On the other hand, I don't know if we can use pthreads in conjunction
with OpenMP.

So, what does everyone else think?  I am thinking our current code is
enough for now for running the parallel code, and we might be better
served to continue to look at places where we are running into
problems.

A step we can take would be to start systematically creating a test
suite of CSD's, much like what was done for the new parser and the
tests in the tests directory.  Those tests for the new parser took one
step at a time and introduced a single new language feature to test
another feature of the processor.  We should probably do something
similar so that we can step by step test and then if we find a
problem, we'd have a good idea of what the problem was from as we only
add one feature at a time.

Thoughts?
steven




On Sun, Aug 31, 2008 at 3:33 PM, victor <Victor.Lazzarini@...> wrote:

> Hello everyone,
>
> just a quick e-mail in relation to the panel at ICMC. John was there and
> might add details to these.
>
> The overall tone was 'yes it is a good idea; we'll have to do it, but we
> don't know how yet.'  I asked the question we wanted to know:
> who is doing it? They basically shrugged and said, "well max has
> the poly object...", and then someone said that SCSynth could be
> run several separate, but unconnected, processes, to what I replied,
> so can any other program...
>
> The only thing I found useful was to hear the FAUST guy talk about
> their multiprocessor output usimg openMP. They also have experience
> with their parallel version of Jack.
>
> Has anyone looked at OpenMP. Looks dead easy to use, it seems available
> across the board for all support platforms (gcc 4.2). Perhaps we can use
> that instead of pthreads?
>
> But overall, they all seemed clueless. The discussions in this list seemed
> to be better informed. The added joke was Miller Puckette saying that with
> his three year PC he could run six PVs so he was happy and did not want
> to bother with it.
>
> Regards
>
> Victor
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: parallel processing panel at ICMC

by Victor Lazzarini :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I was thinking of OpenMP for parallelising engine code rather than to
substitute pthreads for everything (we'll keep pthreads for
threads...). OpenMP seemed to be quite useful.

Victor
----- Original Message -----
From: "Steven Yi" <stevenyi@...>
To: "Developer discussions" <csound-devel@...>
Sent: Monday, September 01, 2008 3:07 AM
Subject: Re: [Cs-dev] parallel processing panel at ICMC


> Hi Victor,
>
> Thanks very much for the report!  It seems to me that we would use
> OpenMP in the same way as the code we currently have in that we use a
> barrier and split work.  We would still need to work on a better work
> partitioning system, regardless of a change to OpenMP or not.
>
> I took a further look int OpenMP and it looks pretty nice. However, it
> looks like gcc 4.x is only in alpha state for MinGW.  If it works then
> that'd be great.
>
> As for replacing pthread, I wonder if that would be appropriate for
> the threaded code we have that isn't related to parallelizing code.
> On the other hand, I don't know if we can use pthreads in conjunction
> with OpenMP.
>
> So, what does everyone else think?  I am thinking our current code is
> enough for now for running the parallel code, and we might be better
> served to continue to look at places where we are running into
> problems.
>
> A step we can take would be to start systematically creating a test
> suite of CSD's, much like what was done for the new parser and the
> tests in the tests directory.  Those tests for the new parser took one
> step at a time and introduced a single new language feature to test
> another feature of the processor.  We should probably do something
> similar so that we can step by step test and then if we find a
> problem, we'd have a good idea of what the problem was from as we only
> add one feature at a time.
>
> Thoughts?
> steven
>
>
>
>
> On Sun, Aug 31, 2008 at 3:33 PM, victor <Victor.Lazzarini@...> wrote:
>> Hello everyone,
>>
>> just a quick e-mail in relation to the panel at ICMC. John was there and
>> might add details to these.
>>
>> The overall tone was 'yes it is a good idea; we'll have to do it, but we
>> don't know how yet.'  I asked the question we wanted to know:
>> who is doing it? They basically shrugged and said, "well max has
>> the poly object...", and then someone said that SCSynth could be
>> run several separate, but unconnected, processes, to what I replied,
>> so can any other program...
>>
>> The only thing I found useful was to hear the FAUST guy talk about
>> their multiprocessor output usimg openMP. They also have experience
>> with their parallel version of Jack.
>>
>> Has anyone looked at OpenMP. Looks dead easy to use, it seems available
>> across the board for all support platforms (gcc 4.2). Perhaps we can use
>> that instead of pthreads?
>>
>> But overall, they all seemed clueless. The discussions in this list
>> seemed
>> to be better informed. The added joke was Miller Puckette saying that
>> with
>> his three year PC he could run six PVs so he was happy and did not want
>> to bother with it.
>>
>> Regards
>>
>> Victor
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@...
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel 


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Parent Message unknown Re: parallel processing panel at ICMC

by Michael Gogins :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

OpenMP is not supported by the Microsoft Visual C++ Express Edition compiler (OpenMP is supported by the commercial editions). Since, for the upcoming release, I was planning to do a Microsoft build for the Windows installers, we may want to think about using OpenMP. Other than that, OpenMP is a later iteration of the parallel concepts and looks like a good choice for Csound.

As far as MinGW/MSys is concerned, the current Windows installers are built with MinGW 4.2.1-2 dw2, which does seem to support OpenMP (haven't actually tried it yet). There was a Google Summer of Code project, recently completed, to fix problems with MinGW:

http://gcc.gnu.org/wiki/WindowsGCCImprovementsGSoC2008

Note the claim that OpenMP support is OK.

So it boils down to this: with OpenMP we can forget about Visual C++. With Visual C++ we can forget about OpenMP.

I'm personally happy enough with MinGW/MSys and could drop Visual C++ and proceed with OpenMP, but I think some Csound users and developers may be anticipating using Visual C++.

Another candidate would be Intel Threading Building Blocks, which has a mirror situation: supported on Linux and with Visual C++, but no support for MinGW,
although it might be possible to go ahead and hack a build with MinGW. TBB has very good documentation and looks cleanly designed.

Regards,
Mike

-----Original Message-----

>From: victor <Victor.Lazzarini@...>
>Sent: Sep 1, 2008 12:00 AM
>To: Developer discussions <csound-devel@...>
>Subject: Re: [Cs-dev] parallel processing panel at ICMC
>
>I was thinking of OpenMP for parallelising engine code rather than to
>substitute pthreads for everything (we'll keep pthreads for
>threads...). OpenMP seemed to be quite useful.
>
>Victor
>----- Original Message -----
>From: "Steven Yi" <stevenyi@...>
>To: "Developer discussions" <csound-devel@...>
>Sent: Monday, September 01, 2008 3:07 AM
>Subject: Re: [Cs-dev] parallel processing panel at ICMC
>
>
>> Hi Victor,
>>
>> Thanks very much for the report!  It seems to me that we would use
>> OpenMP in the same way as the code we currently have in that we use a
>> barrier and split work.  We would still need to work on a better work
>> partitioning system, regardless of a change to OpenMP or not.
>>
>> I took a further look int OpenMP and it looks pretty nice. However, it
>> looks like gcc 4.x is only in alpha state for MinGW.  If it works then
>> that'd be great.
>>
>> As for replacing pthread, I wonder if that would be appropriate for
>> the threaded code we have that isn't related to parallelizing code.
>> On the other hand, I don't know if we can use pthreads in conjunction
>> with OpenMP.
>>
>> So, what does everyone else think?  I am thinking our current code is
>> enough for now for running the parallel code, and we might be better
>> served to continue to look at places where we are running into
>> problems.
>>
>> A step we can take would be to start systematically creating a test
>> suite of CSD's, much like what was done for the new parser and the
>> tests in the tests directory.  Those tests for the new parser took one
>> step at a time and introduced a single new language feature to test
>> another feature of the processor.  We should probably do something
>> similar so that we can step by step test and then if we find a
>> problem, we'd have a good idea of what the problem was from as we only
>> add one feature at a time.
>>
>> Thoughts?
>> steven
>>
>>
>>
>>
>> On Sun, Aug 31, 2008 at 3:33 PM, victor <Victor.Lazzarini@...> wrote:
>>> Hello everyone,
>>>
>>> just a quick e-mail in relation to the panel at ICMC. John was there and
>>> might add details to these.
>>>
>>> The overall tone was 'yes it is a good idea; we'll have to do it, but we
>>> don't know how yet.'  I asked the question we wanted to know:
>>> who is doing it? They basically shrugged and said, "well max has
>>> the poly object...", and then someone said that SCSynth could be
>>> run several separate, but unconnected, processes, to what I replied,
>>> so can any other program...
>>>
>>> The only thing I found useful was to hear the FAUST guy talk about
>>> their multiprocessor output usimg openMP. They also have experience
>>> with their parallel version of Jack.
>>>
>>> Has anyone looked at OpenMP. Looks dead easy to use, it seems available
>>> across the board for all support platforms (gcc 4.2). Perhaps we can use
>>> that instead of pthreads?
>>>
>>> But overall, they all seemed clueless. The discussions in this list
>>> seemed
>>> to be better informed. The added joke was Miller Puckette saying that
>>> with
>>> his three year PC he could run six PVs so he was happy and did not want
>>> to bother with it.
>>>
>>> Regards
>>>
>>> Victor
>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great
>>> prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>> world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@...
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@...
>> https://lists.sourceforge.net/lists/listinfo/csound-devel 
>
>
>-------------------------------------------------------------------------
>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>Build the coolest Linux based applications with Moblin SDK & win great prizes
>Grand prize is a trip for two to an Open Source event anywhere in the world
>http://moblin-contest.org/redirect.php?banner_id=100&url=/
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@...
>https://lists.sourceforge.net/lists/listinfo/csound-devel




-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: parallel processing panel at ICMC

by Victor Lazzarini :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Michael,
thanks for this insight. What if we support OpenMP and use conditionals to
allow for (non-parallel) free Visual C++ builds? Since this seems to be supported
almost everywhere else, if we find that OpenMP is the way to go, this might be
a good compromise. I am not keen on depending on MS Threading Building Blocks,
I think that is possibly waste of our time/resources.

In any case the adoption of OpenMP is of course something for long term planning.

Regards

Victor


----- Original Message -----
From: Michael Gogins <gogins@...>
Date: Monday, September 1, 2008 4:45 pm
Subject: Re: [Cs-dev] parallel processing panel at ICMC
To: Developer discussions <csound-devel@...>

> OpenMP is not supported by the Microsoft Visual C++ Express
> Edition compiler (OpenMP is supported by the commercial
> editions). Since, for the upcoming release, I was planning to do
> a Microsoft build for the Windows installers, we may want to
> think about using OpenMP. Other than that, OpenMP is a later
> iteration of the parallel concepts and looks like a good choice
> for Csound.
>
> As far as MinGW/MSys is concerned, the current Windows
> installers are built with MinGW 4.2.1-2 dw2, which does seem to
> support OpenMP (haven't actually tried it yet). There was a
> Google Summer of Code project, recently completed, to fix
> problems with MinGW:
>
> http://gcc.gnu.org/wiki/WindowsGCCImprovementsGSoC2008
>
> Note the claim that OpenMP support is OK.
>
> So it boils down to this: with OpenMP we can forget about Visual
> C++. With Visual C++ we can forget about OpenMP.
>
> I'm personally happy enough with MinGW/MSys and could drop
> Visual C++ and proceed with OpenMP, but I think some Csound
> users and developers may be anticipating using Visual C++.
>
> Another candidate would be Intel Threading Building Blocks,
> which has a mirror situation: supported on Linux and with Visual
> C++, but no support for MinGW,
> although it might be possible to go ahead and hack a build with
> MinGW. TBB has very good documentation and looks cleanly designed.
>
> Regards,
> Mike
>
> -----Original Message-----
> >From: victor <Victor.Lazzarini@...>
> >Sent: Sep 1, 2008 12:00 AM
> >To: Developer discussions <csound-devel@...>
> >Subject: Re: [Cs-dev] parallel processing panel at ICMC
> >
> >I was thinking of OpenMP for parallelising engine code rather
> than to
> >substitute pthreads for everything (we'll keep pthreads for
> >threads...). OpenMP seemed to be quite useful.
> >
> >Victor
> >----- Original Message -----
> >From: "Steven Yi" <stevenyi@...>
> >To: "Developer discussions" <csound-devel@...>
> >Sent: Monday, September 01, 2008 3:07 AM
> >Subject: Re: [Cs-dev] parallel processing panel at ICMC
> >
> >
> >> Hi Victor,
> >>
> >> Thanks very much for the report!  It seems to me that we
> would use
> >> OpenMP in the same way as the code we currently have in that
> we use a
> >> barrier and split work.  We would still need to work on
> a better work
> >> partitioning system, regardless of a change to OpenMP or not.
> >>
> >> I took a further look int OpenMP and it looks pretty nice.
> However, it
> >> looks like gcc 4.x is only in alpha state for MinGW.  If
> it works then
> >> that'd be great.
> >>
> >> As for replacing pthread, I wonder if that would be
> appropriate for
> >> the threaded code we have that isn't related to parallelizing code.
> >> On the other hand, I don't know if we can use pthreads in
> conjunction>> with OpenMP.
> >>
> >> So, what does everyone else think?  I am thinking our
> current code is
> >> enough for now for running the parallel code, and we might be
> better>> served to continue to look at places where we are
> running into
> >> problems.
> >>
> >> A step we can take would be to start systematically creating
> a test
> >> suite of CSD's, much like what was done for the new parser
> and the
> >> tests in the tests directory.  Those tests for the new
> parser took one
> >> step at a time and introduced a single new language feature
> to test
> >> another feature of the processor.  We should probably do
> something>> similar so that we can step by step test and then if
> we find a
> >> problem, we'd have a good idea of what the problem was from
> as we only
> >> add one feature at a time.
> >>
> >> Thoughts?
> >> steven
> >>
> >>
> >>
> >>
> >> On Sun, Aug 31, 2008 at 3:33 PM, victor
> <Victor.Lazzarini@...> wrote:
> >>> Hello everyone,
> >>>
> >>> just a quick e-mail in relation to the panel at ICMC. John
> was there and
> >>> might add details to these.
> >>>
> >>> The overall tone was 'yes it is a good idea; we'll have to
> do it, but we
> >>> don't know how yet.'  I asked the question we wanted to know:
> >>> who is doing it? They basically shrugged and said, "well max has
> >>> the poly object...", and then someone said that SCSynth
> could be
> >>> run several separate, but unconnected, processes, to what I
> replied,>>> so can any other program...
> >>>
> >>> The only thing I found useful was to hear the FAUST guy talk about
> >>> their multiprocessor output usimg openMP. They also have
> experience>>> with their parallel version of Jack.
> >>>
> >>> Has anyone looked at OpenMP. Looks dead easy to use, it
> seems available
> >>> across the board for all support platforms (gcc 4.2).
> Perhaps we can use
> >>> that instead of pthreads?
> >>>
> >>> But overall, they all seemed clueless. The discussions in
> this list
> >>> seemed
> >>> to be better informed. The added joke was Miller Puckette
> saying that
> >>> with
> >>> his three year PC he could run six PVs so he was happy and
> did not want
> >>> to bother with it.
> >>>
> >>> Regards
> >>>
> >>> Victor
> >>>
> >>> -------------------------------------------------------------
> ------------
> >>> This SF.Net email is sponsored by the Moblin Your Move
> Developer's
> >>> challenge
> >>> Build the coolest Linux based applications with Moblin SDK &
> win great
> >>> prizes
> >>> Grand prize is a trip for two to an Open Source event
> anywhere in the
> >>> world
> >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >>> _______________________________________________
> >>> Csound-devel mailing list
> >>> Csound-devel@...
> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> >>>
> >>>
> >>
> >> --------------------------------------------------------------
> -----------
> >> This SF.Net email is sponsored by the Moblin Your Move
> Developer's
> >> challenge
> >> Build the coolest Linux based applications with Moblin SDK &
> win great
> >> prizes
> >> Grand prize is a trip for two to an Open Source event
> anywhere in the
> >> world
> >> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >> _______________________________________________
> >> Csound-devel mailing list
> >> Csound-devel@...
> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
> >
> >----------------------------------------------------------------
> ---------
> >This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> >Build the coolest Linux based applications with Moblin SDK &
> win great prizes
> >Grand prize is a trip for two to an Open Source event anywhere
> in the world
> >http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >_______________________________________________
> >Csound-devel mailing list
> >Csound-devel@...
> >https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
>
> -----------------------------------------------------------------
> --------
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere
> in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Parent Message unknown Re: parallel processing panel at ICMC

by Michael Gogins :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Thanks for your thoughts.

I don't want to introduce more conditional compilation into C++, even though your suggestion is, of course, quite straightforward.  I'm afraid I don't see the point of making the Csound build more complex than it already is for not much return. As I said, I'm willing to just drop Visual C++ and commit to OpenMP.

But equally, I have no problem with just implementing the primitives that we need using pthreads, spinlocks, and whatnot. What we are trying to do in Csound, whatever might be the state of the art in music programming, is not rocket science in C and C++ programming, and doesn't need to be. There probably are some open source libraries that would work on all platforms, as well. I will look.

By the way, it's not MS Threading Building Blocks, it's Intel Threading Building Blocks, although the fact that Intel supports TBB on Windows only for MSVC could be confusing. Do you oppose TBB because OpenMP is more of a standard, or because you have tried them both and found OpenMP better, or what?

What we need to do is proceed at a reasonable pace, with time to think, and make sure that we understand what our requirements actually are before assuming that one library or package or another is going to satisfy them. So far, I don't see anything that needs any new libraries or APIs beyond what we already have.

Regards,
Mike

-----Original Message-----
>From: Victor.Lazzarini@...
>Sent: Sep 2, 2008 1:56 AM
>To: Michael Gogins <gogins@...>, Developer discussions <csound-devel@...>
>Subject: Re: [Cs-dev] parallel processing panel at ICMC
>
>Michael,thanks for this insight. What if we support OpenMP and use conditionals toallow for (non-parallel) free Visual C++ builds? Since this seems to be supportedalmost everywhere else, if we find that OpenMP is the way to go, this might bea good compromise. I am not keen on depending on MS Threading Building Blocks,I think that is possibly waste of our time/resources.In any case the adoption of OpenMP is of course something for long term planning.RegardsVictor----- Original Message -----From: Michael Gogins <gogins@...>Date: Monday, September 1, 2008 4:45 pmSubject: Re: [Cs-dev] parallel processing panel at ICMCTo: Developer discussions <csound-devel@...>> OpenMP is not supported by the Microsoft Visual C++ Express > Edition compiler (OpenMP is supported by the commercial > editions). Since, for the upcoming release, I was planning to do > a Microsoft build for the Windows installers, we may want to > think about using OpenMP. Other than that, OpenMP is a later > iteration of the parallel concepts and looks like a good choice > for Csound. > > As far as MinGW/MSys is concerned, the current Windows > installers are built with MinGW 4.2.1-2 dw2, which does seem to > support OpenMP (haven't actually tried it yet). There was a > Google Summer of Code project, recently completed, to fix > problems with MinGW:> > http://gcc.gnu.org/wiki/WindowsGCCImprovementsGSoC2008> > Note the claim that OpenMP support is OK.> > So it boils down to this: with OpenMP we can forget about Visual > C++. With Visual C++ we can forget about OpenMP.> > I'm personally happy enough with MinGW/MSys and could drop > Visual C++ and proceed with OpenMP, but I think some Csound > users and developers may be anticipating using Visual C++.> > Another candidate would be Intel Threading Building Blocks, > which has a mirror situation: supported on Linux and with Visual > C++, but no support for MinGW,> although it might be possible to go ahead and hack a build with > MinGW. TBB has very good documentation and looks cleanly designed.> > Regards,> Mike> > -----Original Message-----> >From: victor <Victor.Lazzarini@...>> >Sent: Sep 1, 2008 12:00 AM> >To: Developer discussions <csound-devel@...>> >Subject: Re: [Cs-dev] parallel processing panel at ICMC> >> >I was thinking of OpenMP for parallelising engine code rather > than to> >substitute pthreads for everything (we'll keep pthreads for> >threads...). OpenMP seemed to be quite useful.> >> >Victor> >----- Original Message ----- > >From: "Steven Yi" <stevenyi@...>> >To: "Developer discussions" <csound-devel@...>> >Sent: Monday, September 01, 2008 3:07 AM> >Subject: Re: [Cs-dev] parallel processing panel at ICMC> >> >> >> Hi Victor,> >>> >> Thanks very much for the report!  It seems to me that we > would use> >> OpenMP in the same way as the code we currently have in that > we use a> >> barrier and split work.  We would still need to work on > a better work> >> partitioning system, regardless of a change to OpenMP or not.> >>> >> I took a further look int OpenMP and it looks pretty nice. > However, it> >> looks like gcc 4.x is only in alpha state for MinGW.  If > it works then> >> that'd be great.> >>> >> As for replacing pthread, I wonder if that would be > appropriate for> >> the threaded code we have that isn't related to parallelizing code.> >> On the other hand, I don't know if we can use pthreads in > conjunction>> with OpenMP.> >>> >> So, what does everyone else think?  I am thinking our > current code is> >> enough for now for running the parallel code, and we might be > better>> served to continue to look at places where we are > running into> >> problems.> >>> >> A step we can take would be to start systematically creating > a test> >> suite of CSD's, much like what was done for the new parser > and the> >> tests in the tests directory.  Those tests for the new > parser took one> >> step at a time and introduced a single new language feature > to test> >> another feature of the processor.  We should probably do > something>> similar so that we can step by step test and then if > we find a> >> problem, we'd have a good idea of what the problem was from > as we only> >> add one feature at a time.> >>> >> Thoughts?> >> steven> >>> >>> >>> >>> >> On Sun, Aug 31, 2008 at 3:33 PM, victor > <Victor.Lazzarini@...> wrote:> >>> Hello everyone,> >>>> >>> just a quick e-mail in relation to the panel at ICMC. John > was there and> >>> might add details to these.> >>>> >>> The overall tone was 'yes it is a good idea; we'll have to > do it, but we> >>> don't know how yet.'  I asked the question we wanted to know:> >>> who is doing it? They basically shrugged and said, "well max has> >>> the poly object...", and then someone said that SCSynth > could be> >>> run several separate, but unconnected, processes, to what I > replied,>>> so can any other program...> >>>> >>> The only thing I found useful was to hear the FAUST guy talk about> >>> their multiprocessor output usimg openMP. They also have > experience>>> with their parallel version of Jack.> >>>> >>> Has anyone looked at OpenMP. Looks dead easy to use, it > seems available> >>> across the board for all support platforms (gcc 4.2). > Perhaps we can use> >>> that instead of pthreads?> >>>> >>> But overall, they all seemed clueless. The discussions in > this list > >>> seemed> >>> to be better informed. The added joke was Miller Puckette > saying that > >>> with> >>> his three year PC he could run six PVs so he was happy and > did not want> >>> to bother with it.> >>>> >>> Regards> >>>> >>> Victor> >>>> >>> -------------------------------------------------------------> ------------> >>> This SF.Net email is sponsored by the Moblin Your Move > Developer's > >>> challenge> >>> Build the coolest Linux based applications with Moblin SDK & > win great> >>> prizes> >>> Grand prize is a trip for two to an Open Source event > anywhere in the > >>> world> >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/> >>> _______________________________________________> >>> Csound-devel mailing list> >>> Csound-devel@...> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel> >>>> >>>> >>> >> --------------------------------------------------------------> -----------> >> This SF.Net email is sponsored by the Moblin Your Move > Developer's > >> challenge> >> Build the coolest Linux based applications with Moblin SDK & > win great > >> prizes> >> Grand prize is a trip for two to an Open Source event > anywhere in the > >> world> >> http://moblin-contest.org/redirect.php?banner_id=100&url=/> >> _______________________________________________> >> Csound-devel mailing list> >> Csound-devel@...> >> https://lists.sourceforge.net/lists/listinfo/csound-devel > >> >> >----------------------------------------------------------------> ---------> >This SF.Net email is sponsored by the Moblin Your Move > Developer's challenge> >Build the coolest Linux based applications with Moblin SDK & > win great prizes> >Grand prize is a trip for two to an Open Source event anywhere > in the world> >http://moblin-contest.org/redirect.php?banner_id=100&url=/> >_______________________________________________> >Csound-devel mailing list> >Csound-devel@...> >https://lists.sourceforge.net/lists/listinfo/csound-devel> > > > > -----------------------------------------------------------------> --------> This SF.Net email is sponsored by the Moblin Your Move > Developer's challenge> Build the coolest Linux based applications with Moblin SDK & win > great prizes> Grand prize is a trip for two to an Open Source event anywhere > in the world> http://moblin-contest.org/redirect.php?banner_id=100&url=/> _______________________________________________> Csound-devel mailing list> Csound-devel@...> https://lists.sourceforge.net/lists/listinfo/csound-devel




-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: parallel processing panel at ICMC

by Victor Lazzarini :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I don't know threading blocks, but if it becomes available elsewhere, it
might be OK IMHO. However, OpenMP seems to be more prevalent
and more of an 'open' standard (as the name implies). The reason I suggested
it is that it might make it easier to maintain and expand a multiprocessing
system in Csound. I can see how pthreads etc will also do the job and if
we don't need more than that, there is no problem.

One thing I thought it might be useful for is if we try to parallelise opcode processing,
as in the way FAUST does.

Victor

----- Original Message -----
From: Michael Gogins <gogins@...>
Date: Tuesday, September 2, 2008 1:36 pm
Subject: Re: [Cs-dev] parallel processing panel at ICMC
To: csound-devel@...

> Thanks for your thoughts.
>
> I don't want to introduce more conditional compilation into C++,
> even though your suggestion is, of course, quite
> straightforward.  I'm afraid I don't see the point of
> making the Csound build more complex than it already is for not
> much return. As I said, I'm willing to just drop Visual C++ and
> commit to OpenMP.
>
> But equally, I have no problem with just implementing the
> primitives that we need using pthreads, spinlocks, and whatnot.
> What we are trying to do in Csound, whatever might be the state
> of the art in music programming, is not rocket science in C and
> C++ programming, and doesn't need to be. There probably are some
> open source libraries that would work on all platforms, as well.
> I will look.
>
> By the way, it's not MS Threading Building Blocks, it's Intel
> Threading Building Blocks, although the fact that Intel supports
> TBB on Windows only for MSVC could be confusing. Do you oppose
> TBB because OpenMP is more of a standard, or because you have
> tried them both and found OpenMP better, or what?
>
> What we need to do is proceed at a reasonable pace, with time to
> think, and make sure that we understand what our requirements
> actually are before assuming that one library or package or
> another is going to satisfy them. So far, I don't see anything
> that needs any new libraries or APIs beyond what we already have.
>
> Regards,
> Mike
>
> -----Original Message-----
> >From: Victor.Lazzarini@...
> >Sent: Sep 2, 2008 1:56 AM
> >To: Michael Gogins <gogins@...>, Developer
> discussions <csound-devel@...>
> >Subject: Re: [Cs-dev] parallel processing panel at ICMC
> >
> >Michael,thanks for this insight. What if we support OpenMP and
> use conditionals toallow for (non-parallel) free Visual C++
> builds? Since this seems to be supportedalmost everywhere else,
> if we find that OpenMP is the way to go, this might bea good
> compromise. I am not keen on depending on MS Threading Building
> Blocks,I think that is possibly waste of our time/resources.In
> any case the adoption of OpenMP is of course something for long
> term planning.RegardsVictor----- Original Message -----From:
> Michael Gogins <gogins@...>Date: Monday, September
> 1, 2008 4:45 pmSubject: Re: [Cs-dev] parallel processing panel
> at ICMCTo: Developer discussions <csound-
> devel@...>> OpenMP is not supported by the
> Microsoft Visual C++ Express > Edition compiler (OpenMP is
> supported by the commercial > editions). Since, for the upcoming
> release, I was planning to do > a Microsoft build for the
> Windows installers, we may want to > think about using OpenMP.
> Other than that, OpenMP is a later > iteration of the parallel
> concepts and looks like a good choice > for Csound. > > As far
> as MinGW/MSys is concerned, the current Windows > installers are
> built with MinGW 4.2.1-2 dw2, which does seem to > support
> OpenMP (haven't actually tried it yet). There was a > Google
> Summer of Code project, recently completed, to fix > problems
> with MinGW:> >
> http://gcc.gnu.org/wiki/WindowsGCCImprovementsGSoC2008> > Note
> the claim that OpenMP support is OK.> > So it boils down to
> this: with OpenMP we can forget about Visual > C++. With Visual
> C++ we can forget about OpenMP.> > I'm personally happy enough
> with MinGW/MSys and could drop > Visual C++ and proceed with
> OpenMP, but I think some Csound > users and developers may be
> anticipating using Visual C++.> > Another candidate would be
> Intel Threading Building Blocks, > which has a mirror situation:
> supported on Linux and with Visual > C++, but no support for
> MinGW,> although it might be possible to go ahead and hack a
> build with > MinGW. TBB has very good documentation and looks
> cleanly designed.> > Regards,> Mike> > -----Original Message-----
> > >From: victor <Victor.Lazzarini@...>> >Sent: Sep 1,
> 2008 12:00 AM> >To: Developer discussions <csound-
> devel@...>> >Subject: Re: [Cs-dev] parallel
> processing panel at ICMC> >> >I was thinking of OpenMP for
> parallelising engine code rather > than to> >substitute pthreads
> for everything (we'll keep pthreads for> >threads...). OpenMP
> seemed to be quite useful.> >> >Victor> >----- Original Message -
> ---- > >From: "Steven Yi" <stevenyi@...>> >To:
> "Developer discussions" <csound-devel@...>>
> >Sent: Monday, September 01, 2008 3:07 AM> >Subject: Re: [Cs-
> dev] parallel processing panel at ICMC> >> >> >> Hi Victor,> >>>
> >> Thanks very much for the report!  It seems to me that we >
> would use> >> OpenMP in the same way as the code we currently
> have in that > we use a> >> barrier and split work.  We would
> still need to work on > a better work> >> partitioning system,
> regardless of a change to OpenMP or not.> >>> >> I took a
> further look int OpenMP and it looks pretty nice. > However, it>
> >> looks like gcc 4.x is only in alpha state for MinGW.  If > it
> works then> >> that'd be great.> >>> >> As for replacing
> pthread, I wonder if that would be > appropriate for> >> the
> threaded code we have that isn't related to parallelizing code.>
> >> On the other hand, I don't know if we can use pthreads in >
> conjunction>> with OpenMP.> >>> >> So, what does everyone else
> think?  I am thinking our > current code is> >> enough for now
> for running the parallel code, and we might be > better>> served
> to continue to look at places where we are > running into> >>
> problems.> >>> >> A step we can take would be to start
> systematically creating > a test> >> suite of CSD's, much like
> what was done for the new parser > and the> >> tests in the
> tests directory.  Those tests for the new > parser took one> >>
> step at a time and introduced a single new language feature > to
> test> >> another feature of the processor.  We should probably
> do > something>> similar so that we can step by step test and
> then if > we find a> >> problem, we'd have a good idea of what
> the problem was from > as we only> >> add one feature at a
> time.> >>> >> Thoughts?> >> steven> >>> >>> >>> >>> >> On Sun,
> Aug 31, 2008 at 3:33 PM, victor > <Victor.Lazzarini@...>
> wrote:> >>> Hello everyone,> >>>> >>> just a quick e-mail in
> relation to the panel at ICMC. John > was there and> >>> might
> add details to these.> >>>> >>> The overall tone was 'yes it is
> a good idea; we'll have to > do it, but we> >>> don't know how
> yet.'  I asked the question we wanted to know:> >>> who is doing
> it? They basically shrugged and said, "well max has> >>> the
> poly object...", and then someone said that SCSynth > could be>
> >>> run several separate, but unconnected, processes, to what I
> > replied,>>> so can any other program...> >>>> >>> The only
> thing I found useful was to hear the FAUST guy talk about> >>>
> their multiprocessor output usimg openMP. They also have >
> experience>>> with their parallel version of Jack.> >>>> >>> Has
> anyone looked at OpenMP. Looks dead easy to use, it > seems
> available> >>> across the board for all support platforms (gcc
> 4.2). > Perhaps we can use> >>> that instead of pthreads?> >>>>
> >>> But overall, they all seemed clueless. The discussions in >
> this list > >>> seemed> >>> to be better informed. The added
> joke was Miller Puckette > saying that > >>> with> >>> his three
> year PC he could run six PVs so he was happy and > did not want>
> >>> to bother with it.> >>>> >>> Regards> >>>> >>> Victor> >>>>
> >>> -------------------------------------------------------------
> > ------------> >>> This SF.Net email is sponsored by the Moblin
> Your Move > Developer's > >>> challenge> >>> Build the coolest
> Linux based applications with Moblin SDK & > win great> >>>
> prizes> >>> Grand prize is a trip for two to an Open Source
> event > anywhere in the > >>> world> >>> http://moblin-
> contest.org/redirect.php?banner_id=100&url=/> >>>
> _______________________________________________> >>> Csound-
> devel mailing list> >>> Csound-devel@...> >>>
> https://lists.sourceforge.net/lists/listinfo/csound-devel> >>>>
> >>>> >>> >> -----------------------------------------------------
> ---------> -----------> >> This SF.Net email is sponsored by the
> Moblin Your Move > Developer's > >> challenge> >> Build the
> coolest Linux based applications with Moblin SDK & > win great >
> >> prizes> >> Grand prize is a trip for two to an Open Source
> event > anywhere in the > >> world> >> http://moblin-
> contest.org/redirect.php?banner_id=100&url=/> >>
> _______________________________________________> >> Csound-devel
> mailing list> >> Csound-devel@...> >>
> https://lists.sourceforge.net/lists/listinfo/csound-devel > >>
> >> >-------------------------------------------------------------
> ---> ---------> >This SF.Net email is sponsored by the Moblin
> Your Move > Developer's challenge> >Build the coolest Linux
> based applications with Moblin SDK & > win great prizes> >Grand
> prize is a trip for two to an Open Source event anywhere > in
> the world> >http://moblin-
> contest.org/redirect.php?banner_id=100&url=/> >_______________________________________________> >Csound-devel mailing list> >Csound-devel@...> >https://lists.sourceforge.net/lists/listinfo/csound-devel> > > > > -----------------------------------------------------------------> --------> This SF.Net email is sponsored by the Moblin Your Move > Developer's challenge> Build the coolest Linux based applications with Moblin SDK & win > great prizes> Grand prize is a trip for two to an Open Source event anywhere > in the world> http://moblin-contest.org/redirect.php?banner_id=100&url=/> _______________________________________________> Csound-devel mailing list> Csound-devel@...> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
>
> -----------------------------------------------------------------
> --------
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere
> in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Parent Message unknown Re: parallel processing panel at ICMC

by Michael Gogins :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

That's interesting. How does Faust parallelize opcode processing? I'll look it up...

You need enough instructions in each block of parallel code so that running blocks in parallel more than pays for the overhead of managing parallelizing. This is called 'grain size.' It should be at least 10,000 instructions of machine code, which is at least several thousand arithmetic operations. In Csound, of course, an opcode is usually a loop that iterates ksmps times, so the grain size = opcode instruction count x ksmps (it's not really that simple, jpff has a more complete explanation). For low-latency performance at 44.1 KHz, ksmps can be no more than about 20. So, the opcode frame-rate loops must total at least 10,000/20 = 500 machine instructions, i.e. roughly 500/3 or 167 arithmetic/logic operations inside the frame-rate loops.

jpff already counted opcode instructions, and his figures show that many opcodes are too small to benefit from running them in parallel, but equally, many are big enough. I don't think it would be a big problem to run only some opcodes in parallel, but it would be a basic change in the Csound 'engine.'

Also, parallelizing opcodes could mean either (a) using parallel for within the frame rate loops, or (b) running independent opcodes in parallel. Which are we talking about here, or both?

Regards,
Mike

-----Original Message-----

>From: Victor.Lazzarini@...
>Sent: Sep 2, 2008 9:32 AM
>To: Michael Gogins <gogins@...>, Developer discussions <csound-devel@...>
>Subject: Re: [Cs-dev] parallel processing panel at ICMC
>
>I don't know threading blocks, but if it becomes available elsewhere, it
>might be OK IMHO. However, OpenMP seems to be more prevalent
>and more of an 'open' standard (as the name implies). The reason I suggested
>it is that it might make it easier to maintain and expand a multiprocessing
>system in Csound. I can see how pthreads etc will also do the job and if
>we don't need more than that, there is no problem.
>
>One thing I thought it might be useful for is if we try to parallelise opcode processing,
>as in the way FAUST does.
>
>Victor
>
>----- Original Message -----
>From: Michael Gogins <gogins@...>
>Date: Tuesday, September 2, 2008 1:36 pm
>Subject: Re: [Cs-dev] parallel processing panel at ICMC
>To: csound-devel@...
>
>> Thanks for your thoughts.
>>
>> I don't want to introduce more conditional compilation into C++,
>> even though your suggestion is, of course, quite
>> straightforward.  I'm afraid I don't see the point of
>> making the Csound build more complex than it already is for not
>> much return. As I said, I'm willing to just drop Visual C++ and
>> commit to OpenMP.
>>
>> But equally, I have no problem with just implementing the
>> primitives that we need using pthreads, spinlocks, and whatnot.
>> What we are trying to do in Csound, whatever might be the state
>> of the art in music programming, is not rocket science in C and
>> C++ programming, and doesn't need to be. There probably are some
>> open source libraries that would work on all platforms, as well.
>> I will look.
>>
>> By the way, it's not MS Threading Building Blocks, it's Intel
>> Threading Building Blocks, although the fact that Intel supports
>> TBB on Windows only for MSVC could be confusing. Do you oppose
>> TBB because OpenMP is more of a standard, or because you have
>> tried them both and found OpenMP better, or what?
>>
>> What we need to do is proceed at a reasonable pace, with time to
>> think, and make sure that we understand what our requirements
>> actually are before assuming that one library or package or
>> another is going to satisfy them. So far, I don't see anything
>> that needs any new libraries or APIs beyond what we already have.
>>
>> Regards,
>> Mike
>>
>> -----Original Message-----
>> >From: Victor.Lazzarini@...
>> >Sent: Sep 2, 2008 1:56 AM
>> >To: Michael Gogins <gogins@...>, Developer
>> discussions <csound-devel@...>
>> >Subject: Re: [Cs-dev] parallel processing panel at ICMC
>> >
>> >Michael,thanks for this insight. What if we support OpenMP and
>> use conditionals toallow for (non-parallel) free Visual C++
>> builds? Since this seems to be supportedalmost everywhere else,
>> if we find that OpenMP is the way to go, this might bea good
>> compromise. I am not keen on depending on MS Threading Building
>> Blocks,I think that is possibly waste of our time/resources.In
>> any case the adoption of OpenMP is of course something for long
>> term planning.RegardsVictor----- Original Message -----From:
>> Michael Gogins <gogins@...>Date: Monday, September
>> 1, 2008 4:45 pmSubject: Re: [Cs-dev] parallel processing panel
>> at ICMCTo: Developer discussions <csound-
>> devel@...>> OpenMP is not supported by the
>> Microsoft Visual C++ Express > Edition compiler (OpenMP is
>> supported by the commercial > editions). Since, for the upcoming
>> release, I was planning to do > a Microsoft build for the
>> Windows installers, we may want to > think about using OpenMP.
>> Other than that, OpenMP is a later > iteration of the parallel
>> concepts and looks like a good choice > for Csound. > > As far
>> as MinGW/MSys is concerned, the current Windows > installers are
>> built with MinGW 4.2.1-2 dw2, which does seem to > support
>> OpenMP (haven't actually tried it yet). There was a > Google
>> Summer of Code project, recently completed, to fix > problems
>> with MinGW:> >
>> http://gcc.gnu.org/wiki/WindowsGCCImprovementsGSoC2008> > Note
>> the claim that OpenMP support is OK.> > So it boils down to
>> this: with OpenMP we can forget about Visual > C++. With Visual
>> C++ we can forget about OpenMP.> > I'm personally happy enough
>> with MinGW/MSys and could drop > Visual C++ and proceed with
>> OpenMP, but I think some Csound > users and developers may be
>> anticipating using Visual C++.> > Another candidate would be
>> Intel Threading Building Blocks, > which has a mirror situation:
>> supported on Linux and with Visual > C++, but no support for
>> MinGW,> although it might be possible to go ahead and hack a
>> build with > MinGW. TBB has very good documentation and looks
>> cleanly designed.> > Regards,> Mike> > -----Original Message-----
>> > >From: victor <Victor.Lazzarini@...>> >Sent: Sep 1,
>> 2008 12:00 AM> >To: Developer discussions <csound-
>> devel@...>> >Subject: Re: [Cs-dev] parallel
>> processing panel at ICMC> >> >I was thinking of OpenMP for
>> parallelising engine code rather > than to> >substitute pthreads
>> for everything (we'll keep pthreads for> >threads...). OpenMP
>> seemed to be quite useful.> >> >Victor> >----- Original Message -
>> ---- > >From: "Steven Yi" <stevenyi@...>> >To:
>> "Developer discussions" <csound-devel@...>>
>> >Sent: Monday, September 01, 2008 3:07 AM> >Subject: Re: [Cs-
>> dev] parallel processing panel at ICMC> >> >> >> Hi Victor,> >>>
>> >> Thanks very much for the report!  It seems to me that we >
>> would use> >> OpenMP in the same way as the code we currently
>> have in that > we use a> >> barrier and split work.  We would
>> still need to work on > a better work> >> partitioning system,
>> regardless of a change to OpenMP or not.> >>> >> I took a
>> further look int OpenMP and it looks pretty nice. > However, it>
>> >> looks like gcc 4.x is only in alpha state for MinGW.  If > it
>> works then> >> that'd be great.> >>> >> As for replacing
>> pthread, I wonder if that would be > appropriate for> >> the
>> threaded code we have that isn't related to parallelizing code.>
>> >> On the other hand, I don't know if we can use pthreads in >
>> conjunction>> with OpenMP.> >>> >> So, what does everyone else
>> think?  I am thinking our > current code is> >> enough for now
>> for running the parallel code, and we might be > better>> served
>> to continue to look at places where we are > running into> >>
>> problems.> >>> >> A step we can take would be to start
>> systematically creating > a test> >> suite of CSD's, much like
>> what was done for the new parser > and the> >> tests in the
>> tests directory.  Those tests for the new > parser took one> >>
>> step at a time and introduced a single new language feature > to
>> test> >> another feature of the processor.  We should probably
>> do > something>> similar so that we can step by step test and
>> then if > we find a> >> problem, we'd have a good idea of what
>> the problem was from > as we only> >> add one feature at a
>> time.> >>> >> Thoughts?> >> steven> >>> >>> >>> >>> >> On Sun,
>> Aug 31, 2008 at 3:33 PM, victor > <Victor.Lazzarini@...>
>> wrote:> >>> Hello everyone,> >>>> >>> just a quick e-mail in
>> relation to the panel at ICMC. John > was there and> >>> might
>> add details to these.> >>>> >>> The overall tone was 'yes it is
>> a good idea; we'll have to > do it, but we> >>> don't know how
>> yet.'  I asked the question we wanted to know:> >>> who is doing
>> it? They basically shrugged and said, "well max has> >>> the
>> poly object...", and then someone said that SCSynth > could be>
>> >>> run several separate, but unconnected, processes, to what I
>> > replied,>>> so can any other program...> >>>> >>> The only
>> thing I found useful was to hear the FAUST guy talk about> >>>
>> their multiprocessor output usimg openMP. They also have >
>> experience>>> with their parallel version of Jack.> >>>> >>> Has
>> anyone looked at OpenMP. Looks dead easy to use, it > seems
>> available> >>> across the board for all support platforms (gcc
>> 4.2). > Perhaps we can use> >>> that instead of pthreads?> >>>>
>> >>> But overall, they all seemed clueless. The discussions in >
>> this list > >>> seemed> >>> to be better informed. The added
>> joke was Miller Puckette > saying that > >>> with> >>> his three
>> year PC he could run six PVs so he was happy and > did not want>
>> >>> to bother with it.> >>>> >>> Regards> >>>> >>> Victor> >>>>
>> >>> -------------------------------------------------------------
>> > ------------> >>> This SF.Net email is sponsored by the Moblin
>> Your Move > Developer's > >>> challenge> >>> Build the coolest
>> Linux based applications with Moblin SDK & > win great> >>>
>> prizes> >>> Grand prize is a trip for two to an Open Source
>> event > anywhere in the > >>> world> >>> http://moblin-
>> contest.org/redirect.php?banner_id=100&url=/> >>>
>> _______________________________________________> >>> Csound-
>> devel mailing list> >>> Csound-devel@...> >>>
>> https://lists.sourceforge.net/lists/listinfo/csound-devel> >>>>
>> >>>> >>> >> -----------------------------------------------------
>> ---------> -----------> >> This SF.Net email is sponsored by the
>> Moblin Your Move > Developer's > >> challenge> >> Build the
>> coolest Linux based applications with Moblin SDK & > win great >
>> >> prizes> >> Grand prize is a trip for two to an Open Source
>> event > anywhere in the > >> world> >> http://moblin-
>> contest.org/redirect.php?banner_id=100&url=/> >>
>> _______________________________________________> >> Csound-devel
>> mailing list> >> Csound-devel@...> >>
>> https://lists.sourceforge.net/lists/listinfo/csound-devel > >>
>> >> >-------------------------------------------------------------
>> ---> ---------> >This SF.Net email is sponsored by the Moblin
>> Your Move > Developer's challenge> >Build the coolest Linux
>> based applications with Moblin SDK & > win great prizes> >Grand
>> prize is a trip for two to an Open Source event anywhere > in
>> the world> >http://moblin-
>> contest.org/redirect.php?banner_id=100&url=/> >_______________________________________________> >Csound-devel mailing list> >Csound-devel@...> >https://lists.sourceforge.net/lists/listinfo/csound-devel> > > > > -----------------------------------------------------------------> --------> This SF.Net email is sponsored by the Moblin Your Move > Developer's challenge> Build the coolest Linux based applications with Moblin SDK & win > great prizes> Grand prize is a trip for two to an Open Source event anywhere > in the world> http://moblin-contest.org/redirect.php?banner_id=100&url=/> _______________________________________________> Csound-devel mailing list> Csound-devel@...> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>>
>> -----------------------------------------------------------------
>> --------
>> This SF.Net email is sponsored by the Moblin Your Move
>> Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere
>> in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@...
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>




-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: parallel processing panel at ICMC

by Victor Lazzarini :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Well, I was think parallel processing inside opcodes, which is
what in effect FAUST was doing. This would be useful for large
filterbanks, reverbs with several combs in parallel etc.. I am not
discarding running opcodes in parallel too, but that's a different
thing.

I am aware of the granularity issue (I have done experiments with
MPI in sound synthesis), so all of these things need to be tested
and considered. But if the mechanisms are there, it is possible
to do these tests.

Regards

Victor

----- Original Message -----
From: Michael Gogins <gogins@...>
Date: Tuesday, September 2, 2008 6:58 pm
Subject: Re: [Cs-dev] parallel processing panel at ICMC
To: csound-devel@...

> That's interesting. How does Faust parallelize opcode
> processing? I'll look it up...
>
> You need enough instructions in each block of parallel code so
> that running blocks in parallel more than pays for the overhead
> of managing parallelizing. This is called 'grain size.' It
> should be at least 10,000 instructions of machine code, which is
> at least several thousand arithmetic operations. In Csound, of
> course, an opcode is usually a loop that iterates ksmps times,
> so the grain size = opcode instruction count x ksmps (it's not
> really that simple, jpff has a more complete explanation). For
> low-latency performance at 44.1 KHz, ksmps can be no more than
> about 20. So, the opcode frame-rate loops must total at least
> 10,000/20 = 500 machine instructions, i.e. roughly 500/3 or 167
> arithmetic/logic operations inside the frame-rate loops.
>
> jpff already counted opcode instructions, and his figures show
> that many opcodes are too small to benefit from running them in
> parallel, but equally, many are big enough. I don't think it
> would be a big problem to run only some opcodes in parallel, but
> it would be a basic change in the Csound 'engine.'
>
> Also, parallelizing opcodes could mean either (a) using parallel
> for within the frame rate loops, or (b) running independent
> opcodes in parallel. Which are we talking about here, or both?
>
> Regards,
> Mike
>
> -----Original Message-----
> >From: Victor.Lazzarini@...
> >Sent: Sep 2, 2008 9:32 AM
> >To: Michael Gogins <gogins@...>, Developer
> discussions <csound-devel@...>
> >Subject: Re: [Cs-dev] parallel processing panel at ICMC
> >
> >I don't know threading blocks, but if it becomes available
> elsewhere, it
> >might be OK IMHO. However, OpenMP seems to be more prevalent
> >and more of an 'open' standard (as the name implies). The
> reason I suggested
> >it is that it might make it easier to maintain and expand a
> multiprocessing>system in Csound. I can see how pthreads etc
> will also do the job and if
> >we don't need more than that, there is no problem.
> >
> >One thing I thought it might be useful for is if we try to
> parallelise opcode processing,
> >as in the way FAUST does.
> >
> >Victor
> >
> >----- Original Message -----
> >From: Michael Gogins <gogins@...>
> >Date: Tuesday, September 2, 2008 1:36 pm
> >Subject: Re: [Cs-dev] parallel processing panel at ICMC
> >To: csound-devel@...
> >
> >> Thanks for your thoughts.
> >>
> >> I don't want to introduce more conditional compilation into
> C++,
> >> even though your suggestion is, of course, quite
> >> straightforward.  I'm afraid I don't see the point of
> >> making the Csound build more complex than it already is for
> not
> >> much return. As I said, I'm willing to just drop Visual C++
> and
> >> commit to OpenMP.
> >>
> >> But equally, I have no problem with just implementing the
> >> primitives that we need using pthreads, spinlocks, and
> whatnot.
> >> What we are trying to do in Csound, whatever might be the
> state
> >> of the art in music programming, is not rocket science in C
> and
> >> C++ programming, and doesn't need to be. There probably are
> some
> >> open source libraries that would work on all platforms, as
> well.
> >> I will look.
> >>
> >> By the way, it's not MS Threading Building Blocks, it's Intel
> >> Threading Building Blocks, although the fact that Intel
> supports
> >> TBB on Windows only for MSVC could be confusing. Do you
> oppose
> >> TBB because OpenMP is more of a standard, or because you have
> >> tried them both and found OpenMP better, or what?
> >>
> >> What we need to do is proceed at a reasonable pace, with time
> to
> >> think, and make sure that we understand what our requirements
> >> actually are before assuming that one library or package or
> >> another is going to satisfy them. So far, I don't see
> anything
> >> that needs any new libraries or APIs beyond what we already have.
> >>
> >> Regards,
> >> Mike
> >>
> >> -----Original Message-----
> >> >From: Victor.Lazzarini@...
> >> >Sent: Sep 2, 2008 1:56 AM
> >> >To: Michael Gogins <gogins@...>, Developer
> >> discussions <csound-devel@...>
> >> >Subject: Re: [Cs-dev] parallel processing panel at ICMC
> >> >
> >> >Michael,thanks for this insight. What if we support OpenMP
> and
> >> use conditionals toallow for (non-parallel) free Visual C++
> >> builds? Since this seems to be supportedalmost everywhere
> else,
> >> if we find that OpenMP is the way to go, this might bea good
> >> compromise. I am not keen on depending on MS Threading
> Building
> >> Blocks,I think that is possibly waste of our
> time/resources.In
> >> any case the adoption of OpenMP is of course something for
> long
> >> term planning.RegardsVictor----- Original Message -----From:
> >> Michael Gogins <gogins@...>Date: Monday,
> September
> >> 1, 2008 4:45 pmSubject: Re: [Cs-dev] parallel processing
> panel
> >> at ICMCTo: Developer discussions <csound-
> >> devel@...>> OpenMP is not supported by the
> >> Microsoft Visual C++ Express > Edition compiler (OpenMP is
> >> supported by the commercial > editions). Since, for the
> upcoming
> >> release, I was planning to do > a Microsoft build for the
> >> Windows installers, we may want to > think about using
> OpenMP.
> >> Other than that, OpenMP is a later > iteration of the
> parallel
> >> concepts and looks like a good choice > for Csound. > > As
> far
> >> as MinGW/MSys is concerned, the current Windows > installers
> are
> >> built with MinGW 4.2.1-2 dw2, which does seem to > support
> >> OpenMP (haven't actually tried it yet). There was a > Google
> >> Summer of Code project, recently completed, to fix > problems
> >> with MinGW:> >
> >> http://gcc.gnu.org/wiki/WindowsGCCImprovementsGSoC2008> >
> Note
> >> the claim that OpenMP support is OK.> > So it boils down to
> >> this: with OpenMP we can forget about Visual > C++. With
> Visual
> >> C++ we can forget about OpenMP.> > I'm personally happy
> enough
> >> with MinGW/MSys and could drop > Visual C++ and proceed with
> >> OpenMP, but I think some Csound > users and developers may be
> >> anticipating using Visual C++.> > Another candidate would be
> >> Intel Threading Building Blocks, > which has a mirror
> situation:
> >> supported on Linux and with Visual > C++, but no support for
> >> MinGW,> although it might be possible to go ahead and hack a
> >> build with > MinGW. TBB has very good documentation and looks
> >> cleanly designed.> > Regards,> Mike> > -----Original Message--
> ---
> >> > >From: victor <Victor.Lazzarini@...>> >Sent: Sep 1,
> >> 2008 12:00 AM> >To: Developer discussions <csound-
> >> devel@...>> >Subject: Re: [Cs-dev] parallel
> >> processing panel at ICMC> >> >I was thinking of OpenMP for
> >> parallelising engine code rather > than to> >substitute
> pthreads
> >> for everything (we'll keep pthreads for> >threads...). OpenMP
> >> seemed to be quite useful.> >> >Victor> >----- Original
> Message -
> >> ---- > >From: "Steven Yi" <stevenyi@...>> >To:
> >> "Developer discussions" <csound-
> devel@...>>
> >> >Sent: Monday, September 01, 2008 3:07 AM> >Subject: Re: [Cs-
> >> dev] parallel processing panel at ICMC> >> >> >> Hi Victor,>
> >>>
> >> >> Thanks very much for the report!  It seems to me that
> we >
> >> would use> >> OpenMP in the same way as the code we currently
> >> have in that > we use a> >> barrier and split work.  We
> would
> >> still need to work on > a better work> >> partitioning
> system,
> >> regardless of a change to OpenMP or not.> >>> >> I took a
> >> further look int OpenMP and it looks pretty nice. > However,
> it>
> >> >> looks like gcc 4.x is only in alpha state for MinGW.  
> If > it
> >> works then> >> that'd be great.> >>> >> As for replacing
> >> pthread, I wonder if that would be > appropriate for> >> the
> >> threaded code we have that isn't related to parallelizing
> code.>
> >> >> On the other hand, I don't know if we can use pthreads in
> >
> >> conjunction>> with OpenMP.> >>> >> So, what does everyone
> else
> >> think?  I am thinking our > current code is> >> enough
> for now
> >> for running the parallel code, and we might be > better>>
> served
> >> to continue to look at places where we are > running into> >>
> >> problems.> >>> >> A step we can take would be to start
> >> systematically creating > a test> >> suite of CSD's, much
> like
> >> what was done for the new parser > and the> >> tests in the
> >> tests directory.  Those tests for the new > parser took
> one> >>
> >> step at a time and introduced a single new language feature >
> to
> >> test> >> another feature of the processor.  We should
> probably
> >> do > something>> similar so that we can step by step test and
> >> then if > we find a> >> problem, we'd have a good idea of
> what
> >> the problem was from > as we only> >> add one feature at a
> >> time.> >>> >> Thoughts?> >> steven> >>> >>> >>> >>> >> On
> Sun,
> >> Aug 31, 2008 at 3:33 PM, victor >
> <Victor.Lazzarini@...>
> >> wrote:> >>> Hello everyone,> >>>> >>> just a quick e-mail in
> >> relation to the panel at ICMC. John > was there and> >>>
> might
> >> add details to these.> >>>> >>> The overall tone was 'yes it
> is
> >> a good idea; we'll have to > do it, but we> >>> don't know
> how
> >> yet.'  I asked the question we wanted to know:> >>> who
> is doing
> >> it? They basically shrugged and said, "well max has> >>> the
> >> poly object...", and then someone said that SCSynth > could
> be>
> >> >>> run several separate, but unconnected, processes, to what
> I
> >> > replied,>>> so can any other program...> >>>> >>> The only
> >> thing I found useful was to hear the FAUST guy talk about>
> >>>
> >> their multiprocessor output usimg openMP. They also have >
> >> experience>>> with their parallel version of Jack.> >>>> >>>
> Has
> >> anyone looked at OpenMP. Looks dead easy to use, it > seems
> >> available> >>> across the board for all support platforms
> (gcc
> >> 4.2). > Perhaps we can use> >>> that instead of pthreads?>
> >>>>
> >> >>> But overall, they all seemed clueless. The discussions in
> >
> >> this list > >>> seemed> >>> to be better informed. The added
> >> joke was Miller Puckette > saying that > >>> with> >>> his
> three
> >> year PC he could run six PVs so he was happy and > did not
> want>
> >> >>> to bother with it.> >>>> >>> Regards> >>>> >>> Victor>
> >>>>
> >> >>> ----------------------------------------------------------
> ---
> >> > ------------> >>> This SF.Net email is sponsored by the
> Moblin
> >> Your Move > Developer's > >>> challenge> >>> Build the
> coolest
> >> Linux based applications with Moblin SDK & > win great> >>>
> >> prizes> >>> Grand prize is a trip for two to an Open Source
> >> event > anywhere in the > >>> world> >>> http://moblin-
> >> contest.org/redirect.php?banner_id=100&url=/> >>>
> >> _______________________________________________> >>> Csound-
> >> devel mailing list> >>> Csound-devel@...>
> >>>
> >> https://lists.sourceforge.net/lists/listinfo/csound-devel>
> >>>>
> >> >>>> >>> >> --------------------------------------------------
> ---
> >> ---------> -----------> >> This SF.Net email is sponsored by
> the
> >> Moblin Your Move > Developer's > >> challenge> >> Build the
> >> coolest Linux based applications with Moblin SDK & > win
> great >
> >> >> prizes> >> Grand prize is a trip for two to an Open Source
> >> event > anywhere in the > >> world> >> http://moblin-
> >> contest.org/redirect.php?banner_id=100&url=/> >>
> >> _______________________________________________> >> Csound-
> devel
> >> mailing list> >> Csound-devel@...> >>
> >> https://lists.sourceforge.net/lists/listinfo/csound-devel >
> >>
> >> >> >----------------------------------------------------------
> ---
> >> ---> ---------> >This SF.Net email is sponsored by the Moblin
> >> Your Move > Developer's challenge> >Build the coolest Linux
> >> based applications with Moblin SDK & > win great prizes>
> >Grand
> >> prize is a trip for two to an Open Source event anywhere > in
> >> the world> >http://moblin-
> >> contest.org/redirect.php?banner_id=100&url=/>
> >_______________________________________________> >Csound-devel
> mailing list> >Csound-devel@...>
> >https://lists.sourceforge.net/lists/listinfo/csound-devel> > >
> > > -------------------------------------------------------------
> ----> --------> This SF.Net email is sponsored by the Moblin
> Your Move > Developer's challenge> Build the coolest Linux based
> applications with Moblin SDK & win > great prizes> Grand prize
> is a trip for two to an Open Source event anywhere > in the
> world> http://moblin-
> contest.org/redirect.php?banner_id=100&url=/> _______________________________________________> Csound-devel mailing list> Csound-devel@...> https://lists.sourceforge.net/lists/listinfo/csound-devel
> >>
> >>
> >>
> >>
> >> --------------------------------------------------------------
> ---
> >> --------
> >> This SF.Net email is sponsored by the Moblin Your Move
> >> Developer's challenge
> >> Build the coolest Linux based applications with Moblin SDK &
> win
> >> great prizes
> >> Grand prize is a trip for two to an Open Source event
> anywhere
> >> in the world
> >> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >> _______________________________________________
> >> Csound-devel mailing list
> >> Csound-devel@...
> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
>
>
>
>
> -----------------------------------------------------------------
> --------
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere
> in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: parallel processing panel at ICMC

by Felipe Sateler :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Sorry to resurrect an old thread, but I just came accross OpenMP for other
reasons and remembered this discussion.
OpenMP seems very simple to use. However, I don't get the "still use pthreads
for threads" part. OpenMP has the nice feature that it keeps count of how many
threads are running (if I understood correctly), so the --num-threads
implementation is reduced to setting the openmp max number of threads, and you
can then do loop parallelization, etc without worrying about that. Mixing with
pthreads looses this nice feature.

El lunes 1 de septiembre, victor escribió:

> I was thinking of OpenMP for parallelising engine code rather than to
> substitute pthreads for everything (we'll keep pthreads for
> threads...). OpenMP seemed to be quite useful.
>
> Victor
> ----- Original Message -----
> From: "Steven Yi" <stevenyi@...>
> To: "Developer discussions" <csound-devel@...>
> Sent: Monday, September 01, 2008 3:07 AM
> Subject: Re: [Cs-dev] parallel processing panel at ICMC
>
> > Hi Victor,
> >
> > Thanks very much for the report!  It seems to me that we would use
> > OpenMP in the same way as the code we currently have in that we use a
> > barrier and split work.  We would still need to work on a better work
> > partitioning system, regardless of a change to OpenMP or not.
> >
> > I took a further look int OpenMP and it looks pretty nice. However, it
> > looks like gcc 4.x is only in alpha state for MinGW.  If it works then
> > that'd be great.
> >
> > As for replacing pthread, I wonder if that would be appropriate for
> > the threaded code we have that isn't related to parallelizing code.
> > On the other hand, I don't know if we can use pthreads in conjunction
> > with OpenMP.
> >
> > So, what does everyone else think?  I am thinking our current code is
> > enough for now for running the parallel code, and we might be better
> > served to continue to look at places where we are running into
> > problems.
> >
> > A step we can take would be to start systematically creating a test
> > suite of CSD's, much like what was done for the new parser and the
> > tests in the tests directory.  Those tests for the new parser took one
> > step at a time and introduced a single new language feature to test
> > another feature of the processor.  We should probably do something
> > similar so that we can step by step test and then if we find a
> > problem, we'd have a good idea of what the problem was from as we only
> > add one feature at a time.
> >
> > Thoughts?
> > steven
> >
> > On Sun, Aug 31, 2008 at 3:33 PM, victor <Victor.Lazzarini@...> wrote:
> >> Hello everyone,
> >>
> >> just a quick e-mail in relation to the panel at ICMC. John was there and
> >> might add details to these.
> >>
> >> The overall tone was 'yes it is a good idea; we'll have to do it, but we
> >> don't know how yet.'  I asked the question we wanted to know:
> >> who is doing it? They basically shrugged and said, "well max has
> >> the poly object...", and then someone said that SCSynth could be
> >> run several separate, but unconnected, processes, to what I replied,
> >> so can any other program...
> >>
> >> The only thing I found useful was to hear the FAUST guy talk about
> >> their multiprocessor output usimg openMP. They also have experience
> >> with their parallel version of Jack.
> >>
> >> Has anyone looked at OpenMP. Looks dead easy to use, it seems available
> >> across the board for all support platforms (gcc 4.2). Perhaps we can use
> >> that instead of pthreads?
> >>
> >> But overall, they all seemed clueless. The discussions in this list
> >> seemed
> >> to be better informed. The added joke was Miller Puckette saying that
> >> with
> >> his three year PC he could run six PVs so he was happy and did not want
> >> to bother with it.
> >>
> >> Regards
> >>
> >> Victor
> >>
> >> ------------------------------------------------------------------------
> >>- This SF.Net email is sponsored by the Moblin Your Move Developer's
> >> challenge
> >> Build the coolest Linux based applications with Moblin SDK & win great
> >> prizes
> >> Grand prize is a trip for two to an Open Source event anywhere in the
> >> world
> >> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >> _______________________________________________
> >> Csound-devel mailing list
> >> Csound-devel@...
> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> > challenge
> > Build the coolest Linux based applications with Moblin SDK & win great
> > prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the
> > world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > Csound-devel mailing list
> > Csound-devel@...
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge Build the coolest Linux based applications with Moblin SDK & win
> great prizes Grand prize is a trip for two to an Open Source event anywhere
> in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel


Saludos,
Felipe Sateler


------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

signature.asc (852 bytes) Download Attachment

Re: parallel processing panel at ICMC

by Victor Lazzarini :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

You're quite right. I don't know what I was thinking then, but I guess it's
to do
with a separation of  synthesis/event (messages) loops at host application
level.
Victor

----- Original Message -----
From: "Felipe Sateler" <fsateler@...>
To: "Developer discussions" <csound-devel@...>
Sent: Wednesday, May 27, 2009 3:12 AM
Subject: Re: [Cs-dev] parallel processing panel at ICMC


> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals.
> Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp as they present alongside digital heavyweights like
> Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com


--------------------------------------------------------------------------------


> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: parallel processing panel at ICMC

by RoryWalsh :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I got your comments about the text, thanks for looking over it. I hope
it's Ok. It feel a little naked to me without fancy GUI examples but
in the command line we trust!

Rory.


2009/5/27 victor <Victor.Lazzarini@...>:

> You're quite right. I don't know what I was thinking then, but I guess it's
> to do
> with a separation of  synthesis/event (messages) loops at host application
> level.
> Victor
>
> ----- Original Message -----
> From: "Felipe Sateler" <fsateler@...>
> To: "Developer discussions" <csound-devel@...>
> Sent: Wednesday, May 27, 2009 3:12 AM
> Subject: Re: [Cs-dev] parallel processing panel at ICMC
>
>
>> ------------------------------------------------------------------------------
>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>> is a gathering of tech-side developers & brand creativity professionals.
>> Meet
>> the minds behind Google Creative Lab, Visual Complexity, Processing, &
>> iPhoneDevCamp as they present alongside digital heavyweights like
>> Barbarian
>> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
>
>
> --------------------------------------------------------------------------------
>
>
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@...
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: parallel processing panel at ICMC

by Michael Gogins-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

The current state of the art with OpenMP for audio processing with GCC
and ICC can be gleaned from:

http://lad.linuxaudio.org/events/2009_cdm/Friday/10_Orlarey/10.pdf

Since Sun has supported OpenMP for a long time and is known
performance, I infer that Sun is on roughly the same level as ICC.

In brutal summary, GCC isn't there yet, but ICC is, and I would bet
that Sun is The next release of GCC should be OK.

So, we can't currently count on improving performance with OpenMP on
GCC, but we have shown that we CAN do it with just GCC and pthreads.
We should keep going on this path until GCC actually demonstrates some
oomph.

Or, we should mandate ICC for Csound builds. But this will not work on
Windows unless the free Microsoft compiler supports OpenMP (I don't
think it does, but I will check).

Regards,
Mike


On 5/26/09, Felipe Sateler <fsateler@...> wrote:

> Sorry to resurrect an old thread, but I just came accross OpenMP for other
> reasons and remembered this discussion.
> OpenMP seems very simple to use. However, I don't get the "still use
> pthreads
> for threads" part. OpenMP has the nice feature that it keeps count of how
> many
> threads are running (if I understood correctly), so the --num-threads
> implementation is reduced to setting the openmp max number of threads, and
> you
> can then do loop parallelization, etc without worrying about that. Mixing
> with
> pthreads looses this nice feature.
>
> El lunes 1 de septiembre, victor escribió:
>> I was thinking of OpenMP for parallelising engine code rather than to
>> substitute pthreads for everything (we'll keep pthreads for
>> threads...). OpenMP seemed to be quite useful.
>>
>> Victor
>> ----- Original Message -----
>> From: "Steven Yi" <stevenyi@...>
>> To: "Developer discussions" <csound-devel@...>
>> Sent: Monday, September 01, 2008 3:07 AM
>> Subject: Re: [Cs-dev] parallel processing panel at ICMC
>>
>> > Hi Victor,
>> >
>> > Thanks very much for the report!  It seems to me that we would use
>> > OpenMP in the same way as the code we currently have in that we use a
>> > barrier and split work.  We would still need to work on a better work
>> > partitioning system, regardless of a change to OpenMP or not.
>> >
>> > I took a further look int OpenMP and it looks pretty nice. However, it
>> > looks like gcc 4.x is only in alpha state for MinGW.  If it works then
>> > that'd be great.
>> >
>> > As for replacing pthread, I wonder if that would be appropriate for
>> > the threaded code we have that isn't related to parallelizing code.
>> > On the other hand, I don't know if we can use pthreads in conjunction
>> > with OpenMP.
>> >
>> > So, what does everyone else think?  I am thinking our current code is
>> > enough for now for running the parallel code, and we might be better
>> > served to continue to look at places where we are running into
>> > problems.
>> >
>> > A step we can take would be to start systematically creating a test
>> > suite of CSD's, much like what was done for the new parser and the
>> > tests in the tests directory.  Those tests for the new parser took one
>> > step at a time and introduced a single new language feature to test
>> > another feature of the processor.  We should probably do something
>> > similar so that we can step by step test and then if we find a
>> > problem, we'd have a good idea of what the problem was from as we only
>> > add one feature at a time.
>> >
>> > Thoughts?
>> > steven
>> >
>> > On Sun, Aug 31, 2008 at 3:33 PM, victor <Victor.Lazzarini@...>
>> > wrote:
>> >> Hello everyone,
>> >>
>> >> just a quick e-mail in relation to the panel at ICMC. John was there
>> >> and
>> >> might add details to these.
>> >>
>> >> The overall tone was 'yes it is a good idea; we'll have to do it, but
>> >> we
>> >> don't know how yet.'  I asked the question we wanted to know:
>> >> who is doing it? They basically shrugged and said, "well max has
>> >> the poly object...", and then someone said that SCSynth could be
>> >> run several separate, but unconnected, processes, to what I replied,
>> >> so can any other program...
>> >>
>> >> The only thing I found useful was to hear the FAUST guy talk about
>> >> their multiprocessor output usimg openMP. They also have experience
>> >> with their parallel version of Jack.
>> >>
>> >> Has anyone looked at OpenMP. Looks dead easy to use, it seems available
>> >> across the board for all support platforms (gcc 4.2). Perhaps we can
>> >> use
>> >> that instead of pthreads?
>> >>
>> >> But overall, they all seemed clueless. The discussions in this list
>> >> seemed
>> >> to be better informed. The added joke was Miller Puckette saying that
>> >> with
>> >> his three year PC he could run six PVs so he was happy and did not want
>> >> to bother with it.
>> >>
>> >> Regards
>> >>
>> >> Victor
>> >>
>> >> ------------------------------------------------------------------------
>> >>- This SF.Net email is sponsored by the Moblin Your Move Developer's
>> >> challenge
>> >> Build the coolest Linux based applications with Moblin SDK & win great
>> >> prizes
>> >> Grand prize is a trip for two to an Open Source event anywhere in the
>> >> world
>> >> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> >> _______________________________________________
>> >> Csound-devel mailing list
>> >> Csound-devel@...
>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >
>> > -------------------------------------------------------------------------
>> > This SF.Net email is sponsored by the Moblin Your Move Developer's
>> > challenge
>> > Build the coolest Linux based applications with Moblin SDK & win great
>> > prizes
>> > Grand prize is a trip for two to an Open Source event anywhere in the
>> > world
>> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> > _______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@...
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge Build the coolest Linux based applications with Moblin SDK & win
>> great prizes Grand prize is a trip for two to an Open Source event
>> anywhere
>> in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@...
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> Saludos,
> Felipe Sateler
>


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

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: parallel processing panel at ICMC

by Victor Lazzarini :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I think we should wait for John's parallel code, before trying to
do anything else.

Victor

----- Original Message -----
From: Michael Gogins <michael.gogins@...>
Date: Wednesday, May 27, 2009 1:56 pm
Subject: Re: [Cs-dev] parallel processing panel at ICMC
To: Developer discussions <csound-devel@...>

> The current state of the art with OpenMP for audio processing
> with GCC
> and ICC can be gleaned from:
>
> http://lad.linuxaudio.org/events/2009_cdm/Friday/10_Orlarey/10.pdf
>
> Since Sun has supported OpenMP for a long time and is known
> performance, I infer that Sun is on roughly the same level as ICC.
>
> In brutal summary, GCC isn't there yet, but ICC is, and I would bet
> that Sun is The next release of GCC should be OK.
>
> So, we can't currently count on improving performance with
> OpenMP on
> GCC, but we have shown that we CAN do it with just GCC and pthreads.
> We should keep going on this path until GCC actually
> demonstrates some
> oomph.
>
> Or, we should mandate ICC for Csound builds. But this will not
> work on
> Windows unless the free Microsoft compiler supports OpenMP (I don't
> think it does, but I will check).
>
> Regards,
> Mike
>
>
> On 5/26/09, Felipe Sateler <fsateler@...> wrote:
> > Sorry to resurrect an old thread, but I just came accross
> OpenMP for other
> > reasons and remembered this discussion.
> > OpenMP seems very simple to use. However, I don't get the
> "still use
> > pthreads
> > for threads" part. OpenMP has the nice feature that it keeps
> count of how
> > many
> > threads are running (if I understood correctly), so the --num-
> threads> implementation is reduced to setting the openmp max
> number of threads, and
> > you
> > can then do loop parallelization, etc without worrying about
> that. Mixing
> > with
> > pthreads looses this nice feature.
> >
> > El lunes 1 de septiembre, victor escribió:
> >> I was thinking of OpenMP for parallelising engine code rather
> than to
> >> substitute pthreads for everything (we'll keep pthreads for
> >> threads...). OpenMP seemed to be quite useful.
> >>
> >> Victor
> >> ----- Original Message -----
> >> From: "Steven Yi" <stevenyi@...>
> >> To: "Developer discussions" <csound-devel@...>
> >> Sent: Monday, September 01, 2008 3:07 AM
> >> Subject: Re: [Cs-dev] parallel processing panel at ICMC
> >>
> >> > Hi Victor,
> >> >
> >> > Thanks very much for the report!  It seems to me that
> we would use
> >> > OpenMP in the same way as the code we currently have in
> that we use a
> >> > barrier and split work.  We would still need to work
> on a better work
> >> > partitioning system, regardless of a change to OpenMP or not.
> >> >
> >> > I took a further look int OpenMP and it looks pretty nice.
> However, it
> >> > looks like gcc 4.x is only in alpha state for MinGW. 
> If it works then
> >> > that'd be great.
> >> >
> >> > As for replacing pthread, I wonder if that would be
> appropriate for
> >> > the threaded code we have that isn't related to
> parallelizing code.
> >> > On the other hand, I don't know if we can use pthreads in
> conjunction>> > with OpenMP.
> >> >
> >> > So, what does everyone else think?  I am thinking our
> current code is
> >> > enough for now for running the parallel code, and we might
> be better
> >> > served to continue to look at places where we are running into
> >> > problems.
> >> >
> >> > A step we can take would be to start systematically
> creating a test
> >> > suite of CSD's, much like what was done for the new parser
> and the
> >> > tests in the tests directory.  Those tests for the new
> parser took one
> >> > step at a time and introduced a single new language feature
> to test
> >> > another feature of the processor.  We should probably
> do something
> >> > similar so that we can step by step test and then if we
> find a
> >> > problem, we'd have a good idea of what the problem was from
> as we only
> >> > add one feature at a time.
> >> >
> >> > Thoughts?
> >> > steven
> >> >
> >> > On Sun, Aug 31, 2008 at 3:33 PM, victor
> <Victor.Lazzarini@...>>> > wrote:
> >> >> Hello everyone,
> >> >>
> >> >> just a quick e-mail in relation to the panel at ICMC. John
> was there
> >> >> and
> >> >> might add details to these.
> >> >>
> >> >> The overall tone was 'yes it is a good idea; we'll have to
> do it, but
> >> >> we
> >> >> don't know how yet.'  I asked the question we wanted
> to know:
> >> >> who is doing it? They basically shrugged and said, "well
> max has
> >> >> the poly object...", and then someone said that SCSynth
> could be
> >> >> run several separate, but unconnected, processes, to what
> I replied,
> >> >> so can any other program...
> >> >>
> >> >> The only thing I found useful was to hear the FAUST guy
> talk about
> >> >> their multiprocessor output usimg openMP. They also have
> experience>> >> with their parallel version of Jack.
> >> >>
> >> >> Has anyone looked at OpenMP. Looks dead easy to use, it
> seems available
> >> >> across the board for all support platforms (gcc 4.2).
> Perhaps we can
> >> >> use
> >> >> that instead of pthreads?
> >> >>
> >> >> But overall, they all seemed clueless. The discussions in
> this list
> >> >> seemed
> >> >> to be better informed. The added joke was Miller Puckette
> saying that
> >> >> with
> >> >> his three year PC he could run six PVs so he was happy and
> did not want
> >> >> to bother with it.
> >> >>
> >> >> Regards
> >> >>
> >> >> Victor
> >> >>
> >> >> -----------------------------------------------------------
> -------------
> >> >>- This SF.Net email is sponsored by the Moblin Your Move
> Developer's>> >> challenge
> >> >> Build the coolest Linux based applications with Moblin SDK
> & win great
> >> >> prizes
> >> >> Grand prize is a trip for two to an Open Source event
> anywhere in the
> >> >> world
> >> >> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >> >> _______________________________________________
> >> >> Csound-devel mailing list
> >> >> Csound-devel@...
> >> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
> >> >
> >> > ------------------------------------------------------------
> -------------
> >> > This SF.Net email is sponsored by the Moblin Your Move
> Developer's>> > challenge
> >> > Build the coolest Linux based applications with Moblin SDK
> & win great
> >> > prizes
> >> > Grand prize is a trip for two to an Open Source event
> anywhere in the
> >> > world
> >> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >> > _______________________________________________
> >> > Csound-devel mailing list
> >> > Csound-devel@...
> >> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> >>
> >> --------------------------------------------------------------
> -----------
> >> This SF.Net email is sponsored by the Moblin Your Move Developer's
> >> challenge Build the coolest Linux based applications with
> Moblin SDK & win
> >> great prizes Grand prize is a trip for two to an Open Source event
> >> anywhere
> >> in the world http://moblin-
> contest.org/redirect.php?banner_id=100&url=/>>
> _______________________________________________>> Csound-devel
> mailing list
> >> Csound-devel@...
> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
> >
> >
> > Saludos,
> > Felipe Sateler
> >
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> -----------------------------------------------------------------
> -------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC.
> CaT
> is a gathering of tech-side developers & brand creativity
> professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity,
> Processing, &
> iPhoneDevCamp as they present alongside digital heavyweights
> like Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-
> com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini, Senior Lecturer, Dept. of Music,National University of Ireland, Maynooth

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: parallel processing panel at ICMC

by Michael Gogins-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

How does John's code differ from what Steven Yi has done?

Regards,
Mike

On 5/27/09, Victor.Lazzarini@... <Victor.Lazzarini@...> wrote:

> I think we should wait for John's parallel code, before trying todo anything
> else.Victor----- Original Message -----From: Michael Gogins
> <michael.gogins@...>Date: Wednesday, May 27, 2009 1:56 pmSubject: Re:
> [Cs-dev] parallel processing panel at ICMCTo: Developer discussions
> <csound-devel@...>> The current state of the art with
> OpenMP for audio processing > with GCC> and ICC can be gleaned from:> >
> http://lad.linuxaudio.org/events/2009_cdm/Friday/10_Orlarey/10.pdf> > Since
> Sun has supported OpenMP for a long time and is known> performance, I infer
> that Sun is on roughly the same level as ICC.> > In brutal summary, GCC
> isn't there yet, but ICC is, and I would bet> that Sun is The next release
> of GCC should be OK.> > So, we can't currently count on improving
> performance with > OpenMP on> GCC, but we have shown that we CAN do it with
> just GCC and pthreads.> We should keep going on this path until GCC actually
>> demonstrates some> oomph.> > Or, we should mandate ICC for Csound builds.
> But this will not > work on> Windows unless the free Microsoft compiler
> supports OpenMP (I don't> think it does, but I will check).> > Regards,>
> Mike> > > On 5/26/09, Felipe Sateler <fsateler@...> wrote:> > Sorry to
> resurrect an old thread, but I just came accross > OpenMP for other> >
> reasons and remembered this discussion.> > OpenMP seems very simple to use.
> However, I don't get the > "still use> > pthreads> > for threads" part.
> OpenMP has the nice feature that it keeps > count of how> > many> > threads
> are running (if I understood correctly), so the --num-> threads>
> implementation is reduced to setting the openmp max > number of threads,
> and> > you> > can then do loop parallelization, etc without worrying about >
> that. Mixing> > with> > pthreads looses this nice feature.> >> > El lunes 1
> de septiembre, victor escribió:> >> I was thinking of OpenMP for
> parallelising engine code rather > than to> >> substitute pthreads for
> everything (we'll keep pthreads for> >> threads...). OpenMP seemed to be
> quite useful.> >>> >> Victor> >> ----- Original Message -----> >> From:
> "Steven Yi" <stevenyi@...>> >> To: "Developer discussions"
> <csound-devel@...>> >> Sent: Monday, September 01, 2008
> 3:07 AM> >> Subject: Re: [Cs-dev] parallel processing panel at ICMC> >>> >>
>> Hi Victor,> >> >> >> > Thanks very much for the report!  It seems to me
> that > we would use> >> > OpenMP in the same way as the code we currently
> have in > that we use a> >> > barrier and split work.  We would still need
> to work > on a better work> >> > partitioning system, regardless of a change
> to OpenMP or not.> >> >> >> > I took a further look int OpenMP and it looks
> pretty nice. > However, it> >> > looks like gcc 4.x is only in alpha state
> for MinGW.  > If it works then> >> > that'd be great.> >> >> >> > As for
> replacing pthread, I wonder if that would be > appropriate for> >> > the
> threaded code we have that isn't related to > parallelizing code.> >> > On
> the other hand, I don't know if we can use pthreads in > conjunction>> >
> with OpenMP.> >> >> >> > So, what does everyone else think?  I am thinking
> our > current code is> >> > enough for now for running the parallel code,
> and we might > be better> >> > served to continue to look at places where we
> are running into> >> > problems.> >> >> >> > A step we can take would be to
> start systematically > creating a test> >> > suite of CSD's, much like what
> was done for the new parser > and the> >> > tests in the tests directory.
> Those tests for the new > parser took one> >> > step at a time and
> introduced a single new language feature > to test> >> > another feature of
> the processor.  We should probably > do something> >> > similar so that we
> can step by step test and then if we > find a> >> > problem, we'd have a
> good idea of what the problem was from > as we only> >> > add one feature at
> a time.> >> >> >> > Thoughts?> >> > steven> >> >> >> > On Sun, Aug 31, 2008
> at 3:33 PM, victor > <Victor.Lazzarini@...>>> > wrote:> >> >> Hello
> everyone,> >> >>> >> >> just a quick e-mail in relation to the panel at
> ICMC. John > was there> >> >> and> >> >> might add details to these.> >> >>>
>>> >> The overall tone was 'yes it is a good idea; we'll have to > do it,
> but> >> >> we> >> >> don't know how yet.'  I asked the question we wanted >
> to know:> >> >> who is doing it? They basically shrugged and said, "well >
> max has> >> >> the poly object...", and then someone said that SCSynth >
> could be> >> >> run several separate, but unconnected, processes, to what >
> I replied,> >> >> so can any other program...> >> >>> >> >> The only thing I
> found useful was to hear the FAUST guy > talk about> >> >> their
> multiprocessor output usimg openMP. They also have > experience>> >> with
> their parallel version of Jack.> >> >>> >> >> Has anyone looked at OpenMP.
> Looks dead easy to use, it > seems available> >> >> across the board for all
> support platforms (gcc 4.2). > Perhaps we can> >> >> use> >> >> that instead
> of pthreads?> >> >>> >> >> But overall, they all seemed clueless. The
> discussions in > this list> >> >> seemed> >> >> to be better informed. The
> added joke was Miller Puckette > saying that> >> >> with> >> >> his three
> year PC he could run six PVs so he was happy and > did not want> >> >> to
> bother with it.> >> >>> >> >> Regards> >> >>> >> >> Victor> >> >>> >> >>
> -----------------------------------------------------------> ------------->
>>> >>- This SF.Net email is sponsored by the Moblin Your Move >
> Developer's>> >> challenge> >> >> Build the coolest Linux based applications
> with Moblin SDK > & win great> >> >> prizes> >> >> Grand prize is a trip for
> two to an Open Source event > anywhere in the> >> >> world> >> >>
> http://moblin-contest.org/redirect.php?banner_id=100&url=/> >> >>
> _______________________________________________> >> >> Csound-devel mailing
> list> >> >> Csound-devel@...> >> >>
> https://lists.sourceforge.net/lists/listinfo/csound-devel> >> >> >> >
> ------------------------------------------------------------> ------------->
>>> > This SF.Net email is sponsored by the Moblin Your Move > Developer's>>
>> challenge> >> > Build the coolest Linux based applications with Moblin SDK
>> & win great> >> > prizes> >> > Grand prize is a trip for two to an Open
> Source event > anywhere in the> >> > world> >> >
> http://moblin-contest.org/redirect.php?banner_id=100&url=/> >> >
> _______________________________________________> >> > Csound-devel mailing
> list> >> > Csound-devel@...> >> >
> https://lists.sourceforge.net/lists/listinfo/csound-devel> >>> >>
> --------------------------------------------------------------> ----------->
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's> >>
> challenge Build the coolest Linux based applications with > Moblin SDK &
> win> >> great prizes Grand prize is a trip for two to an Open Source event>
>>> anywhere> >> in the world http://moblin->
> contest.org/redirect.php?banner_id=100&url=/>> >
> _______________________________________________>> Csound-devel > mailing
> list> >> Csound-devel@...> >>
> https://lists.sourceforge.net/lists/listinfo/csound-devel> >> >> >> >
> Saludos,> > Felipe Sateler> >> > > -- > Michael Gogins> Irreducible
> Productions> http://www.michael-gogins.com> Michael dot Gogins at gmail dot
> com> > ----------------------------------------------------------------->
> -------------> Register Now for Creativity and Technology (CaT), June 3rd,
> NYC. > CaT > is a gathering of tech-side developers & brand creativity >
> professionals. Meet> the minds behind Google Creative Lab, Visual
> Complexity, > Processing, & > iPhoneDevCamp as they present alongside
> digital heavyweights > like Barbarian > Group, R/GA, & Big Spaceship.
> http://p.sf.net/sfu/creativitycat-> com >
> _______________________________________________> Csound-devel mailing list>
> Csound-devel@...>
> https://lists.sourceforge.net/lists/listinfo/csound-develDr Victor
> Lazzarini, Senior Lecturer, Dept. of Music,National University of Ireland,
> Maynooth
>


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

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: parallel processing panel at ICMC

by Victor Lazzarini :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

He has a new automatic parallelisation scheme. You can ask for
details directly and/or check out the ParCS branch (might not
be usable yet, ask him).

Victor

----- Original Message -----
From: Michael Gogins <michael.gogins@...>
Date: Wednesday, May 27, 2009 3:28 pm
Subject: Re: [Cs-dev] parallel processing panel at ICMC
To: Developer discussions <csound-devel@...>

> How does John's code differ from what Steven Yi has done?
>
> Regards,
> Mike
>
> On 5/27/09, Victor.Lazzarini@...
> <Victor.Lazzarini@...> wrote:
> > I think we should wait for John's parallel code, before trying
> todo anything
> > else.Victor----- Original Message -----From: Michael Gogins
> > <michael.gogins@...>Date: Wednesday, May 27, 2009
> 1:56 pmSubject: Re:
> > [Cs-dev] parallel processing panel at ICMCTo: Developer discussions
> > <csound-devel@...>> The current state of
> the art with
> > OpenMP for audio processing > with GCC> and ICC can be gleaned
> from:> >
> >
> http://lad.linuxaudio.org/events/2009_cdm/Friday/10_Orlarey/10.pdf> > Since
> > Sun has supported OpenMP for a long time and is known>
> performance, I infer
> > that Sun is on roughly the same level as ICC.> > In brutal
> summary, GCC
> > isn't there yet, but ICC is, and I would bet> that Sun is The
> next release
> > of GCC should be OK.> > So, we can't currently count on improving
> > performance with > OpenMP on> GCC, but we have shown that we
> CAN do it with
> > just GCC and pthreads.> We should keep going on this path
> until GCC actually
> >> demonstrates some> oomph.> > Or, we should mandate ICC for
> Csound builds.
> > But this will not > work on> Windows unless the free Microsoft
> compiler> supports OpenMP (I don't> think it does, but I will
> check).> > Regards,>
> > Mike> > > On 5/26/09, Felipe Sateler <fsateler@...>
> wrote:> > Sorry to
> > resurrect an old thread, but I just came accross > OpenMP for
> other> >
> > reasons and remembered this discussion.> > OpenMP seems very
> simple to use.
> > However, I don't get the > "still use> > pthreads> > for
> threads" part.
> > OpenMP has the nice feature that it keeps > count of how> >
> many> > threads
> > are running (if I understood correctly), so the --num-> threads>
> > implementation is reduced to setting the openmp max > number
> of threads,
> > and> > you> > can then do loop parallelization, etc without
> worrying about >
> > that. Mixing> > with> > pthreads looses this nice feature.> >>
> > El lunes 1
> > de septiembre, victor escribió:> >> I was thinking of OpenMP for
> > parallelising engine code rather > than to> >> substitute
> pthreads for
> > everything (we'll keep pthreads for> >> threads...). OpenMP
> seemed to be
> > quite useful.> >>> >> Victor> >> ----- Original Message ----->
> >> From:
> > "Steven Yi" <stevenyi@...>> >> To: "Developer discussions"
> > <csound-devel@...>> >> Sent: Monday,
> September 01, 2008
> > 3:07 AM> >> Subject: Re: [Cs-dev] parallel processing panel at
> ICMC> >>> >>
> >> Hi Victor,> >> >> >> > Thanks very much for the report! 
> It seems to me
> > that > we would use> >> > OpenMP in the same way as the code
> we currently
> > have in > that we use a> >> > barrier and split work.  We
> would still need
> > to work > on a better work> >> > partitioning system,
> regardless of a change
> > to OpenMP or not.> >> >> >> > I took a further look int OpenMP
> and it looks
> > pretty nice. > However, it> >> > looks like gcc 4.x is only in
> alpha state
> > for MinGW.  > If it works then> >> > that'd be great.> >>
> >> >> > As for
> > replacing pthread, I wonder if that would be > appropriate
> for> >> > the
> > threaded code we have that isn't related to > parallelizing
> code.> >> > On
> > the other hand, I don't know if we can use pthreads in >
> conjunction>> >
> > with OpenMP.> >> >> >> > So, what does everyone else
> think?  I am thinking
> > our > current code is> >> > enough for now for running the
> parallel code,
> > and we might > be better> >> > served to continue to look at
> places where we
> > are running into> >> > problems.> >> >> >> > A step we can
> take would be to
> > start systematically > creating a test> >> > suite of CSD's,
> much like what
> > was done for the new parser > and the> >> > tests in the tests
> directory.> Those tests for the new > parser took one> >> > step
> at a time and
> > introduced a single new language feature > to test> >> >
> another feature of
> > the processor.  We should probably > do something> >> >
> similar so that we
> > can step by step test and then if we > find a> >> > problem,
> we'd have a
> > good idea of what the problem was from > as we only> >> > add
> one feature at
> > a time.> >> >> >> > Thoughts?> >> > steven> >> >> >> > On Sun,
> Aug 31, 2008
> > at 3:33 PM, victor > <Victor.Lazzarini@...>>> > wrote:>
> >> >> Hello
> > everyone,> >> >>> >> >> just a quick e-mail in relation to the
> panel at
> > ICMC. John > was there> >> >> and> >> >> might add details to
> these.> >> >>>
> >>> >> The overall tone was 'yes it is a good idea; we'll have
> to > do it,
> > but> >> >> we> >> >> don't know how yet.'  I asked the
> question we wanted >
> > to know:> >> >> who is doing it? They basically shrugged and
> said, "well >
> > max has> >> >> the poly object...", and then someone said that
> SCSynth >
> > could be> >> >> run several separate, but unconnected,
> processes, to what >
> > I replied,> >> >> so can any other program...> >> >>> >> >>
> The only thing I
> > found useful was to hear the FAUST guy > talk about> >> >> their
> > multiprocessor output usimg openMP. They also have >
> experience>> >> with
> > their parallel version of Jack.> >> >>> >> >> Has anyone
> looked at OpenMP.
> > Looks dead easy to use, it > seems available> >> >> across the
> board for all
> > support platforms (gcc 4.2). > Perhaps we can> >> >> use> >>
> >> that instead
> > of pthreads?> >> >>> >> >> But overall, they all seemed
> clueless. The
> > discussions in > this list> >> >> seemed> >> >> to be better
> informed. The
> > added joke was Miller Puckette > saying that> >> >> with> >>
> >> his three
> > year PC he could run six PVs so he was happy and > did not
> want> >> >> to
> > bother with it.> >> >>> >> >> Regards> >> >>> >> >> Victor> >>
> >>> >> >>
> > -----------------------------------------------------------> --
> ----------->
> >>> >>- This SF.Net email is sponsored by the Moblin Your Move >
> > Developer's>> >> challenge> >> >> Build the coolest Linux
> based applications
> > with Moblin SDK > & win great> >> >> prizes> >> >> Grand prize
> is a trip for
> > two to an Open Source event > anywhere in the> >> >> world> >> >>
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/> >> >>
> > _______________________________________________> >> >> Csound-
> devel mailing
> > list> >> >> Csound-devel@...> >> >>
> > https://lists.sourceforge.net/lists/listinfo/csound-devel> >>
> >> >> >
> > ------------------------------------------------------------> -
> ------------>
> >>> > This SF.Net email is sponsored by the Moblin Your Move >
> Developer's>>>> challenge> >> > Build the coolest Linux based
> applications with Moblin SDK
> >> & win great> >> > prizes> >> > Grand prize is a trip for two
> to an Open
> > Source event > anywhere in the> >> > world> >> >
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/> >> >
> > _______________________________________________> >> > Csound-
> devel mailing
> > list> >> > Csound-devel@...> >> >
> > https://lists.sourceforge.net/lists/listinfo/csound-devel> >>> >>
> > --------------------------------------------------------------
> > ----------->
> >>> This SF.Net email is sponsored by the Moblin Your Move
> Developer's> >>
> > challenge Build the coolest Linux based applications with >
> Moblin SDK &
> > win> >> great prizes Grand prize is a trip for two to an Open
> Source event>
> >>> anywhere> >> in the world http://moblin->
> > contest.org/redirect.php?banner_id=100&url=/>> >
> > _______________________________________________>> Csound-devel
> > mailing
> > list> >> Csound-devel@...> >>
> > https://lists.sourceforge.net/lists/listinfo/csound-devel> >>
> >> >> >
> > Saludos,> > Felipe Sateler> >> > > -- > Michael Gogins> Irreducible
> > Productions> http://www.michael-gogins.com> Michael dot Gogins
> at gmail dot
> > com> > --------------------------------------------------------
> --------->
> > -------------> Register Now for Creativity and Technology
> (CaT), June 3rd,
> > NYC. > CaT > is a gathering of tech-side developers & brand
> creativity >
> > professionals. Meet> the minds behind Google Creative Lab, Visual
> > Complexity, > Processing, & > iPhoneDevCamp as they present
> alongside> digital heavyweights > like Barbarian > Group, R/GA,
> & Big Spaceship.
> > http://p.sf.net/sfu/creativitycat-> com >
> > _______________________________________________> Csound-devel
> mailing list>
> > Csound-devel@...>
> > https://lists.sourceforge.net/lists/listinfo/csound-develDr Victor
> > Lazzarini, Senior Lecturer, Dept. of Music,National University
> of Ireland,
> > Maynooth
> >
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> -----------------------------------------------------------------
> -------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC.
> CaT
> is a gathering of tech-side developers & brand creativity
> professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity,
> Processing, &
> iPhoneDevCamp as they present alongside digital heavyweights
> like Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-
> com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini, Senior Lecturer, Dept. of Music,National University of Ireland, Maynooth

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: parallel processing panel at ICMC

by Michael Gogins-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Thanks, I'll look at the ParCS branch.

Regards,
Mike

On 5/27/09, Victor.Lazzarini@... <Victor.Lazzarini@...> wrote:

> He has a new automatic parallelisation scheme. You can ask for details
> directly and/or check out the ParCS branch (might notbe usable yet, ask
> him).Victor----- Original Message -----From: Michael Gogins
> <michael.gogins@...>Date: Wednesday, May 27, 2009 3:28 pmSubject: Re:
> [Cs-dev] parallel processing panel at ICMCTo: Developer discussions
> <csound-devel@...>> How does John's code differ from what
> Steven Yi has done?> > Regards,> Mike> > On 5/27/09,
> Victor.Lazzarini@... > <Victor.Lazzarini@...> wrote:> > I think we
> should wait for John's parallel code, before trying > todo anything> >
> else.Victor----- Original Message -----From: Michael Gogins> >
> <michael.gogins@...>Date: Wednesday, May 27, 2009 > 1:56 pmSubject:
> Re:> > [Cs-dev] parallel processing panel at ICMCTo: Developer discussions>
>> <csound-devel@...>> The current state of > the art with>
>> OpenMP for audio processing > with GCC> and ICC can be gleaned > from:> >>
>> > http://lad.linuxaudio.org/events/2009_cdm/Friday/10_Orlarey/10.pdf> >
> Since> > Sun has supported OpenMP for a long time and is known> >
> performance, I infer> > that Sun is on roughly the same level as ICC.> > In
> brutal > summary, GCC> > isn't there yet, but ICC is, and I would bet> that
> Sun is The > next release> > of GCC should be OK.> > So, we can't currently
> count on improving> > performance with > OpenMP on> GCC, but we have shown
> that we > CAN do it with> > just GCC and pthreads.> We should keep going on
> this path > until GCC actually> >> demonstrates some> oomph.> > Or, we
> should mandate ICC for > Csound builds.> > But this will not > work on>
> Windows unless the free Microsoft > compiler> supports OpenMP (I don't>
> think it does, but I will > check).> > Regards,>> > Mike> > > On 5/26/09,
> Felipe Sateler <fsateler@...> > wrote:> > Sorry to> > resurrect an old
> thread, but I just came accross > OpenMP for > other> >> > reasons and
> remembered this discussion.> > OpenMP seems very > simple to use.> >
> However, I don't get the > "still use> > pthreads> > for > threads" part.> >
> OpenMP has the nice feature that it keeps > count of how> > > many> >
> threads> > are running (if I understood correctly), so the --num-> threads>>
>> implementation is reduced to setting the openmp max > number > of
> threads,> > and> > you> > can then do loop parallelization, etc without >
> worrying about >> > that. Mixing> > with> > pthreads looses this nice
> feature.> >> > > El lunes 1> > de septiembre, victor escribió:> >> I was
> thinking of OpenMP for> > parallelising engine code rather > than to> >>
> substitute > pthreads for> > everything (we'll keep pthreads for> >>
> threads...). OpenMP > seemed to be> > quite useful.> >>> >> Victor> >> -----
> Original Message -----> > >> From:> > "Steven Yi" <stevenyi@...>> >>
> To: "Developer discussions"> > <csound-devel@...>> >>
> Sent: Monday, > September 01, 2008> > 3:07 AM> >> Subject: Re: [Cs-dev]
> parallel processing panel at > ICMC> >>> >>> >> Hi Victor,> >> >> >> >
> Thanks very much for the report!  > It seems to me> > that > we would use>
>>> > OpenMP in the same way as the code > we currently> > have in > that we
> use a> >> > barrier and split work.  We > would still need> > to work > on a
> better work> >> > partitioning system, > regardless of a change> > to OpenMP
> or not.> >> >> >> > I took a further look int OpenMP > and it looks> >
> pretty nice. > However, it> >> > looks like gcc 4.x is only in > alpha
> state> > for MinGW.  > If it works then> >> > that'd be great.> >> > >> >> >
> As for> > replacing pthread, I wonder if that would be > appropriate > for>
>>> > the> > threaded code we have that isn't related to > parallelizing >
> code.> >> > On> > the other hand, I don't know if we can use pthreads in > >
> conjunction>> >> > with OpenMP.> >> >> >> > So, what does everyone else >
> think?  I am thinking> > our > current code is> >> > enough for now for
> running the > parallel code,> > and we might > be better> >> > served to
> continue to look at > places where we> > are running into> >> > problems.>
>>> >> >> > A step we can > take would be to> > start systematically >
> creating a test> >> > suite of CSD's, > much like what> > was done for the
> new parser > and the> >> > tests in the tests > directory.> Those tests for
> the new > parser took one> >> > step > at a time and> > introduced a single
> new language feature > to test> >> > > another feature of> > the processor.
> We should probably > do something> >> > > similar so that we> > can step by
> step test and then if we > find a> >> > problem, > we'd have a> > good idea
> of what the problem was from > as we only> >> > add > one feature at> > a
> time.> >> >> >> > Thoughts?> >> > steven> >> >> >> > On Sun, > Aug 31, 2008>
>> at 3:33 PM, victor > <Victor.Lazzarini@...>>> > wrote:> > >> >> Hello>
>> everyone,> >> >>> >> >> just a quick e-mail in relation to the > panel at>
>> ICMC. John > was there> >> >> and> >> >> might add details to > these.> >>
>>>>> >>> >> The overall tone was 'yes it is a good idea; we'll have > to >
> do it,> > but> >> >> we> >> >> don't know how yet.'  I asked the > question
> we wanted >> > to know:> >> >> who is doing it? They basically shrugged and
>> said, "well >> > max has> >> >> the poly object...", and then someone said
> that > SCSynth >> > could be> >> >> run several separate, but unconnected, >
> processes, to what >> > I replied,> >> >> so can any other program...> >>
>>>> >> >> > The only thing I> > found useful was to hear the FAUST guy >
> talk about> >> >> their> > multiprocessor output usimg openMP. They also
> have > > experience>> >> with> > their parallel version of Jack.> >> >>> >>
>>> Has anyone > looked at OpenMP.> > Looks dead easy to use, it > seems
> available> >> >> across the > board for all> > support platforms (gcc 4.2).
>> Perhaps we can> >> >> use> >> > >> that instead> > of pthreads?> >> >>> >>
>>> But overall, they all seemed > clueless. The> > discussions in > this
> list> >> >> seemed> >> >> to be better > informed. The> > added joke was
> Miller Puckette > saying that> >> >> with> >> > >> his three> > year PC he
> could run six PVs so he was happy and > did not > want> >> >> to> > bother
> with it.> >> >>> >> >> Regards> >> >>> >> >> Victor> >> > >>> >> >>> >
> -----------------------------------------------------------> -->
> ----------->> >>> >>- This SF.Net email is sponsored by the Moblin Your Move
>>> > Developer's>> >> challenge> >> >> Build the coolest Linux > based
> applications> > with Moblin SDK > & win great> >> >> prizes> >> >> Grand
> prize > is a trip for> > two to an Open Source event > anywhere in the> >>
>>> world> >> >>> >
> http://moblin-contest.org/redirect.php?banner_id=100&url=/> >> >>> >
> _______________________________________________> >> >> Csound-> devel
> mailing> > list> >> >> Csound-devel@...> >> >>> >
> https://lists.sourceforge.net/lists/listinfo/csound-devel> >> > >> >> >> >
> ------------------------------------------------------------> ->
> ------------>> >>> > This SF.Net email is sponsored by the Moblin Your Move
>> > Developer's>>>> challenge> >> > Build the coolest Linux based >
> applications with Moblin SDK> >> & win great> >> > prizes> >> > Grand prize
> is a trip for two > to an Open> > Source event > anywhere in the> >> >
> world> >> >> > http://moblin-contest.org/redirect.php?banner_id=100&url=/>
>>> >> > _______________________________________________> >> > Csound-> devel
> mailing> > list> >> > Csound-devel@...> >> >> >
> https://lists.sourceforge.net/lists/listinfo/csound-devel> >>> >>> >
> --------------------------------------------------------------> >
> ----------->> >>> This SF.Net email is sponsored by the Moblin Your Move >
> Developer's> >>> > challenge Build the coolest Linux based applications with
>> > Moblin SDK &> > win> >> great prizes Grand prize is a trip for two to an
> Open > Source event>> >>> anywhere> >> in the world http://moblin->> >
> contest.org/redirect.php?banner_id=100&url=/>> >> >
> _______________________________________________>> Csound-devel > > mailing>
>> list> >> Csound-devel@...> >>> >
> https://lists.sourceforge.net/lists/listinfo/csound-devel> >> > >> >> >> >
> Saludos,> > Felipe Sateler> >> > > -- > Michael Gogins> Irreducible> >
> Productions> http://www.michael-gogins.com> Michael dot Gogins > at gmail
> dot> > com> > -------------------------------------------------------->
> --------->> > -------------> Register Now for Creativity and Technology >
> (CaT), June 3rd,> > NYC. > CaT > is a gathering of tech-side developers &
> brand > creativity >> > professionals. Meet> the minds behind Google
> Creative Lab, Visual> > Complexity, > Processing, & > iPhoneDevCamp as they
> present > alongside> digital heavyweights > like Barbarian > Group, R/GA, >
> & Big Spaceship.> > http://p.sf.net/sfu/creativitycat-> com >> >
> _______________________________________________> Csound-devel > mailing
> list>> > Csound-devel@...>> >
> https://lists.sourceforge.net/lists/listinfo/csound-develDr Victor> >
> Lazzarini, Senior Lecturer, Dept. of Music,National University > of
> Ireland,> > Maynooth> >> > > -- > Michael Gogins> Irreducible Productions>
> http://www.michael-gogins.com> Michael dot Gogins at gmail dot com> >
> ----------------------------------------------------------------->
> -------------> Register Now for Creativity and Technology (CaT), June 3rd,
> NYC. > CaT > is a gathering of tech-side developers & brand creativity >
> professionals. Meet> the minds behind Google Creative Lab, Visual
> Complexity, > Processing, & > iPhoneDevCamp as they present alongside
> digital heavyweights > like Barbarian > Group, R/GA, & Big Spaceship.
> http://p.sf.net/sfu/creativitycat-> com >
> _______________________________________________> Csound-devel mailing list>
> Csound-devel@...>
> https://lists.sourceforge.net/lists/listinfo/csound-develDr Victor
> Lazzarini, Senior Lecturer, Dept. of Music,National University of Ireland,
> Maynooth
>


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

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: parallel processing panel at ICMC

by Felipe Sateler :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hmm, thanks for pointing to this paper. What is intriguing is that gcc with
vectorization gets worse performance than scalar processing in a number of
cases.

El miércoles 27 de mayo, Michael Gogins escribió:

> The current state of the art with OpenMP for audio processing with GCC
> and ICC can be gleaned from:
>
> http://lad.linuxaudio.org/events/2009_cdm/Friday/10_Orlarey/10.pdf
>
> Since Sun has supported OpenMP for a long time and is known
> performance, I infer that Sun is on roughly the same level as ICC.
>
> In brutal summary, GCC isn't there yet, but ICC is, and I would bet
> that Sun is The next release of GCC should be OK.
>
> So, we can't currently count on improving performance with OpenMP on
> GCC, but we have shown that we CAN do it with just GCC and pthreads.
> We should keep going on this path until GCC actually demonstrates some
> oomph.
>
> Or, we should mandate ICC for Csound builds. But this will not work on
> Windows unless the free Microsoft compiler supports OpenMP (I don't
> think it does, but I will check).
>
> Regards,
> Mike
>
> On 5/26/09, Felipe Sateler <fsateler@...> wrote:
> > Sorry to resurrect an old thread, but I just came accross OpenMP for
> > other reasons and remembered this discussion.
> > OpenMP seems very simple to use. However, I don't get the "still use
> > pthreads
> > for threads" part. OpenMP has the nice feature that it keeps count of how
> > many
> > threads are running (if I understood correctly), so the --num-threads
> > implementation is reduced to setting the openmp max number of threads,
> > and you
> > can then do loop parallelization, etc without worrying about that. Mixing
> > with
> > pthreads looses this nice feature.
> >
> > El lunes 1 de septiembre, victor escribió:
> >> I was thinking of OpenMP for parallelising engine code rather than to
> >> substitute pthreads for everything (we'll keep pthreads for
> >> threads...). OpenMP seemed to be quite useful.
> >>
> >> Victor
> >> ----- Original Message -----
> >> From: "Steven Yi" <stevenyi@...>
> >> To: "Developer discussions" <csound-devel@...>
> >> Sent: Monday, September 01, 2008 3:07 AM
> >> Subject: Re: [Cs-dev] parallel processing panel at ICMC
> >>
> >> > Hi Victor,
> >> >
> >> > Thanks very much for the report!  It seems to me that we would use
> >> > OpenMP in the same way as the code we currently have in that we use a
> >> > barrier and split work.  We would still need to work on a better work
> >> > partitioning system, regardless of a change to OpenMP or not.
> >> >
> >> > I took a further look int OpenMP and it looks pretty nice. However, it
> >> > looks like gcc 4.x is only in alpha state for MinGW.  If it works then
> >> > that'd be great.
> >> >
> >> > As for replacing pthread, I wonder if that would be appropriate for
> >> > the threaded code we have that isn't related to parallelizing code.
> >> > On the other hand, I don't know if we can use pthreads in conjunction
> >> > with OpenMP.
> >> >
> >> > So, what does everyone else think?  I am thinking our current code is
> >> > enough for now for running the parallel code, and we might be better
> >> > served to continue to look at places where we are running into
> >> > problems.
> >> >
> >> > A step we can take would be to start systematically creating a test
> >> > suite of CSD's, much like what was done for the new parser and the
> >> > tests in the tests directory.  Those tests for the new parser took one
> >> > step at a time and introduced a single new language feature to test
> >> > another feature of the processor.  We should probably do something
> >> > similar so that we can step by step test and then if we find a
> >> > problem, we'd have a good idea of what the problem was from as we only
> >> > add one feature at a time.
> >> >
> >> > Thoughts?
> >> > steven
> >> >
> >> > On Sun, Aug 31, 2008 at 3:33 PM, victor <Victor.Lazzarini@...>
> >> >
> >> > wrote:
> >> >> Hello everyone,
> >> >>
> >> >> just a quick e-mail in relation to the panel at ICMC. John was there
> >> >> and
> >> >> might add details to these.
> >> >>
> >> >> The overall tone was 'yes it is a good idea; we'll have to do it, but
> >> >> we
> >> >> don't know how yet.'  I asked the question we wanted to know:
> >> >> who is doing it? They basically shrugged and said, "well max has
> >> >> the poly object...", and then someone said that SCSynth could be
> >> >> run several separate, but unconnected, processes, to what I replied,
> >> >> so can any other program...
> >> >>
> >> >> The only thing I found useful was to hear the FAUST guy talk about
> >> >> their multiprocessor output usimg openMP. They also have experience
> >> >> with their parallel version of Jack.
> >> >>
> >> >> Has anyone looked at OpenMP. Looks dead easy to use, it seems
> >> >> available across the board for all support platforms (gcc 4.2).
> >> >> Perhaps we can use
> >> >> that instead of pthreads?
> >> >>
> >> >> But overall, they all seemed clueless. The discussions in this list
> >> >> seemed
> >> >> to be better informed. The added joke was Miller Puckette saying that
> >> >> with
> >> >> his three year PC he could run six PVs so he was happy and did not
> >> >> want to bother with it.
> >> >>
> >> >> Regards
> >> >>
> >> >> Victor
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >>--- - This SF.Net email is sponsored by the Moblin Your Move
> >> >> Developer's challenge
> >> >> Build the coolest Linux based applications with Moblin SDK & win
> >> >> great prizes
> >> >> Grand prize is a trip for two to an Open Source event anywhere in the
> >> >> world
> >> >> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >> >> _______________________________________________
> >> >> Csound-devel mailing list
> >> >> Csound-devel@...
> >> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
> >> >
> >> > ----------------------------------------------------------------------
> >> >--- This SF.Net email is sponsored by the Moblin Your Move Developer's
> >> > challenge
> >> > Build the coolest Linux based applications with Moblin SDK & win great
> >> > prizes
> >> > Grand prize is a trip for two to an Open Source event anywhere in the
> >> > world
> >> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >> > _______________________________________________
> >> > Csound-devel mailing list
> >> > Csound-devel@...
> >> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> >>
> >> ------------------------------------------------------------------------
> >>- This SF.Net email is sponsored by the Moblin Your Move Developer's
> >> challenge Build the coolest Linux based applications with Moblin SDK &
> >> win great prizes Grand prize is a trip for two to an Open Source event
> >> anywhere
> >> in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >> _______________________________________________
> >> Csound-devel mailing list
> >> Csound-devel@...
> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
> > Saludos,
> > Felipe Sateler


Saludos,
Felipe Sateler


------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

signature.asc (852 bytes) Download Attachment
< Prev | 1 - 2 | Next >