Adaptive Filter | ADPCM | ADSP | ADSP-2181 | Aliasing | AMR | Anti-Aliasing | ARMA | Autocorrelation | AutoCovariance | Beamforming | Bessel | Blackfin | Butterworth | C6713 | CCS | Chebyshev | CIC Filter | Circular Convolution | Code Composer Studio | Comb Filter | Compression | Convolution | Cross Correlation | DCT | Decimation | Deconvolution | Demodulation | DM642 | DSP Boards | DSP/BIOS | DTMF | Echo Cancellation | Equalization | Equalizer | ETSI | EZLITE (Ez-kit Lite) | FFT | FFTW | FIR Filter | Fixed Point | FSK | G.711 | G.723 | G.729 | Gaussian Noise | Goertzel | GPIO | Hilbert Transform | IFFT | IIR Filter | Interpolation | Invariance | JTAG | Kalman | Laplace Transform | Levinson | LPC | McBSP | MIPS | Modulation | MPEG | Multirate | Notch Filter | Nyquist | OFDM | Oversampling | Pink Noise | Pitch | PLL | Polyphase | QAM | QDMA | Quantization | Quantizer | Radar | Random Noise | Reed Solomon | Remez | Resampling | RTDX | Sampling | Sharc | TI C6711 | Undersampling | Viterbi | Wavelets | White Noise | Wiener Filter | Windowing | XDS510PP | Z Transform

All,

I need to write some code that is portable in C to do some signal
processing. I've only used MATLAB in the past.

Can someone give me some insight into using BLAS. Would it be a better
choice to use a vendor optimized version of BLAS, or should I use VSIPL?

Any discussion would be great here. Even if it is someones experience with
BLAS or VSIPL.


I was told to use VSIPL because it is very portable. However, I am looking
through the API and it looks like a pain. I don't know what the benefits
would be using this, compared to using a vendor optimized BLAS. It seems
like the vendor BLAS would be much faster, and would also be very
portable.


Any thoughts?

______________________________
DSPRelated.com's 50,000th member announced! Details Here.

On 4 Jul, 00:15, "mbaran" <matthew.t.ba...@lmco.com> wrote:
> All,
>
> I need to write some code that is portable in C to do some signal
> processing. I've only used MATLAB in the past.
>
> Can someone give me some insight into using BLAS. Would it be a better
> choice to use a vendor optimized version of BLAS, or should I use VSIPL?
>
> Any discussion would be great here. Even if it is someones experience with
> BLAS or VSIPL.
>
> I was told to use VSIPL because it is very portable. However, I am looking
> through the API and it looks like a pain. I don't know what the benefits
> would be using this, compared to using a vendor optimized BLAS. It seems
> like the vendor BLAS would be much faster, and would also be very
> portable.
>
> Any thoughts?

In the mid '90s I tried to use LAPACK with C. LAPACK
is built on top of BLAS, so extrapolate my experiences
with LAPACK as below, at your own risk.

LAPACK is (was) writen for use with FORTRAN. Both C and
FORTRAN are compiled languages, which means that source
is compiled to object code, which in turn is linked to
executable code.

The problem I found was that C and FORTRAN use different
conventions when converting names of source code functions
to corresponding items in the object code.

On some systems, the function name 'foo' becomes '_foo'
(only leading underscore) in object code compiled from C,
and '_foo_' (both leading and trailing underscores) when
compiled from FORTRAN code.

Worse, the FORTRAN conventions vary from system to
system, meaning that portability and maintenance
becomes a nightmare.

So whoever told you not to use BLAS might have a point.

Rune

______________________________
DSPRelated.com's 50,000th member announced! Details Here.

On Jul 3, 6:15=A0pm, "mbaran" <matthew.t.ba...@lmco.com> wrote:
> All,
>
> I need to write some code that is portable in C to do some signal
> processing. I've only used MATLAB in the past.
>
> Can someone give me some insight into using BLAS. Would it be a better
> choice to use a vendor optimized version of BLAS, or should I use VSIPL?
>
> Any discussion would be great here. Even if it is someones experience wit=
h
> BLAS or VSIPL.
>
> I was told to use VSIPL because it is very portable. However, I am lookin=
g
> through the API and it looks like a pain. I don't know what the benefits
> would be using this, compared to using a vendor optimized BLAS. It seems
> like the vendor BLAS would be much faster, and would also be very
> portable.
>
> Any thoughts?

