----- Original Message ----- From: "Paul Baxter" <pauljbaxter@hotmail.com> To: <boost@lists.boost.org> Sent: Thursday, June 02, 2005 10:59 AM Subject: [boost] Re: Probing interest in fixed dimension matrix class
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 library I wrote I do not believe has any constraint for smallness.
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.
I concur.
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).
That is precisely my implementation approach.
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.
I don't expose data, but that would be easy enough and I would like to see it done.
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).
I full agree. I have just posted my code to the public domain on comp.lang.c++ at http://tinyurl.com/d5oom Unfortunately I do not have time for the time being to make it fully boostified but I would like to help anyone who wants to make a full boost proposal, any takers? -Christopher Diggins