MATLAB: MEX – accessing structure of arrays

cMATLABmexperformancestructure

Hi all,

I’m looking for some advice in a project in which speed and performance is of great importance.

I created a model which consists of an outer function with 1 for-loop (10 000 iterations) which invokes several custom-made functions. To increase model’s performance, I rewrote the custom-made functions into MEX-functions. This already gave a good speed-up. However, I would also like to place the outer for-loop in a MEX-function. But I have a problem passing data from MATLAB to the MEX-functions. (Note that it’s not possible to vectorize the for-loop).

The data which is known prior to the model’s simulation is saved to a large nested structure of arrays (built in the form of “data.Q.position1” with “position1” an array of 10000 doubles). All arrays containing doubles have the same length. The results of the model will also be written to this structure of arrays (different fieldnames of course, and pre-allocation is done before the for-loop)

So currently, the model is looking like this:

  [data]  = function model(data)
  for i=1:10000
    data.Q.position1(i) = MEX-function1(data.WL.position4(i), data.WL.position3(i), …);
    data.Q.position2(i) = MEX-function1(data.WL.position6(i), data.WL.position12(i), …);
    …
    data.WL.position7(i) = MEX-function2(data.Q.position1(i), …);
                …
         end

I chose for the structure of arrays so I can point easily at the required variables for the function inputs.

So my question is, how can I place the for-loop in a MEX function and what do I have to do with the structure? Will I still by able to refer to the variables like data.WL.position1 etc? I’m really new to MEX and C-language as you will probably notice…

Secondly, and at least equally important, does this whole concept looks good with regard to performance, or are better solutions available?

Thanks in advance!

Best Answer

There will likely be some speed improvement if you put the loop inside a mex functions. At the m-file level, each time you pass data.WL.position4(i) etc as an argument MATLAB creates a temporary shared data copy of the actual variable and passes that. So there is overhead associated with calling the function in this manner. Inside a mex routine, however, these temporary shared data copies can be avoided by using mxGetField on the data variable directly (returns the actual variable pointer instead of creating a temporary shared data copy). So that part is fairly straightforward. The problem is going to be putting the results back into the data.Q.position1(i) etc positions. In order to do that inside the mex routine and have the for-loop inside the mex routine you will need to modify the data variable "in-place", which is (strictly speaking) against the official rules but can be done. The downside is that you risk unintended side effects if there is any variable sharing going on. Are all of the left-hand-side variables (e.g., data.Q.position1(i)) pristine and not shared with anything? If so, then you can safely modify them in place. An outline is below:

Calling syntax at m-file level:

mymodel(data); % Note: no left-hand-side

Mex function code snippet outline:

mxArray *Q, *WL, *position1, *position2, etc;
mwSize i;
double *pr1, *pr2, *pr3, *pr4, *pr5, *pr6, *pr7, etc;
    :
Q = mxGetField(prhs[0],0,"Q");
WL = mxGetField(prhs[0],0,"WL");
position1 = mxGetField(Q,0,"position1");
position2 = mxGetField(Q,0,"position2");
position4 = mxGetField(Q,0,"position4");
position3 = mxGetField(WL,0,"position3");
position6 = mxGetField(WL,0,"position6");
position7 = mxGetField(WL,0,"position7");
etc
pr1 = mxGetPr(position1);
pr2 = mxGetPr(position2);
pr3 = mxGetPr(position3);
pr4 = mxGetPr(position4);
pr6 = mxGetPr(position6);
pr7 = mxGetPr(position7);
etc
for( i=0; i<10000; i++ ) {
    pr1[i] = MEX_function1(pr4[i],pr3[i],etc);
    pr2[i] = MEX_function1(pr6[i],pr12[i],etc);
    etc
}

For a robust mex routine, you would need to check variable types and sizes etc before dereferencing any of the pointers (which I did not do above). I will again caution you that this will only work if the left-hand-side stuff has been pre-allocated properly so as not to be shared. Can you post how you are doing this pre-allocation?

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: Using a .mexw64 in a mexFunction

Either insert the C-source of function1.c without the mexFunction gateway to function2.c. Or call function2 through mexCallMATLAB:

mxArray *Input[1];
Input[1] = mxCreate...
mexCallMATLAB(0,NULL,1, Input, "function2");

The later is less efficient due to the double overhead of calling Matlab to call the mex.

Best Answer

Related Solutions

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

MATLAB: Using a .mexw64 in a mexFunction

Related Question