"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote:
> To address the original question, support for parallel programming, both
> SIMD and MIMD will be considered for the next version of C++. If no one
> else does, the UK will put it on the table.

Given the existence of well-defined and popular third-party solutions --
namely, MPI -- why will "the UK" insist on considering parallel extensions
in the next revision of C++?

In the world of high-performance computing -- where parallel development is
a given -- MPI has a strong following, is language independent (C, C++,
Fortran 77/90), is cross-platform, and seems to get the job done (albeit a
bit obtusely at times). Would value would come from adding parallelism to
C++ in the Standard?

And does the C++ committee have experienced parallel developers, or will
"parallel C++" end up like "numerical C++" -- largely forgotten because no
one on the committee is really committed to it?

No offense meant; I'm just trying to figure out where the C++ process is
headed.

--
Scott Robert Ladd
Master of Complexity, Destroyer of Order and Chaos
  Visit CoyoteGulch at http://www.coyotegulch.com
    No ads -- just info, algorithms, and very free code.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <8vTC7.488429$8c3.85820353@typhoon.tampabay.rr.com>, Scott
Robert Ladd <scott@coyotegulch.com> writes
>And does the C++ committee have experienced parallel developers, or will
>"parallel C++" end up like "numerical C++" -- largely forgotten because no
>one on the committee is really committed to it?

It is not a lack of commitment, but a lack of expertise in that
speciality. Some of us believe (maybe mistakenly) that providing
language support for multiple processors and array processors will have
rather more extensive application in the next decade, than support for
extended numerical programming has and will have.

>
>No offense meant; I'm just trying to figure out where the C++ process is
>headed.

Putting something on the table for consideration means exactly what it
says. We do not have fixed views as to solutions but we do think that
consideration is needed. Certainly it is our opinion that the current
core of the language is not enough to support robust and efficient
parallel programming (as opposed to multi-threading). It is possible
that a couple of other proposals for evolving C++ may provide the
necessary tools but until we look carefully and talk to those with
relevant expertise we do not know.

Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

I work on a commercial MPI and for years our company hadn't seen much
interest in the C++ bindings that exist for MPI until recently.  Most MPI
programs in existance are Fortran or C.

Recently some of our customers have been interested in C++ bindings and I
think this might be a new "big area" for C++ in the next 5 years.

I would have to say that from every interview I have ever seen with Bjarne
and other standard committee members seems to imply that the number of
language extensions that will occur to C++ will be minimal or none.
Libraries will be used to fill in the gaps instead.

Otherwise you end up with languages like Ada or Java which have their "own
threads" and big API's which seemingly lock you in to one way of doing
things.

OpenMP [to the best of my knowledge] has to do with compiler extensions for
generating parallel code.  I don't know of any C++ compilers that have such
extensions as I have never really used OpenMP.   I doubt such an add-on to
C++ will happen in the standard.  Perhaps there could be a separate
standard for a few smaller C++ extensions but I wouldn't put it in the main
C++ standard.   Vendors have enough trouble as it is trying to conform to
that. [or not trying..]

[I should of course disclaim that my views have nothing to do with the
views of the company I work for should any of you know who that is.]

> "Scott Robert Ladd" <scott@coyotegulch.com> wrote:
>> Does the Standard C++ committee have a plan to address parallel
> programming
>> in a future version of C++ ?
>
> Hmmm... I guess not, since I'm replying to myself here.
>
> So will anyone hazard a guess as to why parallelism isn't be addressed in
> a future C++ standard?
>
> --
> Scott Robert Ladd
> Master of Complexity, Destroyer of Order and Chaos
>   Visit CoyoteGulch at http://www.coyotegulch.com
>     No ads -- just info, algorithms, and very free code.
>
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"David Leimbach" <leimbacd@bellsouth.net> wrote:
> I work on a commercial MPI and for years our company hadn't seen much
> interest in the C++ bindings that exist for MPI until recently.  Most MPI
> programs in existance are Fortran or C.

Ah, thank you! This is the type of response I was looking for...
unfortunately, several other people seemed to equate "parallel programming"
with "threads"...

> Recently some of our customers have been interested in C++ bindings and I
> think this might be a new "big area" for C++ in the next 5 years.

That's what I'm expecting, too. I've done some MPI work in FORTRAN on
clusters; recently, I've had a custoemr give me reason to investigate MPI
for C++.

> Otherwise you end up with languages like Ada or Java which have their "own
> threads" and big API's which seemingly lock you in to one way of doing
> things.

