A problem about lapack in MKL

A problem about lapack in MKL

I an using MKL for matrix computation. But, it seems that the lapack in MKL only gives fortran lib. I want to call lapack in C++. So how can I do?
3x

19 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I guess what you mean is that the lapack links against Fortran run-time to display error messages. Or, maybe, you simply mean that the documented way of doing a Fortran-compatible call is not C++-specific. Or, maybe you mean that CLAPACK doesn't appear to be included in MKL.
In principle, you could use netlib CLAPACK to substitute for MKL lapack and still use MKL BLAS (with the Fortran-compatible calls, I assume). CLAPACK contains generic instructions for using optimized BLAS libraries, such as MKL. That would take care of the Fortran library dependence. If you cared to modify CLAPACK, and go further out on your own limb, you could make it compatible with the C++ calling convention of your choice.

Thank you.
I am sorry maybe I didn't describe the problem clearly.

I have purchased MKL for matrix computation in my project. However Ifound that lapack in MKL is fortran lib. I don't know how to call the fortran lib in my c++ code. I think there maybe exists some way to do this.

As to CLapack, I don't know its efficency.
If the fortran lib call in C++ can't be solved, maybe I will choose MTL (Matrix Template Library) instead of MKL.

Please be more specific, if you are having difficulty with examples of the calling sequence. MKL lapack should work the same as CLAPACK, so you have plenty of places to look for examples. Calling from C++, you use extern "C" declarations so that your calls are reduced to C syntax (so there is no overloading). For most operations, performance would be determined by the underlying BLAS, so you would get the performance benefit as long as you linked to MKL BLAS. But, if your difficulties are not among those I guessed at, I suppose there is no reason to use CLAPACK.

I will describe the problem in detail.

I want to use mkl lapack for LU factoring. So I new a project in vc 6.0. I also inlcude the header file "mkl_lapack.h" in my source file.
the source file can be like this:

#include "mkl_lapack.h"
int main(){
sgetrf(&m,&m,a,&m,ipv,&m);
}
compilation is right.

then I add the lib "mkl_lapack.lib" in my project (actually, I have tried almost all the libs in the mkl ia32/lib directory, but it is useless). I also tried to change the call convention into stdcall, but it is still useless.

the error information is of link, as the following:
test_mkl.obj : error LNK2001: unresolved external symbol _sgetrf@24

I want to know how I can solve the link problem
thanks

I just had exactly the same problem.

When I called the function using capital letters,

DGETRF rather than dgetrf it linked fine.

First of all, you need to link only one library to use MKL. We have tried to make this as easy as possible no matter what from MKL you are using. Now comes the hard part. Whether you use cdecl or stdcall determines what you link into the your program. And as I have explained in another issue, MKL does not have, strictly speaking, a stdcall version.

Having said all that, unless you do something special your compiler will generate cdecl calling conventions. For that you simply link mkl_s.lib.

Here is the general idea of the library. There are two interfaces we have supported. But below the interfaces all the library is identical so to avoid duplicating all the binary code we have the two interfaces and the rest of the code gets linked in automatically through default library identificaitons in the interface libraries.

Now, assuming that your data is in the right order to use Fortran, you simply need to declare the functions you need (in this case dgetrf) as a C funtion and link in mkl_c.lib.

Bruce

Thank you very much.
I have solved this problem.

would you like to tell me why mkl_s.lib use uppercase link.
and for a fortran lib like mkl lapack, why we choose cdecl instead of stdcall?

thank you again?

Thank you very much.
I have solved this problem.

would you like to tell me why mkl_s.lib use uppercase link.
and for a fortran lib like mkl lapack, why we choose cdecl instead of stdcall?

thank you again

I think I can answer your questions. Within the library we can use what we choose as long as all the parts can talk to each other. The default interface used by Intel compilers is cdecl. But we go beyond that to support both upper and lower cases since a user can specify either at compile time. As to upper case for mkl_s.lib, that is consistent with CVF.

Again, our intended interface to the library is either mkl_c.lib or mkl_s.lib. The names to functions in the other libraries have been decorated. For instance, the name of dgetrf in mkl_lapack.lib is __MKL_LAPACK_dgetf, which is not callable from Fortran because of the mixed case.

Bruce

sorry, maybe my questions are somewhat many.

(1) waht is CVF
(2) you say, the function name in mkl_lapack.lib is as __MKL_LAPACK_dgetf, then how can I use it in my c++ program (dose mkl include such header file that we can use the mkl_lapalck.lib). And what's the difference between mkl_lapack.lib and mkl_s.lib and mkl_c.lib?
(3) are there some good tutorials of lapack and blas. I think the two libs are somewhat too complex.

