Answers.Body: <p>After a whole epoch, with multiple update steps, the neural networks in each thread will have diverged in a way where it may not make sense to take means of the weights. Ideally you should be combining data for each update step. In turn that means you will want to avoid making updates on every example, because the overhead of starting, stopping and combining the threads may lose most of the benefits.</p>
  <p>It is common in neural networks to use mini-batches (larger than 1, smaller than the whole dataset), to get more accurate gradients, and for parallelisation. There is often a sweet spot in terms of learning speed (or sample efficiency) with some size of mini-batch. Each mini-batch calculates gradients for all examples, combines them into a mean gradient, then performs a single weight update step.</p>
  <p>Use your threads to calculate the gradients for a mini-batch, divided up between the threads, and average the gradients across all threads in order to make a single shared weight update. Using larger mini-batches will make more efficient use of multiple threads, but smaller mini-batches can be beneficial because you get to make more weight updates per epoch.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-08-28T20:53:31.173Z
Answers.Text: I am not sure if I really got what you mean: The adding and dividing by n to synchronize the weights is correct but I should use mini-batches (= subset of the training set) instead of the whole set. Does this mean I use more threads or do I just use like 50% of the data in a thread per epoch?
  This "sweet spot", how do I know where it is and is there a specific strategy to find it?
Answers.UserDisplayName: CptK
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-08-28T21:01:04.240Z
Answers.Text: @CptK: You will need to experiment with suitable mini-batch sizes, and these will vary depending on the problem. You may also find that the approach that makes most efficient use of threading is not the fastest overall, and there may even be measurable differences in learning metrics that mean the neural network has best results when neither fastest nor most efficient (although IME above a relatively small mini-batch size, the batch-size choice is mainly about speed).
Answers.UserDisplayName: Neil Slater
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-08-28T20:32:13.533Z
Answers.LastActivityDate: 2021-08-28T20:53:21.950Z
Answers.LastEditDate: 2021-08-28T20:53:21.950Z
Answers.UserDisplayName: Neil Slater
Body: <p>I implemented a parallel backpropagation algorithm that uses <span class="math-container">$n$</span> threads. Now every thread gets <span class="math-container">$\dfrac{1}{n}$</span> examples of the training data and updates its instance of the net with it. After every epoch the different threads share their updated weights. For that I simply add the weights of the threads and then divide each weight by the number of threads. The problem now is that the more threads I use the worse the result. For me this means that my way of synchronizing the threads is not as good as it should be.</p>
  <p>Is there a better way to do it?</p>
  
Tags: <backpropagation>
Title: Parallelize Backpropagation - How to synchronize the weights of each thread?
UserDisplayName: CptK
ThreadText: # Parallelize Backpropagation - How to synchronize the weights of each thread?
  
  (Asked by: username_0 on 2021-08-28)
  
  I implemented a parallel backpropagation algorithm that uses $n$ threads. Now every thread gets $\dfrac{1}{n}$ examples of the training data and updates its instance of the net with it. After every epoch the different threads share their updated weights. For that I simply add the weights of the threads and then divide each weight by the number of threads. The problem now is that the more threads I use the worse the result. For me this means that my way of synchronizing the threads is not as good as it should be.
  
  Is there a better way to do it?
  
  **Tags:** backpropagation
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2021-08-28. Score: 1
  
  After a whole epoch, with multiple update steps, the neural networks in each thread will have diverged in a way where it may not make sense to take means of the weights. Ideally you should be combining data for each update step. In turn that means you will want to avoid making updates on every example, because the overhead of starting, stopping and combining the threads may lose most of the benefits.
  
  It is common in neural networks to use mini-batches (larger than 1, smaller than the whole dataset), to get more accurate gradients, and for parallelisation. There is often a sweet spot in terms of learning speed (or sample efficiency) with some size of mini-batch. Each mini-batch calculates gradients for all examples, combines them into a mean gradient, then performs a single weight update step.
  
  Use your threads to calculate the gradients for a mini-batch, divided up between the threads, and average the gradients across all threads in order to make a single shared weight update. Using larger mini-batches will make more efficient use of multiple threads, but smaller mini-batches can be beneficial because you get to make more weight updates per epoch.
  
  > **Comments:**
  > **username_0**: I am not sure if I really got what you mean: The adding and dividing by n to synchronize the weights is correct but I should use mini-batches (= subset of the training set) instead of the whole set. Does this mean I use more threads or do I just use like 50% of the data in a thread per epoch? This "sweet spot", how do I know where it is and is there a specific strategy to find it?  
  > **username_1**: @CptK: You will need to experiment with suitable mini-batch sizes, and these will vary depending on the problem. You may also find that the approach that makes most efficient use of threading is not the fastest overall, and there may even be measurable differences in learning metrics that mean the neural network has best results when neither fastest nor most efficient (although IME above a relatively small mini-batch size, the batch-size choice is mainly about speed).  
  
  ---
  
  