[Cplex] Cplex: suggested topics for discussion on the next teleconf.
jhammond at alcf.anl.gov
Wed Jun 19 05:20:54 CEST 2013
>> It will not surprise me if my position pisses off 110% of the people who read
>> this email, but this is how I see the world.
> :) It me gives a nice hook to say some things, though:
>> for the C++ programmers
>> of the world who do not like the bare-metal perspective of C.
> The difference between C and C++ has nothing to do with bare-metal. Both C and C++ are equally bare-metal don't-hide-anything efficient systems languages. Both have the design goal "leave room for no language lower (other than asm)." In the real world, both are used for demanding systems projects and are roughly equally efficient (for every example someone can show where C runs faster, I'll show one where C++ runs faster, and probably vice versa -- notably C++ often builds faster reusable libraries because it naturally eliminates pointer and pointer-to-function indirections in more cases while remaining).
I absolutely agree with you in theory, but at least in my world of
HPC, the practice of programmers is reflected in my statement.
> If you meant "a simpler less-abstracted language like C," I agree, but then let's say that.
All of my perceived differences between C and C++ are due to practice.
If that's not a valid position from which to argue, then I'll not do
>> It is also worth thinking about why people use C instead of C++ [...]
> Given that both are equally "portable efficient systems programming languages," the actual major reasons people use C or C++ are dominated by two things AFAICS:
> - skill set (in their staff and available in the marketplace); and
> - tools and libraries (e.g., FFmpeg is C only, so if you want FFmpeg you have a technical reason to use C, at least for part of your project).
One of the primary reasons many projects in HPC do not use C++ or C99
is lack of compiler support for relevant features. In Japan, there is
a billion-dollar supercomputer called "K" that can't compile C99. It
took over two years of filing bugs before I could compile an important
C++ application code with the vendor compiler on the machine I am paid
to program and it isn't even using C++11. Boost is a dirty word in my
community because it is the exception rather than the rule that one
can depend on the compiler to be able to parse it properly. I try to
avoid C++ even when it makes perfect sense because I cannot trust that
my compilers will be able to turn it into correct code.
> In fact, a large and probably growing set is "projects that use both C and C++," which brings us to:
>> My point is that, if Cplex is C-centric, we should be attentive to what C
>> programmers want and not what C++ programmers want.
> This is a WG14 study group, so I hope that it will focus on (at least) what's best for real-world C programmers -- including both (a) C-only projects, and (b) the very large number of combined C-and-C++ projects.
> For example, one issue the industry is still dealing with is multiple schedulers when different parts of the app are parallel (e.g., different libraries the app uses are parallel) but use different schedulers (e.g., one uses Acme OpenMP and another uses Atomic Cilk, or whatever), which leads to oversubscription, contention, and/or worst of all surfacing knobs to the user to make him participate in the scheduling to control the mess.
I agree that is a great goal, but it's going to be quite a challenge.
How many examples do we have of this being done today? Intel
OMP/TBB/MKL is the only case I've heard that supposedly fixes this for
users that oversubscribe (I have no specific experience since I
intentionally do not oversubscribe).
I'd like to hear some skeleton proposals for how people actually
intend to do this on a few different systems before making any
judgement. I have a hard time seeing how this will work without
OS-awareness. A solution that doesn't work on a lightweight kernel
like Cray Catamount, Sandia Kitten, or Blue Gene CNK isn't a solution.
How do we determine what oversubscription is with hardware SMT? Does
the thread implementation know what is the hardware bottleneck for the
code executing on a given thread? Mild oversubscription can be very
useful to hide latency or it can be catastrophic for caching.
> How this impacts WG14 and WG21: IMO we cannot live with a long-term requirement that applications use multiple schedulers. Therefore we desperately need any Standard C and Standard C++ solutions to be able to use the same scheduler (and prototyped proof of this) while still surfacing a programming model appropriate for their users (i.e., not hamstringing the language design). It would be a disaster to try standardize a Standard C model and a Standard C++ model that cannot demonstrably share a scheduler -- and I'm pretty sure that would be a non-starter for SC22 standardization in an IS, though of course a TS can be more experimental.
(nods in agreement)
> (For completeness, of course WG21 is also interested in the third group -- (c) C++-only projects, and the pressure we will get to directly emulate anything C does, but that's a separate topic.)
>> My hope is that Cplex can provide a mechanism for C programs to achieve
>> what they can only today achieve with non-portable language constructs like
>> inline assembly. I see absolutely no value in putting into the language that
>> which is already provided for by libraries like Pthreads unless it is provable
>> that compiler interaction provides a measurable _performance_ benefit.
> Are you saying that it's possible that C11 threading might be enough for C parallelization needs?
It might be mostly sufficient for me but I have very, very low
standards for what my software ecosystem gives me for parallelism; in
general, I am sure that it is not sufficient. Once I have C11, I can
eliminate Pthreads and my inline assembly atomics but I still need
SIMD either as a non-portable language extension or inline assembly.
I joined Cplex in hopes of seeing something happen on this front.
Argonne Leadership Computing Facility
University of Chicago Computation Institute
jhammond at alcf.anl.gov / (630) 252-5381
ALCF docs: http://www.alcf.anl.gov/user-guides
More information about the Cplex