thanks

As Bruce pointed out, mkl_s.lib is set up for convenient use with the Compaq Fortran "CVF," which is a predecessor of the current Intel Fortran. As mkl_c.lib and cdecl are the recommended usage with current compilers, I would expect cblas headers not to be set up specifically for mkl_s.lib. There is nothing to prevent you from grabbing the headers you use and making the modifications. That is probably a good idea, rather than calling the functions without prototypes.
Evidently, the most authoritative tutorials on BLAS et al are the ones from netlib. Google shouldn't have any difficulty turning up reading material.
As the lapack and cblas interfaces go back to the days before C, the cblas and f90blas interfaces are simply add-ons intended to clean up the interface to those languages. The underlying f77 calls remain, and the clapack authors chose to keep them active in the interface between their lapack and BLAS. If you don't want the generality and other advantages of BLAS or MKL, no doubt you could find information on alternatives.
No matter what library you choose, when you post saying you require certain choices, the assumption is that you have already researched your problem that far. You started right out saying you couldn't use the standard method, and required lapack functions, then later on it turns out you wanted commonly used BLAS functions. So you could have avoided some of the confusion.

I will add some comments to those that Tim has provided.

You should forget about mkl_lapack.lib. In fact you should forget about every bit of software in the lib directory except mkl_c.lib unless you are using Compaq Visual Fortran (CVF). If you use mkl_c.lib you should include mkl.h which will provide all the prototypes you need for any function in MKL. If you do this you will need to concern yourself only with such matters as naming conventions (upper case or lower case) and passing parameters correctly to functions, remembering that Fortran passes all parameters by reference.

DGETRF contains a great deal of complexity but is easy to call. Some of the BLAS, on the other hand, are relatively simple in their operation but quite complex in how they are called because they need to meet many criteria in supporting the solutions of systems of equations. DGEMM, matrix multiplication, has 13 parameters which allow you to perform four different matrix multiplication problems: alpha*A*B->beta*c, alpha*transposeA*B->beta*c, alpha*A*transposeB->beta*c, or alpha*transposeA*transposeB->beta*c.

Bruce

How about an example project with Visual Studio?

I have seen no example projects setup for the Intel Math library and Visual Studio (the most common development environment!). This entire thread would have probably been avoided with a single example project. I've had the Intel math library for a day, and still haven't gotten anything working. If I had a ten line example program with the project so I could see what library to link against, I would have been good to go in about five minutes.

This is a great idea. For myself I tend to prefer to create my own makefiles and build environment, but your point is well taken. Over the next few days we will try to provide an example of building a project in Visual Studio calling one or more of the BLAS functions, for instance.

Bruce

I read that you will post a MS Visual C++ project with a sample coding problem. Please let me know where it is posted.

I have used the IPP and it has done wonders for me. I am hoping the MKL will be as useful.

By mere chance I happened to revisit the forum today and saw your comment and realized I had promised a project but had done nothing about it. I will either do it my self or have someone do it for me. I will make it very simple.

Bruce

Thanks. I use MS VC++ 6.0 and VS C++.net 2003. Whatever you could show us would be appreciated. Especially calling Fortran functions from C. I know it should be easy, but sometimes there are small problems or little techniques that are needed to make it all work well.

I used IPP 2.0 to perform FFT's for a scientific instrument. By upgrading to IPP I reduced my execute time on the FFT and associated loading and unloading by a factor of 5 on a P4. I routinely perform 2000 FFT/sec (size 2K points, real FFT)and the computation is the fast part. Storage, analysis of the spectra and display are much bigger issues. Attached is a spreadhseet showing the results on several Intel processors.

I now need to do large matrix inversions. I do the inversion once (on data taken in the field) and then multiply the inverse into a vector that is measured on an instrument in real time. I hope to be able to put the two parts together (fast FFT and fast inversion and multiplication) for fast operation. The matrices are between 200x200 and 1500x1500 in size. I use SVD now to invert the matrix. It is not bad, but an order of magnitude improvement would be welcome.

Yo Bruce,

Where is the sample MS VC++ sample project?

I am preparing a proposal and I would like to exercise the MKL before I send it out.

Ralph

"Posted: 07-25-2005 03:17 PM ID#: 706 (Viewed 242 times)

By mere chance I happened to revisit the forum today and saw your comment and realized I had promised a project but had done nothing about it. I will either do it my self or have someone do it for me. I will make it very simple.

Bruce"

Leave a Comment

Please sign in to add a comment. Not a member? Join today