Vector, Signal and Image Processing Library

Is anyone here doing anything with VSIPL?

I've been working on a VSIPL project for a few months now, looking at
developing a commercial implementation. I've been looking mostly at the
system design issues and the hardware specifics. I reckoned it was
maybe about time to take another look at the motivations and I'm trying
to get more of a feel for what's happening with this standard at this
point in time.

If you go looking on the internet for what people think of VSIPL, you
don't hit on a lot of stuff. There are a good few discussions from a
couple of years ago talking about VSIPL as something that never
happened. Another failed standard.

However, interest in the standard seems to be growing again. My project
for example, and this appeared in september:

http://www.dna-cs.com/pdf/datasheet_vsipl.pdf

At the MAPLD conference in Washington in September I spoke to a number
of people in industry who were very interested in VSIPL, senior
scientists at the Air Force Research Laboratory for example. I
understand that Lockheed Martin have also shown a strong interest in
VSIPL implementation development.

Any thoughts?

Yes, we have used VSIPL.

The main reason for us to use it was to provide portability. Specific 
optimized libraries for VSIPL were difficult to find for some common 
procssors (Pentium and Opteron). We've used it for the G4 and G5 
PowerPCs since they were readily available.

As for the standard - It really isn't a good library from the interface 
point of view. You end up creating a lot of Views to your data without 
descriptive names - which makes understanding and debugging code a real 
pain.

You cannot write you own VSIPL type functions and have good performance 
- there is too much overhead in getting the data in to and out of the 
VSIPL world.

To me it appears to be a standard done by a committee - I don't think 
anyone there has really though about how the library would be used.

The C++ bindings are a complete joke. They don't use any object 
orientation at all.

If we had a real choice on another library for portable code we wouldn't 
have used VSIPL.

Cheers,
David

robin.bruce@gmail.com wrote:
> Is anyone here doing anything with VSIPL?
> 
> I've been working on a VSIPL project for a few months now, looking at
> developing a commercial implementation. I've been looking mostly at the
> system design issues and the hardware specifics. I reckoned it was
> maybe about time to take another look at the motivations and I'm trying
> to get more of a feel for what's happening with this standard at this
> point in time.
> 
> If you go looking on the internet for what people think of VSIPL, you
> don't hit on a lot of stuff. There are a good few discussions from a
> couple of years ago talking about VSIPL as something that never
> happened. Another failed standard.
> 
> However, interest in the standard seems to be growing again. My project
> for example, and this appeared in september:
> 
> http://www.dna-cs.com/pdf/datasheet_vsipl.pdf
> 
> At the MAPLD conference in Washington in September I spoke to a number
> of people in industry who were very interested in VSIPL, senior
> scientists at the Air Force Research Laboratory for example. I
> understand that Lockheed Martin have also shown a strong interest in
> VSIPL implementation development.
> 
> Any thoughts?
> 

On Thu, 13 Oct 2005 19:21:08 -0400, David Kirkland wrote:

> Yes, we have used VSIPL.
> 
> The main reason for us to use it was to provide portability. Specific 
> optimized libraries for VSIPL were difficult to find for some common 
> procssors (Pentium and Opteron). We've used it for the G4 and G5 
> PowerPCs since they were readily available.
> 
> As for the standard - It really isn't a good library from the interface 
> point of view. You end up creating a lot of Views to your data without 
> descriptive names - which makes understanding and debugging code a real 
> pain.
> 
> You cannot write you own VSIPL type functions and have good performance 
> - there is too much overhead in getting the data in to and out of the 
> VSIPL world.
> 
> To me it appears to be a standard done by a committee - I don't think 
> anyone there has really though about how the library would be used.
> 
> The C++ bindings are a complete joke. They don't use any object 
> orientation at all.
> 
> If we had a real choice on another library for portable code we wouldn't 
> have used VSIPL.

Out of interest: if you're targetting high-end PC-type processors, what
was it in the VSIPL library that you needed?  I haven't done the
third-party library thing myself, much, so I'm asking from a perspective
of ignorance.  Was it something that wasn't available in a more
traditional BLAS or LAPAC library, such as netlib or ATLAS?

The one time, years ago, that I used a third-party library was when I
needed an SVD/Pseudo-inverse to productize some Matlab code.  When we
eventually moved to an incompatible OS and had to replace that piece of
code we just spent the time (not much, in the grand scheme of things) to
port the code from Golub and van Loan (which is in Matlab itself, rather
than C). Now that function can go wherever we need it to.

My impression of VSIPL, from the brief look at it that I gave it, years
ago, was that it hoped to shield "application layer" code from the
optimized compute code, even in the case where the compute code had to
live somewhere unfriendly, like a multiple-memory-space DSP, perhaps even
fixed-point ones.  For my purposes (at the time) the "view" overhead was
obviously going to make it impossible.

Thanks for your observations.

Cheers,

-- 
Andrew

