在大型仿真中改善Matlab功能

Question

I have a very big Matlab simulation project in my hands, which I wanted to optimize, since I'm running it many times to tune parameters and the like.

Using Matlab's profile I identified one function that is eating up most of my time, specifically the line output(i,1)= max(mean(dens(i+1:a,1)),dens(i+1,1));

This function is called a LOT , where input is a 10x1 double passed as an argument, and output is also a 10x1 vector.

function output = my_function(input)

a = size(input,1);
output = input*0;
dens = density(input);

% for each i, output(i) is the maximum between output(i+1) and mean(output(i+1:end))
for i = 1:a-1
    output(i,1)= max(mean(dens(i+1:a,1)),dens(i+1,1));
end
output(a,1) = dens(a,1);

end

My ideas:

• I think vectorization would maybe help to get rid of the loop (?), but I'm not familiar at all with the technique.
• Is there a faster/alternative way to calculate the mean (maybe without Matlab's built-in function call?)

---

EDIT I tried to vectorize the function, and I got the following alternative result, which performs the same operations:

function output = my_function_vectorized(input)

a = size(input,1);
rho_ref = zeros(size(input));
dens = density(input);

temp_cumsum = flip(cumsum(flip(dens))./(1:1:a)');
output = [max(temp_cumsum(2:end),dens(2:a));dens(a)];

end

I tried testing both function in the following way:

Ts = random('unif',40,80,10,1000);
Results_original = zeros(size(Ts));
Results_vectorized = zeros(size(Ts));
TIMES_original = zeros(size(Ts,2),1);
TIMES_vectorized = zeros(size(Ts,2),1);

for ii = 1:size(Ts,2)
    tic;
    Results_original(:,ii) = my_function(Ts(:,ii));
    TIMES_original(ii) = toc;
end

for ii = 1:size(Ts,2)
    tic;
    Results_vectorized(:,ii) = my_function_vectorized(Ts(:,ii));
    TIMES_vectorized(ii) = toc;
end

res = norm(Res_1 - Res_2);
mTIMES_original = mean(TIMES_original);
mTIMES_vectorized = mean(TIMES_vectorized);

For which I get:

res =

   3.1815e-12

mTIMES_original/mTIMEZ_vectorized =

   3.0279

• Should this residual be concerning to me?
• Is it correct to say that I have fastened this computation by a factor of 3?

Answer 1

Vectorize it.

The re-read of dens is what is killing you, not the mean. Mean is as optimized as Donald Knuth can make it.

I don't know your density function, so I can't be sure about my indexing.

Pseudocode snips:

%(1)faster predeclaration that shows intent
output=zeroes(size(input))

%(2)vectorize your "mean between here and the end"
b = fliplr(fliplr(cumsum(dens(1:a-1)))./fliplr(1:a-1))

%(3)assemble your interior nX2 matrix 
c = [b,dens]

%(4)vectorized max, I think
output = max(c,[],2)

(1) it is hard to beat the built-ins for speed and efficiency. It is also nice to be able to figure out a year from now what your code does. Over time I find myself trying to be more and more of a literate programmer ( link ) because it is less time expensive in the long run than coming back in a year or ten and trying to reverse engineer my own work.

(2) the idea here is to flip the density vector around, then make a cumulative sum, then divide each element of the reversed cumulative sum by how many points fed into it, then flip it around again. When you divide that sum by the count - it becomes a mean. I just read the description (link) and there is an internal switch so you can restate this without the fliplr's and make it even more fast.

b = cumsum(dens(1:a-1),'reverse')./(a-1:-1:1) %this might work

(3) in theory when this is done you should have a matrix that is two columns wide, and has as many rows as "dens" does. resizing and predeclaring can be expensive - so if you are changing sizes often then you might want to pre-declare it like (1).

(4) the "max" function is going to be screaming fast too. Not you nor Mr. Knuth are going to make it faster. I think that one compare (silicon op) for each element of the array and a few shuffles (less than one per element) are all that is required.

This is an element-wise max. (I forgot to add the buffer in the middle). It is already made fast and its output is an array. It may need a 1 instead of a 2, but you know what you are doing there and can figure that out.

Let me know if that works for you. I'm guessing it might give no more than 5x improvement.

I was stunned to find that LabVIEW can do some fundamentals 100x faster than MatLab because it is (always) compiled. When compiling in MatLab one must impose many new constraints on types and values, but in LV the compiling mostly pain-free because all of that constraining was part of the initial program creation. If you find the heart of your MatLab program isn't fast enough, you can make a wrapper for LV and run it much (much much) faster there with very little heartache. LV doesn't do elaborate - there is a reason why we use text for books instead of pictures (or individualized renderings of the topic by da Vinci, as a more correct metaphor).

EDIT: (about speed)

It looks like you are ~3x faster.

EDIT: (about code, note I'm using 2014a)

clc; format short g;
a = 1:15
mu = fliplr(cumsum(fliplr(a))./(1:length(a)))

which gives:

a =

     1     2     3     4     5     6     7     8     9    10    11    12    13    14    15


mu =

  Columns 1 through 9

            8          8.5            9          9.5           10         10.5           11         11.5           12

  Columns 10 through 15

         12.5           13         13.5           14         14.5           15

So I make "a", a vector starting at 1 and going to 15. The last value is 15. The average between the 2nd to the last value and the last is 14.5. The average of the last 3 values is 14. The math seems to be working here.

Edit:

One great speedup was to switch off of the current java-based system. I have seen code get a large (better than 3x) speed boost by running in the version 2010a. Some code runs substantially slower when run through Java than when run through Fortran or C-based compiled libraries.

Answer 2

As has already been suggested, you can consider vectorizing your code; however, realistically, I'm not sure how much improvement that would really offer, in this case. Firstly, keep in mind that although in older versions of MATLAB for loops were generally considered very inefficient compared to vectorized approaches, due to the JIT accelerator in modern-day MATLAB, for loops aren't as big of an issue (performance wise) as they were several years ago.

Secondly, consider that if you have to jump through hoops to try to get your data into a form that can execute vectorized commands (which looks like it might be the case, here), then it might be a wash -- meaning that performance benefits of executing a vectorized command is outweighed by the time it takes to manipulate the data into the necessary vectorized form (and could potentially make your code thoroughly unreadible, open to potential bugs, and difficult to maintain).

That, of course, is not to say that vectorization won't at all be helpful in your case (the only real way to know is to give it a shot and profile it), but just realize the potential limitations.

In addition to the suggestions made by EngrStudent, I would also suggest taking a look at the article Accelerating MATLAB Algorithms and Applications from the MathWorks.

In particular, two of the options described in this article jumped out at me as being potentially helpful in your case.

The first is to convert your function to a MATLAB executable (MEX-function) . This is a fairly straightforward process that involves using MATLAB Coder to automatically generate C code from your function which can then be compiled as an executable MEX-function. I suspect that this offers the greatest potential for performance improvement. (And if you don't have the MATLAB Coder toolbox you could also consider manually writing a C code version of your function (or at least the time-intensive portion of it) and using this to produce a MEX function that you can use in MATLAB).

The second would be to make use of parallel computing . For example, because each iteration of your for loop functions independently from one another, you could potentially replace this with a parallel for loop ( parfor ). Additionally, perhaps other parts of your overarching system or workflow could be parallelized. This approach would obviously require access to the Parallel Computing Toolbox as well as a multi-core processor (or a cluster), so this might be of limited use to you... but if you have access to those resources, then this could be very beneficial for performance.