Matlab: Czy wywoływanie tej samej funkcji mexa z pętli powoduje zbyt wiele narzutów?

Question

Mam trochę kodu Matlab, który musi zostać przyspieszony. Poprzez profilowanie zidentyfikowałem określoną funkcję jako sprawcę spowolnienia wykonywania. Ta funkcja nazywa się setki tysięcy razy w pętli.

Moją pierwszą myślą było przekonwertowanie funkcji na mex (używając Matlab Coder), aby przyspieszyć. Jednak wspólny rozsądek programowania mówi mi, że interfejs pomiędzy Matlabem i kodem mex doprowadziłby do pewnego narzutu, co oznacza, że ​​wywoływanie tej funkcji mex tysiące razy nie jest dobrym pomysłem. Czy to jest poprawne? A może Matlab robi trochę magii, gdy jest to ten sam mex, który jest wielokrotnie wywoływany, aby usunąć narzut?

Jeśli jest znaczący głową, myślę restrukturyzacji kodu, tak aby dodać pętlę do samej funkcji i następnie tworząc mex tego. Zanim to zrobię, chciałbym potwierdzić moje założenie, aby uzasadnić czas poświęcony na to.

Aktualizacja:

Próbowałem @ sugestią angainor, a stworzony donothing.m z następującego kodu:

function nothing = donothing(dummy) %#codegen 
nothing = dummy; 
end 

Potem stworzyliśmy funkcję mex od tego jak donothing_mex i próbowałem następujący kod :

tic; 
for i=1:1000000 
    donothing_mex(5); 
end 
toc; 

Rezultatem było to, że milion połączeń z funkcją zajęło około 9 sekund. Nie jest to znaczące obciążenie dla naszych celów, więc na razie myślę, że zmienię wywoływaną funkcję samodzielnie na mex. Jednak wywołanie funkcji z pętli, która wykonuje około miliona razy, wydaje się dość głupim pomysłem z perspektywy czasu, biorąc pod uwagę, że jest to kod krytyczny pod względem wydajności, więc przeniesienie pętli do funkcji mex jest nadal w książkach, ale o znacznie mniejszym priorytecie.

Answer 1

Jak zwykle wszystko zależy od ilości pracy wykonywanej w pliku MEX. Narzut wywoływania funkcji MEX jest stały i nie zależy np. Od rozmiaru problemu. Oznacza to, że argumenty są kopiowane na nowe, tymczasowe tablice. Stąd, jeśli jest to wystarczająca ilość pracy, obciążenie MATLAB wywołania pliku MEX nie zostanie pokazane. W każdym razie, z mojego doświadczenia wynika, że ​​obciążenie wywołaniem MEX jest znaczące tylko wtedy, gdy po raz pierwszy wywoływana jest funkcja mex - biblioteka dynamiczna musi być ładowana, symbole rozwiązywane itd. Kolejne wywołania MEX mają bardzo mały narzut i są bardzo wydajne.

Prawie wszystko w MATLAB wiąże się z pewnym obciążeniem ze względu na charakter tego wysokiego poziomu języka. Chyba że masz kod, który na pewno jest w pełni skompilowany z JIT (ale wtedy nie potrzebujesz pliku mex :)) Więc masz wybór jednego narzutu nad drugim ..

Podsumowując - I nie obawiałbym się, że MEX wezwie nad głową.

Edit Jak często słyszałem tu i gdzie indziej, jedyną rozsądną rzeczą do zrobienia w każdym konkretnym przypadku jest oczywiście BENCHMARKU i sprawdzić je dla siebie. można łatwo oszacować połączeń napowietrznych MEX pisząc trywialny funkcji MEX:

#include "mex.h" 
void mexFunction(int nlhs, mxArray *plhs[ ], int nrhs, const mxArray *prhs[ ]) 
{  
} 

Na moim komputerze masz

tic; for i=1:1000000; mexFun; end; toc 
Elapsed time is 2.104849 seconds. 

To 2e-6s napowietrznych za MEX rozmowy.Dodaj swój kod, czas i zobacz, czy obciążenie jest na akceptowalnym poziomie, czy nie.

Jak zauważył Andrew Janke poniżej (dziękuję!), Funkcja MEX na ogół zależy od liczby argumentów przekazywanych do funkcji MEX. Jest to mała zależność, ale jest tam:

a = ones(1000,1); 
tic; for i=1:1000000; mexFun(a); end; toc 
Elapsed time is 2.41 seconds. 

to nie jest związane z wielkością a:

a = ones(1000000,1); 
tic; for i=1:1000000; mexFun(a); end; toc 
Elapsed time is 2.41805 seconds. 

Ale to jest związane z liczbą argumentów

a = ones(1000000,1); 
b = ones(1000000,1); 
tic; for i=1:1000000; mexFun(a, b); end; toc 
Elapsed time is 2.690237 seconds. 

Więc możesz wziąć to pod uwagę w swoich testach.

Answer 2

Powinieneś bezwzględnie bez wahania przenieść pętlę do pliku mex. Poniższy przykład demonstruje 1000-krotne przyspieszenie dla praktycznie pustej jednostki pracy w pętli for. Oczywiście, gdy ilość pracy w pętli for ulegnie zmianie, to przyspieszenie będzie się zmniejszać.

Oto przykład różnicą,

funkcji Mex bez pętli wewnętrznej:

#include "mex.h" 
void mexFunction(int nlhs, mxArray *plhs[ ], int nrhs, const mxArray *prhs[ ]) 
{  
    int i=1;  
    plhs[0] = mxCreateDoubleScalar(i); 
} 

wywoływane w Matlab:

tic;for i=1:1000000;donothing();end;toc 
Elapsed time is 3.683634 seconds. 

funkcja Mex z pętli wewnętrznej:

#include "mex.h" 
void mexFunction(int nlhs, mxArray *plhs[ ], int nrhs, const mxArray *prhs[ ]) 
{  
    int M = mxGetScalar(prhs[0]); 
    plhs[0] = mxCreateNumericMatrix(M, 1, mxDOUBLE_CLASS, mxREAL); 
    double* mymat = mxGetPr(plhs[0]); 
    for (int i=0; i< M; i++) 
     mymat[i] = M-i; 
} 

Powołani w Matlab:

tic; a = donothing(1000000); toc 
Elapsed time is 0.003350 seconds. 

Answer 3

Cóż, jest to najszybszy mogę to zrobić w Matlab:

%#eml 
function L = test(s,t) 

    m = numel(s); 
    n = numel(t); 

    % trivial cases 
    if m==0 && n==0 
     L = 0; return; end 
    if n==0 
     L = m; return; end 
    if m==0 
     L = n; return; end 

    % non-trivial cases 
    M = zeros(m+1,n+1);  
    M(:,1) = 0:m; 

    for j = 2:n+1 
     for i = 2:m+1 
      M(i,j) = min([ 
       M(i-1,j) + 1 
       M(i,j-1) + 1 
       M(i-1,j-1) + (s(i-1)~=t(j-1)); 
       ]); 
     end 
    end 

    L = min(M(end,:)); 

end 

można skompilować i uruchomić to jakieś testy? (Z jakiegoś dziwnego powodu kompilacja nie działa na mojej instalacji ...) Być może najpierw zmień %#eml na %#codegen, jeśli uważasz, że to jest łatwiejsze.

UWAGA: w przypadku wersji C należy również zamienić pętle for, tak aby pętla nad j była wewnętrzną.

Ponadto, podejście row1 i row2 zapewnia znacznie większą wydajność pamięci. Jeśli masz zamiar skompilować i tak, użyłbym tego podejścia.