[Mono-list] Mono.Simd - Phylosophical comments

[efortin]

Rodrigo Kumpera wrote:
> 
> 
>>
>> 1) Why calling it something that ties it to the underlying technology
>> used?
>> Why not calling it Mono.Math.Advanced, or Mono.Math.Vectors, or
>> Mono.Math.Matrix? It doesn't have a big impact and it's just a question
>> of
>> taste I guess, but I find that Mono.Simd relates too much to the
>> implementation technology.
> 
> The idea is to expose the Single Instruction Multiple Data extensions of
> modern cpus.
> It's not specific to vector or matrix math as it can be used with
> cryptography and image
> processing with the same degree of success.
> 
> 

With your explanation, now I understand better the scope of this effort.
It'll be building blocks for higher level libraries to build on. However, I
would still make it less tightly linked with the underlying hardware. Two
examples : AccelMode mention SSEx. I would rater take an abstract approach
and make, for example, an "Hardware Acceleration Capabilities Flags" (packed
byte addition, packed float additions). A certain "signature" would be
equivalent to a certain SSEx version. However, these flags would be usable
for any SIMD technology (x86, Altivec, Larabee, and any other in the
future). Maybe hard to factorize these capabilities though.

Second example is the types themselves. They make assumption of 128-bits
wide SSE units, very specific to a particular technology. But what about
256-bits units (Larabee for example)? What about Altivec? What about the
Cell processor (why not)? What about GPGPU (why not as well)? That's why I
was talking about generics and making it abstract enough to hide these
things and open-up the vector hardware of modern processing units. 


Rodrigo Kumpera wrote:
> 
> 
> Generics would pose some of very complicated problems to solve, such as
> the default implementation (can't do math over generic arguments), and
> confusion
> with the users as to what would get accelerated or not. The second issue
> is
> due to the
> fact that not all operations are available for all element types and the
> vector unit is 128 bits
> long - so a Vector16<double> would not flight.
> 
> 

I think there'll be confusion anyway as not all users will have the same
hardware in the current state of how the library is made. So not all the
same methods will be accelerated. Besides, there's already a facility to get
if a method is accelerated or not in Mono.Simd as it is right now. The same
could be used. 

As for your example, a Vector16<double> may not flight, but the Vector16<T>
type can do with the hardware it has to accelerate it as much as it can,
doing multiple passes if needed. Personally, but I'm still no expert in the
backbone of the Mono runtime, I don't see any big issue. 


Rodrigo Kumpera wrote:
> 
> 
>> 3) I would add more high level constructs like Matrix that make use of
>> the
>> SIMD hardware.
>>
> 
> We first need to expose a rich and usable set of intrinsics to what SSE
> currently has.
> Once we do finish with that, we might look at exposing more high level
> functionality.
> 
> On the other hand, such experimentation should happens outside of
> Mono.Simd
> to be
> more agile and not bound to mono's own release schedule.
> 
> 

Understood, and I'm perfectly in sync with that. 


Etienne

-- 
View this message in context: http://www.nabble.com/Mono.Simd---Phylosophical-comments-tp20503986p20543815.html
Sent from the Mono - General mailing list archive at Nabble.com.