On Wed, Apr 1, 2009 at 4:59 PM, Mike Tegtmeyer <tegtmeye@eecis.udel.edu> 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