On Mon, Nov 17, 2008 at 3:19 PM, efortin <[EMAIL PROTECTED]>wrote: > > > > Rodrigo Kumpera wrote: > > > > > >> > >> 1) Why calling it something that ties it to the underlying technology > >> used? > >> Why not calling it Mono.Math.Advanced, or Mono.Math.Vectors, or > >> Mono.Math.Matrix? It doesn't have a big impact and it's just a question > >> of > >> taste I guess, but I find that Mono.Simd relates too much to the > >> implementation technology. > > > > The idea is to expose the Single Instruction Multiple Data extensions of > > modern cpus. > > It's not specific to vector or matrix math as it can be used with > > cryptography and image > > processing with the same degree of success. > > > > > > With your explanation, now I understand better the scope of this effort. > It'll be building blocks for higher level libraries to build on. However, I > would still make it less tightly linked with the underlying hardware. Two > examples : AccelMode mention SSEx. I would rater take an abstract approach > and make, for example, an "Hardware Acceleration Capabilities Flags" > (packed > byte addition, packed float additions). A certain "signature" would be > equivalent to a certain SSEx version. However, these flags would be usable > for any SIMD technology (x86, Altivec, Larabee, and any other in the > future). Maybe hard to factorize these capabilities though. >
The capabilities model doesn't work with SSE as a given operation availability is spread across many revisions of the instruction set. As said before, right now this is considered an implementation internal detail. The fact is that intrinsics availability queries must be done on a per method basis. It's a bit unfortunate, but a requirement if you want to squeeze as much performance as possible. What I would expect to is that high level tools are build around the query primitive to automate this task. If the attributes emerge to be close to a feature the users want, we'll rework then to be part of the public interface. Our design fits reasonable well to general purpose processors with simd units. Stream/vector processors with a very different design such as cell or Larabee are on our radar, but I don't know if it's possible to design such a library that's equally usable and functional over all these chips. > > Second example is the types themselves. They make assumption of 128-bits > wide SSE units, very specific to a particular technology. But what about > 256-bits units (Larabee for example)? What about Altivec? What about the > Cell processor (why not)? What about GPGPU (why not as well)? That's why I > was talking about generics and making it abstract enough to hide these > things and open-up the vector hardware of modern processing units. > > Right now, our main target is SSE, Altivec/VMX and ARM VFP/Neon which all maps very well to 128-bits vector types. Honestly, as much fun extending Mono.Simd to Cell/Larabee/GPGPUs would be, this is the kind of work that is of reach for us now for a few reasons. First we lack enough expertise on these processors as one doesn't use them in the same way as an ordinary cpu; second, we lack enough man power to research on how to do it; and, at last, I believe in evolutionary and incremental design, so I rather deliver a great experience for our current goals and then look into what needs to be adjusted for the next set of stuff we might want to add. If we were do to a BDUF I can assure you that right now we would not be beyond the design board and no single line of code would have been written. This doesn't mean we won't take any feedback on Mono.Simd, right now we are about in second-to-third interaction of the design. The first one was thrown out after a round of reviews and a lot of changes have happened to the second one - you can find in the svn history, if you want to.
_______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
