[Mono-dev] Mono.Simd Acceleration Attributes

russell.kay at realtimeworlds.com russell.kay at realtimeworlds.com
Mon Nov 10 07:04:38 EST 2008


Rodrigo,

 

My only problem with this is the language is tied to the x86
architecture, when Altivec or Paired Single  etc are added for PowerPC
then these attributes are nonsensical and will mean nothing to the user.
This would be better done in a static location (rather than spread over
the libraries) and split into a machine agnostic (Simd acceleration ON)
and a machine specific manner (sse1 - 4.2 active).

 

My 2c


Russell

 

________________________________

From: mono-devel-list-bounces at lists.ximian.com
[mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Rodrigo
Kumpera
Sent: 07 November 2008 15:15
To: Christophe Guillon
Cc: mono-devel-list at lists.ximian.com
Subject: Re: [Mono-dev] Mono.Simd Acceleration Attributes

 

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

____________________________________________________________________
This email has been scanned by the MessageLabs Email Security System


____________________________________________________________________
DISCLAIMER

This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd.

 

Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081110/fb8bed69/attachment.html 


More information about the Mono-devel-list mailing list