Answers.Body: <p>The correct number of child processes will depend on the hardware available to you.</p>
  
  <p>Simplifying a bit, child processes can be in one of two states: waiting for memory or disk access, or running.</p>
  
  <p>If your problem fits nicely in your computers' memory, then processes will spend almost all of their time running. If it's too big for memory, they will periodically need to wait for disk.</p>
  
  <p>You should use approximately 1 Child process per CPU core. If you are training on a GPU, then it depends whether the process can make use of the entire GPU at once (in which case, use just 1), or whether a "process" is really more like a CUDA thread here (in which case you'd want one per CUDA core).</p>
  
  <p>If you think your processes will wait for disk, use more than one per core. About 50% more is a good starting point. You can use a program like <a href="https://en.wikipedia.org/wiki/Top_(software)" rel="nofollow noreferrer">top</a> to monitor CPU usage and adjust the number of processes accordingly.</p>
  
  <p>To answer your question more explicitly:</p>
  
  <ul>
  <li>Having more child processes (up to a point, discussed above), will increase hardware utilization, and make your training run faster. With a Core i7 CPU for instance, you might be able to run 8 or 16 child processes at a time, so you'd train 8-16x times faster.</li>
  <li>Having more child processes than processing units (CPU cores, CUDA cores), will begin to cause frequent context switching, where the processing units have to pause to change between different jobs. Changing jobs is extremely expensive, and ultimately, your program cannot train faster than it would by using all the available hardware. If you have more processes than processing units, reducing the number should make your program train faster.</li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-08-26T11:20:03.450Z
Answers.LastActivityDate: 2018-08-26T11:20:03.450Z
Answers.UserDisplayName: John Doucette
Body: <p>In A3C, there are several child processes and one master process. The child precesses calculate the loss and backpropagation, and the master process sums them up and updates the parameters, if I understand it correctly.</p>
  <p>But I wonder how I should decide the number of the child processes to implement. I think the more child processes are, the better it is to disentangle the correlation between the samples is, but I'm not sure what is the cons of setting a large number of child processes.</p>
  <p>Maybe the more child processes are, the larger the variance of the gradient is, leading to the instability of the learning? Or is there any other reason?</p>
  <p>And finally, how should I decide the number of the child processes?</p>
  
Tags: <reinforcement-learning><deep-rl><hyperparameter-optimization><hyper-parameters><a3c>
Title: What is the pros and cons of increasing and decreasing the number of worker processes in A3C?
UserDisplayName: Blaszard
ThreadText: # What is the pros and cons of increasing and decreasing the number of worker processes in A3C?
  
  (Asked by: username_0 on 2018-08-26)
  
  In A3C, there are several child processes and one master process. The child precesses calculate the loss and backpropagation, and the master process sums them up and updates the parameters, if I understand it correctly.
  
  But I wonder how I should decide the number of the child processes to implement. I think the more child processes are, the better it is to disentangle the correlation between the samples is, but I'm not sure what is the cons of setting a large number of child processes.
  
  Maybe the more child processes are, the larger the variance of the gradient is, leading to the instability of the learning? Or is there any other reason?
  
  And finally, how should I decide the number of the child processes?
  
  **Tags:** reinforcement-learning, deep-rl, hyperparameter-optimization, hyper-parameters, a3c
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2018-08-26. Score: 3 | Accepted answer
  
  The correct number of child processes will depend on the hardware available to you.
  
  Simplifying a bit, child processes can be in one of two states: waiting for memory or disk access, or running.
  
  If your problem fits nicely in your computers' memory, then processes will spend almost all of their time running. If it's too big for memory, they will periodically need to wait for disk.
  
  You should use approximately 1 Child process per CPU core. If you are training on a GPU, then it depends whether the process can make use of the entire GPU at once (in which case, use just 1), or whether a "process" is really more like a CUDA thread here (in which case you'd want one per CUDA core).
  
  If you think your processes will wait for disk, use more than one per core. About 50% more is a good starting point. You can use a program like [top](https://en.wikipedia.org/wiki/Top_(software)) to monitor CPU usage and adjust the number of processes accordingly.
  
  To answer your question more explicitly:
  
  * Having more child processes (up to a point, discussed above), will increase hardware utilization, and make your training run faster. With a Core i7 CPU for instance, you might be able to run 8 or 16 child processes at a time, so you'd train 8-16x times faster.
  * Having more child processes than processing units (CPU cores, CUDA cores), will begin to cause frequent context switching, where the processing units have to pause to change between different jobs. Changing jobs is extremely expensive, and ultimately, your program cannot train faster than it would by using all the available hardware. If you have more processes than processing units, reducing the number should make your program train faster.
  
  
  ---
  
  