Vector performance

[Manu]

On 12 January 2012 01:15, F i L <witte2008 at gmail.com> wrote:

> Manu wrote:
>
>> Yes the lib would supply standard operations, probably even a matrix type
>> or 2.
>>
>
> Okay cool. That's basically what I wanted to know. However, I'm still
> wondering exactly how flexible these libraries will be.


Define 'flexible'?
Probably not very flexible, they will be fast!


> Have some code of more complex operations?
>>
>
> My main concern is with my "transition" objects. Example:
>
>   struct Transition(T) {
>       T value, start, target;
>       alias value this;
>
>       void update(U)(U iteration) {
>           value = start + ((target - start) * iteration);
>
>       }
>   }
>
>
>   struct Vector4(T) {
>       T x, y, z, w;
>
>       auto abs() { ... }
>       auto dot() { ... }
>       auto norm() { ... }
>       // ect...
>
>       static if (isTransition(T)) {
>           void update(U)(U iteration) {
>               x.update(iteration);
>               y.update(iteration);
>               z.update(iteration);
>               w.update(iteration);
>           }
>       }
>   }
>
>
>   void main() {
>       // Simple transition vector
>       auto tranVec = Transition!(Vector4!float)();
>       tranVec.target = {50f, 36f}
>       tranVec.update(0.5f);
>
>       // Or transition per channel
>       auto vecTran = Vector4!(Transition!float)();
>       vecTran.x.target = 50f;
>       vecTran.y.target = 36f;
>       vecTran.update();
>   }
>
> I could make a free function "auto Linear(U)(U start, U target)" but it's
> but best to keep things in object oriented containers, IMO. I've
> illustrated a simple linear transition here, but the goal is to make many
> different transition types: Bezier, EaseIn, Circular, Bounce, etc and
> continuous/physics one like: SmoothLookAt, Giggly, Shaky, etc.
>

I don't see any problem here. This looks trivial. It depends on basically
nothing, it might even work with what Walter has already added, and no libs
:)
I think the term 'iteration' is a bit ugly/misleading though, it should be
't' or 'time'.


My matrix code also looks something like:
>
>   struct Matrix4(T)
>    if (isVector(T) || isTransitionOfVector(T)) {
>
>       T x, y, z, w;
>   }
>
> So Transitions potentially work with matrices in some areas. I'm still new
> to Quarternion math, but I'm guessing these might be able to apply there as
> well.
>

I would probably make a transition of matrices, rather than a matrix of
vector transitions (so you can get references to the internal matrices)...
but aside from that, I don't see any problems here either.


So my main concern is how SIMD will effect this sort of flexibility, or if
> I'm going to have to rethink my whole model here to accommodate SSE
> operations. SIMD is usually 128 bit right? So making a Vector4!double
> doesn't really work... unless it was something like:
>
>   struct Vector4(T) {
>       version (SIMD_128) {
>           static if (T.sizeof == 32) {
>               __v128 xyzw;
>           }
>           else if (T.sizeof == 64) {
>               __v128 xy;
>               __v128 zw;
>           }
>       }
>       version (SIMD_256) {
>           // ...
>       }
>   }
>
> Of course, that would obviously complicate the method code quite a bit.
> IDK, your thoughts?
>

I think that is also possible if that's what you want to do, and I see no
reason why any of these constructs wouldn't be efficient (or supported).
You can probably even try it out now with what Walter has already done...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120112/84e67321/attachment-0001.html>