BLAS vs CBLAS in C++

[nitroamos]

hello --

i'm working on a C++ code that uses dgemm in a simple way, but i want
ports of my code to different machines to be easy.

further, i want to make compiling of my code easy for new users -- i
don't want them to compile more libraries than absolutely necessary
(compiling ATLAS or GotoBLAS is necessary).

i already have my code working with both BLAS and CBLAS interfaces,
but I have some questions.


1) can i expect cblas to be available on pretty much any machine i
want to use? because ATLAS packages CBLAS, it didn't occur to me that
CBLAS might be standard until now.

2) to use blas, I had to switch from using new [] to malloc, and
delete [] to free. why? once allocated, i didn't realize there was a
difference.
is it not possible to use new [] allocated arrays with fortran
libraries?

3) once your code can is programmed to use either, is linking directly
to BLAS preferable in any way to using CBLAS?

thanks!

amos.

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

hello --

i'm working on a C++ code that uses dgemm in a simple way, but i want
ports of my code to different machines to be easy.

further, i want to make compiling of my code easy for new users -- i
don't want them to compile more libraries than absolutely necessary
(compiling ATLAS or GotoBLAS is necessary).

i already have my code working with both BLAS and CBLAS interfaces,
but I have some questions.

You might also be interested in uBlas from Boost, which would remove the
dependency on external libraries (do not know how the compare
performance wise). There is also Lapack++ which provide both BLAS and
LAPACK, once again, I make no guarantees of performance.

1) can i expect cblas to be available on pretty much any machine i
want to use? because ATLAS packages CBLAS, it didn't occur to me that
CBLAS might be standard until now.

I don't have it on any of my computers, however you might be able to
assume that those computers where your program will run will have it, or
perhaps you cannot.

2) to use blas, I had to switch from using new [] to malloc, and
delete [] to free. why? once allocated, i didn't realize there was a
difference.
is it not possible to use new [] allocated arrays with fortran
libraries?

There should not be any problem as long as BLAS does not try to free or
reallocate memory (memory allocated with new[] must be freed with
delete[], using free() will not work). Are you sure it does not work?

3) once your code can is programmed to use either, is linking directly
to BLAS preferable in any way to using CBLAS?

I seem to recall that CBLAS is BLAS converted to C, and I seem to recall
that there are certain features (or lack thereof) in Fortran that allows
for better optimisations in Fortran than C. So it probably depends on
how good your Fortran compiler is compared to your C compiler.

 

[Lionel B]

hello --

i'm working on a C++ code that uses dgemm in a simple way, but i want
ports of my code to different machines to be easy.

[...]

3) once your code can is programmed to use either, is linking directly
to BLAS preferable in any way to using CBLAS?

I seem to recall that CBLAS is BLAS converted to C,

I think, rather, it's just a set of C wrappers for the (Fortran) BLAS
functions, so you should not see any performance difference at all.

[...]

 

[nitroamos]

i would expect that for large enough matrices, there would be no
performance difference between BLAS and CBLAS since the overhead of
calling libraries would be amortized.

however, if CBLAS is not available and my code relies on it, then a
user might be stuck having to compile it. and that is more work than i
want them to have to do.

basically, i put in the effort to program direct BLAS links, and I'm
trying to find excuses to convince myself that i didn't waste my
effort!

amos.

hello --
i'm working on a C++ code that uses dgemm in a simple way, but i want
ports of my code to different machines to be easy.

[...]

3) once your code can is programmed to use either, is linking directly
to BLAS preferable in any way to using CBLAS?

I seem to recall that CBLAS is BLAS converted to C,

I think, rather, it's just a set of C wrappers for the (Fortran) BLAS
functions, so you should not see any performance difference at all.

[...]

 

[nitroamos]

There should not be any problem as long as BLAS does not try to free or
reallocate memory (memory allocated with new[] must be freed with
delete[], using free() will not work). Are you sure it does not work?

I've gone back to investigate this issue, and the problem has
disappeared. I can use either memory allocation/deallocation method
with no problem.

 

[Lionel B]

On Tue, 04 Sep 2007 17:27:54 +0000, nitroamos wrote:

Please don't top-post [rearranged]

On 2007-09-04 01:12, (e-mail address removed) wrote:
hello --

