[Cplex] Cplex: suggested topics for discussion on the next teleconf.

Geva, Robert robert.geva at intel.com
Tue Jun 18 22:44:01 CEST 2013


I think that this clarification from Tim as well as the other one from Arch explain the “mandatory” characteristic of OpenMP.
My question would be, can we specify a language that allows both this behavior and also composability, or do we have to pick one?

Robert.

From: cplex-bounces at open-std.org [mailto:cplex-bounces at open-std.org] On Behalf Of Mattson, Timothy G
Sent: Tuesday, June 18, 2013 1:39 PM
To: Robison, Arch; Tom Scogland; Nelson, Clark
Cc: cplex at open-std.org
Subject: Re: [Cplex] Cplex: suggested topics for discussion on the next teleconf.

And just to be absolutely clear … once the OpenMP runtime decides how many threads a program will get, it is required to keep that number of threads available throughout the parallel region.  In static mode, if the programmer doesn’t ask for a different number of threads, the system is required to make that same number of threads available in subsequent parallel regions.  Not only that, it is required to keep the threadprivate variables and their mapping onto thread IDs between parallel regions.

This is important since it means you can use OpenMP for concurrent algorithms, not just parallel algorithms.  You just have to be careful that after you enter the first parallel region, you check that you got enough threads to support your concurrent algorithm (since as Arch pointed out, a system can legally decide that you only get one thread).

OpenMP exposes the threads and it is an explicit API.  Other than the task construct, how constructs map onto explicit threads is exposed.  In many ways, this makes OpenMP a much lower level programming model than Cilk.  For folks in the HPC market, this lower level control is perceived to be very important and a big part of why in HPC, OpenMP is dramatically more popular than Cilk or TBB (not surprisingly, outside of HPC it’s probably the other way around).

--Tim

From: cplex-bounces at open-std.org<mailto:cplex-bounces at open-std.org> [mailto:cplex-bounces at open-std.org] On Behalf Of Robison, Arch
Sent: Tuesday, June 18, 2013 1:27 PM
To: Tom Scogland; Nelson, Clark
Cc: cplex at open-std.org<mailto:cplex at open-std.org>
Subject: Re: [Cplex] Cplex: suggested topics for discussion on the next teleconf.

Technically, no parallelism is mandatory in OpenMP since an implementation is allowed to limit the number of threads to 1.  ( “Algorithm 2.1” in the OpenMP standard has details.)  Though an implementation that does that is unlikely to succeed in the marketplace.

What is effectively mandatory in OpenMP is that when a parallel construct is entered, the system must figure out how many threads (thread = stack + threadprivate memory) to allocate to that construct, using Algorithm 2.1.  The “how many threads” value must be computed before the amount of work inside the construct is known.  This is both a boon to high performance in the hands of programmers who control the entire program, and a bane to programmers who don’t have that control and want composability.

In contrast, Cilk implementations really do pick and choose, at runtime, which potential parallelism should be converted to real parallelism to keep the machine busy, but not oversubscribed.

- Arch

From: cplex-bounces at open-std.org<mailto:cplex-bounces at open-std.org> [mailto:cplex-bounces at open-std.org] On Behalf Of Tom Scogland
Sent: Tuesday, June 18, 2013 11:47 AM
To: Nelson, Clark
Cc: cplex at open-std.org<mailto:cplex at open-std.org>
Subject: Re: [Cplex] Cplex: suggested topics for discussion on the next teleconf.

​Clark, your answer here, as well as some statements in the call yesterday, imply that you believe there is a case where parallelism is mandatory in OpenMP applications.  To my understanding, there is no such case for a conforming application, is there one I am missing?

To the point of the pragmas being "hints" however, I completely agree.  While both the Cilk and OpenMP constructs can be safely ignored as a whole, if one is honored, they all must be or correctness is highly unlikely.

On Tue, Jun 18, 2013 at 6:20 PM, Nelson, Clark <clark.nelson at intel.com<mailto:clark.nelson at intel.com>> wrote:
> Are we defining compiler instructions or hints?: The proposal points out
> that Cilk uses keywords, whilst OpenMP is based on pragmas, so presumably
> OpenMP is providing 'hints' to the compiler that it is free or accept, or
> not. If one of our objectives is to support both approaches, does this
> mean that the Cilk-like keywords also have to be treated as 'optional',
> at least in the sense of having an agreed semantics expressible in the
> language without the parallelism extensions?
That's a very good question. The answer is kind of subtle; it depends on
*exactly* what is considered "optional".

The semantics of Cilk are defined such that actual parallel execution is
never guaranteed/mandatory, so all parallelism could be considered optional;
in that sense even the Cilk keywords could be considered to be hints.

But from a different perspective, the keywords are interpreted as a
guarantee by the programmer that it is safe to do certain things in parallel;
in other words, that the compiler is free to transform things in a way that
might otherwise cause undefined behavior. In that sense, the keywords are
semantically significant: putting one in the wrong place causes a program
to be broken.

The fact that OpenMP constructs are expressed as pragmas does not mean that
any OpenMP pragma can be taken as hint when a program is interpreted as an
OpenMP program. The intention is that it is OK to ignore all of them, but if
any of them are honored, they should all be. So it can also be misleading to
call OpenMP pragmas hints.

But it's very important to keep in mind the exact sense in which any given
construct is or is not a hint.

Clark
_______________________________________________
Cplex mailing list
Cplex at open-std.org<mailto:Cplex at open-std.org>
http://www.open-std.org/mailman/listinfo/cplex



--
-Tom Scogland
http://tom.scogland.com
"A little knowledge is a dangerous thing.
 So is a lot."
-Albert Einstein
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/cplex/attachments/20130618/9e720a28/attachment.html 


More information about the Cplex mailing list