[Mono-dev] simd: more accelerated classes

crashfourit crashfourit at gmail.com
Tue Jan 13 19:09:26 EST 2009




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.



More information about the Mono-devel-list mailing list