mkl_sparse_?_create_{csr,coo,csc} and mkl_sparse_destroy

[Gagan]

hi,

quick question: what does mkl_sparse_?_create_{csr,coo,csc} do, exactly? i am aware a handle is created, but does this handle have its OWN copy of the data given as input? or does it create pointers to the original input data?

i'm trying to figure out whether i can safely call free() on the data given as input to mkl_sparse_?_create_{csr,coo,csc}, after the sparse_matrix_t handle is created, but before it is used by mkl_sparse_?_ev.

similarly, after using an mkl_sparse_t object (via mkl_sparse_?_ev), do i free() the input data used to create the handle, and then call mkl_sparse_destroy?

the example doesn't make it clear, since it simply destroys the sparse_t object and gives no indication as to what exactly happens with the input matrices used for its creation.

[noffermans · Accepted solution]

Hi Gagan,

Generally speaking, user data is the responsibility of the user, and data allocated internally is the responsibility of the library. The library uses the data passed to the handle and the mkl_sparse_?_create_{csr,coo,csc} routines do not allocate their own copies. So no, you cannot safely free() your data after creating the handle and before calling other oneMKL routines that will use the handle. The "contract" between the library and the user when it comes to the sparse handle is:
- the user data must persist until all uses of the matrix handle have finished,
- the user must not modify the data while it is in a matrix handle,
- the library will not modify data provided by the user, except for calls to mkl_sparse_order().

Looking at the c/sparse_blas/source/sparse_spmm_export_csr.c example (that computes the product of sparse matrices A and B into sparse matrix C), you can see that a call to mkl_sparse_destroy() only frees the handle for matrices A and B, and that user arrays for A and B are freed explicitly, while both the handle and the library's internal data for C are freed by a call to mkl_sparse_destroy().

Best,
Nicolas

[Gagan]

yeah that seemed to be the case.

i tried to use the handle after freeing the input matrices and it would segfault on the first run after compilation, and then seem okay. this erratic behaviour is probably a consequence of the intended operation and the mkl's 'fast alloc' that probably leaves traces of the existing matrix, even after a call to free, provided that the requisite address isn't overwritten.

i was looking at the solvers_eec/source/dextremal_ev_c.c example so i admit i could have been a little more thorough, but i do think that the freeing of ia, ja, and a matrices before the destroy call would be helpful just so others don't have to look at other examples.

i'm a big believer in the "self contained example" stuff.

thanks for your answer.

[noffermans]

Glad that I could help!

I understand, thanks for the feedback.

Nicolas