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" 
To: "Developer discussions" 
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  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@lists.sourceforge.net
>> 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@lists.sourceforge.net
> 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@lists.sourceforge.net

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" 
To: "Developer discussions" 
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@lists.sourceforge.net
> 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@lists.sourceforge.net

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 :
> 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" 
> To: "Developer discussions" 
> 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@lists.sourceforge.net
>> 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@lists.sourceforge.net
> 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@lists.sourceforge.net

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  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" 
>> To: "Developer discussions" 
>> 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 
>> > 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@lists.sourceforge.net
>> >> 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@lists.sourceforge.net
>> > 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@lists.sourceforge.net
>> 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@lists.sourceforge.net

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

Regards,
Mike

On 5/27/09, Victor.Lazzarini@nuim.ie  wrote:
> I think we should wait for John's parallel code, before trying todo anything
> else.Victor----- Original Message -----From: Michael Gogins
> Date: Wednesday, May 27, 2009 1:56 pmSubject: Re:
> [Cs-dev] parallel processing panel at ICMCTo: Developer discussions
> > 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  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" > >> To: "Developer discussions"
> > >> 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 > >> > 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@lists.sourceforge.net> >> >>
> 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@lists.sourceforge.net> >> >
> 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@lists.sourceforge.net> >>
> 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@lists.sourceforge.net>
> 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@lists.sourceforge.net

Thanks, I'll look at the ParCS branch.

Regards,
Mike

On 5/27/09, Victor.Lazzarini@nuim.ie  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
> Date: Wednesday, May 27, 2009 3:28 pmSubject: Re:
> [Cs-dev] parallel processing panel at ICMCTo: Developer discussions
> > How does John's code differ from what
> Steven Yi has done?> > Regards,> Mike> > On 5/27/09,
> Victor.Lazzarini@nuim.ie >  wrote:> > I think we
> should wait for John's parallel code, before trying > todo anything> >
> else.Victor----- Original Message -----From: Michael Gogins> >
> Date: Wednesday, May 27, 2009 > 1:56 pmSubject:
> Re:> > [Cs-dev] parallel processing panel at ICMCTo: Developer discussions>
>> > 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  > 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" > >>
> To: "Developer discussions"> > > >>
> 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 > >> > 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@lists.sourceforge.net> >> >>> >
> 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@lists.sourceforge.net> >> >> >
> 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@lists.sourceforge.net> >>> >
> 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@lists.sourceforge.net>> >
> 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@lists.sourceforge.net>
> 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@lists.sourceforge.net

I was there and saw the presentation, which was very interesting. The guys 
at
GRAME are the ones to ask if we have questions about these matters, because
they seem to have good experience with these things.

However, I'll say this in relation to the parallelism they were 
implementing.
I think it was too fine-grained. It would be the equivalent to doing it at
the opcode level or even sometimes at the processing loop level.

Victor


----- Original Message ----- 
From: "Felipe Sateler" 
To: "Developer discussions" 
Sent: Thursday, May 28, 2009 5:22 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@lists.sourceforge.net
> 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@lists.sourceforge.net

I would only assume that the Faust level of parallelization is too
fine-grained if experiments demonstrated that coarser grained
parallelization of the same algorithms run faster.

At this point, I myself have no idea what is really the optimal level
of graining for Csound, except that Intel's Threading Building Blocks
documentation says a task should have "tens of thousands of machine
instructions." I am guessing that is a small-size Csound instrument,
or a large Csound opcode, at 15-20 ksmps (optimal in my experience for
real-time performance) or so. Keep in mind, doing
multiply-accumulate-add in a non-unrolled loop for a stereo sample
frame of 20 ksmps  (e.g. the outs opcode) should be, in itself, around
100 machine instructions.

Does John ffitch's "costing" document provide better estimates of granularity?

However, it may well be that the level of granularity best for OpenMP
is smaller than the level of granularity best for TBB. Certainly, the
OpenMP pragmas are designed for the loop level of granularity. Of
course such OpenMP loops could be inner loops, or they could be outer
loops.