I agree. Java threads are one of the *least* portable aspects of that
language. Don't know much about Ada...

> I would have to say that from every interview I have ever seen with Bjarne
> and other standard committee members seems to imply that the number of
> language extensions that will occur to C++ will be minimal or none.
> Libraries will be used to fill in the gaps instead.

I'm very happy to hear this, and *totally* agree with the philosophy of
minimizing changes in the base language.

My concern was that "Standard C++" would add a class library aimed at
parallel development, thus dilluting the market for MPI skills. It seems to
me that C++ should only add a standard library if one does not exist -- and
given MPI's existence, I don't see that a different parallel class library
is necessary in Standard C++.

> OpenMP [to the best of my knowledge] has to do with compiler extensions
for
> generating parallel code.

OpenMP uses pragmas (in the case of C/C++) to identify parallel sections of
code; a compiler must (obviously) support the expected pragmas and generate
appropriate machine code, but pragmas are outside the actual language
definition, so OpenMP doesn't require any deviations from Standard C++.

The Intel compilers support OpenMP, on both Linux and Windows.

The basic OpenMP package is focused on SMP/SMT machines; I believe there is
a distributed/cluster variant of OpenMP, but I haven't looked at it.

Thanks.

--
Scott Robert Ladd
Master of Complexity, Destroyer of Order and Chaos
  Visit CoyoteGulch at http://www.coyotegulch.com
    No ads -- just info, algorithms, and very free code.



======================================= MODERATOR'S COMMENT:
 Warning:  topic drift, standard-related content flatlining...

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3ryB7.10205$cj7.581367@e3500-atl1.usenetserver.com>, David
Leimbach <leimbacd@bellsouth.net> writes
>I would have to say that from every interview I have ever seen with Bjarne
>and other standard committee members seems to imply that the number of
>language extensions that will occur to C++ will be minimal or none.
>Libraries will be used to fill in the gaps instead.

Most of us want to limit changes to the core and real extensions as
opposed to evolutions (cleaning up the language) will need to make a
very strong case. Largely changes will be driven by the needs of the
library. So if multi-threading libraries require some direct language
support those will be treated sympathetically, but we would not wish to
modify the language in ways that might make it harder for some platforms
than others.

Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

> Ah, thank you! This is the type of response I was looking for...
> unfortunately, several other people seemed to equate "parallel
> programming" with "threads"...

Threads can mean parallel code of course..  Mach has Cthreads that can be
pinned to a particular processor.  I know that Windows NT has this
capability as well and suspect that Solaris probably could too.

>
>> Recently some of our customers have been interested in C++ bindings and I
>> think this might be a new "big area" for C++ in the next 5 years.
>
> That's what I'm expecting, too. I've done some MPI work in FORTRAN on
> clusters; recently, I've had a custoemr give me reason to investigate MPI
> for C++.

Things like template metaprogramming in C++ can create source that has been
"pre-executed" for some pretty impressive run-time speedups at the cost of
compile time overhead. [depending on how you measure compile time.. the
cost can be negligible]

>> I would have to say that from every interview I have ever seen with
>> Bjarne and other standard committee members seems to imply that the
>> number of language extensions that will occur to C++ will be minimal or
>> none. Libraries will be used to fill in the gaps instead.
>
> I'm very happy to hear this, and *totally* agree with the philosophy of
> minimizing changes in the base language.
>
> My concern was that "Standard C++" would add a class library aimed at
> parallel development, thus dilluting the market for MPI skills. It seems
> to me that C++ should only add a standard library if one does not exist --
> and given MPI's existence, I don't see that a different parallel class
> library is necessary in Standard C++.

Yes... the MPI C++ bindings do exist and they are class based but the MPI
standard writers have made some pretty bad mistakes lately in the errata
they are currently working on.

There are MPI datatypes which were const Objects of MPI::Datatype [MPI
namespace].  Someone complained that since it was const certain internal
private data members wouldn't be changeable... everyone bought the argument
and now data that should have been const is no longer.  [Obviously they
have never heard of mutable... I am allowed to watch these proceedings but
apparently have no voice in the issue].

For C++/MPI to get along we need more competent C++ programmers to get
involved with the MPI standard or more such irrational rationalizations
will pop up.

