A maneira mais simples para dividir tarefas entre múltiplos “workers” é através de uma

máquina com memória compartilhada, como um processador multi cores, onde há múltiplos
núcleos individuais, cada um trabalhando em uma tarefa ou problema separado e todos
conectados a uma única memória através de um único bus interno, todos podem acessar o
mesmo bit de memória usando o mesmo endereço contanto que não estejam tentando ler
ou escrever ao mesmo tempo nessa parte de memória.

Para máquinas maiores, partimos para o paralelismo de memória distribuída. Nesse caso,
há múltiplas máquinas individuais com múltiplos cores e com sua própria memória
comunicando-se explicitamente através de um protocolo de internet. Com esse tipo de
paralelismo, deve-se atentar aos custos de comunicação e fluxo de trabalho entre cada
máquina. Se uma máquina é mais lenta comparada a outra trabalhando em um trabalho
maior, todas as máquinas restantes devem esperar por essa última máquina para completar
sua tarefa. Um grande processo envolvido em otimização para paralelismo de memória
distribuída é o balanceamento de carregamento, fazendo com que cada máquina tenha a
mesma quantidade de trabalho.

Se tratando de scaling, que podem ser fracos ou fortes. Esperamos que apenas
aumentando o número de máquinas e núcleos estaremos também aumentando a
velocidade que se completa um problema ao mesmo nível, mas isso não é correto. Se por
exemplo, você tem uma parte de um código que deve ser feito em serial, você está lidando
com a lei de Ahmdalhs, e mesmo que você tenha uma grande parte deste código podendo
ser executado em paralelo, digamos 95%, não se tem o aumento de velocidade esperado.
Mesmo que você tenha 200 threads, só vai ter um ganho de aproximadamente 17x, ou seja,
cada thread está operando abaixo dos 10% de sua capacidade se estivesse operando
como um programa singlethread. Então para um único problema, com um tamanho fixado, a
não ser que tudo esteja sendo executado em paralelo, não haverá muito benefício para um
grande número de processadores. No entanto, se você for no sentido de aumentar o
tamanho do problema você não está mais lidando com a lei de Ahmdalhs, e sim com a lei
de Gustavson que tem um comportamento de scaling muito diferente, você realmente pode
abordar o nível de scaling que se espera para o número de threads, mas diferente da lei de
Ahmdalhs, não se pode fazer isso com um tamanho fixado para o problema. Com a lei de
Gustavson, você está aumentando o tamanho do problema enquanto aumenta o número de
threads, em outras palavras, não se está aumentando a velocidade de um tamanho fixado
de um problema. você está contando com o maior número de threads paralelos para
permitir que você execute um problema cada vez maior. você está aumentando o tamanho
do problema de acordo com o número de threads disponíveis e é isso que permite escalar
muito melhor.