[Mono-list] Mono.Simd - Phylosophical comments

[Rodrigo Kumpera]

On Mon, Nov 17, 2008 at 3:19 PM, efortin <etienne.fortin at sympatico.ca>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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-list/attachments/20081117/2aa126a4/attachment.html