[Mono-dev] simd: more accelerated classes

Tue Jan 13 19:12:12 EST 2009

There's no benefits to using mono as opposed to using any of the free
hosting ones out there. Mono doesn't come with a bug tracker, it doesn't
come with space to host downloads, it doesn't come with a wiki of any kind.
You really should consider using a free hosting that gives you all that. For
example google code, github, whatever.

Alan.

On Wed, Jan 14, 2009 at 12:09 AM, crashfourit <crashfourit at gmail.com> wrote:

>
>
>
> Rodrigo Kumpera wrote:
> >
> > 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
> >
> I, for one, would prefer the library on the mono svn if it is going to have
> the unofficial nod, but I'm going to see what the others here that wanted a
> similar library have to say.
> --
> View this message in context:
> http://www.nabble.com/simd%3A-more-accelerated-classes-tp21442105p21447449.html
> Sent from the Mono - Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090114/b09f9c4e/attachment.html 