Parallel programming: parfor vs for computing time
10 views (last 30 days)
I'm interested in learning parallel programming in matlab. For that reason I tried some scripts in matlab using both the function for and parfor, just to explore the differences between them and the time that took both to run the script. I am yet to see a script where parfor runs in less time than a for cycle... I'm starting to think that the problem might be of my computer instead of my scripts..
My processor is dual-core, and whenever I use parfor I first run the function matlabpool open 2.
Can anyone tell me if the problem is from my computer or my scripts? If possible can anyone give me a simple script that should run faster with parfor so I can test it against a normal version using for?
Thanks in advance. Jaló.
Sumit Tandon on 9 Aug 2012
Performance improvement when using PARFOR vs FOR loops depends on several factors including but not limited to:
0. Serial code performance - If the serial code in MATLAB is not efficient, parallelizing it would not give too much benefit. Use techniques and tools like vectorization, preallocation and the MATLAB Profiler to improve the serial code itself. See this
1. Size and type of the problem - If the problem is not large enough or it a large part of it cannot be represented as time and data independent iterations, speed up will be small
2. Number of workers - If there are too many workers, then a lot of time is spent on the data distribution part
3. Location of workers - Local vs cluster - network latency can play a role here
4. File and path dependencies - Functions specified as file dependencies are sent to workers as zip files - which means more data transfer
As for testing performance gain, something like below can give you an idea of the speed up:
c(:,i) = eig(rand(1000));
The videos here talk about some of these things in more detail.
More Answers (2)
Walter Roberson on 9 Aug 2012
I would expect that you might improve by using functions instead of scripts. Until one of the very recent releases, scripts were not accelerated.
Jason Ross on 9 Aug 2012
In addition to Sumit's response, you also have to take a look at the machine itself. If you open too many worker processes, you can take more resources than the machine has to give, and end up taking longer since you have to wait on some shared resource like memory or disk access.