>
>> OpenMP [to the best of my knowledge] has to do with compiler extensions
> for
>> generating parallel code.
>
> OpenMP uses pragmas (in the case of C/C++) to identify parallel sections
> of code; a compiler must (obviously) support the expected pragmas and
> generate appropriate machine code, but pragmas are outside the actual
> language definition, so OpenMP doesn't require any deviations from
> Standard C++.
>
> The Intel compilers support OpenMP, on both Linux and Windows.
>
> The basic OpenMP package is focused on SMP/SMT machines; I believe there
> is a distributed/cluster variant of OpenMP, but I haven't looked at it.

I think so too...

>
> Thanks.
>
> --
> Scott Robert Ladd
> Master of Complexity, Destroyer of Order and Chaos
>   Visit CoyoteGulch at http://www.coyotegulch.com
>     No ads -- just info, algorithms, and very free code.
>
>
>
> ======================================= MODERATOR'S COMMENT:
>  Warning:  topic drift, standard-related content flatlining...
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <qsHB7.11840$cj7.659566@e3500-atl1.usenetserver.com>, David
Leimbach <leimbacd@bellsouth.net> writes
>> Ah, thank you! This is the type of response I was looking for...
>> unfortunately, several other people seemed to equate "parallel
>> programming" with "threads"...


To address the original question, support for parallel programming, both
SIMD and MIMD will be considered for the next version of C++. If no one
else does, the UK will put it on the table.


Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Scott Robert Ladd" <scott@coyotegulch.com> wrote:
> Does the Standard C++ committee have a plan to address parallel
programming
> in a future version of C++ ?

Hmmm... I guess not, since I'm replying to myself here.

So will anyone hazard a guess as to why parallelism isn't be addressed in a
future C++ standard?

--
Scott Robert Ladd
Master of Complexity, Destroyer of Order and Chaos
  Visit CoyoteGulch at http://www.coyotegulch.com
    No ads -- just info, algorithms, and very free code.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Scott Robert Ladd" <scott@coyotegulch.com> writes:

> "Scott Robert Ladd" <scott@coyotegulch.com> wrote:
> > Does the Standard C++ committee have a plan to address parallel
> programming
> > in a future version of C++ ?
>
> Hmmm... I guess not, since I'm replying to myself here.
>
> So will anyone hazard a guess as to why parallelism isn't be addressed in a
> future C++ standard?

Depends on what you mean by "parallelism".  If you mean something like
multithreading, then my guess is that it will be addressed in some
way.

There's a slight conceptual difficulty here, because not all platforms
do support multithreading.  (Think of embedded controllers, for
example.)  One way of dealing with this might be to say that we don't
require these facilities to be present, but that if they're present
they have to conform to what the standard says.

In the short run, this isn't a difficulty: the first step, before
doing anything like revising the standard, will be a technical report
on library extensions. I think it's likely that we'll describe some
kind of threading library in it.  There are a number of possibilities
that we could look at as starting points.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Scott Robert Ladd" <scott@coyotegulch.com> writes:

> Hmmm... I guess not, since I'm replying to myself here.
>
> So will anyone hazard a guess as to why parallelism isn't be
> addressed in a future C++ standard?

For the same reason it isn't addressed in the C standard. There are
extensions to C (like Posix) which offer multi-threading, but there is
not universal consensus that *this* specific API is the one to make
mandatory, nor is there consensus that multi-threading should be
mandatory in C++ in the first place. Some systems (e.g. Win32) expose
a different API for threads than Posix threads.

I see a number of options to change the status quo:
- The Posix standard should recognize the existence of C++, and
  add a C++ compiler into the XCU document. It should then clarify
  aspects of multithreading for C++. Alternatively,
- The C standard standard should recognize a threading API.

In either case, the next revision of C++ could then copy the
pre-existing text. A third alternative is certainly the proposed
document on common extensions; people would then have atleast a
document where all the problems are elaborated.

Regards,
Martin

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Does the Standard C++ committee have a plan to address parallel programming
in a future version of C++ ?

I've been doing quite a bit of parallel programming recently, using OpenMP
(http://www.openmp.org) and MPI (http://www.mpi-forum.org) in both C++ and
Fortran.

Has any specific model stood out as a leading candidate for parallelism in
C++?

Since the code I'm writing now will still be running in five or ten years,
I'm interested in glimpsing the future, if possible, so I can plan ahead.

Thanks.

--
Scott Robert Ladd
Master of Complexity, Destroyer of Order and Chaos
  Visit CoyoteGulch at http://www.coyotegulch.com
    No ads -- just info, algorithms, and very free code.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]