|
View:
New views
2 Messages
—
Rating Filter:
Alert me
|
|
|
Mono.Simd API SuggestionsJust 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 SuggestionsOn 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 |
| Free embeddable forum powered by Nabble | Forum Help |