Thanks for your replies guys.

I've not really got much of an opinion on VSIPL, having never even seen
a real application program.

The aim off my project is to implement the core profile of the VSIPL
library using FPGAs as the principal processing element. A big task I'd
say, but I like to think I'm not gambling on VSIPL being a great
library or otherwise. I believe that the lessons learned from this
project would apply to the porting of other libraries to VSIPL

I'm interested in hearing your criticisms of VSIPL in greater detail.
The block/view thing is something that is very prominent in VSIPL. What
exactly is the interest in this? Everyone seems to lament it. I'm
certainly going to have to redo a few things to get round it.

David, when you talk about C++ bindings, what are you referring to? Is
this anything to do with the VSIPL++ extension?

Cheers,

Robin

Andrew Reilly wrote:
> On Thu, 13 Oct 2005 19:21:08 -0400, David Kirkland wrote:
> 
> 
>>Yes, we have used VSIPL.
>>
>>The main reason for us to use it was to provide portability. Specific 
>>optimized libraries for VSIPL were difficult to find for some common 
>>procssors (Pentium and Opteron). We've used it for the G4 and G5 
>>PowerPCs since they were readily available.
>>
>>As for the standard - It really isn't a good library from the interface 
>>point of view. You end up creating a lot of Views to your data without 
>>descriptive names - which makes understanding and debugging code a real 
>>pain.
>>
>>You cannot write you own VSIPL type functions and have good performance 
>>- there is too much overhead in getting the data in to and out of the 
>>VSIPL world.
>>
>>To me it appears to be a standard done by a committee - I don't think 
>>anyone there has really though about how the library would be used.
>>
>>The C++ bindings are a complete joke. They don't use any object 
>>orientation at all.
>>
>>If we had a real choice on another library for portable code we wouldn't 
>>have used VSIPL.
> 
> 
> Out of interest: if you're targetting high-end PC-type processors, what
> was it in the VSIPL library that you needed?  I haven't done the
> third-party library thing myself, much, so I'm asking from a perspective
> of ignorance.  Was it something that wasn't available in a more
> traditional BLAS or LAPAC library, such as netlib or ATLAS?
> 
> The one time, years ago, that I used a third-party library was when I
> needed an SVD/Pseudo-inverse to productize some Matlab code.  When we
> eventually moved to an incompatible OS and had to replace that piece of
> code we just spent the time (not much, in the grand scheme of things) to
> port the code from Golub and van Loan (which is in Matlab itself, rather
> than C). Now that function can go wherever we need it to.
> 
> My impression of VSIPL, from the brief look at it that I gave it, years
> ago, was that it hoped to shield "application layer" code from the
> optimized compute code, even in the case where the compute code had to
> live somewhere unfriendly, like a multiple-memory-space DSP, perhaps even
> fixed-point ones.  For my purposes (at the time) the "view" overhead was
> obviously going to make it impossible.
> 
> Thanks for your observations.
> 
> Cheers,
> 

Most of our stuff uses the filtering and FFT's. We could find libraries 
for the types of processors we were looking at, but nothing was 
portable. On our systems we have a signal processing engine consisting 
of multiple processors (usually not Pentium based), and a GUI which is 
done on a standard PC. Some of the algorithms need to run on both the SP 
  Engine and the GUI. Using VSIPL makes the maintenance easier.

For some of the advanced stuff we also use the linear algebra (BLAS) 
based routines.

 From what I've heard most commercial library versions of VSIPL are just 
a wrapper around their already existing vector library.

Cheers,
David

robin.bruce@gmail.com wrote:
> Thanks for your replies guys.
> 
> I've not really got much of an opinion on VSIPL, having never even seen
> a real application program.
> 
> The aim off my project is to implement the core profile of the VSIPL
> library using FPGAs as the principal processing element. A big task I'd
> say, but I like to think I'm not gambling on VSIPL being a great
> library or otherwise. I believe that the lessons learned from this
> project would apply to the porting of other libraries to VSIPL
> 
> I'm interested in hearing your criticisms of VSIPL in greater detail.
> The block/view thing is something that is very prominent in VSIPL. What
> exactly is the interest in this? Everyone seems to lament it. I'm
> certainly going to have to redo a few things to get round it.
> 
> David, when you talk about C++ bindings, what are you referring to? Is
> this anything to do with the VSIPL++ extension?
> 
> Cheers,
> 
> Robin
> 

The Block/View thing will take a bit longer than I have right now to 
explain - I'll try a bit later.

I believe that VSIPL++ is what I was referring to. The bindings (atleast 
when I looked at them - quite awhile ago) did use any OO features - 
which would help simplfy the calls.

As an example currently the type or argument is stuck on the end of the 
function call so you see xxxx_f() (for float) and xxx_d() (for double). 
While this is needed for C it isn't needed for C++, the bindings didn't 
address this at all.

Cheers,
David