Boost logo

Boost :

From: Paul Baxter (pauljbaxter_at_[hidden])
Date: 2005-06-02 09:59:34

>> I have just finished writing a fixed dimensionality matrix template
>> (kmatrix<T, Rows, Cols>) which appears to significantly outperform the
>> ublas::matrix. Is there any interest? Below are the results of the
>> benchmarks using Visual C++ 7.1 on an Intel Celeron 1.6 GHZ:
> I believe we badly need some de jure standard for C++ incarnations
> of common mathematical concepts, in particular w.r.t. algebra and
> (euclidian) geometry. "Small" matrices are in that group.
> The fact that they would be fast would be icing on the cake, not
> the cake itself, as it were. What is most needed IMHO is a clear and
> rich set of links between the various elements of that collection
> (complex <-> plane (vector) rotation; rotation <-> geometric elements of
> the rotation (when meaningful); 2D, 3D, 4D points;...).

Whilst I'm happy that a mathematicians/physicists set of concepts and tools
need hammering out for that field of programming, in many application areas
(e.g. gaming, image/signal processing) there is also a need for a fast
implementation of 1d, 2d and 3d data structures and associated processing
routines that are going to approach the speed of vector C libraries.

Several signal/image processing libraries exist though often in
architecture-optimised binary-only forms (e.g. the richness of the Intel
performance Primitives library). Others (such as MacSTL at use C++ techniques and interfaces to low level
architecture-specific vectorisation that work reasonably well.

Personally I prefer the use of non-architecture specific code that an
autovectorising compiler has a good chance of optimising but defining a
'good chance' with current compilers is sometimes challenging if supporting
multiple compilers/platforms.

I believe that a 'vector processing' library should provide a data structure
implementation that could maintain interoperability with C high-performance
libraries (e.g. contiguous memory, perhaps assuming constant x,y,z strides).
I'm not suggesting that would be its only implementation. It should be able
to expose raw pointers, with an assumed data layout. I understand that
exposing data structure is 'bad', but the fact is that users of such a
library will often need to call diverse third party architecture optimised C
libraries in cases where absolute performance is essential.

Many C++ vector/matrix library implementations I've seen that hide the
underlying structure and support variable size containers do pay a
significant abstraction penalty in traversing the container or in making it
difficult for compiler's to take advantage of additional optimisations that
are possible with fixed sized containers (such as cache manipulation,


Boost list run by bdawes at, gregod at, cpdaniel at, john at