Run-time linking MKL

Run-time linking MKL

Portrait de jd_weeks
jd_weeks
jeu, 06/05/2004 - 00:27

My company sells Igor Pro, a scientific graphing and numerical analysis program. It runs under Windows 98/Me/2000/XP and Macintosh.

I want to be able to make use of MKL optional in case Windows customers are using hardware that's not appropriate (is that, in fact, a problem?). I have successfully linked to LAPACK routines using LoadLibrary to load mkl_lapack64.dll and mkl_lapack32.dll, plus GetProcAddress. I call LAPACK routines through function pointers.

Now I want to try out the dft routines, but I can't get function pointers. It appears that the routines exported by the MKL dll's do not correspond exactly to the documented routines. What can I do?

Thanks, John Weeks

RSS Haut
6 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.
Portrait de Community Admin
Community Admin
jeu, 06/05/2004 - 17:13


John,


Thanks for joining the forum and for raising this issue.


First of all I don't understand your question about "appropriate" hardware. Please explain what you mean and I will try to respond to that.


As to the exporting of names from the DLLs, I will ask the developers about this since I am not certain about this myself, and will ask then to post a response.


Bruce


Haut
Portrait de jd_weeks
jd_weeks
jeu, 06/05/2004 - 22:25

Thanks for your response to my questions.

By "appropriate hardware" I mean a processor that can take advantage of MKL. Since we sell to customers with a wide range of machines, we have to be ready for just about anything. This question really has two parts:

1) I have found that my Athlon processor benefits from MKL LAPACK in spite of not being Intel hardware. Are there processors that will choke if I try to run MKL?

2) MKL includes different dll's for different processors, so presumably I want to link to the right dll for a given processor.

Thank you,
John Weeks

Haut
Portrait de Community Admin
Community Admin
ven, 07/05/2004 - 17:11

John,


Thanks for theclarification. Perhaps you should be linking with our static dll interface since the correct dll would then automatically be chosen at run time. So if you linked with mkl_c_dll.lib, you would need to provide with your application all the DLLs, but the correct one would be chosen at run time for the platform being used.


There are processors that might choke if the wrong DLL is used. For instance, with MKL 7.0 there are Prescott optimizations that include the use of SSE3 instructions, and no processor other than Prescott has these instructions. If these instructions try to run on any other processor (including other Intel processors) there will be an error that will cause the program to crash.

Bruce
Haut
Portrait de jd_weeks
jd_weeks
ven, 07/05/2004 - 17:27

But are there processors (maybe manufactured by AMD?) that can't use MKL at all? If I statically link, then we use it regardless. Or at least, we still have to figure out what processor we're running so that we can avoid calling into MKL.

Haut
Portrait de Community Admin
Community Admin
ven, 07/05/2004 - 17:42

If you statically link with mkl_c.lib, the objects you need will be linked with your application. The objects with will contain binaries for various processors and the correct code will be run for the processor your code is running on.

The process is similar if you choose to use the DLLs. As I had mentioned in the last response, link with mkl_c_dll.lib. This will satisfy all the references in your code. At run time the software you have linked in will determine the correct DLLs to call for the processor the code is running on.

Which ever approach you take MKL will always excute instructions appropriate for the machine the code is running on.

Bruce

Haut

Connectez-vous pour laisser un commentaire.