[Mono-dev] Mono.Simd Acceleration Attributes

[Rodrigo Kumpera]

Hi Christophe,


2008/11/7 Christophe Guillon <christophe.guillon.perso at gmail.com>

> Thank you for the explanation. It confirms my point and it seems that we
> agree.
>
> For the user guide aspect:
> >2) the attributes on the methods are never inspected by the runtime:
> >they are there to guide the programmers using Mono.Simd in determining
> >what kind of optimizations are usually available or currently enabled.
> If it is indeed "just" a guide to the user of Mono.Simd, thus why putting
> it in the library and coupling this with the specific architecture (SSE2 or
> other). The fact that it is an AddWithSaturation on a Vector16b is
> sufficient for the semantic. Then a note in the mono VM documentation can
> tell that on SSE2 architectures -O=simd will select the corresponding SSE2
> op is sufficient. Optionaly a note in the library documentation can tell
> that mono "normally" should catch such calls on SSE2 architectures.


We want to expose this information on the documentation as well and instead
of having to dig this information twice we are planning on generating this
part of the docs.



>
>
> For the choice of the accelerated or not accelerated mode at runtime:
> >       static readonly bool use_mono_simd = (SimdRuntime.AccelMode &
> AccelMode.SSE2) != >0;
> >      ...
> >       if (use_mono_simd)
> >               // simd codepath
> >       else
> >               //scalar codepath
> If it is actually to overcome a temporary inneficiency due to some copy, it
> is imho far too intrusive in the user code. Here the user clearly wrote a
> code that is dependent on some "external" context, but instead of querying
> the actual VM runtime, or simply a user defined variable that can be found
> in some configuration file of the application, the query is on the Mono.Simd
> library itself.
> While in fact the library itself as no knowledge of the actual efficiency
> of the running VM.


There are two good reasons for using this approach, the first one is because
the user requires the best performance in all situations and want to know if
it's method will be optimized or not.

The second reason happens when there are many different ways to implement a
given function, each one using different instruction sets and the user wants
to have improved performance on newer processors.

For example, there are 3 ways to implement dot product using Mono.Simd:

1) Only using sse1 and sse2 which takes 5 instructions (1 mul, 2 add and 2
shuffle)
2) Using sse3, which takes 3 instructions (1 mul, 2 hadd)
3) Using sse4.2 which takes 1 instruction (dotp) -- sse4.2 still not
supported by Mono.Simd.

For some users having this option is important and this is the main
objective of the runtime query capabilities.



>
> Thus I fully agree with this (which is my point):
> "Note that we may eventually either return the attribute not based on the
> metadata in the assembly, but based on the runtime understanding: this
> will avoid the need to have an updated Mono.Simd assembly when new
> optimizations are added. Just use the b pattern if you want to avoid
> that issue and remember that you don't usually need to check all the
> methods, but just the ones you actually need to be optimized."
>
> All the question there is, whether or not there is a way to get from the
> runtime this information and by which mean?
> Is it possible to have attributes attached (or simulated) by the runtime?
>
>
The SimdRuntime.AccelMode property queries the runtime for the supported
instruction sets. You might look
at the implementation and get puzzled by the fact that it returns
AccelMode.None, but in fact this is a "magic method"
that the runtime takes special care and make sure it returns the right
thing.


Thanks for taking your time looking at the Mono.Simd library :)


Cheers,
Rodrigo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081107/d9123049/attachment.html