[Mono-dev] [PATCH] Optimize Mono.Simd non-accelerated bitwise-ops

Cedric Vivier cedricv at neonux.com
Wed Nov 12 08:58:20 EST 2008


Hey again,

Thanks for your answers, committed patch this morning.
Also would you mind adding indexers to - at least - Vector16*, whose
final individual elements are quite cumbersome to retrieve using .V0
to .V15 properties.

Attached patch adds an indexer to these.
If you are okay with the patch can add indexers for other Vector types
if it makes sense.

Regards,


On Wed, Nov 12, 2008 at 4:54 AM, Rodrigo Kumpera <kumpera at gmail.com> wrote:
> Hi Cedric,
>
>
>
> On Mon, Nov 10, 2008 at 3:50 AM, Cedric Vivier <cedricv at neonux.com> wrote:
>>
>> Hi Rodrigo,
>>
>> While playing with Mono.Simd on a (for now ;( ) non-accelerated x86-64
>> setup [1], I've
>> noticed that performance of bitwise-ops on Vector16b and others could
>> be improved.
>>
>> This patch implements these ops as two 64-bit bitwise ops [2] instead
>> of processing
>> each vector element separately. Giving up to 4X perf increase for
>> Vector16(s)b and 2X for others.
>>
>> Please review,
>
> The patch looks fine, please commit.
>
>>
>> 1: any plans about enabling acceleration on x86-64 soon?
>
> Soon? No. But I wish to have a x86-64 preview for the 2.4 release.
> Right now everyones attention is in the 2.2 release, so no work
> will be done on the port.
>
>>
>>
>> 2: using two ulong obviously gives the best perf on x86-64, I have no
>> 32-bit setup handy
>> to test if it would give significantly better perf using four uint
>> instead on them (at the expense of 64-bit platforms though if it
>> would).
>
> The code under 32bits won't be significantly worse by using ulong.
> The penalty is not significant enough.
>
>
> Thanks,
> Rodrigo
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-WIP-on-branch-SIMD.patch
Type: text/x-diff
Size: 2499 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081112/1417d8d7/attachment-0001.bin 


More information about the Mono-devel-list mailing list