VSIPL

[Chris]

[NOTE: I posted this yesterday in comp.lang.c]

Is anybody out there using VSIPL and can confirm my findings please?

I'm experiencing a '20-fold' increase in processing time for a simple
vsip_cvmag_f function when passed a view with stride length of 2.

EG..
viewNonInterlaced = vsip_cvbind_f( block, 0, 2, N );
viewInterlaced = vsip_cvbind_f( block, 0, 1, N );

Times =
vsip_cvmag_f( viewNonInterlaced, viewMag ) = ~480 micro secs
vsip_cvmag_f( viewInterlaced, viewMag ) = ~8000 micro secs, or 8
mSecs!!

Data size = ~40000 complex numbers.
Processor, PPC7410.

All I can presume is that any stride length not equal to '1' is using
non-optimised code, probably written in 'c', in the VSIP library. At
this rate it will be quicker to de-stride the input data before
working.

Thanks
Chris (UK)

[Jerry Avins]

Chris wrote:

> [NOTE: I posted this yesterday in comp.lang.c]
>
> Is anybody out there using VSIPL and can confirm my findings please?
>
> I'm experiencing a '20-fold' increase in processing time for a simple
> vsip_cvmag_f function when passed a view with stride length of 2.
>
> EG..
> viewNonInterlaced = vsip_cvbind_f( block, 0, 2, N );
> viewInterlaced = vsip_cvbind_f( block, 0, 1, N );
>
> Times =
> vsip_cvmag_f( viewNonInterlaced, viewMag ) = ~480 micro secs
> vsip_cvmag_f( viewInterlaced, viewMag ) = ~8000 micro secs, or 8
> mSecs!!
>
> Data size = ~40000 complex numbers.
> Processor, PPC7410.
>
> All I can presume is that any stride length not equal to '1' is using
> non-optimised code, probably written in 'c', in the VSIP library. At
> this rate it will be quicker to de-stride the input data before
> working.
>
> Thanks
> Chris (UK)

OH, where is eBob when you need him!

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