TITLE: musings on valarray for numerical work (Source: object-oriented-numerics mailing list, 19 June 2000) [ Contributed by Saul Tamari (saul_tamari@creoscitex.com)] HOPKINS: Michale Hopkins [snip] > ---------------------------------------------------------------------- > > 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. BUDGE: "Kent Budge" 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: HOPKINS: > As I see it, valarray was designed by BS [Bjarne Stroustrup] BUDGE: 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 ... HOPKINS: 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? BUDGE: 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. HOPKINS: > > 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. BUDGE: 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. HOPKINS: > 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? BUDGE: I'm not aware of anyone attempting to implement BLAS or LAPACK using valarray. HOPKINS: 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? BUDGE: Arch Robison can answer this better than I, but the short answer to both questions is No. HOPKINS: > Numerical methods people; have you compared it (on a level playing > field) with C, Fortran, C++ template-based libraries (Blitz, MTL, > POOMA)? _______________________________________________ cpptips mailing list http://cpptips.hyperformix.com