[Mono-dev] simd: more accelerated classes
crashfourit
crashfourit at gmail.com
Tue Jan 13 19:15:27 EST 2009
Good point, what about sourceforge?
Alan McGovern-2 wrote:
>
> 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
>>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
--
View this message in context: http://www.nabble.com/simd%3A-more-accelerated-classes-tp21442105p21447546.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
More information about the Mono-devel-list
mailing list