Hi Russel, Our initial goal is to make simd instructions available to managed code. At first we thought about trying to make an instruction set agnostic library, but there are way too many quirks and differences between them that the result could be too crippled to be usable.
There are quite many valid use cases for having the whole sse instruction set available and these are what we are targeting now. But then, this was an analysis based on the fact that no well known compiler/runtime exposes such library (arch agnostic simd), they always have a binding to a specific platform. This doesn't mean we just won't do it. Once we have, for example, Altivec and VFP supported if an usable common subset emerge, we'll work on making it available. Now back to the Acceleration attribute. It's meant to support not only sse, but others as well, they are not present for the simple reason that we didn't have the time for it. Anyway, the attribute right now should be considered an implementation detail and if it shows to be a problem in cases such as the one you describe we'll change it. Keep in mind that the current design is not final, but at the same time it's hard to change it based on assumptions. Thanks for the feedback, Rodrigo On Mon, Nov 10, 2008 at 10:04 AM, <[EMAIL PROTECTED]> wrote: > 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:* [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] *On Behalf Of *Rodrigo Kumpera > *Sent:* 07 November 2008 15:15 > *To:* Christophe Guillon > *Cc:* mono-devel-list@lists.ximian.com > *Subject:* Re: [Mono-dev] Mono.Simd Acceleration Attributes > > > > Hi Christophe, > > 2008/11/7 Christophe Guillon <[EMAIL PROTECTED]> > > 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. >
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
