From: christopher diggins (cdiggins_at_[hidden])
Date: 2005-06-02 10:16:57
----- Original Message -----
From: "Paul Baxter" <pauljbaxter_at_[hidden]>
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.
> 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
> 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,
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk