[Mono-dev] Mono.Simd.dll and operator*

[Rodrigo Kumpera]

On Sun, Feb 14, 2010 at 1:38 PM, Erven Rohou <erven.rohou at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20100217/dc738f62/attachment.html