[Cplex] Cplex: suggested topics for discussion on the next teleconf.
hsutter at microsoft.com
Wed Jun 19 01:48:22 CEST 2013
Jeff Hammond wrote:
> 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).
If you meant "a simpler less-abstracted language like C," I agree, but then let's say that.
> 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).
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.
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.
(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?
More information about the Cplex