11

When I have the parallel computing toolbox installed and use parfor in my code, MATLAB starts the pool automatically once it reaches the parfor loop. This however makes it difficult to debug at times, which is why I would like to prevent MATLAB from opening a pool in certain situations. So, how can I tell MATLAB not to open a pool? Obviously I could go through my code and remove all parfor loops and replace them with normal for loops, but this is tedious and I might forget to undo my changes.

edit: To specify, I ideally would like the parfor loop to behave exactly like a for when setting a control or variable or something. That is, I should for example also be able to place breakpoints in the for-loop.

user1809923
  • 1,235
  • 3
  • 12
  • 27

3 Answers3

7

Under Home->parallel->parallel preferences you can deselect the check box "Automatically create a parallel pool (if one doesn't already exist) when parallel keywords are executed." This makes all the parfor loops behave as a normal for loop.

I'll get back to you if I figure out a way to do this in the code as opposed to using the check box.

Update turns out it is indeed possible to change the settings through code, although I would not recommend this, as it involves changing MATLAB's preference file. This is taken from the Undocumented MATLAB blog by Yair Altman.

ps = parallel.Settings;
ps.Pool
ans = 
  PoolSettings with properties:
                            AutoCreate: 1
                RestartOnClusterChange: 1
    RestartOnPreferredNumWorkersChange: 1
                           IdleTimeout: 30
                   PreferredNumWorkers: 12

where you need to change the AutoCreate switch to 0.

As alternative I'd suggest wrapping everything inside your parfor in a function, thus calling

parfor 1:N
    output = function(..)
end

Now modify your script/function to have a Parallel switch on top:

if Parallel
    parfor 1:N
        output = function(..)
    end
else
    for 1:N
        output = function(..)
    end
end

You can edit and debug the function itself and set your switch on top of your program to execute in parallel or serial.

Adriaan
  • 17,741
  • 7
  • 42
  • 75
  • That setting just controls whether a pool is automatically created or not. If there's no pool available, the `parfor` will execute on the local machine - but it is still a `parfor` loop, and it is not the same as a `for` loop. For example, there is no guarantee about the order in which the loop iterations will be executed, and there are still restrictions on the code that can be placed within the loop. – Sam Roberts Jan 29 '16 at 12:06
  • 1
    Previous to your post I did not know about this setting and its certainly useful to know about it, due to the reasons Sam stated however, it still is not the ideal solution. The alternative you mentioned probably actually is the only "solution" fully covering my needs so far. Even though I feel like it is still not ideal (so much "dead"-code) I will accept this as an answer - one year to find better solutions was enough, I guess ;) – user1809923 May 02 '16 at 06:13
5

As well as the normal syntax

parfor i = 1:10

you can also use

parfor (i = 1:10, N)

where N is the maximum number of workers to be used in the loop. N can be a variable set by other parts of the code, so you can effectively turn on and off parallelism by setting the variable N to 1 or 0.


Edit: to be clear, this only controls the number of workers on which the code is executed (and if N is zero, whether a pool is started at all). If no pool exists, the code will execute on the client. Nevertheless, the code remains a parfor loop, which does not have the same semantics as a for loop - there are restrictions on the loop code for parfor loops that do not exist for for loops, and there is no guarantee on the order in which the loop iterations are executed.

When you use parfor, you're doing more than just saying "speed this up please". You're saying to MATLAB "I can guarantee to you that the iterations of this loop are independent, and can be executed in any order, so you will be OK if you try to parallelize it". Because you've guaranteed that, MATLAB is able to speed things up by using different semantics than it would do for a for loop.

The only way to completely get for loop behaviour is to use for, and if you need to switch back and forth for debugging purposes you'll need to comment and uncomment the for/parfor (or perhaps use an if/else block, switching between a for and a parfor depending on some variable).

Sam Roberts
  • 23,951
  • 1
  • 40
  • 64
  • Nice, did not know that. But I do not think parfor (i = 1:10, 1) behaves like a normal for in terms of debugging (see my comment to Dennis' answer) – user1809923 Aug 12 '14 at 12:47
  • 1
    N=1 runs the code on a worker, unlike the for loop. I think N=0 is possible to run it on your primary MATLAB instance but I would have to test it. – Daniel Jan 29 '16 at 11:39
  • 1
    I tested it with N=0, it runs on the primary matlab instance, but still has major limitations when debugging. A simple `dbstop if error` did not work. – Daniel Jan 29 '16 at 11:45
  • @Daniel that's correct. Setting N to 0 will ensure that no workers are started up and that the code runs on the client MATLAB - but it is still run as a `parfor` loop, not as a `for` loop, and they have different semantics. Not only does debugging not work, but there are still restrictions on the code that can go within the loop, and there is no guarantee on the order in which the loop iterations are executed. (I think I'm right that PCT actually deliberately executes them in reverse order, in order to make sure that people think about this restriction). – Sam Roberts Jan 29 '16 at 12:01
2

I think that the way to go here, is not to disable the parfor, but rather to let it behave like a simple for.

This should be possible by setting the number of workers to 1.

parpool(1)

Depending on your code you may be able to just do this once before you run the code, or perhaps you need to do this (conditionally) each time when you set the number of workers anywhere in your code.

Dennis Jaheruddin
  • 21,208
  • 8
  • 66
  • 122
  • Well, I do not think this behaves like a normal for then in terms of debugging. If I enable "stop on errors", include an error in my parfor loop, set parpool(1) and start my script an error is thrown but the script is not stopped at the error but in the parallel function. – user1809923 Aug 12 '14 at 12:46
  • @user1809923 Could you update your question with a minimal working example that reproduces this problem? (And clearly state where it stops and where the error occurs). – Dennis Jaheruddin Aug 12 '14 at 13:11
  • 2
    @DennisJaheruddin: Running it with parpool(1) is a major difference. It actually runs the code on a single worker which is connected via a localhost network connection to your primary matlab instance. To my knowledge there is no debugging on worker threads, no matter if you have one or multiple of them. – Daniel Jan 29 '16 at 11:41