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@nuim.ie
>Sent: Sep 2, 2008 9:32 AM
>To: Michael Gogins , Developer discussions 
>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 
>Date: Tuesday, September 2, 2008 1:36 pm
>Subject: Re: [Cs-dev] parallel processing panel at ICMC
>To: csound-devel@lists.sourceforge.net
>
>> 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@nuim.ie
>> >Sent: Sep 2, 2008 1:56 AM
>> >To: Michael Gogins , Developer 
>> discussions 
>> >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 Date: Monday, September 
>> 1, 2008 4:45 pmSubject: Re: [Cs-dev] parallel processing panel 
>> at ICMCTo: Developer discussions > devel@lists.sourceforge.net>> 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 > >Sent: Sep 1, 
>> 2008 12:00 AM> >To: Developer discussions > devel@lists.sourceforge.net>> >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" > >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> > > > > -----------------------------------------------------------------> --------> 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