[Mono-list] Mono.Simd - Phylosophical comments

[Rodrigo Kumpera]

Hi Etienne.


On Fri, Nov 14, 2008 at 2:38 PM, efortin <etienne.fortin at sympatico.ca>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-list/attachments/20081116/a9abdd65/attachment.html