Here's another option:

http://eigen.tuxfamily.org/index.php?title=3DMain_Page

John

______________________________
DSPRelated.com's 50,000th member announced! Details Here.

On Jul 3, 3:15 pm, "mbaran" <matthew.t.ba...@lmco.com> wrote:
> ...
> I was told to use VSIPL because it is very portable. However, I am looking
> through the API and it looks like a pain.

API's should be as simple as they can be and no simpler.

Consider whether the API complexity is about application programmer
convenience or providing information to support optimization in
different implementations..

> I don't know what the benefits
> would be using this, compared to using a vendor optimized BLAS. It seems
> like the vendor BLAS would be much faster, and would also be very
> portable.
> ...

Don't mistake the demo version of VSIPL (which is intended to merely
produce the proper outputs in response to the standard VSIPL API
inputs) for the optimized implementations available from commercial
vendors for whatever architectures are supported.

BLAS also has a reference implementation.

Dale B. Dalrymple

______________________________
DSPRelated.com's 50,000th member announced! Details Here.

>On Jul 3, 3:15 pm, "mbaran" <matthew.t.ba...@lmco.com> wrote:
>> ...
>> I was told to use VSIPL because it is very portable. However, I am
looking
>> through the API and it looks like a pain.
>
>API's should be as simple as they can be and no simpler.
>
>Consider whether the API complexity is about application programmer
>convenience or providing information to support optimization in
>different implementations..
>
>> I don't know what the benefits
>> would be using this, compared to using a vendor optimized BLAS. It
seems
>> like the vendor BLAS would be much faster, and would also be very
>> portable.
>> ...
>
>Don't mistake the demo version of VSIPL (which is intended to merely
>produce the proper outputs in response to the standard VSIPL API
>inputs) for the optimized implementations available from commercial
>vendors for whatever architectures are supported.
>
>BLAS also has a reference implementation.
>
>Dale B. Dalrymple
>
>


Would you recommend VSIPL over BLAS, AMD's math library, or the Sun
Performance Library? 

