[boost] Re: Probing interest in fixed dimension matrix class

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 
www.pixelglow.com) 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, 
pre-fetch).

Paul