Re: [boost] [gsoc] Proposal - Boost.Matrix - DRAFT RFC

Subject: Re: [boost] [gsoc] Proposal - Boost.Matrix - DRAFT RFC
From: Kornel Kisielewicz (kornel.kisielewicz_at_[hidden])
Date: 2009-04-01 11:15:37

On Wed, Apr 1, 2009 at 4:59 PM, Mike Tegtmeyer <tegtmeye_at_[hidden]> wrote:
> So my .02 is that vectors and matrices need to be two different things.
> Having them as a single entity is not a good idea because:
>
> - unnecessarily complicates implementation as there are many operations that
> make sense on a vector but not on a matrix and vice versa

Well thought out implementation will just branch into two at a given point.

> - vectors and matrices are _really_ disjoint when it comes to common usage
> patterns. (in my world anyway)

In CG it's multiplying vectors and matrices all the time, what do you
suggest by disjoint?

> - Vector operations are much more likely to take advantage of SIMD than
> matrix operations - no point attempting to unify the un-unifiable

That's where specializations enter.

> - What a perfect interface for a matrix is much more controversial than a
> vector (again in my world)

That I have to agree with.

> Having written a pretty complete numeric vector class (which I _really_
> think folks should take a look at BTW) I would have this to say about your
> proposal:
>
> It is too ambitious for a summer. You will find a few major issues that will
> dominate your time and how what your proposal is implemented.

It's not the first and not the second time I would be writing such
classes, the main difference would be compatibility, a higher level of
genericness and the need of implementing some more obscure operations
that I never bothered with. I still think it's in scope, as long as I
focus on what's important, and not week-long tries of reducing the
constant of an algorithms complexity.

> -Minor implementation details have _major_ performance implications. Again
> when I wrote cvalarray, I initially was using array references as the
> underlying thing that was passed around in the expression templates, even
> though they are basically the same thing, switching to pointers, there was a
> ~20%-30% performance improvement for certain operations (at least on gcc)
> due to how gcc was interpreting what was going on and how the SIMD register
> would get loaded. You will likely spend a lot of time trying to understand
> this kind of compiler behavior and getting a decent common implementation
> across compilers takes time.

The across compilers thing here is the major problem, however that is
to be addressed with the performance suite. Also, the goal for this
SoC is not to write *the optimal* implementation. It's to write an
implementation that will be optimal enough to be optimized without
full rewriting.

> I would focus on getting an interface that the majority of people will like
> the majority of the time.

I agree.

-- 
regards,
Kornel Kisielewicz