At 12:08 AM 10/20/99 +0200, Josef Wagenhuber wrote:
>Hello,
>My comment refers to the problem of static (compile time) polymorphism
>as a faster alternative to dynamic (run time) polymorphism
>to implement a primitive access function, e.g. Mat(i,j) such, that
>Mat(i,j) always selects the right one of
>operator()(const int&, const int&), but without declaring this method
>as virtual
> virtual operator()(const int&, const int&).
>
>Main assumption is, that the matrix type is known beforehand at
>compile time (which is nearly always the case in scientific software).
I read these discussions with interest because my field is the solution of large sparse
parallel linear systems, and this group often uses this area as an illustrative target
area... Not being a C++ guru, I have nothing of merit to contribute to this aspect of
the conversation, and I realize that the techniques you are discussing are applicable
in many other areas besides for linear systems.
I am a member of the
Equation Solver Interface forum (ESI), an informal consortium of developers and users mostly
associated with the DOE labs working on standards for linear solver components (see
http://z.ca.sandia.gov/esi/). In the ESI, we specifically avoid any access functions at
the element level, i.e. no Mat(I,J), precisely because the overhead of such a call will
kill us if we use dynamic polymorphism. Though this portion of the ESI is underdeveloped,
the general plan is to provide intermediate-level access functions like GetRow( int row )
that are usable by algorithmic clients but provide a large enough granularity that
function dispatching is a small overhead. This does of course have the tradeoff that
we still have to have a standard data structure for the return value of these functions
(e.g. a standard row format for GetRow), but arguably that is a much easier thing to
standardize then an entire matrix data structure (which is impossible).
For linear systems, though, I would say that there is considerable contention to the
claim that the matrix type is always known at compile time. One of our drivers behind the adoption of
a runtime polymorphism model is that we feel that the nature of solving huge parallel
sparse systems is such that users have to be able to quickly and easily experiment
with different solution strategies, including mixing and matching various solvers,
preconditioners, matrix classes, accelerators, etc., from different development teams,
all for different problems that may occur in their simulation. In other words: our move
to a dynamic, "component-like" (whatever that means; I am still learning) model is
driven almost precisely by our first principle that solution components have to be flexible
enough to be chosen at runtime.
Anyways, the two approaches are obviously somewhat complementary and I think
it is best if both proceed...
Regards,
Andy Cleary
Andrew J. Cleary
Computational Scientist
Center for Applied Scientific Computing
Lawrence Livermore National Lab
L-561, PO Box 808, Livermore, CA 94551
925-422-1939
--------------------- 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:09 EST