On Sun, Feb 14, 2010 at 1:38 PM, Erven Rohou <erven.ro...@inria.fr> wrote:
> Hi Rodrigo, > > Do you mean that Mono.Simd if for SSE only? > Mono.Simd is meant to work with other hardware than x86. There are efforts to port it to Altivec and NEON. The point is that there is no advantage in using an operation that can't be properly supported by the target cpu. I expect that, for example, the Altivec support will result into a few new methods been added that won't have a decent translation with SSE. Multiplication is an example of operations that there is no point in adding if there is no hardware that supports it. No matter how well our JIT does, it will be very slow if there is no reasonable translation into what the hardware supports. If there is a reasonable, even if not optimal, translation of a given function, there is not reason why mono's JIT won't do it. > > There is an ongoing effort to support AltiVec. What would be the right way > to support it in the library? > The way to support it is to add specific operations that are Altivec only and then check if it's doable to implement them with SSE. > > Wouldn't it make sense to provide generic functionality at the library > level, and then the JIT generates the best code sequence on any platform? > > We thought about that during the initial development of Mono.Simd and a few issues were raised: -There was no available similar library offering x-arch generic functionally to us learn from; -We had no expert in all the main simd hardware (x86, neon and altivec) to help us; -Our initial target was x86/amd64. We decided that is was better to initially map only to SSE and fix the design once other port happened. It was better to something out that nothing at all. Mono.SIMD is meant to be a low level library and we don't expect that much code will be portable across hardware because if the idea is to squeeze maximum performance, there will be multiple versions of the same method, depending on what it's running on. I don't pretend to know the answer for what will be the generic portable set of functionality so I rather wait to see it emerges.
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list