MATLAB: Is it possible to create a sub-array without using additional memory on Matlab

MATLABmemorymexmex compiler

Well, I am trying to implement an algorithm on Matlab. It requires the usage of a slice of an high dimensional array inside a for loop. When I try to use the logical indexing, Matlab creates an additional copy of that slice and since my array is huge, it takes a lot of time.

 slice = x(startInd:endInd);

What I am trying to do is to use that slice without copying it. I just need the slice data to input a linear operator. I won't update that part during the iterations.

To do so, I tried to write a Mex file whose output is a double type array and whose size is equal to the intended slice data size.

 plhs[0] = mxCreateUninitNumericMatrix(0, 0, mxDOUBLE_CLASS,mxREAL); % initialize but do not allocate any additional memory
 ptr1 = mxGetPr(prhs[0]); % get the pointer of the input data

Then set the pointer of the output to the starting index of the input data.

 mxSetPr(plhs[0], ptr1+startInd);
 mxSetM(plhs[0], 1);
 mxSetN(plhs[0], (endInd-startInd)); % Update the dimensions as intended

When I set the starting index to be zero, it just works fine. When I try to give other values than 0, Mex file compiles with no error but Matlab crashes when the Mex function is called.

 slice = mex_slicer(x, startInd, endInd);

What might be the problem here?

ps: when doing logical indexing, it creates the index array of 'size = size([startInd:endInd])'. So, what I try to do here is a bit of hacking. Just give the pointer to a memory place where I know what exists and tell how many elements to obtain after that memory. I don't want to create any index array, too. (size of the index array in the order of 2 millions).

Best Answer

Bruno Luong has implemented an inplace slice: See https://www.mathworks.com/matlabcentral/fileexchange/23576-min-max-selection, especially the function inplacesolumnmex.c . It worked fluently in my tests, but in the debug mode working with the temporary arrays let Matlab crash tremendously. Therefore I do not use it in productive code.

It might be easier to provide the complete array together with the indices:

slice = {x, startInd, endInd};

Then you x is created as shared data copy, such that no additional memory is used (except for the about 100 bytes for the header). Then the provided information should be enough to access the data inplace - as long as the contents of x is not changed. Of course you have to modify the functions to consider this type of object. But this should be less hard than fighting with Matlab's memory manager and the effects of shared data copies.

Related Solutions

MATLAB: `mxGetField` could not be assigned to output of c mex

The reason this crashes is because you have created a copy of an mxArray variable without telling the MATLAB Memory Manager that you did so. So when MATLAB subsequently clears one of these it invalidates the other, and then when MATLAB tries to use or clear the other it accesses invalid memory and crashes. I.e.,

plhs[0]= mxGetField(prhs[0],0,"b");

The above gets the the mxArray pointer from prhs[0] and assigns this exact pointer to plhs[0] ... essentially a reference copy. So now there is an extra reference copy of prhs[0] in the system but the MATLAB Memory Manager doesn't know about it. Eventually downstream in your code all of these copies get cleared, but on the next to last one MATLAB thinks all the copies are cleared so it releases the memory. Then when it tries to use or clear the last one it accesses invalid memory and crashes.

The same thing would happen if you tried to copy an mxArray pointer from one cell or struct array element into another element, either in the same or a different cell or struct array. This would in essence create a reference copy of the variable without telling the MATLAB Memory Manager about it. MATLAB will crash downstream at some point when these variables are cleared. This practice could be done safely if you were to bump up the reference count of the variable each time you made a new assignment, but this requires mxArray hacks because there is no API function to do this.

There are three ways to extract an mxArray variable from a cell or struct variable and assign it to a plhs[ ] variable. Assuming you have already checked that nrhs >= 1 and that mxGetField(prhs[0],0,"b") is not NULL:

1) The only official way, which creates a deep copy:

plhs[0] = mxDuplicateArray(mxGetField(prhs[0],0,"b"));

This is the only method that is officially supported and will likely not break in the future. The downside is that if you are working with very large variables it can be a tremendous waste of time and memory to create this deep copy.

2) Using an unofficial API function to create a shared data copy:

plhs[0] = mxCreateSharedDataCopy(mxGetField(prhs[0],0,"b"));

This method is very fast and is useful for large variables. But this method requires you to jump through some hoops, and it may break in the future if they remove this function from the API library. Details for using it can be found in the header file here:

https://www.mathworks.com/matlabcentral/fileexchange/67016-c-mex-matlab-version

3) Bump up the reference count:

plhs[0] = mxCreateReference(mxGetField(prhs[0],0,"b"));

This method is also very fast and useful for large variables. This function used to be in the API library, and the only thing needed to use it was a prototype. However, this function was removed from the API library back in R2014a. So the only way to do this now is to hack into the mxArray itself. This is tricky to do since the mxArray definition and the location of the reference count field has changed over the years. Also the rules for how MATLAB handles the plhs[ ] variables are not published so it is unclear if this will even work for a sub-array type variable instead of a temporary variable. Although this would be the obvious method to use when copying cell or struct field variables from one cell or struct array to another cell or struct array, I wouldn't advise this option for assigning to the plhs[ ] array variables. I would advise method 2 instead for plhs[ ] array variable assignment.

Note that MATLAB itself generally uses either method 2 or 3 in the background when you are working at the m-file level, but for some reason has not made these methods official for mex programmers.

MATLAB: Contiguous memory for complex arrays in mex

Yes and No. It is easily possible to physically do this, but the clearing of such a variable will likely crash MATLAB if you are not very careful. The outline is as follows.

In the mex routine create a double array that is sized to hold all of your intended complex data. E.g., if you want a 1x5 complex array then create a double array that is 1x10. Then manually use mxSetN to change the column size to 5. Then pick the midpoint of the real data area and use mxSetPi to set the imaginary data pointer to that address. That will create a complex mxArray variable with the real and imaginary parts contiguous.

This will work fine up until the point that MATLAB tries to clear this variable from memory. Then it will try to free the address you just set with the mxSetPi function. Since this is not a valid address to free, the results are unpredictable and MATLAB will likely crash.

The only robust solution I can think of is to manually create a shared data copy of this variable, make it persistent, and keep this shared data copy inside the mex routine so MATLAB cannot try to clear it. Then use a mexAtExit function to manually reverse the process, use mxSetPi with a NULL, and then clear the variable. But I will tell you right now that this is very tricky to accomplish and requires that you dig under the hood of the mxArray structure to do some unofficial manipulation. You need to be able to detect when the mxArray is shared with other variables inside your mex routine, etc etc. Not recommended for the faint of heart and not easy to accomplish even for a seasoned programmer IMO.

You might be able to get away with it if you can keep all the operations inside the mex routine so that you can carefully manage all of the operations on the variable to ensure there is no shared data copy of it floating around in memory elsewhere, and then manually fix & clear it yourself inside the mex routine.

What operations will you be doing with this variable?

Best Answer

Related Solutions

MATLAB: `mxGetField` could not be assigned to output of c mex

MATLAB: Contiguous memory for complex arrays in mex

Related Question