Some thoughts based on messages in the first weekly digest of this list.
Many of my opinions are formed by interacting with a set of computational
scientists who have mission-specific goals--I bet others have different
opinions.
* Language - Why C++ and not something else?
With luck the list will not be discovered by the language bigots for
a little while, so we can have some rational discourse. One can
complain about large and small unhappinesses in C++, debate why they're
there, explain what to do about them, etc. My belief is that C++
holds the prominent position in OON for two reasons: commercial
market share, and comprehensive facilities.
--First: At least in the U.S. high-performance computing (HPC) world,
the current mantra is that one must adapt technologies with broad
commercial support to the HPC arena, which some believe no longer
has its own commercial viability. Hence architectures like Pile o'
PCs and Clusters of SMPs. Hence also C++. No other O-O language
has such significant marketplace presence. This is working:
commercially available, high-quality C++ compilers are rapidly
converging on complete implementations of all standard language
features (all needed in OON), but not because of the puny number
of sales possible in the high-end community.
In fact, vendors feel greater pressure to deliver highly optimizing
C++ compilers than F90 compilers, because the latter has a smaller
market.
--Second: As exemplified below, the people I know who develop OON
technology need ALL the features of standard C++, including those
not found in Java, the other O-O language with market share in
the U.S.
* Performance
The above is one reason to be optimistic about computing using C++
on HPC platforms. Here are two more:
--Expression templates
This technology is effective in generating efficient code for
expressions involving application-specific operands and overloaded
operators. Current disadvantages of them are:
> Not all compilers implement enough standard features and
optimizations to make their use effective. This statement
is nearly obsolete, because of market pressure, mentioned above.
> They are obscure and hard to understand. However, they are the
province of the library writer, not the application writer, so
the population that must understand them is presumably smaller.
In addition, I know of one project that will provide a compile-
time template engine for library writers to make expression
templates much simpler to use.
> Slow compile times. If you've used them, please envision the
compile time associated with expressions from a 27-point stencil
calculation. I have optimism that this problem can be overcome,
for two reasons. First, when partial specialization is used,
the text that a compiler must process drops to a small fraction
of the size needed for templates defined without this feature
being implemented. Second, like most new software technologies,
slow now means faster "real soon now." Remember the speed of
early Ada compilers?
--More libraries a` la the STL
A large but unknown number of projects aim to develop comprehensive
templated libraries to enable HPC in C++. The part of DOE I work in
is funding one such project (but the goals are more comprehensive
than that): please visit the web page at http://www.acl.lanl.gov/SciTL.
The intention is to continue investments to give the application writer
a domain-specific, high-level programming environment in the same way
that the STL provides common computer-science data structures and
algorithms. Programs written in this environment are meant to be
portable among, and achieve high performance on, relevant parallel
computing systems. Issues of interoperable APIs among components
are also to be addressed.
* Productivity
I found the volume edited by Boisvert in Computer Literacy Books in
Tysons Corner today. In a scan of it, I found no productivity study
as suggested in Todd's original post. Maybe some info is buried in
an article, but I didn't find it. The TOC is findable online, and the
book will no doubt be of great value to others, but at $140 I passed.
* Teaching O-O numerics to the masses
The best way to diffuse knowledge of and competent use of O-O
techniques is to build successful, non-trivial numerical applications
and publish them with lots of explanatory material that helps a beginner
understand what's going on. Many people learn well by example, and
first tries are often alterations of things that already work.
While we should be concerned that people learn about what we think
of as useful techniques, we cannot make people do what they don't
want to do. I recall my dissertation advisor saying (ca. 1973):
"You do the research, publish your papers, get your techniques into
the textbooks. Then you wait for the old professors to die." Only
months ago, I heard a physicist exclaim about these different modes
of computing, "I don't have time to learn anything new!"
I'm actually optimistic about solving this problem. The younger
(<= 10 years post-graduate) computational scientists I've met are
aggressive about learning and using new techniques well, including
O-O languages and design. Colleges are doing a good job of teaching
O-O skills, so the supply of talent will grow.
My advice: Do good things with these new techniques, write them up
well, don't oversell what the techniques can accomplish, don't belittle
other technical approaches--and wait for the old scientists to die.
-- |--------------------------------------------------------------| | Rod Oldehoeft Voice: 301/903/6904 | | Math/Info/Computational Sciences Fax: 301/903/7774 | | ER-31, U.S. Department of Energy Email: rro@er.doe.gov | | 19901 Germantown Road rro@acm.org | | Germantown, MD 20874-1290 PGP key available | |--------------------------------------------------------------| | I always wanted to be somebody, but I should | | have been more specific. ---Lily Tomlin | |--------------------------------------------------------------|
This archive was generated by hypermail 2b29 : Wed Feb 20 2002 - 03:20:05 EST