Why a Matlab function is faster than the corresponding MEX?

41 ビュー (過去 30 日間)
Giulio Brandizzi 2022 年 9 月 20 日
コメント済み: Bruno Luong 2022 年 9 月 23 日
Problem Statement:
I created a MEX function that is equivalent to the following Matlab function
function d = Mex_for_fun(x,y)
% Inputs: x and y are matrices of n (generic) rows and 2 columns
d=zeros(length(x),1);
for i=1:length(x)
if x(i,1)<=y(i,1) && x(i,2)<=y(i,2) && (x(i,1)<y(i,1) || x(i,2)<y(i,2))
d(i)=1;
else
d(i)=0;
end
end
end
The MEX function is simply obtained by using the Matlab coder in the app menu bar.
By comparing the run times of the two methods i used the following script:
%Test
Np=1000;
fitness=rand([Np,2])*1000;
all_perm=nchoosek(1:Np,2);
all_perm=[all_perm;[all_perm(:,2) all_perm(:,1)]];
x=(fitness(all_perm(:,1),:));
y=(fitness(all_perm(:,2),:));
%Matlab Function
tic
d_matlab_fun=Mex_for_fun(x,y);
toc
%Mex function
tic
d_mex=Mex_for_fun_mex(x,y);
toc
The results from the time on my pc are:
0.029305 seconds for the Mex function.
0.011935 seconds for the Matlab function.
Question:
Why is this the case? Shouldn't the Mex function be faster since it is compiled in C?
Thank you for the attention.
8 件のコメント6 件の古いコメントを表示6 件の古いコメントを非表示
Bruno Luong 2022 年 9 月 20 日

Your for-loop is pretty straigh-forward, there is no much to be optimize about it unfortunately. You might try to create d with logical, and assign directly the boolean expression instead of branching with "if", migh be reverse the test so that less logical testing will be performed with your data. Again you have to mex manually so you can optimize it. Just forget coder to do the job for you.
Giulio Brandizzi 2022 年 9 月 20 日
Ok thank you very much @Bruno Luong, you were very helpful.

サインインしてコメントする。

採用された回答

Apeksha Bagrecha 2022 年 9 月 23 日
It is important to remember that under the hood, a MEX file is simply a function that calls a C/C++ (or sometimes Fortran) subroutine. So when we are comparing the execution time of a MATLAB script to that of a MEX file, we are comparing the amount of time it takes the MATLAB script to be interpreted to the amount of time it takes the generated C/C++ code to execute.
Now it is reasonable to think that compiled C code should execute faster than M code is interpreted. However, it has been many years since MATLAB has been a true interpreted language. Today it is a just-in-time (JIT) compiled language with a large library of pre-compiled routines that are optimized for the target that MATLAB is running on. With MEX code generation, we are generating portable C code. Sometimes the MATLAB libraries are even multi-threaded while the generated code is not. Generally speaking, when an application mostly exercises pre-compiled binaries in MATLAB, or things that the JIT compiler handles well, the more realistic expectation is for MATLAB to be faster than the generated C code. The times when we see large speed-ups tend to correspond to those functions which are still implemented as complicated MATLAB functions in MATLAB. One might expect, therefore, to see speedups with QUADGK or QUAD2D, for example, but not with FFT.
With a simple script, we are really just comparing the C compiler to the MATLAB JIT compiler. For instance, the "mod" function is executing the exact same binary code in MATLAB as it is in a MEX file generated with MATLAB Coder. There just is not any opportunity for speedup here.
2 件のコメントなしを表示なしを非表示
Walter Roberson 2022 年 9 月 23 日
@Bruno Luong and I have been (politely) arguing about whether MATLAB is currently a "just-in-TIme (JIT) compiled language".
At one point I was told by Mathworks staff that MATLAB is no longer considered to be "just-in-Time": that instead, as of the introduction of the Execution Engine, scripts and functions are now internally compiled at parse time, rather than Just-In-Time (JIT implies optimization when a section of cide is executed.)
But the public documentation does not make that clear, and Bruno's interpretation is that the current language still qualifies as being "JIT".
Timing tests that we do to resolve the matter tend to be ambiguous. It is common for the first execution of a loop (such as here in Answers) to take notably longer than other iterations. But only common -- my timing experience shows that it is common for the 3rd (typically, sometimes 2nd or 4th) iteration of a loop to be the longest version, with a lot of variability in the first 6 iterations, after which the maximum time tends to cut down considerably.
Bruno Luong 2022 年 9 月 23 日
Thank you @Apeksha Bagrecha for claering this out.
My observation on the simple loop withh expression on scalar (could be array element though) is that MATLAB become extremely efficient, and even my equivlent manual MEX cannot beat it. II then assume that MATLAB compile the for-loop code and not calling a library (since calling function is alway slow). My assumptionmight be wrong though.
In any case It is much harder to improve speed using MEX programing for sure.

サインインしてコメントする。

カテゴリ

Help Center および File ExchangeMATLAB Coder についてさらに検索

R2022a

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by