| 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 > 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 > >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.sourc |