- mkl_[c,s]_dll.lib - cdecl and CVF static interfaces to DLLs
- mkl_lapack.lib - LAPACK, processor independent code
- mkl_ia32.lib - processor dependent code which dynamically selects correct binaries at run time based on what processor code is running on.
- mkl_solver.lib - direct sparse solver binaries. May be folded in to other libraries in future.
- libguide.lib - threading library
The list for the DLLs is similar except that a specific processor will cause a processor-specific DLL to be loaded. Also, to reduce somewhat the footprint of LAPACK and because most of the time only single precison or double precision LAPACK routines would be included in an application, separte DLLs are created for each precision.
1. There will generally be no significant speed differences between statically and dynamically linked programs. If you call a single, simple function with a small data set, the cost of loading the DLL will favor static linking, but in any realistic situation the differences should be small.
2. Linking the BLAS from C++ has two approaches. First of all you should include mkl.h which will pull in a lot of additional include files. These files include declaring the functions to be extern "C" if C++ is being used.
If you want to make life e asy for yourself, I would suggest looking at using the cblas interface. These interfaces allow you to forget about Fortran/C issues in paramter passing and also help take care of the differences in how data is stored between the two languages.
3. We are looking at ways to make the DSS more useful. We would probably want to increase the functionality of Pardiso rather than expose the factors.
4. MKL 7.0 will have better documentation on the DSS.
5. Out-of-core: this is an interesting request. Is this because you want to solve a problem that is larger than 32-bit addressing will allow or to save memory costs?
6. We have had at least one other request of ARPACK. Of course, you can build ARPACK and link in MKL for the LAPACK and BLAS portions of the software to get most of the advantages that an MKL-suppied version of ARPACK would offer.
Thanks for raising these interesting points.
I am looking at an Open source FEA solver Calculix and during the study I found that it has an option of using Pardiso solver. During my furtehr search I found that I will need Intel MKL libraries and Pardiso solver comes with it. I noticed that there is 30 day trial version for Intel Parallel studio XE which I believe contains Intel MKL and Pardiso solver. Before buying the solver I was thinking of trying this trial version to see if I am able to compile it with Calculix and also if it helps me in solving some of the finite element problems.
I will appreciate if any one can let me know if I am looking at the right software and also if 30 day trial version will be good test to see it can be compiled with Calculix.
I do not know anything about Calculix. The trial version of MKL should be sufficient for your purposes, if you have one of the compilers known to work with MKL. Note that you will only be able to do command-line development, even if you download the evaluation version of Parallel Studio, unless you already have Visual Studio installed.
Yes, please try MKL eval version first by click the needed version in https://software.intel.com/en-us/intel-parallel-studio-xe/try-buy.
After install, there is a ready pardiso sample (code, input matrix A and makefile) in C:\Program Files (x86)\Intel\Composer XE 2013 SP1\mkl\examples\*.zip => solverc or solverf .
You may create a new post if any further usage issue, with title "Calculix and MKL xxxx", thus more developers may share their experience on this.
Intel MKL Consulting Engineer