Well, I was think parallel processing inside opcodes, which is what in effect FAUST was doing. This would be useful for large filterbanks, reverbs with several combs in parallel etc.. I am not discarding running opcodes in parallel too, but that's a different thing. I am aware of the granularity issue (I have done experiments with MPI in sound synthesis), so all of these things need to be tested and considered. But if the mechanisms are there, it is possible to do these tests. Regards Victor ----- Original Message ----- From: Michael Gogins Date: Tuesday, September 2, 2008 6:58 pm Subject: Re: [Cs-dev] parallel processing panel at ICMC To: csound-devel@lists.sourceforge.net > 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" devel@lists.sourceforge.net>> > >> >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 > https://lists.sourceforge.net/lists/listinfo/csound-devel