Re: [eigen] Re: Eigen 2 design

[Benoît Jacob <jacob@xxxxxxxxxxxxxxx>]

On Monday 14 May 2007 12:33:32 Tommi Rantala wrote:
> * About the expression templates: did you already check out tvmet? It
> seems to be quite close to what you have in mind for eigen-basic.

I didn't really look at it (though I knew the name) so I'll have a look. 
Thanks for the suggestion!

> * Some kind of performance test suite would be very useful, especially
> if we add optimizations like SSE support and expression templates. It's
> very easy to actually make things much slower when changing something.
> Creating a good suite is probably very tricky.

Good point. We don't have such a test suite currently but I'll think about it.

> * I'm planning on adding SSE support via the SSE instrinsics API. This
> should provide performance gains while still being reasonably portable.
> I'm not sure whether this can be easily done for any NxM matrices and
> vectors -- multiples of 4 are at the sweet spot. A few more things:

I see. The important sizes for which to optimize to are: 2x2, 3x3 and 4x4. Of 
these, only 3x3 is not a multiple of 4. I'm not sure what to do here; but 
anyway, you can start with 2x2 and 4x4 and it'll already be a very 
interesting progress.

> a) the matrix array should be aligned to 16-byte boundary (just
> add "__attribute__ ((aligned (16)))" ), SSE has unaligned and aligned
> loads/stores, and it seems that the unaligned stuff can be slow

ok, I've done some computations, the memory overhead is pretty much OK (worst 
case +33%) for most kinds of vectors/matrices. Only one exception: 
2-dimensional vectors of floats. sizeof=8, so the 16-byte alignment doubles 
the memory usage. But I don't really know SSE; probably you didn't intend to 
use SSE for such small vectors.

Still I like to be able to say that Eigen brings zero memory overhead as 
compared to plain arrays. Would it be possible to let the user turn alignment 
off if memory usage really does matter more to him than performance?

> b) it should be easy to add specialized cases, like <float, 4, 4> etc.
>
> * How should we enable the SSE support? #ifdef __SSE__ or runtime
> checks? Runtime checks could enable even the generic distro packages to
> have SSE support.

Yeah but runtime checks mean a nasty overhead due to checking in every 
function whether SSE is present, right? I mean, if a function has two 
codepaths, there has to be an "if" to determine which codepath to follow.
That seems to be a no-go to me, so I'd favor a compile-time approach.

I still haven't created the svn branch to work on eigen2, much less have I 
laid down the initial groundwork before you can work on SSE. Sorry about 
that, I'm just 100% busy with KDE-Edu-related stuff. Anyway, there's a 
feature freeze on June 1, so this will have to be finished before that 
date :) Then (or perhaps before) we can start with Eigen 2. So please bear 
with me. Oh and we have some pretty big potential "clients" for Eigen 2. 
Krita and KSpread could use Eigen more than they do today. OpenBabel (major 
chemistry library) might port to Eigen2. And the project i've been working on 
lately, Avogadro (3D molecular editor/viewer with library to be used by 
Kalzium), already is based on Eigen. 

Just to tell you that your SSE optimization will benefit a lot of projects :)

Cheers,
Benoit

Attachment: pgpvQhaDto_46.pgp
Description: PGP signature