According to this website
(http://www.unmaintained-free-software.org/wiki/VSIPL) the VSIPL website
has not been updated since 2003. 

I mean is VSIPL going to be around for awhile? 

______________________________
DSPRelated.com's 50,000th member announced! Details Here.

On Jul 6, 12:20 pm, "mbaran" <matthew.t.ba...@lmco.com> wrote:
> >On Jul 3, 3:15 pm, "mbaran" <matthew.t.ba...@lmco.com> wrote:
> >> ...
> >> I was told to use VSIPL because it is very portable. However, I am
> looking
> >> through the API and it looks like a pain.
>
> >API's should be as simple as they can be and no simpler.
>
> >Consider whether the API complexity is about application programmer
> >convenience or providing information to support optimization in
> >different implementations..
>
> >> I don't know what the benefits
> >> would be using this, compared to using a vendor optimized BLAS. It
> seems
> >> like the vendor BLAS would be much faster, and would also be very
> >> portable.
> >> ...
>
> >Don't mistake the demo version of VSIPL (which is intended to merely
> >produce the proper outputs in response to the standard VSIPL API
> >inputs) for the optimized implementations available from commercial
> >vendors for whatever architectures are supported.
>
> >BLAS also has a reference implementation.
>
> >Dale B. Dalrymple
>
> Would you recommend VSIPL over BLAS, AMD's math library, or the Sun
> Performance Library?
>
> According to this website
> (http://www.unmaintained-free-software.org/wiki/VSIPL) the VSIPL website
> has not been updated since 2003.
>
> I mean is VSIPL going to be around for awhile?

What site? At
http://www.vsipl.org/
it says:
"Last Updated April 23, 2009"

Development seems to be continuing:
http://www.hpec-si.org/workshop27.html

You might check with the vendors listed at vsipl.org to see  what
their plans are for VSIPL.

Dale B. Dalrymple

______________________________
DSPRelated.com's 50,000th member announced! Details Here.

>On Jul 6, 12:20 pm, "mbaran" <matthew.t.ba...@lmco.com> wrote:
>> >On Jul 3, 3:15 pm, "mbaran" <matthew.t.ba...@lmco.com> wrote:
>> >> ...
>> >> I was told to use VSIPL because it is very portable. However, I am
>> looking
>> >> through the API and it looks like a pain.
>>
>> >API's should be as simple as they can be and no simpler.
>>
>> >Consider whether the API complexity is about application programmer
>> >convenience or providing information to support optimization in
>> >different implementations..
>>
>> >> I don't know what the benefits
>> >> would be using this, compared to using a vendor optimized BLAS. It
>> seems
>> >> like the vendor BLAS would be much faster, and would also be very
>> >> portable.
>> >> ...
>>
>> >Don't mistake the demo version of VSIPL (which is intended to merely
>> >produce the proper outputs in response to the standard VSIPL API
>> >inputs) for the optimized implementations available from commercial
>> >vendors for whatever architectures are supported.
>>
>> >BLAS also has a reference implementation.
>>
>> >Dale B. Dalrymple
>>
>> Would you recommend VSIPL over BLAS, AMD's math library, or the Sun
>> Performance Library?
>>
>> According to this website
>> (http://www.unmaintained-free-software.org/wiki/VSIPL) the VSIPL
website
>> has not been updated since 2003.
>>
>> I mean is VSIPL going to be around for awhile?
>
>What site? At
>http://www.vsipl.org/
>it says:
>"Last Updated April 23, 2009"
>
>Development seems to be continuing:
>http://www.hpec-si.org/workshop27.html
>
>You might check with the vendors listed at vsipl.org to see  what
>their plans are for VSIPL.
>
>Dale B. Dalrymple
>
>


I appreciate the responses. I can't believe I missed the "...Updated ...
2009".

______________________________
DSPRelated.com's 50,000th member announced! Details Here.

In article <03b6b3a8-cd50-4ae0-bf5f-
4...@g1g2000yqh.googlegroups.com>, a...@tele.ntnu.no says...

>
>In the mid '90s I tried to use LAPACK with C. LAPACK
>is built on top of BLAS, so extrapolate my experiences
>with LAPACK as below, at your own risk.
>
>LAPACK is (was) writen for use with FORTRAN. Both C and
>FORTRAN are compiled languages, which means that source
>is compiled to object code, which in turn is linked to
>executable code.
>
>The problem I found was that C and FORTRAN use different
>conventions when converting names of source code functions
>to corresponding items in the object code.
>
>On some systems, the function name 'foo' becomes '_foo'
>(only leading underscore) in object code compiled from C,
>and '_foo_' (both leading and trailing underscores) when
>compiled from FORTRAN code.
>
>Worse, the FORTRAN conventions vary from system to
>system, meaning that portability and maintenance
>becomes a nightmare.
>
>So whoever told you not to use BLAS might have a point.

FWIW, as a result of popular demand, the latest version of Fortran formalizes 
c interoperability.

______________________________
DSPRelated.com's 50,000th member announced! Details Here.

On 9 Jul, 04:27, Robert Orban <donotre...@spamblock.com> wrote:
> In article <03b6b3a8-cd50-4ae0-bf5f-
> 44ab9e350...@g1g2000yqh.googlegroups.com>, all...@tele.ntnu.no says...
>
>
>
>
>
>
>
> >In the mid '90s I tried to use LAPACK with C. LAPACK
> >is built on top of BLAS, so extrapolate my experiences
> >with LAPACK as below, at your own risk.
>
> >LAPACK is (was) writen for use with FORTRAN. Both C and
> >FORTRAN are compiled languages, which means that source
> >is compiled to object code, which in turn is linked to
> >executable code.
>
> >The problem I found was that C and FORTRAN use different
> >conventions when converting names of source code functions
> >to corresponding items in the object code.
>
> >On some systems, the function name 'foo' becomes '_foo'
> >(only leading underscore) in object code compiled from C,
> >and '_foo_' (both leading and trailing underscores) when
> >compiled from FORTRAN code.
>
> >Worse, the FORTRAN conventions vary from system to
> >system, meaning that portability and maintenance
> >becomes a nightmare.
>
> >So whoever told you not to use BLAS might have a point.
>
> FWIW, as a result of popular demand, the latest version of Fortran formalizes
> c interoperability.

I hope you are right. Still, it will take time for vendors
to comply, since one would need to find a way to handle
legacy code. 50 years worth of random decisions are not
undone quickly.

Rune

______________________________
DSPRelated.com's 50,000th member announced! Details Here.