i'm working on a C++ code that uses dgemm in a simple way, but i
want ports of my code to different machines to be easy.
[...]

3) once your code can is programmed to use either, is linking
directly to BLAS preferable in any way to using CBLAS?

I seem to recall that CBLAS is BLAS converted to C,

I think, rather, it's just a set of C wrappers for the (Fortran) BLAS
functions, so you should not see any performance difference at all.

[...]

i would expect that for large enough matrices, there would be no
performance difference between BLAS and CBLAS since the overhead of
calling libraries would be amortized.

I should imagine that the overhead incurred by calling a CBLAS function
would be absolutely minimal compared with the overhead of making a call
directly to the corresponding Fortran BLAS routine. There is a good
chance that your compiler would optimise away any (additional) overhead
entirely. Essentially, CBLAS just wraps the Fortran calls in convenient C
syntax.

however, if CBLAS is not available and my code relies on it, then a user
might be stuck having to compile it. and that is more work than i want
them to have to do.

Well... your user has to have a BLAS installed, don't they? And many
BLASes ship with CBLAS these days. And note too that the CBLAS interface
is standardised; see:

http://www.netlib.org/blas/faq.html#7

If you decide not to use CBLAS it will entail somewhat more work on your
part (as you've probably discovered) to make the Fortran calls to BLAS. I
seem to recall doing just this once and that it is a bit of a pain if you
want portability - different platforms/compilers seem to use different
conventions for calling Fortran from C++ (underscores? capitals? ...?).
And the row/column-major array order issue is more vexing, since the
Fortran default order differs from C++'s. The advantage of CBLAS is that
it does all the ugly stuff for you.

basically, i put in the effort to program direct BLAS links,

Oh, you've done that, then.

and I'm
trying to find excuses to convince myself that i didn't waste my effort!

Indeed. Still, I don't think performance should be a consideration, if
that makes you feel worse about it ;-)

^^^^^^^^
Please don't quote signatures.

Cheers,

 

[Klaas Vantournhout]

Hi,

i'm working on a C++ code that uses dgemm in a simple way, but i want
ports of my code to different machines to be easy.

further, i want to make compiling of my code easy for new users -- i
don't want them to compile more libraries than absolutely necessary
(compiling ATLAS or GotoBLAS is necessary).

I am currently also using BLAS and LAPACK in a c++ code, and I generally
want the same features like you. Being easily portable, disregarding of
the BLAS LAPACK library the person uses (original netlib BLAS and
LAPACK, GotoBLAS, Intel MKL, AMD CML, ...)

If you take a look at most of these libraries, they all contain the
FORTRAN versions with/without a c wrapper. CLAPACK and CBLAS on the
other hand, are fully f2c versions of the original FORTRAN code and need
F2Clibs to work.

This means that if you take a look at the symbols whit for example the
gnutool nm or objdump, you will notice that all the same symbols
(representing the functions) are there. For BLAS this means srotg_,
drotg_ scopy_, dcopy_, ... (notice the underscore at the end).

For this reason, I strongly suggest to use these symbols to call the
functions, and this according the rules of engagement when it comes to
calling FORTRAN from C(++). This makes sure that you don't have to
implement any different BLAS wrappers like there exist several and are
also included in the Intel and AMD versions.

2) to use BLAS, I had to switch from using new [] to malloc, and
delete [] to free. why? once allocated, i didn't realize there was a
difference.
is it not possible to use new [] allocated arrays with FORTRAN
libraries?

I had the same problem when I used the CBLAS version, and this is mainly
because you can not mix new, delete with malloc, free. When linking
CBLAS you also need to link the libF77.a and libI77.a from the F2CLIBS.
If you check out this code, you see they make use of the free and
malloc command there, and hence all new and delete operations will
conflict with this. You see this clearly with valgrind.

3) once your code can is programmed to use either, is linking directly
to BLAS preferable in any way to using CBLAS?

Hence as I stated above, I suggest linking to FORTRAN versions and not
C-wrapped or F2C versions of BLAS (i.e. CBLAS). A FORTRAN version is
more frequent available then a C converted version.

I hope this helped.

Regards
Klaas

 

[nitroamos]

yes, your discussion answered my questions.

i won't delete my CBLAS calls, but they'll be commented out.

thanks!


amos.