424,279 Members | 1,893 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,279 IT Pros & Developers. It's quick & easy.

BLAS vs CBLAS in C++

P: n/a
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.

Sep 3 '07 #1
Share this Question
Share on Google+
6 Replies


P: n/a
On 2007-09-04 01:12, ni*******@gmail.com 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.

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.

--
Erik Wikström
Sep 4 '07 #2

P: n/a
On Tue, 04 Sep 2007 11:15:59 +0000, Erik Wikström wrote:
On 2007-09-04 01:12, ni*******@gmail.com 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.

[...]

--
Lionel B
Sep 4 '07 #3

P: n/a
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.
On Sep 4, 5:25 am, Lionel B <m...@privacy.netwrote:
On Tue, 04 Sep 2007 11:15:59 +0000, Erik Wikström wrote:
On 2007-09-04 01:12, nitroa...@gmail.com 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.

[...]

--
Lionel B

Sep 4 '07 #4

P: n/a
>
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.

Sep 4 '07 #5

P: n/a
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
Sep 5 '07 #6

P: n/a
yes, your discussion answered my questions.

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

thanks!
amos.

Sep 6 '07 #7

This discussion thread is closed

Replies have been disabled for this discussion.