Mono.Simd API Suggestions

View: New views
2 Messages — Rating Filter:   Alert me  

Mono.Simd API Suggestions

by Jonathan Pryor :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Just perusing through the Mono.Simd API, and one question (and a few
other suggestions) occurs to me: Why the non-reliance on method
overloading?

More specifically, many (most?) types have an UnpackLow() method:

        public class Vector2L {
          public static Vector2l UnpackLow (Vector2l x, Vector2l y);
        }
 public class Vector8s {
          public static Vector8s UnpackLow (Vector8s x, Vector8s y);
        }
        // ...

Why do we require type qualification for these methods, so that to call
them you need Vector2L.UnpackLow() or Vector8s.UnpackLow()?  Why not
instead use method overloading on a common type:

        static class VectorOperations /* [0] */ {
          public static Vector2l UnpackLow (Vector2l x, Vector2l y);
          public static Vector8s UnpackLow (Vector8s x, Vector8s y);
          // ...
        }

The benefit to this are twofold:

1. Documentation: the class-level documentation will only contain
   members which are specific to the given type (except for overloaded
   operators, but those can't be located anywhere else anyway...).
   Meanwhile, semantically equivalent operations would all be located
   in and documented in the same place.

2. Type migration: if the developer starts with Vector8s and needs to
   migrate to Vector4f, fewer code changes will be required (e.g. you
   won't need to change every UnpackLow() method call to refer to your
   new type).

On a completely different note (and to start a bikeshed discussion ;-),
why "ShiftRightLogic"?  Wouldn't "LogicalRightShift" be more
conventional?  We should also avoid abbreviations, so
SubtractWithSaturation() would be better than SubWithSaturation()...

Thoughts?

 - Jon

[0] or some better name.  `VectorOperations' is rather verbose, but the
name chosen doesn't really matter as far as this question is
concerned...


_______________________________________________
Mono-docs-list maillist  -  Mono-docs-list@...
http://lists.ximian.com/mailman/listinfo/mono-docs-list

Re: Mono.Simd API Suggestions

by Jonathan Pryor :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Tue, 2008-11-04 at 21:00 -0500, Jonathan Pryor wrote:
> ...

Other suggestions:

SimdRuntime.IsMethodAccelerated() and
SimdRuntime.MethodAccelerationMode() should be overloaded to accept a
MethodInfo of the desired method, as it can be ~trivial to get a
MethodInfo in a static, type-checked fashion, e.g.:

        MethodInfo average = ((Func<Vector8us, Vector8us, Vector8us>)
                Vector8us.Average).Method;
        bool b = SimdRuntime.IsMethodAccelerated (average);

Even better, this is _faster_ than typeof(Vector8us).GetMethod
("Average").  (Not by a lot, but faster nonetheless.)

AccelerationAttribute should be AcceleratedOnAttribute, and AccelMode
should be InstructionSet.  I think this would make for more readable
documentation prototypes:

        [Mono.Simd.AcceleratedOn (Mono.Simd.InstructionSet.SSE2)]
        public static Vector8us Average (Vector8us va, Vector8us vb);

Finally (for now), parameter names should be more consistent.  On some
methods the arguments are (va, vb) (e.g. Vector8us.Average()), while on
others they're (v1, v2) (e.g. Vector2d.InterleaveHigh()).  I don't care
which we choose, but we should stick to something and use it
consistently (`a` and `b`, perhaps?).

(This will be even more useful in C# 4 in which arguments can be named,
as changing the method invoked won't needlessly require changing the
parameter names...)

 - Jon


_______________________________________________
Mono-docs-list maillist  -  Mono-docs-list@...
http://lists.ximian.com/mailman/listinfo/mono-docs-list