Processor usage
18 views (last 30 days)
Show older comments
So, I wrote a quite complicated model of an air bearing. As I've been developing this model for three years, it started out very simple and has been getting complex. So, at the beginning I just used variables in the workspace and handled them to the functions one after the other. Now the model and the variables list is HUGE. Yesterday the code was running just fine, using both cores to 100%. Sometimes I ran it in another computer I have which has 4 cores and it would run the 4 cores to 100%. So yesterday I thought of the brilliant idea of grouping these variables to structures, so my code would be a lot more elegant and it would be easier for me to handle data from one function to the other and etc. I commited the BIG mistake of not saving a copy of this running code 'cause I never thought this would happen but, anyway. Today the code runs fine, but WON'T use the processors to 100%. I have tried reading on the web about this multi core stuff but I can't really understand what could have changed in the code for it to run that much slower. So I ran the profiler to see if by re writing a lot of the code and how functions handle data I wrote a bottleneck I did not expect and NO, the profiler recognizes the most heavy parts as lines that were just like that before I re-wrote the code. I like the new code a lot more since it is WAY cleaner than the huge-variable-list functions I used to have. So I would like to know what could have changed that would not allow the processor to run at full capacity.
To summarize, I had a code with a big variable list in the workspace, and I handled them to functions separately, so I thought of grouping these variables to different structures, and just handle 3 or 4 structures to each of the functions I call. That is basically all I did.
PS: And just to test if it was something wrong with my MATLAB or my PC, I ran another previous model I had and both processors went to 100% right from the beginning, so I is definitely something with the new structured code.
Thanks in advance.
1 Comment
Stephen
on 23 Mar 2012
To my knowledge, extra processors will only kick in if the MATLAB algorithm forecasts a level of speed improvement above a certain threshold, because partitioning calculations to into multiple threads adds computation time. So if your computer has dormant cores, it could be because MATLAB doesn't want to steal the processor speed from internet browsing while you are waiting for results.
Without the original code it is hard to perform a benchmark test on your code, but the first step in solving this question is to check to see if the code is running faster or slower isn't it? If your code was inelegant and required all your processors to execute, and now your code is elegant and does not utilize all processing available, that could mean you changed something for the worse, OR it could mean you made your code much more efficient and the extra power isn't necessary.
Answers (9)
Titus Edelhofer
on 29 Mar 2012
Hi Juan,
this is indeed most likely a multithreading issue: unless you are using the Parallel Computing Toolbox ("explicit parallelism"), MATLAB will use more then 25% on a quad core (13% if with hyperthreading) only if it calls linear algebra routines that are multithreaded (search doc for multithreaded and you will find some explanations and functions that have been changed to support multithreading). But in any case the profile should tell you the lines that got slower (or faster). May be it's worth to start the profile including builtin functions:
profile on -detail builtin
Titus
0 Comments
Juan P. Viera
on 29 Mar 2012
1 Comment
Titus Edelhofer
on 29 Mar 2012
Hi,
one more comment on multithreading: general speaking, MATLAB is single threaded. It's only that some of builtin functions like eig, multiplication, qr etc. are multithreaded. So it's not, that a whole function or script is multithreaded.
Some other thing that comes to my mind: assignin could have another effect, it changes workspaces in a way the accelerator (JIT) in MATLAB doesn't like. It could be, that the JIT handles cases with explicit variable transfer better. But again, without taking a closer look it's probably viping dust only ...
Titus
Titus Edelhofer
on 29 Mar 2012
Hi Juan,
in the (are you using Windows?) taskmanager you can assign a process (i.e. MATLAB) to run on one (or more) cores. Doing this you would compare codes without multithreading differences ...
Assignin is definetely not multithreaded, since it "just" moves variables around. Although it is not a preferred way of variable passing, it on the other hand should not be responsible (really) ...
Sorry for not having much more advice ...
Titus
0 Comments
Jan
on 12 Jul 2012
Multi-threading and 100% processor usage are no guarantee for small run-times. Variables created by the evil ASSIGNIN, EVAL or EVALIN create entries in the dynamic lookup table of variables, while the hard coded transfer of variables as input and output allow the JIT acceleration to use a direct adressing. After the dynamic lookup table has been populated, Matlab has to check it even for calls of built-in functions: Imagine that you create a variable called "sin" by ASSIGNIN and use "sin(2)" in the main function. The decision if "sin(2)" means the function or the variable wastes time. Btw. this is handled even differently in debug and non-debug mode - cruel!
It is very easy to create a multi-threaded function with 100% load on 8 cores, which needs exactly the same run-time as a single-threaded version: False cache sharing can move the bottleneck from the calculations to the memory access. A standard example is a large matrix of type single, which is process row-wise in different threads. Then each write access to the matrix cause a time-consuming update of the cachelines of the other cores. Therefore "multi-threading" does not only mean to let more cores process the same data, but an adjusted data representation is required for efficient processing.
2 Comments
Jan
on 12 Jul 2012
For "normal" people or for Matlab users? :-)
Without seeing the code and a detailed analysis, explanations are more or less pure speculations only. So the following is not an educated guess:
ASSIGNIN creates a variable in the caller's (or base) workspace. There this variable appears magically, and the parser of the M-file cannot know, where this variable is comming from or which type it has. Therefore the variable (better: a pointer to it) has to be stored in a dynamically created list, a lookup table. When this variable appears the next time in the Matlab code, this table has to be checked at first to find the pointer to the actual data. But Matlab has to decide in addition, if the name is a local function, function in the current folder, user-defined function, builtin function or Java class.
In opposite to this hard coded variables and variables provided as output of other functions can be accessed more efficiently, because it is known already, that they are variables.
A similar problem appears, when the type of a variable is changed inside a function. Then the JIT acceleration cannot use the pointer to the variable directly, but obviously a lookup table method is applied.
per isakson
on 12 Jul 2012
Edited: per isakson
on 12 Jul 2012
In discussions on performance of Matlab version of Matlab, the OS and the use of the Parallel Toolbox are all important.
According to a previous answer by Titus Edelhofer (The Mathworks)
... MATLAB is single threaded. It's only that some of builtin
functions like eig, multiplication, qr etc. are multithreaded.
Thus, your code is dominated by builtin functions, which are multi-threaded. That's why you see 100% cpu usage.
You ask
Could it be memory related? I have 4GB and all the time I have
more than 2 available so I don't know.
I have fooled myself lately by focusing on Available memory. I run R2012a 64bit on Windows 7 with 8GB.
Does Free Memory ever decreases to low values (/zero)? If it does that is part of the problem. I find the behavior of Windows' System Cache difficult to understand. And the task managers way of showing memory usage a bit misleading. You don't read large files(?)
Your "unpack" function creates a bunch of new variables. That doesn't requires much memory until values of the new variables are changed (lazy-copy). Does that happen to large arrays?
It is possible to get information on the memory usage from profile. See: Undocumented profiler options
Matlab has this piece of magic code, which they call "Accelerator", part of which is a just in time compiler, JIT. (Or Accelerator is JIT?) The Mathworks develops the accelerator actively and they argue that we, the ordinary users, should not craft our code to fit the current state of the accelerator. The accelerator is not documented.
My guess: The major reason for the performance issues you see is related to the Accelerator. As Jan describe variables "popping up in the workspace" (my words) certainly causes problems to JIT. assignin, eval, load('...mat), etc. does that.
The Julia Language indicates that the accelerator can be further improved. However, backward compatibility makes things difficult - I guess. There was an informative video on Julia, but I cannot find it now.
0 Comments
See Also
Categories
Find more on Performance and Memory in Help Center and File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!