MATLAB Answers

Poor performance of mex file

9 views (last 30 days)
Michal Szkup
Michal Szkup on 9 Apr 2020
Edited: Michal Szkup on 12 Apr 2020
I am trying to speed up a code using Matlab coder, but the resulting mex code is actually slower than the m-file. The simplified version of the code that I am trying to speed up is attached below. I am wondering:
  1. Why the mex function is so much slower than the m-file function?
  2. Is there any way to improve performance of my code using Matlab coder?
Any hep would be much appreciated.
function v_d = choice_model_nop(q,v_exp,wealth,b_grid_choice,k_grid_choice,nz,nk,nb)
v_d = coder.nullcopy(zeros(nz,nk,nb));
parfor ii = 1:nz
q_ini_ii = reshape(q(ii,:,:),[],nk);
v_ini_exp_ii = reshape(v_exp(ii,:,:),[],nk);
choice = q_ini_ii.*b_grid_choice - k_grid_choice;
for jj = 1:nk
for kk = 1:nb
% dividends at time t
d = wealth(ii,jj,kk) + choice;
% choosing optimal consumption
vec_d = d + v_ini_exp_ii.*(d>0);
v_d(ii,jj,kk) = max(vec_d,[],'all');
When I run the above code as an m-file I get:
>> timeit( @() choice_model(q,v_exp,wealth,b_grid_choice,k_grid_choice,nz,nk,nb))
ans =
When I use matlab coder to convert the above code into a mex-file (without using JIT to use parallelization and with all speed options unchecked) I obtain
timeit( @() choice_model_mex(q,v_exp,wealth,b_grid_choice,k_grid_choice,nz,nk,nb))
ans =
So the mex-function is actually slower. When I actually used squeeze instead of reshape the prerformance of the m-file was unaffected by mex-file was twice as low as using reshape...
In my testing q, v_exp,wealth are 61-by-61-by-61 arrays, b_grid_choice and k_grid_choice are 61-by-61 matrices, and nz,nk,nb are constants equal to 61.
So I am left wondering why the mex code is slower than the m-file. Is it because a large fraction of the time is spent using in-built matlab function? Is there a way to speed it up?


Sign in to comment.

Answers (1)

Yair Altman
Yair Altman on 11 Apr 2020
You m-function uses parallelization (parfor), while your mex file does not. This in itself could cause your m-code to run much faster than mex, depending on the parallelization speedup. Moreover, you said that you turned off the speedup options in the Matlab Coder, effectively forcing it to run in "crippled" mode.
To compare apples to apples, you need to (1) disable m-code parallelization by replacing parfor with a regular for loop, and (2) enable all the speedup options in the coder. My guess is that you will then see significant speedup of mex vs. m-code.
In case you want to employ parallelization in both your m-code and mex code, you'll need to use a compiler that supports the OpenMP parallelization pragmas that the Matlab Coder generates (many compilers do NOT support them). Also rememeber to turn on all the performance options in your C compiler.

  1 Comment

Michal Szkup
Michal Szkup on 11 Apr 2020
@Yair Thank you for your reply Yair. Just to clarify a few things.
  1. What I meant by switching off speed options is that I unchecked the options under speed tabin the coder. As far as I understand, unchecking these options should result in a faster mex files. For example, I unchecked "Enable responsiveness to CTRL+C and graphics refreshing". The Matlab coder says that switching off this option "results in less generated code and faster mex files." The only one I was not sure was about extrinsic call option.
  2. I have tried using both MinGW and Microsoft Visual C++ 2019 (that comes with Visual Studio Community) compiler. As far as I understand, MinGW uses OpenMP. In my task manager, when I am running the code CPU usage is 100%.
  3. When I was testing the above code I simply used randn to generate the input arrays. The results I posted are for those inputs. But when I generated them inside the function and compared the performance of the mex file and m-file then the former was almost three times as fast. But when I specify the inputs then the mex file is twice as slow as my m-file. I tried both specifying them by example or by using assert with little difference.
PS. Btw, I am big an of your book! I hope you will release a new edition at some point in the future.

Sign in to comment.