Small Matrix (30x1) using significant time/memory to update in a loop
Afficher commentaires plus anciens
I have a small vector Rv (30x1) which need to be updated in every loop. Before going in the loop, I have initiated the vector assigning values zeros. On profiling (with memory and time), I find that this updating step takes a significant amount of time compared to others. Also, the memory usage seems to be higher than for what a 30x1 matrix should use. I am attaching the image of profiler analysis. All the other variables appearing (like Kd K_Ir_Ac etc) are simple scaler variables.
What am I missing? What can I do the reduce the overhead in terms of memory and time usage?
This analysis was done for only a fraction of total time to test the complete function. On running the code upto final point (~100-200 times more loops that in this test run), these times will matter. And moreover, this is just out of curiosity as well!!
1 commentaire
dpb
le 24 Déc 2013
Not enough info to tell for certain as there's no context to know what's invariant and what's not as well as sizes of everything else presuming some may not be simply constants?
Firstly, however, is there at least one redundant computation of the same values -- start by factoring the denominator out entirely from each computation and do it once at the end.
I didn't try to read the mishmash of similarly named variables to try to see what, if anything else, could either be factored or at least computed only once as a subfactor and used multiple locations.
But, need more context most of all methinks...
Réponse acceptée
John D'Errico
le 24 Déc 2013
Preallocating this vector with zeros is a waste of time! At least it is if immediately after that, you replace the entire vector with other numbers. So don't waste that time. (In general, preallocation is a VERY smart thing to do.)
Next, how many times must MATLAB compute the product (Nav*V), and then divide by it? Why force a computation to be done repeatedly? In fact, you go further than that, since you form things like Ir/(Nav*V) multiple times.
Next, I'd not be at all surprised to find that there is a difference in time between
Rv = zeros(30,1);
Rv(:,1) = [stuff];
and
Rv = [stuff];
Next, are ALL of these scalar variables changing all of the time? I would sincerely bet they are not. So why not precompute some parts of this vector and save the results?
Finally, I was going to try optimizing how your line is written, but since it is an image, I cannot copy it into the MATLAB editor.
18 commentaires
Sean de Wolski
le 24 Déc 2013
He's using the profiler which is a great first step, credit where due!
Amit
le 24 Déc 2013
Walter Roberson
le 24 Déc 2013
The copying of the right hand side into Rv(:,1) is likely to take more time than recreating Rv.
When the right hand side is computed, an unnamed variable is created that describes the block of memory and points to its contents.
Then to assign it to a variable involves releasing what was there previously and pointing the symbol table entry to the existing anonymous descriptor.
When it is instead copied into Rv(:,1), the anonymous right-hand side is still computed, and the data block associated with the left hand side is located and a memory copy is done; then the space associated with the anonymous right-hand side is released. Difference in speed: copying the data.
dpb
le 24 Déc 2013
To amplify a little on Walter's and John's point on the preallocation -- IF (the proverbial "big if") you were filling an array by computing each individual array element in a loop sotoo
for i=1:N
x(i)=RHS(i);
end
then preallocating would make a difference if x didn't already exist as Matlab otherwise would have to allocate a new array every pass thru, copying the new, expanded array into the original and destroying it. OTOH, if the whole array is there up front, then it does avoid that reallocation.
In your case, however, you're building a whole RHS vector at one time anyway, so whether the LHS has been previously allocated doesn't really make any big difference UNLESS Rv is more than a vector and Rv(:,2:end) is extant (which it appears from your description it doesn't). In that case the subscripting expression is superfluous and it could possibly actually take more time than simply the expression
Rv=[_RHSexpression_];
without the preallocation and since the whole array is being reassigned every time, there's nothing different in the end result.
Walter Roberson
le 24 Déc 2013
Though by my calculation the memory copying time would be different, less in the case where everything was overwritten.
Amit
le 24 Déc 2013
dpb
le 24 Déc 2013
Probably not but it's easy enough to try/test...
My thought (altho like John since you didn't post code but an image so can't cut'n paste to do anything with it w/o too much effort), would be that of
a) factor what can as much can (already mentioned), then
b) since it appears that each term is essentially(*) A*B*C/D, if you were to be able to build A, B, C as arrays effectively then whole thing could just become
Rv=A.*B.*C/D;
(*) For row 1, C==1 and there may be some others; I didn't try to read every line precisely, but you should get the idea.
John D'Errico
le 25 Déc 2013
No, I don't think doing the elements individually will help, and probably will be worse. Really though, you need to do some tests, because MATLAB's own built-in acceleration may be a factor.
I would definitely factor what you can. My gut says I'd do something like this:
NV = Nav*V;
IrNV = Ir./NV;
ArNV = Ar./NV;
BrNV = Br./NV;
Rv = [Kd*I; ...
[K_Ir_Ac;K_Ir_Bc;K_Ir_Pc;K_Ir_Arc;K_Ir_Brc;K_Ir_Prc;K_Ir_Pirc].*[A;B;P;Ar;Br;Pr;Pir].*IrNV; ...];
Etc. You should get the idea.
I'd still suggest that if many of these numbers are constant, then you don't want to recompute things over and over again.
Agree that if there isn't any way to generalize the terms other than itemize them individually but it's worth looking at I'd think as we don't know where the various terms come from...but there are untold numbers of times where posters ask how to generate a zillion variables from what could and should have been handled as an array. We don't know something of the sort couldn't have led to the above formulation as we're not privy to the additional info--which was my first comment that need more context to answer more generally than just "peephole" optimization of the specific statement.
And of course the factorization of common terms out so they're not recomputed as you've pointed out.
Amit
le 26 Déc 2013
My point is that how are the various Kxxx, etc., computed before the psuedo-code section given?
I'm looking for a generalization of these to perchance vectorize the whole thing instead of enumerating them individually as you have. That would be the only way I see of making much difference but again, whether that's possible is indeterminate w/o seeing what they consist of. It may be that you would need to restructure the earlier data for the ability to get to the vector arrangement. Then again, if they're all just independent semi-random combinations of things or wildly different computations, then you're likely "just stuck".
Also, just out of curiosity, how much does the minor expedient previously noted of writing
Rv=[stuff];
eliminating the preallocation and rewriting into the existing array as currently written help (or hurt)?
ADDENDUM:
Just picking a few at random 'cuz they were close enough by to see at the same time on the monitor -- you've got stuff like
Kp_P1r_Ac
Kp_P1r_Bc
Kp_P1r_Pc
Are these somehow related such that even this subset of three could be combined into a single computational vectorized chunk to load a portion of A in my previous factorization of
A.*B.*C
? The more that could be generalized the better, of course, but again there's not enough context given for us to know whether there's any hope or not; it's just a suggestion of the only way otomh I can see to make any real difference in the single expression posted.
dpb
le 27 Déc 2013
Then move to the next set(s)...the point is to see if can get those that are recalculated into a more nearly vectorized form to make use of the internal routines of Matlab.
While the last case may take less time in the above calculation, will you lose that gain later on by having to deal with that many individual variables perhaps?
Amit
le 27 Déc 2013
dpb
le 27 Déc 2013
BTW, you're doing the timing tests from within m-files, not by pasting code sections at the command line, right?
Amit
le 27 Déc 2013
dpb
le 29 Déc 2013
OK; just wanted to be sure you did get the benefit of the JIT engine included in the testing; otherwise one can draw entirely the wrong conclusion.
Those results are all consistent with what I would have expected.
Again, the only way I can see you can help much is by looking at the code that generates these values earlier on and see what, if anything, can be done there to vectorize that, again with the idea of eventually getting to the vectorized version of the end result. As noted previously, there may not be much else to be done in which case one can then start thinking about mex-ing stuff if there's a serious bottleneck and this will be done more than just once or twice so that can just let it take a couple of hours (or whatever) at some point and then be done with it.
Amit
le 29 Déc 2013
Plus de réponses (0)
Catégories
En savoir plus sur Startup and Shutdown dans Centre d'aide et File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!
Translated by 