At any rate, using OpenMP with Csound currently appears to be
meaningful at this time only with the Intel C Compiler on Linux. It
would be interesting to apply OpenMP pragmas to various loops in
Csound.

Preliminary tests could be performed by taking some STK style
instruments and writing plugin opcodes from them with and without
OpenMP parallelization, then making heavy use of these opcodes in a
test csd.

Or by simply using Faust to generate such opcodes.

In fact, rather than parallelize all existing opcodes in Csound, we
might select a number of widely used opcodes (enough to rewrite some
popular instrument definitions) and write new versions of them  (par-
or p- opcodes) using Faust and OpenMP.

We might also want to parallelize the kperf loop as we already have
done, but with thread safety in those parts of the Csound API that are
used by opcodes.

But really, these two roads to parallelizing Csound are logically
independent. We could do one, or the other, or both. The advantage of
parallelizing opcodes is that it requires no changes to the Csound
"engine." The avantage of parallelizing kperf is that it provides
across-the-board performance gains that we already know are quite
real.

Doing both would, of course, put Csound at the head of the class,
performance-wise.

My next computer will certainly be a high-performance Linux or maybe
Apple machine with at least 4 cores.

Regards,
Mike

On 5/28/09, victor  wrote:
> I was there and saw the presentation, which was very interesting. The guys
> at
> GRAME are the ones to ask if we have questions about these matters, because
> they seem to have good experience with these things.
>
> However, I'll say this in relation to the parallelism they were
> implementing.
> I think it was too fine-grained. It would be the equivalent to doing it at
> the opcode level or even sometimes at the processing loop level.
>
> Victor
>
>
> ----- Original Message -----
> From: "Felipe Sateler" 
> To: "Developer discussions" 
> Sent: Thursday, May 28, 2009 5:22 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@lists.sourceforge.net
>> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


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

------------------------------------------------------------------------------
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@lists.sourceforge.net

Not really, some of their results demonstrated that even some
typically parallel algorithms were slower in parallel than single-thread
implementations, which I can only attribute to grain size.

Victor
----- Original Message ----- 
From: "Michael Gogins" 
To: "Developer discussions" 
Sent: Thursday, May 28, 2009 1:40 PM
Subject: Re: [Cs-dev] parallel processing panel at ICMC


>I would only assume that the Faust level of parallelization is too
> fine-grained if experiments demonstrated that coarser grained
> parallelization of the same algorithms run faster.


------------------------------------------------------------------------------
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@lists.sourceforge.net

Point taken.

BTW, it now seems that Intel Threading Building Blocks (TBB) is
supported to some extent on MinGW, so it can be considered available
for Csound, at least on Windows and Linux. So TBB would be appropriate
for parallelizing the kperf loop, and for supplying thread-safe
collections and function locks.

TBB can do function locks both with pthreads and with spinlocks.

Regards,
Mike

On 5/28/09, victor  wrote:
> Not really, some of their results demonstrated that even some
> typically parallel algorithms were slower in parallel than single-thread
> implementations, which I can only attribute to grain size.
>
> Victor
> ----- Original Message -----
> From: "Michael Gogins" 
> To: "Developer discussions" 
> Sent: Thursday, May 28, 2009 1:40 PM
> Subject: Re: [Cs-dev] parallel processing panel at ICMC
>
>
>>I would only assume that the Faust level of parallelization is too
>> fine-grained if experiments demonstrated that coarser grained
>> parallelization of the same algorithms run faster.
>
>
> ------------------------------------------------------------------------------
> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


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

------------------------------------------------------------------------------
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@lists.sourceforge.net

Is it better than OpenMP or a pthread approach?
----- Original Message ----- 
From: "Michael Gogins" 
To: "Developer discussions" 
Sent: Thursday, May 28, 2009 3:55 PM
Subject: Re: [Cs-dev] parallel processing panel at ICMC


