VSIPL

[Chris]

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)

 

[Mark McIntyre]

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.

Chris
unfortunately this is most definitely not a C question, but something
specific about the VSIPL library.

You need to find a group that specialises in vector signal processing, or
perhaps visit the VSIPL fora at www.vsipl.org Its wildly offtopic here.

 

[Joona I Palaste]

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

If there are, here's not the proper place to discuss it. VSIPL,
whatever that is, is not a feature of the C language, but instead a
non-standard extension. Please ask in another newsgroup.

(Snip VSIPL question)

 

[E. Robert Tisdale]

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.

It might be.

My guess is that you are using Randy Judd's "Reference Library"
that you downloaded from the Vector Signal Image Processing Library
(VSIPL) web site:

http://www.vsipl.org/

The reference library is hardly optimized at all.
It serves only to help VSIP library developers
verify their own optimized implementations of the VSIPL API.

You have two options:

1. Fork up the bucks for an optimized VSIPL from one of the vendors or
2. write your own optimized version.

 

[Chris]

It might be.

My guess is that you are using Randy Judd's "Reference Library"
that you downloaded from the Vector Signal Image Processing Library
(VSIPL) web site:

http://www.vsipl.org/

The reference library is hardly optimized at all.
It serves only to help VSIP library developers
verify their own optimized implementations of the VSIPL API.

You have two options:

1. Fork up the bucks for an optimized VSIPL from one of the vendors or
2. write your own optimized version.

Actually using the MPI, but thanks.

Sorry for posting off-topic. Was getting kind of desperate and
finding little help elsewhere. This VSIPL is interesting stuff!

Chris.

 

[E. Robert Tisdale]

Sorry for posting off-topic.
Was getting kind of desperate and finding little help elsewhere.
This VSIPL is interesting stuff!

I'm glad that you like it.
And I hope that you can make money writing applications
that use the VSIPL API.