I'm working on a project on Matlab where we have to optimize the performance, and I was thinking about parallelizing a couple of function calls that were made from a .m file.
The idea was simple, from a Matlab file (.m) call a C file compiled as MEX, and from that C file, create a couple of threads and call back the matlab functions from each thread.
The theory works, I can create the threads, and I can also call the matlab function, the problem is that I cannot call the matlab function from the thread:
//Global variables
mxArray **g_plhs;
mxArray **g_prhs;
int g_nlhs;
int g_nrhs;
//Thread function
DWORD WINAPI my_function( LPVOID lpParam )
{
mexCallMATLAB(g_nlhs,g_plhs,g_nrhs,g_prhs,"matlab_function");
return 0;
}
//Main function
void mexFunction(int nlhs, mxArray *plhs[],
int nrhs, const mxArray *prhs[]) {
DWORD dwThreadIdArray[MAX_THREADS];
HANDLE hThreadArray[MAX_THREADS];
g_plhs = plhs;
g_prhs = prhs;
g_nlhs = nlhs;
g_nrhs = nrhs;
hThreadArray[0] = CreateThread(
NULL,
0,
my_function,
NULL,
0,
&dwThreadIdArray[0]);
WaitForMultipleObjects(MAX_THREADS, hThreadArray, TRUE, INFINITE);
for(i=0; i<MAX_THREADS; i++)
{
CloseHandle(hThreadArray[i]);
}
}
Do we have any restriction on that option when working with matlab?
Has somebody tried something like this?
Edit: Is there any option that doesn't require Parallel Toolbox?
You can only call the mx* and mex* functions from the MATLAB main thread. You can write multithreaded MEX files providing these do their work at a level below the mx interface. If you want multiple MATLAB interpreters, you need multiple MATLAB processes. One way is through the Parallel Computing Toolbox as pointed out by @You. This gives you PARFOR
loops and SPMD
blocks for running things simultaneously.
You'd probably be better off using MATLABs built-in multithreading features such as parfor
. In fact, many MATLAB functions are already multithreaded (including matrix operations), so there should be no need for you to parallelize things yourself apart from replacing for
with parfor
. (In general, while
loops cannot be paralellized.)
Your best option is parfor
. if you're a student you can get parallel toolbox for pretty cheap. even full price is not much if you're serious about performance. Your code above will be error prone and hard to test. using parfor
is intuitive and clean.
I'm surprised everyone is pushing for parfor
. I would encourage you to at least think through whether you can design your algorithm to be called from Matlab and run the critical sections low level from multithreaded C/C++ without calling back to mex. This should generally be possible. Especially if you use Matlab profiler
or similar tool to figure out which steps of your analysis are the bottleneck, then you may be able to write only 1 or 2 steps in multithreaded C.
Another way to go would be to write your parallelism in Java, which is easier to work with from Matlab.
Other options you might want to check out include the multicore
submission on Matlab Central or the MatlabMPI
library. Both are a little kludgy and are designed for interprocess parallelism (you have to run multiple instances of Matlab), so not good for very fine-grained, complicated parallelism. But for simply breaking a job into 4 or 8 or 16 parts they should get the job done, and at least multicore
has reasonable community support. I haven't tried MatlabMPI
yet, but it looks promising. As a bonus, these should work across multiple machines although they will probably require a shared network filesystem.