> Can you elaborate a little on this "architectural specification" for
> us? It seems to be a vague and fuzzy notion which no one is able to
> articulate very well. Are you prepared to propose one? How will it
> be different from the standards like the one I have proposed for
> example?
The MTL is an example of such and should serve as a preliminary
proposal. The basic idea of MTL is to establish container, iterator,
algorithm, adapter, and function object classes for the linear algebra
domain, much as STL did for the "foundation class" domain. While the
rest of this reply answers these questions in part, rather than repeat
everything about MTL here (and I apologize anyway for the length of
this reply) I refer interested individuals to the MTL web page (see
end of this email) for a much more detailed description.
> I don't like it. All the operations are implemented as void
> functions which means that the application programmer can't write
> expressions and must manage all of the temporary results explicitly.
This was done deliberately. We attempted to expose rather than hide
issues that affect (and that effect) performance.
> Application programs will require two to three times as many lines
> of code as equivalent SVMT code and will be much harder to read,
> understand and maintain than SVMT. Your examples look like FORTRAN
> 77 code.
Possibly. However, this is an apples and oranges comparison (see the
discussion below about the target audience for MTL). Although the
interface to MTL may seem to be somewhat more verbose than, say, SVMT,
the implementation of MTL is much more compact -- which is somewhat
the point -- we are trying to make development of rich linear algebra
functionality into a manageable task.
> Is there something about your approach that requires a
> design like this?
Number one: performance. Using C++ only, MTL achieves or exceeds
the performance of vendor tuned BLAS.
Number two: genericity. Like MTL or not, MTL has an astonishing set
of functionality with only a small amount of code. The functionality
is combinatorial but the work required for implementation is only
additive.
Number three: MTL is aimed more at library writers than programmers
who want a C++ library that looks like matlab. One could, for
example, easily layer a library with a semantically pleasing interface
on top of MTL (and we have done preliminary implementations of such
libraries). We wanted to get the guts right first for a number of
reasons.
While having a library that provides a matlab like interface to the
programmer always seem to be appealing, the usefulness of such an
interface is over-rated, in my opinion -- at least to library
developers. To "application programmers" this might not necessarily
be the case, but then matlab itself becomes an attractive alternative,
especially with the matlab->C++ translators available. There have
been any number of vector and matrix class libraries developed and
released (and I have developed and released one or two such libraries)
and yet no one ever gets very excited about any of them. In trying to
understand why this has happened I compared what has been happening in
the linear algebra domain with what has happened in the "foundation
class" domain.
As with linear algebra class libraries, numerous foundation class
libraries have been developed and promoted (many more than in the
linear algebra case, in fact). Yet, only one really prospered and was
embraced by the C++ community -- the STL. IMHO, the reason that STL
prospered was because it was in fact an architectural specification,
of how a container should behave, how an algorithm should interfact to
a container (through the use of iterators) and so forth. Although the
actual concrete components of STL are considered by many to be the
true success of STL, I consider the contribution of STL to be much
more profound -- namely the elucidation of foundation class behavior
rather than the specification of a particular class library.
This was the basic idea behind MTL. MTL presents a picture of linear
algebra objects as being compositionally constructed from certain
types of containers (i.e., containers with certain specifications) and
adapters (in particular, one and two dimensional containers for
storage, adapter classes for orientation, shape, and the like).
Given this presentation of linear algebra objects and the
corresponding interfaces, linear algebra algorithms can be written
generically.
One particularly interesting example of the power of this approach is
in the matrix-matrix product. To get high-performance for this type
of operation, one typically writes several sets of nested and unrolled
loops to capture notions of register usage, data re-use for cache, and
so forth. Abstractly, this corresponds directly to a recursive block
matrix-matrix product -- and this is precisely how the matrix-matrix
product is implemented -- and it achieves vendor-tuned BLAS
performance. I am unaware of any other C++ library that can claim to
be written in a format corresponding the abstract linear algebra
operations that are being performed (i.e., as a recursive set of
matrix-matrix products) and that achieves high performance. (In fact,
many C++ libraries just make calls to the BLAS to try to get high
performance).
Yours Truly,
Andrew Lumsdaine
------------------------------------------------------------------------
Andrew Lumsdaine
Associate Professor email: lums@lsc.nd.edu
Dept. Comp. Sci. & Engr. phone: (219) 631-8716
353 Fitzpatrick Hall fax: (219) 631-9260
University of Notre Dame www: http://www.cse.nd.edu/~lums/
Notre Dame, IN 46556
------------------------------------------------------------------------
More information about MTL, including the code, documentation, and
publications, can be found at
http://www.lsc.nd.edu/research/mtl