[Mono-dev] Incoming changes to Mono.Simd

Hurliman, John john.hurliman at intel.com
Wed Dec 3 12:12:24 EST 2008


> -----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: Wednesday, December 03, 2008 8:19 AM
> To: mono-devel-list at lists.ximian.com
> Subject: [Mono-dev] Incoming changes to Mono.Simd
> 
> After some discussions with Mark we decided to do a few changes to 
> Mono.Simd and it would be really nice to have some feedback from 
> everyone on them.
> 
> One of the motivation is that the current C# of Mono.Simd is not 
> endianess safe and doesn't work as expected on platforms such as ppc.
> The other is to advance the quality of the API.
> 
> The first change is to remove byte oriented methods from all vector 
> types that don't work on byte quantities.
> 
> Right now the only method is ExtractByteMask which is mostly used 
> together with compare ops and will be replaced  with proper operator 
> overloads.
> 
> The second change is actually a clarification, Mono.Simd have some 
> arch dependent methods such as casting between vector types that are 
> endian unsafe. The alternative would be to define those methods to 
> have little-endian semantics and, latter on, when we add support to a
> big- endian arch revert this decision.
> 
> The last one is a call if extension methods should be used or not.
> Extensions methods will make coding with vector types quite a bit 
> simpler as a lot less typing will be needed. For example, 
> "Vector8us.AddWithSaturation (a, b)" would become "a.AddWithSaturation 
> (b)". Right now we already expose some extension methods for 
> interoperability with arrays.
> 
> There are two issues with extension methods, first that it requires C# 
> 3.0 and .NET 3.5 if you want your code to compile for it.
> AFAIK this is no big deal as those methods would still be available 
> under C# 2.0. The second issue is a limitation of the C# language, 
> which require extension methods to be defined of sealed classes. This 
> would mean that code written against mono 2.2 version of Mono.Simd 
> might not compiler with newer versions.
> 
> Keeping both versions of the methods is an option as well, but I'm not 
> very keen on the extra bloat imposed. Either way, I would love to rear 
> feedback from people evaluating or using Mono.Simd.
> 
> 
> Cheers,
> Rodrigo
> 

I think more extension methods would be a nice addition to Mono.Simd. I'm pretty sure everyone who is using Mono.Simd at this point is prepared for bugs, quirks, and breaking API changes.

John


More information about the Mono-devel-list mailing list