I have MATLAB mex code that hacks into the mxArray header to read and modify fields such as the CrossLink pointer (used for shared data copies) etc. This is necessary to allow me to work with very large variables inside mex routines without creating deep copies. This code works well up to R2018b but now crashes MATLAB. What has changed?
The mxArray header has changed in R2019a. The location of the CrossLink field in the mxArray header has moved next to the reverse CrossLink field. So, the order for R2018b and earlier is this:
void *RevCrossLink;
mxClassID ClassID;
int VariableType;
mxArray *CrossLink;
:
etc.
but for R2019a it is this
void *RevCrossLink;
mxArray *CrossLink; <-- moved
mxClassID ClassID;
int VariableType;
:
etc.
So if you want your code to be robust and compile/run under different MATLAB versions, you will need to programmatically determine the MATLAB version. C code to determine the MATLAB version at compile and run time can be found here:
https://www.mathworks.com/matlabcentral/fileexchange/67016-c-mex-matlab-version
First of all, it is a request not to mark this question as duplicate as it will be clear once it is studied in detail.
I am trying to implement Orthogonal Matching Pursuit algorithm. For that I need to find the dot product of two matrices of size 144*14596 and 144*1 as shown below
clc,clear;
load('E');
load('R');
load('P');
sparse=zeros(14596,2209);
dictionary=tem2;
atoms=zeros(size(dictionary,1),size(dictionary,2));
coefs=zeros(size(dictionary,2),1);
tic
%Normalize the dictionary
for index=1:size(dictionary,2)
dictionary(:,index)=dictionary(:,index)./norm(dictionary(:,index));
end
D=dictionary;
/* NOTE: I tried for ii=1:5 to check the difference in computational time*/
for ii=1:2209
r=tem4(:,ii);
dictionary=D;
index=[];
count=0;
t=5;
while(t>1e-15 && count~=144)
/***************Problem lies here**************/
% inner_product=dictionary'*r; %Dot Product (Should be slow but is fast)
inner_product=dotProduct(dictionary',r); %(Should be fast but is very slow)
/****************************************************/
[m,ind]=max(abs(inner_product));
index=[index ind];
atoms(:,ind)=dictionary(:,ind); %Select atom which has maximum inner product
dictionary(:,ind)=0;
at=atoms(:,index);
x=(at'*at)\(at'*r);
coefs(index)=x;
r=r-at*x;
t=norm(r);
count=count+1;
end
sparse(:,ii)=coefs;
end
sig=D*sparse;
final=uint8((repmat((((max(tem4))-min(tem4))./((max(sig)-min(sig)))),size(tem4,1),1).*(sig-repmat(min(sig),size(tem4,1),1)))+repmat(min(tem4),size(tem4,1),1));
toc
but the problem I am facing is that it takes a lot of time (as seen in the profiler report) in finding out the dot product using the following code in MATLAB.
inner_product=dictionary'*r;
In order to reduce the computational time, I wrote the MEX code as shown below to find out the dot product:
/***********************************************************************
*Program to create a MEX-file to find the dot product of matrices *
*Created by: Navdeep Singh *
*#Copyright Reserved *
***********************************************************************/
#include "mex.h"
void dot_prod(double *m1,double *m2, double *t,size_t M,size_t N, size_t M2,size_t N2 )
{
int i,j,k;
double s;
for(i=0;i<M;i++)
{ for(k=0;k<N2;k++)
{ s=0;
for(j=0;j<N;j++)
{ s=s+*((m1+i)+(M*j))*(*(m2+(j+M2*k)));
}
*((t+i)+(M*k))=s;
}
}
}
void mexFunction(int nlhs,mxArray *plhs[],int nrhs, const mxArray *prhs[])
{ double *mat1,*mat2,*out;
size_t rows_mat1,cols_mat1,rows_mat2,cols_mat2;
mat1=mxGetPr(prhs[0]);
mat2=mxGetPr(prhs[1]);
rows_mat1=mxGetM(prhs[0]);
cols_mat1=mxGetN(prhs[0]);
rows_mat2=mxGetM(prhs[1]);
cols_mat2=mxGetN(prhs[1]);
plhs[0]=mxCreateDoubleMatrix(rows_mat1,cols_mat2,mxREAL);
out=mxGetPr(plhs[0]);
dot_prod(mat1,mat2,out,rows_mat1,cols_mat1,rows_mat2,cols_mat2);
}
But to my surprise I found out that MEX solution is much much slower than the one used in MATLAB, which defeats the ultimate purpose of MEX. To know the cause I searched a lot on internet and found some interesting facts such as :
Matlab: Does calling the same mex function repeatedly from a loop incur too much overhead?
Matlab mex-file with mexCallMATLAB is almost 300 times slower than the corresponding m-file
These links suggests that overhead should not be much and if there is some it is always for the first call, as time is needed to load symbol tables etc . -- But contrary to this I found that a lot of overhead is incurring in my code.
Also I found out that size of arguments does not matter though number of arguments can affect the computational time but it is again minimal. One of the link also suggest that dynamically allocated memory should be freed (apart from the one allocated by matlab itself) but I don't have any such kind of allocation also.
So kindly let me know what is the reason behind
why MEX is taking huge amount of time?
What can be the solution to it?
Your help is really appreciated.
Various files can be found here:
dictionary.m
dotProduct.c
Report MEX
E.mat
R.mat
P.mat
Matlab has highly optimized code to calculate dot product of to matrices,
you just wrote a nested for loop to calculate the dot product , so you could compare this Mex code just with "similar nested for loops" in matlab then decide whether MEX code is faster or matlab ,
in fact matlab does not use nested for loop to calculate dot product of matrices,
from MATLAB doc:
MEX-Files have several applications:
calling large pre-existing c/c++ and FORTRAN programs from MATLAB without rewriting them as MATLAB functions
Replacing performance-critical routines with c/c++ implementations
MEX files are not appropriate for all applications. MATLAB is a high-productivity environment whose specialty is eliminating time-consuming, low-level programming in compiled languages like C or C++. In general, do your programming in MATLAB. Do not use MEX files unless your application requires it.
EXAMPLE1
I want to run MATLAB 2015b algorithm on Android device through NDK. So I need a standalone c code from algorithm. I used Matlab Coder for this, But I get this error:
The function 'bwboundaries' is not supported for standalone code generation. See the documentation for coder.extrinsic to learn how you can use this function in simulation.`
I used this function in this way:
[B,L]=bwboundaries(h1);
the h1 is an 280*500 logical array which comes from a Black & White image.
I searched and found this list: Functions and Objects Supported for C and C++ Code Generation
As we see there the bwboundaries declared in the list:
bwboundaries :
The conn and options arguments must be compile-time constants and the return value A can only be a full matrix, not a sparse matrix.
If you choose the generic MATLAB Host Computer target platform, generated code uses a precompiled, platform-specific shared library.
MATLAB Function Block support: No.
I don't understand it!! How should I use this function to have its c code?
OR Is there any function to use instead?
I see this SO questions which didn't help me:
q1 q2 q3
Is it possible to create an array of system objects in Matlab and then mex into C code?
For example, in C++ you can create vector where myClass is a user defined class. Is it possible to create the equivalent thing in Matlab using system objects and then build to C code?
Creating ordinary arrays of System objects is not supported. You can place them in cell arrays. But code generation to C code or mex file does not support any array of classes. If you can give more detail on what you are trying to do with array of objects we can try to see whether there are alternate approaches to solve your problem.
I have an m file from which I use to create dll using the Matlab deploytool. the code simply reads as:
function hello
disp('Hello')
end
there are six functions in the compiled dll exported as:
uint8 helloInitialize
[uint8, voidPtr, voidPtr] helloInitializeWithHandlers(voidPtr, voidPtr)
helloPrintStackTrace
helloTerminate
uint8 mlfHello
[uint8, MATLAB arrayPtr, MATLAB arrayPtr] mlxHello(int32, MATLAB arrayPtr, int32, MATLAB arrayPtr)
Now I want to run this dll from my matlab command window using calllib and use
the hello function. Assuming that I use the correct function mlfHello, calllib('hello','mlfHello') gives me nothing. Please advise me on what function to call and how to do it?
I'm not 100% its still the case but it certainly used to be that you couldn't load DLL's which were created in Matlab back into Matlab.
I suspect its still the case - so you cant do what your trying to do.
[edit] I dont have a link because they dont like to advertise the fact. The reason AFAIK is to avoid users compiling toolbox capability into DLL and giving to others to use in Matlab without a toolbox license.