Hi Etienne.
On Fri, Nov 14, 2008 at 2:38 PM, efortin <[EMAIL PROTECTED]>wrote: > > Hi All, > I just decided to get involved more in Mono and all related tools. Was an > hardcore .NET Framework (Windows) developer but now it seems time to let go > and explore something else. And Mono is just what I need! > > Anyway, I was quite pleased to see the Mono.Simd experimental addition. > It's > about time someone in the CIL world put efforts in exploiting the power of > the SIMD instruction sets on modern x86 CPU, even more because most of the > processing power increase in these CPU comes from SSE and al. > > I have a couple of comments on Mono.Simd: > > 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. > 2) Would it be possible to use generic instead of "hardcoding" the types > and > sizes of vectors in each class? I don't know if it's possible, but there > are > probably ways to pre-instantiate templates like you do in C++, so you have > each supported template specification ready, and/or design the native > underlying module that actually does the transformation to SIMD > instructions > do it in hardware only for the supported types. This would make this > library > quite flexible I think. Generics would pose some of very complicated problems to solve, such as the default implementation (can't do math over generic arguments), and confusion with the users as to what would get accelerated or not. The second issue is due to the fact that not all operations are available for all element types and the vector unit is 128 bits long - so a Vector16<double> would not flight. > 3) I would add more high level constructs like Matrix that make use of the > SIMD hardware. > We first need to expose a rich and usable set of intrinsics to what SSE currently has. Once we do finish with that, we might look at exposing more high level functionality. On the other hand, such experimentation should happens outside of Mono.Simd to be more agile and not bound to mono's own release schedule. I would love to see such extensions been build, but rather as a separate library which has way more flexibility in how it's developed - let's take the awesome Mono.Rocks as a fine example of that. 4) Maybe classes to help "vectorize" loops and other code construct would be > good, since the runtime is not currently able to vectorize code itself. I > still don't know how this could be done, but something like the "using" > directive in C#, but using method calls and not extension to the language, > could do the trick. > There are a lot of stuff to be explored here. One could do a vectorizing extension of LINQ to Objects, for example. Bytecode manipulation with CECIL is another opportunity. Or maybe something a lot simpler such a set of foundation classes to build such algorithms is enough. I don't know which solution could work or could be better than the others, so I'm open to help anyone trying any crazy idea over Mono.Simd. Thanks for the feedback, Rodrigo
_______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
