Hi, I am looking for more info for mkl_malloc - the one on the manual is not much and my "googling" it did not produce much.. a) What is the thread safety behavior of the function? Is it the same as malloc? b) What is the behavior of the function inside a thread? i.e. does it allocate on tls or on the heap? c) Is the last argument same/different for 32 and 64 bit builds? Thank you, in advance, for your help, Kind Regards, Petros ps: in case this makes a difference - which I doubt - I work on win7 win VS2010.
mkl_malloc function is thread safe function which enables safe execution by multiple threads at the same time. Such buffer can be allocated in one thread but freed inanother one. So, it is not TLSdata.In comparison with standard malloc,mkl_malloc allocates memory from heap but with needed alignment to get better performance via vectorization instructions oncomputation with these data if any. As to the last argument MKL default value is 64 byte alignment now and corresponds to AVX architecture not to 32/64 bit OS/builds.
Vipin and Victor, Thank yo very much. One final question: if I use the rbb cache_align_alloc, do you know if I would have the same behavior? The reason I am asking is that I would prefer not to have both allocators (and a few more) in my code. Thank you again. Best Regards, Petros
One final question: if I use the rbb cache_align_alloc, do you know if I would have the same behavior? The reason I am asking is that I would prefer not to have both allocators (and a few more) in my code.
Do you mean TBB tbb::cache_aligned_allocator It is recommended to use the only memory manager inside ofan application and don't mix both. In MKL you can use your favorite memory managervia i_malloc/i_free settings. See MKL doc for details.
Hi Victor, Thank you for your response. Although I know the "rule" of not mixing allocators, in today's practice where you have to bring many libraries together. this -simply- cannot be done. So, if I use some other library which as mkl has its own memory policies/strategies, my only hope is that I will need to write an allocator that would be mkl-compliant (say like in Boost's unbounded array or some stl container). In order to avoid or go on scavanging the TBBallocator, I was asking for the similarity of the two. Rerwritting malloc and free is a much bigger choice which I would opt to avoid as much as I can. Thank ypu for your help, Petros
Hi Victor, So looked into the mkl user's manual for i_malloc etc. Thank you for the pointer. One last question, has to do with your comment on 64 byte argument corresponding to the AVX architecture. From looking at a wiki page for AVX I see that AVX is not supported by my processor chips (Nethalem i7 and Quad Q9000 -for the laptop). Also my mkl version is 10.2.4,and in the documentation, shipped along with it, the use of 16-byte alignment is recommended.
All this is a bit confusing to me.. It seems thatboth processor chip and mkl version matter.
Finally, what is not clear to me is also whether integer arrays (as for example the permutation ones used for pivoting) should have the same alignment requirement (apologies if I do not enough and this is a really naive question).
Thank you very much for your help, Best Regards, Petros
16-byte alignments have been useful since SSE was first introduced. Usefulness of 32- and 64-byte alignment increases with AVX code and OS with AVX support, but I observed gains in recent MKL even when running on my pre-AVX CPUs. CoreI7-2 supports AVX. Like you, I have original I7 (and WSM) CPUs.
One question I have with all this is the following (which complements my response to Victor, as well). If I am writting a plugg-in (an xll for ms excel, or a lib for python) and use mkl, how can I avoid that the mkl allocator will not clash with the application's one? In windows, under new there seems to be malloc to be called and this, seems to me, saves the day.
O/wise, encapsulating the chosen allocation policy (for mkl) secures me from potential catastrophic memory issues ?
If not, what is the way around that the designers of mkl had in mind?
Thank you again for your help, Bset Regards, Petros
To avoid usage of theMKL memory manager (static case)in your plug-in, the standard Windows allocator can be usedby settings: i_malloc = malloc i_free = free i_realloc = realloc i_calloc = calloc It can be resulted in some performance impact but therewill beno potential catastrophic memory issues at all.