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

From: christopher diggins (cdiggins_at_[hidden])
Date: 2005-06-02 10:16:57

----- Original Message ----- 
From: "Paul Baxter" <pauljbaxter_at_[hidden]>
To: <boost_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.

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