> Point taken.
>
> BTW, it now seems that Intel Threading Building Blocks (TBB) is
> supported to some extent on MinGW, so it can be considered available
> for Csound, at least on Windows and Linux. So TBB would be appropriate
> for parallelizing the kperf loop, and for supplying thread-safe
> collections and function locks.
>
> TBB can do function locks both with pthreads and with spinlocks.
>
> Regards,
> Mike
>
> On 5/28/09, victor  wrote:
>> Not really, some of their results demonstrated that even some
>> typically parallel algorithms were slower in parallel than single-thread
>> implementations, which I can only attribute to grain size.
>>
>> Victor
>> ----- Original Message -----
>> From: "Michael Gogins" 
>> To: "Developer discussions" 
>> Sent: Thursday, May 28, 2009 1:40 PM
>> Subject: Re: [Cs-dev] parallel processing panel at ICMC
>>
>>
>>>I would only assume that the Faust level of parallelization is too
>>> fine-grained if experiments demonstrated that coarser grained
>>> parallelization of the same algorithms run faster.
>>
>>
>> ------------------------------------------------------------------------------
>> 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@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> 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@lists.sourceforge.net
> 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@lists.sourceforge.net

It is different, not better. In theory, I would prefer OpenMP because
it becomes part of the language, part of the compiler, and the loop
pragmas can of course be used for higher level loops as well as for
inner loops.

However, TBB offers thread-safe collections and global synchronization
primitives and functions. I feel that this stuff is very valuable. It
is hard to get right if you have to do it yourself. So in practice, I
might end up preferring TBB. But I do not have experience with both so
cannot yet say.

Regarding pthreads, TBB uses and wraps pthreads or Windows threads.

Regards,
Mike

On 5/28/09, victor  wrote:
> Is it better than OpenMP or a pthread approach?
> ----- Original Message -----
> From: "Michael Gogins" 
> To: "Developer discussions" 
> Sent: Thursday, May 28, 2009 3:55 PM
> Subject: Re: [Cs-dev] parallel processing panel at ICMC
>
>
>> Point taken.
>>
>> BTW, it now seems that Intel Threading Building Blocks (TBB) is
>> supported to some extent on MinGW, so it can be considered available
>> for Csound, at least on Windows and Linux. So TBB would be appropriate
>> for parallelizing the kperf loop, and for supplying thread-safe
>> collections and function locks.
>>
>> TBB can do function locks both with pthreads and with spinlocks.
>>
>> Regards,
>> Mike
>>
>> On 5/28/09, victor  wrote:
>>> Not really, some of their results demonstrated that even some
>>> typically parallel algorithms were slower in parallel than single-thread
>>> implementations, which I can only attribute to grain size.
>>>
>>> Victor
>>> ----- Original Message -----
>>> From: "Michael Gogins" 
>>> To: "Developer discussions" 
>>> Sent: Thursday, May 28, 2009 1:40 PM
>>> Subject: Re: [Cs-dev] parallel processing panel at ICMC
>>>
>>>
>>>>I would only assume that the Faust level of parallelization is too
>>>> fine-grained if experiments demonstrated that coarser grained
>>>> parallelization of the same algorithms run faster.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> 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@lists.sourceforge.net
>> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


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

------------------------------------------------------------------------------
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@lists.sourceforge.net

I should add, the main difference between OpenMP and TBB is that
OpenMP tries to sneak itself into the C++ language, but TBB assumes
you are writing in standard C++ and that you will parallelize your
work by writing classes that encapsulate logically independent tasks
and the data they require.

Quite frankly, in my considered judgment the best way to get Csound up
to speed (literally) is to rewrite it in C++, use the TBB collections
for tables and lists, parallelize the kperf loop and perhaps some
selected opcodes (oscillator banks etc.), and put spinlocks on all the
API calls that opcodes use. We would then be done and light years
ahead of other synthesizers -- especially on 4 or more cores. I
estimate this is a few man-months of work.

As I have suggested in the past, rewriting Csound in C++ is not so
hard; we would turn the CSOUND struct into a class and the existing
low-level API calls and "engine" functions that take a CSOUND pointer
into member functions of this class, then replace existing arrays and
lists with TBB collections.

Later, once OpenMP is supported by all compilers, it would make sense
to use OpenMP to parallelize important opcodes.

People ended up mostly following my advice on the Csound API... though
it took long enough.

Please, listen to what I am saying. I don't like to toot my own horn,
but I also hate to see wasted effort. This advice is pure gold.

It would work, it would make Csound parallel, it would not be too much
work, and it would have a side effect of making Csound actually
simpler and easier to maintain.

I don't know if my advice would work with the parser code, or with
John ffitch's prototype for parallelizing Csound.

Regards,
Mike


On 5/28/09, Michael Gogins  wrote:
> It is different, not better. In theory, I would prefer OpenMP because
> it becomes part of the language, part of the compiler, and the loop
> pragmas can of course be used for higher level loops as well as for
> inner loops.
>
> However, TBB offers thread-safe collections and global synchronization
> primitives and functions. I feel that this stuff is very valuable. It
> is hard to get right if you have to do it yourself. So in practice, I
> might end up preferring TBB. But I do not have experience with both so
> cannot yet say.
>
> Regarding pthreads, TBB uses and wraps pthreads or Windows threads.
>
> Regards,
> Mike
>
> On 5/28/09, victor  wrote:
>> Is it better than OpenMP or a pthread approach?
>> ----- Original Message -----
>> From: "Michael Gogins" 
>> To: "Developer discussions" 
>> Sent: Thursday, May 28, 2009 3:55 PM
>> Subject: Re: [Cs-dev] parallel processing panel at ICMC
>>
>>
>>> Point taken.
>>>
>>> BTW, it now seems that Intel Threading Building Blocks (TBB) is
>>> supported to some extent on MinGW, so it can be considered available
>>> for Csound, at least on Windows and Linux. So TBB would be appropriate
>>> for parallelizing the kperf loop, and for supplying thread-safe
>>> collections and function locks.
>>>
>>> TBB can do function locks both with pthreads and with spinlocks.
>>>
>>> Regards,
>>> Mike
>>>
>>> On 5/28/09, victor  wrote:
>>>> Not really, some of their results demonstrated that even some
>>>> typically parallel algorithms were slower in parallel than
>>>> single-thread
>>>> implementations, which I can only attribute to grain size.
>>>>
>>>> Victor
>>>> ----- Original Message -----
>>>> From: "Michael Gogins" 
>>>> To: "Developer discussions" 
>>>> Sent: Thursday, May 28, 2009 1:40 PM
>>>> Subject: Re: [Cs-dev] parallel processing panel at ICMC
>>>>
>>>>
>>>>>I would only assume that the Faust level of parallelization is too
>>>>> fine-grained if experiments demonstrated that coarser grained
>>>>> parallelization of the same algorithms run faster.
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> 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@lists.sourceforge.net
>>> 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@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>


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

------------------------------------------------------------------------------
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@lists.sourceforge.net

...
> Or by simply using Faust to generate such opcodes.

Does Faust have a "csound plugin" output? That would be wonderful and a
great reason for me to learn faust. :)

