Memory leakage in dtrmm shipped with MKL 8.0 Windows/IA32

Memory leakage in dtrmm shipped with MKL 8.0 Windows/IA32

Bild des Benutzers wy2002@columbia.edu



I am giving the C++ code below to demonstrate this memory leakage. The C++ code can be complied in .Net 2003 and linked with MKL 8.0 (remember to include "mkl.h" to you "include path" and to add "libguide.lib" and "mkl_c.lib" to your library list).


If you start the debug in the .Net DEV, you willsee the leakage information in the "Output" window in the DEV. For comparison, you can uncomment the "dtrmv" line and comment the "dtrmm" line; then, you will see no leakage.


I am very concerned with this problem.


======================================


#include "mkl.h"


using namespace std;


#define CRTDBG_MAP_ALLOC
#include
#include


/* Test the memory leakage of dtrmm in MKL */


int _tmain(int argc, _TCHAR* argv[])
{
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );


double a[] = {1,2,3,1,0,1,2,1,0,0,1,4,0,0,0,1};
double b[] = {1,2,3,4};
// a=
// 1 0 0 0
// 2 1 0 0
// 3 2 1 0
// 1 1 4 1
// A*b = [1 4 10 19]'


double alpha = 1.0;
int lda=4;
int m=4;
int rhs=1;
int inc = 1;


dtrmm("L","L","N","U",&m,&rhs,&alpha,a,&lda,b,&lda);
//dtrmv("L","N","U",&m,a,&m,b,&inc);

return 0;
}

Message Edited by wy2002@columbia.edu on 11-22-2005 10:13 PM

3 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.
Bild des Benutzers wy2002@columbia.edu

My college reported that he did not observe the leakage of dtrmm under Linux using "LeakTrace".

I am wondering whethersome authorities from INTEL could confirm my observation and provide with a patch.

Bild des Benutzers Community Admin

MKL allocates buffers that it doesn't automatically give back at the end of the function call. This is an optimization because frequently functions such as DTRMM (which finally calls DGEMM) need buffers and will often be called many hundreds or thousands or even more times during the execution of a program.

I would not call this a leak as it is planned and intentional. However, were you to put calls to this function in a loop and the "leaks" kept growing, then we have a problem.

Also, you can turn the memory manager off by setting to any value MKL_DISABLE_FAST_MM.

The memory manager is discussed in Technical User Notes (mkluse).

Melden Sie sich an, um einen Kommentar zu hinterlassen.