Michael,
thanks for this insight. What if we support OpenMP and use conditionals to
allow for (non-parallel) free Visual C++ builds? Since this seems to be supported
almost everywhere else, if we find that OpenMP is the way to go, this might be
a good compromise. I am not keen on depending on MS Threading Building Blocks,
I think that is possibly waste of our time/resources.
In any case the adoption of OpenMP is of course something for long term planning.
Regards
Victor
----- Original Message -----
From: Michael Gogins <gogins@pipeline.com>
Date: Monday, September 1, 2008 4:45 pm
Subject: Re: [Cs-dev] parallel processing panel at ICMC
To: Developer discussions <csound-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 <Victor.Lazzarini@nuim.ie>
> >Sent: Sep 1, 2008 12:00 AM
> >To: Developer discussions <csound-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" <stevenyi@gmail.com>
> >To: "Developer discussions" <csound-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
> <Victor.Lazzarini@nuim.ie> 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