-- 
/Jonatan         [ http://kymatica.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@lists.sourceforge.net

It does, for float csound.

Regards,
Mike

On 5/28/09, Jonatan Liljedahl  wrote:
> ...
>> Or by simply using Faust to generate such opcodes.
>
> Does Faust have a "csound plugin" output? That would be wonderful and a
> great reason for me to learn faust. :)
>
> --
> /Jonatan         [ http://kymatica.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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


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

------------------------------------------------------------------------------
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@lists.sourceforge.net

I am not in favour of moving the code to C++.

Victor
----- Original Message ----- 
From: "Michael Gogins" 
To: "Developer discussions" 
Sent: Thursday, May 28, 2009 4:22 PM
Subject: Re: [Cs-dev] parallel processing panel at ICMC


>I should add, the main difference between OpenMP and TBB is that
> OpenMP tries to sneak itself into the C++ language, but TBB assumes
> you are writing in standard C++ and that you will parallelize your
> work by writing classes that encapsulate logically independent tasks
> and the data they require.
>
> Quite frankly, in my considered judgment the best way to get Csound up
> to speed (literally) is to rewrite it in C++, use the TBB collections
> for tables and lists, parallelize the kperf loop and perhaps some
> selected opcodes (oscillator banks etc.), and put spinlocks on all the
> API calls that opcodes use. We would then be done and light years
> ahead of other synthesizers -- especially on 4 or more cores. I
> estimate this is a few man-months of work.
>
> As I have suggested in the past, rewriting Csound in C++ is not so
> hard; we would turn the CSOUND struct into a class and the existing
> low-level API calls and "engine" functions that take a CSOUND pointer
> into member functions of this class, then replace existing arrays and
> lists with TBB collections.
>
> Later, once OpenMP is supported by all compilers, it would make sense
> to use OpenMP to parallelize important opcodes.
>
> People ended up mostly following my advice on the Csound API... though
> it took long enough.
>
> Please, listen to what I am saying. I don't like to toot my own horn,
> but I also hate to see wasted effort. This advice is pure gold.
>
> It would work, it would make Csound parallel, it would not be too much
> work, and it would have a side effect of making Csound actually
> simpler and easier to maintain.
>
> I don't know if my advice would work with the parser code, or with
> John ffitch's prototype for parallelizing Csound.
>
> Regards,
> Mike
>
>
> On 5/28/09, Michael Gogins  wrote:
>> It is different, not better. In theory, I would prefer OpenMP because
>> it becomes part of the language, part of the compiler, and the loop
>> pragmas can of course be used for higher level loops as well as for
>> inner loops.
>>
>> However, TBB offers thread-safe collections and global synchronization
>> primitives and functions. I feel that this stuff is very valuable. It
>> is hard to get right if you have to do it yourself. So in practice, I
>> might end up preferring TBB. But I do not have experience with both so
>> cannot yet say.
>>
>> Regarding pthreads, TBB uses and wraps pthreads or Windows threads.
>>
>> Regards,
>> Mike
>>
>> On 5/28/09, victor  wrote:
>>> Is it better than OpenMP or a pthread approach?
>>> ----- Original Message -----
>>> From: "Michael Gogins" 
>>> To: "Developer discussions" 
>>> Sent: Thursday, May 28, 2009 3:55 PM
>>> Subject: Re: [Cs-dev] parallel processing panel at ICMC
>>>
>>>
>>>> Point taken.
>>>>
>>>> BTW, it now seems that Intel Threading Building Blocks (TBB) is
>>>> supported to some extent on MinGW, so it can be considered available
>>>> for Csound, at least on Windows and Linux. So TBB would be appropriate
>>>> for parallelizing the kperf loop, and for supplying thread-safe
>>>> collections and function locks.
>>>>
>>>> TBB can do function locks both with pthreads and with spinlocks.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> On 5/28/09, victor  wrote:
>>>>> Not really, some of their results demonstrated that even some
>>>>> typically parallel algorithms were slower in parallel than
>>>>> single-thread
>>>>> implementations, which I can only attribute to grain size.
>>>>>
>>>>> Victor
>>>>> ----- Original Message -----
>>>>> From: "Michael Gogins" 
>>>>> To: "Developer discussions" 
>>>>> Sent: Thursday, May 28, 2009 1:40 PM
>>>>> Subject: Re: [Cs-dev] parallel processing panel at ICMC
>>>>>
>>>>>
>>>>>>I would only assume that the Faust level of parallelization is too
>>>>>> fine-grained if experiments demonstrated that coarser grained
>>>>>> parallelization of the same algorithms run faster.
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> 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@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>
>>>>
>>>> --
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://www.michael-gogins.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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@lists.sourceforge.net
>>>> 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@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>
>
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> 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@lists.sourceforge.net
> 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@lists.sourceforge.net

yes, it's currently experimental and in CVS.
----- Original Message ----- 
From: "Jonatan Liljedahl" 
To: "Developer discussions" 
Sent: Thursday, May 28, 2009 4:28 PM
Subject: [Cs-dev] Faust and csound


> ...
>> Or by simply using Faust to generate such opcodes.
>
> Does Faust have a "csound plugin" output? That would be wonderful and a
> great reason for me to learn faust. :)
>
> -- 
> /Jonatan         [ http://kymatica.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@lists.sourceforge.net
> 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@lists.sourceforge.net

Why not? I do not advocate porting all of Csound to C++, certainly not
the working opcodes. I am talking about the "engine."

At any rate, even if we choose not to port the "engine" to C++, it
would still be possible to compile it with the C++ compiler, and use
the TBB where that makes sense.

Regards,
Mike

On 5/28/09, victor  wrote:
> I am not in favour of moving the code to C++.
>
> Victor
> ----- Original Message -----
> From: "Michael Gogins" 
> To: "Developer discussions" 
> Sent: Thursday, May 28, 2009 4:22 PM
> Subject: Re: [Cs-dev] parallel processing panel at ICMC
>
>
>>I should add, the main difference between OpenMP and TBB is that
>> OpenMP tries to sneak itself into the C++ language, but TBB assumes
>> you are writing in standard C++ and that you will parallelize your
>> work by writing classes that encapsulate logically independent tasks
>> and the data they require.
>>
>> Quite frankly, in my considered judgment the best way to get Csound up
>> to speed (literally) is to rewrite it in C++, use the TBB collections
>> for tables and lists, parallelize the kperf loop and perhaps some
>> selected opcodes (oscillator banks etc.), and put spinlocks on all the
>> API calls that opcodes use. We would then be done and light years
>> ahead of other synthesizers -- especially on 4 or more cores. I
>> estimate this is a few man-months of work.
>>
>> As I have suggested in the past, rewriting Csound in C++ is not so
>> hard; we would turn the CSOUND struct into a class and the existing
>> low-level API calls and "engine" functions that take a CSOUND pointer
>> into member functions of this class, then replace existing arrays and
>> lists with TBB collections.
>>
>> Later, once OpenMP is supported by all compilers, it would make sense
>> to use OpenMP to parallelize important opcodes.
>>
>> People ended up mostly following my advice on the Csound API... though
>> it took long enough.
>>
>> Please, listen to what I am saying. I don't like to toot my own horn,
>> but I also hate to see wasted effort. This advice is pure gold.
>>
>> It would work, it would make Csound parallel, it would not be too much
>> work, and it would have a side effect of making Csound actually
>> simpler and easier to maintain.
>>
>> I don't know if my advice would work with the parser code, or with
>> John ffitch's prototype for parallelizing Csound.
>>
>> Regards,
>> Mike
>>
>>
>> On 5/28/09, Michael Gogins  wrote:
>>> It is different, not better. In theory, I would prefer OpenMP because
>>> it becomes part of the language, part of the compiler, and the loop
>>> pragmas can of course be used for higher level loops as well as for
>>> inner loops.
>>>
>>> However, TBB offers thread-safe collections and global synchronization
>>> primitives and functions. I feel that this stuff is very valuable. It
>>> is hard to get right if you have to do it yourself. So in practice, I
>>> might end up preferring TBB. But I do not have experience with both so
>>> cannot yet say.
>>>
>>> Regarding pthreads, TBB uses and wraps pthreads or Windows threads.
>>>
>>> Regards,
>>> Mike
>>>
>>> On 5/28/09, victor  wrote:
>>>> Is it better than OpenMP or a pthread approach?
>>>> ----- Original Message -----
>>>> From: "Michael Gogins" 
>>>> To: "Developer discussions" 
>>>> Sent: Thursday, May 28, 2009 3:55 PM
>>>> Subject: Re: [Cs-dev] parallel processing panel at ICMC
>>>>
>>>>
>>>>> Point taken.
>>>>>
>>>>> BTW, it now seems that Intel Threading Building Blocks (TBB) is
>>>>> supported to some extent on MinGW, so it can be considered available
>>>>> for Csound, at least on Windows and Linux. So TBB would be appropriate
>>>>> for parallelizing the kperf loop, and for supplying thread-safe
>>>>> collections and function locks.
>>>>>
>>>>> TBB can do function locks both with pthreads and with spinlocks.
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>> On 5/28/09, victor  wrote:
>>>>>> Not really, some of their results demonstrated that even some
>>>>>> typically parallel algorithms were slower in parallel than
>>>>>> single-thread
>>>>>> implementations, which I can only attribute to grain size.
>>>>>>
>>>>>> Victor
>>>>>> ----- Original Message -----
>>>>>> From: "Michael Gogins" 
>>>>>> To: "Developer discussions" 
>>>>>> Sent: Thursday, May 28, 2009 1:40 PM
>>>>>> Subject: Re: [Cs-dev] parallel processing panel at ICMC
>>>>>>
>>>>>>
>>>>>>>I would only assume that the Faust level of parallelization is too
>>>>>>> fine-grained if experiments demonstrated that coarser grained
>>>>>>> parallelization of the same algorithms run faster.
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> 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@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://www.michael-gogins.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> 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@lists.sourceforge.net
>>>>> 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@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> 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@lists.sourceforge.net
>> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


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

------------------------------------------------------------------------------
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@lists.sourceforge.net

The TBB is GPLv2 with the "runtime exception:"

      As a special exception, you may use this file as part of a free software
      library without restriction.  Specifically, if other files instantiate
      templates or use macros or inline functions from this file, or you compile
      this file and link it with other files to produce an executable, this
      file does not by itself cause the resulting executable to be covered by
      the GNU General Public License.  This exception does not however
      invalidate any other reasons why the executable file might be covered by
      the GNU General Public License.

As far as I can tell, this lets us use the TBB in Csound. The TBB
itself is the "free software library" that can be used without
restruction, and the Csound shared libraries and programs are the
executables thus produced, which do not thereby fall under the GPL.

Regards,
Mike

On 5/28/09, Felipe Sateler  wrote:
> El viernes 29 de mayo, Michael Gogins escribió:
>> Point taken.
>>
>> BTW, it now seems that Intel Threading Building Blocks (TBB) is
>> supported to some extent on MinGW, so it can be considered available
>> for Csound, at least on Windows and Linux. So TBB would be appropriate
>> for parallelizing the kperf loop, and for supplying thread-safe
>> collections and function locks.
>>
>> TBB can do function locks both with pthreads and with spinlocks.
>
> But TBB is not open source.
>
> 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@lists.sourceforge.net

Cool, where is it? I can't find it with the other architecture files in
the faust tarball.

Michael Gogins wrote:
> It does, for float csound.
> 
> Regards,
> Mike
> 
> On 5/28/09, Jonatan Liljedahl  wrote:
>> ...
>>> Or by simply using Faust to generate such opcodes.
>> Does Faust have a "csound plugin" output? That would be wonderful and a
>> great reason for me to learn faust. :)
>>
>> --
>> /Jonatan         [ http://kymatica.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@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
> 
> 


-- 
/Jonatan         [ http://kymatica.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@lists.sourceforge.net

CVS only. Ask Yann.
----- Original Message ----- 
From: "Jonatan Liljedahl" 
To: "Developer discussions" 
Sent: Thursday, May 28, 2009 7:44 PM
Subject: Re: [Cs-dev] Faust and csound


> Cool, where is it? I can't find it with the other architecture files in
> the faust tarball.
>
> Michael Gogins wrote:
>> It does, for float csound.
>>
>> Regards,
>> Mike
>>
>> On 5/28/09, Jonatan Liljedahl  wrote:
>>> ...
>>>> Or by simply using Faust to generate such opcodes.
>>> Does Faust have a "csound plugin" output? That would be wonderful and a
>>> great reason for me to learn faust. :)
>>>
>>> --
>>> /Jonatan         [ http://kymatica.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@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>
>
> -- 
> /Jonatan         [ http://kymatica.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@lists.sourceforge.net
> 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@lists.sourceforge.net