Michale Hopkings wrote:
>
> Hi all,
>
> I've been sending questions to various maths & C++ lists but now I may
> have found the right place to go! Here is a copy of a recent post;
> I'm very interested on any thoughts.
>
> Please feel free to CC me directly as well.
>
> Thanks,
>
> Michael Hopkins
>
> ----------------------------------------------------------------------
>
> I am canvassing opinion on the usefulness (or otherwise) of the STL
> ‘valarray’ for high-performance numerical work in C++. I’m deciding
> whether to move my library of numerical algorithms (linear algebra,
> simulation, global optimisation, Bayesian methods) from C to C++, as I
> now understand the potential benefits of an OO approach.
>
> However, there do seem to be alternatives (Objective-C, Eiffel, Java?)
> and I’ve heard several complaints about C++ as a working tool; possibly
> as a reaction against the inevitable pressure to go with the flow that
> surrounds a major new language. I am trying to achieve runtime speed
> (mainly for BLAS/LAPACK-style algorithms), clarity of code, ANSI/ISO
> compatibility across compilers/platforms & ease of extension. I’m
> currently working on the Macintosh which limits the development tools
> somewhat, but I’m hoping that OS X will open up a whole bunch of new
> UNIX-based stuff that will solve that.
The usefulness of C++ for numerical work is really a separate issue
from the usefulness of valarray for numerical work. On this point, at
least, I think you will find near-universal consensus.
Let me address the first issue first. C is properly regarded as a kind
of portable assembler. In fact, the operator set for C closely
parallels the instruction set of the PDP-11 microcomputer DEC marketed
in the late 70's, which is not a bad thing; the PDP-11 had the most
beautiful machine language I've ever seen. (The parallel is not
accidental. C was developed on PDP machines.) ANSI C is very nearly a
subset of C++, which helps ease the transition to the higher level C++
constructs. I believe this was crucial in allowing C++ to get its
initial market toehold in spite of its notoriously steep learning
curve.
Objective-C seems not to be in widespread use, although there are still
people who swear by it. I have no working experience with it. My
impression is that it is a much smaller language than C++, adding the
bare minimum to C required to support a form of object-oriented
programming. I suspect its user community is too small to be viable.
Eiffel is a language I've toyed with for a long time. I haven't yet
done a major project in it, however, so I can claim no expertise.
Eiffel has a somewhat small but extremely devoted user community.
Unfortunately, its user community is too often unbearably arrogant,
which is tough on the neophyte and tends to insulate Eiffel from the
sort of criticisms that could improve it significantly. And, yes, the
user community is an important consideration in language selection.
>From a technical perspective, Eiffel offers automatic garbage
collection and compiler support for Design by Contract, and is
generally a very tight language, which are definite plusses; on the
other hand, Eiffel does not offer any form of function overloading
(only function overriding, which is not the same thing) and there is no
way to declare a truly symmetric operator function. This makes
operator overloading in Eiffel of little practical use. There's an
interesting case study on an attempt to write an Eiffel complex number
class that discussed the considerable difficulties involved.
Unfortunately, I can no longer find this on the Web. My take on Eiffel
versus C++ is this: About 30% of C++ is beautiful, and the remaining
ugly 70% is something I can live with. About 90% of Eiffel is
beautiful, but the ugly 10% has so far proven intolerable.
The real expert on numerical Eiffel is Paul Dubois, whose views are
well worth seeking out (even though they are probably about 180 degrees
away from my own.)
IMO Java is not yet worthy of consideration as a language for serious
number crunching. My general take on Java is that it is a neat idea
that was very badly implemented. It seems to combine the simplicity of
C++ and the flexibility of Eiffel with the lightning speed of Smalltalk,
if you know what I mean.
I would strongly encourage you to make the jump from C to C++. But do
it right: Learn everything you can about C++ BEFORE you start a major
coding effort. It's too easy to fall in love with a relatively
low-level technique, like operator overloading (which, strictly
speaking, isn't an object-oriented technique at all) and miss out on
the benefits of truly high-level techniques, like polymorphic objects
(the *real* heart of OOP) or advanced generic programming. We made this
mistake.
Now on to your other issue:
> As I see it, valarray was designed by BS
No, Bjarne should not be blamed for valarray. If any one person should
be blamed for valarray, it's me. That's why I tend to sign my postings
to this reflector as Kent "Frankenstein" Budge. -- Oops, I guess I've
tipped my hand already ...
exactly for this purpose; to
> allow aggressive optimisation by compilers in various ways e.g. because
> it is guaranteed to be alias-free. In theory, this should make it
> potentially faster than ANSI C until the restrict keyword is
> implemented, should it not?
Yes, that was the idea. I wanted valarray to provide a mechanism for
expressing any one-loop operation as a single expression which could be
highly optimized. I also had a vague notion that nested-loop
expressions could in turn be expressed as single expressions on nested
template classes, but the experience just wasn't there to see all the
implications -- you should know that valarray was originally *not* a
class template, but a pair of classes based on int and double for which
there *was* some experience. This is because implementations of
templates were not widely available at the time valarray was first
proposed.
>
> However, there does seem to be a body of (informed?) opinion that
> valarray is ‘broken’ or at least not working well enough to be worth the
> effort.
Yes, that is probably a fair assessment, and probably the assessment of
the vast majority (though not a unanimous view.) It has become fairly
clear that the aliasing guarantees provided by valarray simply aren't
strong enough to be useful, and that the market incentives for taking
advantage of them aren't strong enough even if they were.
valarray was written at a time when vector supercomputers were still
the sexy leading edge of computing. Unfortunately, the best
optimization strategy for a vector supercomputer is almost the opposite
of the best optimization strategy for modern hierarchical-storage
machines. On a vector supercomputer, you wanted to run the largest
possible data set past each instruction, so that the vector pipeline
remained full. On a hierarchical-memory machine, you want to throw the
largest possible number of instructions at a particular working set of
data, so that you keep your data in cache (or paged into memory or on
processor, depending on which level of the memory hierarchy you are
concerned with.) valarray might conceivably have been helpful for
optimization on vector machines, because it assumes operations are best
treated atomically. It's hopeless on modern machines.
In any case, it's not at all clear that valarray is the right philosophy.
valarray was meant to replace loops with expressions, but STL has shown
that loops can be beautiful.
> Does anyone here have experience of the runtime speed of a
> carefully constructed (i.e. avoiding the C++ efficiency pitfalls)
> valarray-based set of BLAS, LAPACK or whatever?
I'm not aware of anyone attempting to implement BLAS or LAPACK using
valarray.
If so, are you using
> slices, iterators etc and doing it fully STL-style or doing access with
> more traditional Fortran-style (i,j) operators.
>
> Compiler writers; are you taking full advantage of valarray? Does it
> offer what it suggests?
Arch Robison can answer this better than I, but the short answer to both
questions is No.
>
> Numerical methods people; have you compared it (on a level playing
> field) with C, Fortran, C++ template-based libraries (Blitz, MTL,
> POOMA)?
>
> Thanks in advance for any thoughts or pointers,
>
> Mike
>
> P.S. Please CC any replies to my email.
>
-Kent "Frankenstein" Budge
--------------------- Object Oriented Numerics List --------------------------
* To subscribe/unsubscribe: use the handy web form at
http://oonumerics.org/oon/
* If this doesn't work, please send a note to owner-oon-list@oonumerics.org
This archive was generated by hypermail 2b29 : Wed Feb 20 2002 - 03:20:13 EST