[Mono-dev] simd: more accelerated classes

Rodrigo Kumpera kumpera at gmail.com
Tue Jan 13 18:56:48 EST 2009


On Tue, Jan 13, 2009 at 9:26 PM, crashfourit <crashfourit at gmail.com> wrote:

>
>
>
> Hurliman, John wrote:
> >
> >> -----Original Message-----
> >> From: mono-devel-list-bounces at lists.ximian.com
> >> [mailto:mono-devel-list- bounces at lists.ximian.com] On Behalf Of
> >> Rodrigo Kumpera
> >> Sent: Tuesday, January 13, 2009 12:00 PM
> >> To: crashfourit
> >> Cc: mono-devel-list at lists.ximian.com
> >> Subject: Re: [Mono-dev] simd: more accelerated classes
> >>
> >> On Tue, Jan 13, 2009 at 5:50 PM, crashfourit <crashfourit at gmail.com>
> >> wrote:
> >>
> >>       crashfourit wrote:      >       > I was wondering what it would
> >> take to use simd
> >> to acclerate this     >       > Vector4f {    > public float X;       >
> >> public float Y;
> >>       > public float Z;       > public float W;       > //.......     >
> }
> >> >       > instead of
> >> this  > Vector4f {    > internal float x;     > internal float y;     >
> >> internal
> >> float z;      > internal float w;     >       > public float X {get
> >> {return x;} set
> >> {x = value;}}         > public float Y {get {return y;} set {y =
> value;}}
> >> >
> >> public float Z {get {return z;} set {z = value;}}     > public float W
> >> {get
> >> {return w;} set {w = value;}}         > //.......     > }     > Any
> >> sugestions?       >
> >>
> >>
> >>
> >>       Also, I was wondering is there any interest in accelerated
> versions
> >> of high
> >>       level math constructs?
> >>
> >>       Like, QuaternionF, QuaternionD, Matrix4f, Matrix4d, etc?
> >>       --
> >>
> >>
> >> I would love to see a library with such high level constructs that
> >> exploit Mono.Simd. I would help with it for sure, but it shouldn't be
> >> bundled with mono.
> >>
> >
> > I would be willing to help with this as well. I currently maintain a
> > library called OpenMetaverseTypes (code is at
> >
> http://www.openmetaverse.org/viewvc/index.cgi/omf/libopenmetaverse/trunk/OpenMetaverse/Types/
> )
> > which implements Vector2/3/4, Quaternion, Matrix4, Color4, Ray, and a few
> > collections. In the future I'd like to accelerate as many of these as
> > possible. Sharing code with another library on top of Mono.Simd would be
> a
> > good start.
> >
> > John
> >
> Is that code under the X11/MIT license? If so, we can start there. I will
> set up a sourceforge project for that purpose if the mono team does not
> want
> the code on there svn server.
> --


Let me explain the implications of shipping such library.

First, it would require to be API stable, which will be a pain in the neck
during the initial ramp up while the design is flushed out.
Second, we really really want to stop adding non essential libraries to the
shipping mono. This only increases the load on our QA team at near to no
benefit for the end user.
Third, as Novell offers commercial support over the entire mono stack,
adding stuff increase the load on all of us mono developers that are Novell
employees. This is, for me, the major reason not to add it to our core
stack. It will increase the support load on my shoulders at little gain.

This is only strict related to the inclusion of such library into the lib
shipped with mono. It's not the first time this issues has come before us
with other libraries, such as Mono.Rocks for example, and the consensus was
the same: it would be in the best interest of all parties involved to not
have it included.

But this doesn't mean the library can't be endorsed as the preferred one for
high level usage of Mono.Simd. From the very begging we already have
realized that almost everyone would not be willing to use it directly, as
the lib itself is just some building blocks.

As for hosting the project in the mono svn server, there isn't much of an
advantage for it, really. I, for one, would rather use github for example.
But if you really fancy it, please talk to Miguel, as he is the one that can
make such arrangement.

What would be really nice is to make a single effort for such library and
make sure that the Mono.Simd side of the things are well fit for such
library. Keep me posted on your efforts and I'll try to help as much as I
can.

Cheers,
Rodrigo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090113/5c723101/attachment.html 


More information about the Mono-devel-list mailing list