O GNU Parallel pode executar mais processos paralelos?

Question

Posso, por exemplo, executar:

parallel -j 200 < list0

Onde "lista" tem:

nice -n -20 parallel -j 100 < list2
nice -n -20 parallel -j 100 < list1

Isso seria viável / possível?

    

Answer 1

Não só é possível; também é recomendado em algumas situações.

O GNU Parallel leva cerca de 10 ms para executar um trabalho. Então, se você tem 8 núcleos e os trabalhos que você executa levam menos de 70 ms, você verá que o GNU Parallel usa 100% de um único núcleo, e ainda assim haverá tempo ocioso em outros núcleos. Assim, você não usará 100% de todos os núcleos.

A outra situação em que é recomendado é que você queira executar mais trabalhos do que -j0 fará. Atualmente, -j0 executará cerca de 250 trabalhos em paralelo, a menos que você ajuste alguns limites do sistema. Faz todo o sentido executar mais de 250 trabalhos se os trabalhos não forem limitados pela CPU e pelo disco I / O. Isso é verdade, por exemplo, se a latência da rede for o fator limitante.

No entanto, usar duas listas não é a maneira recomendada de dividir as tarefas. A maneira recomendada é usar o GNU Parallel para chamar o GNU Parallel:

cat list0 | parallel -j20 --pipe parallel -j100

Isso executará 2000 trabalhos em paralelo. Para executar mais ajuste -j . É recomendado que o exterior (o 20) seja pelo menos o número de núcleos, de modo que haja pelo menos um processo Paralelo GNU em cada núcleo.

Usando essa técnica, você não deve ter problemas para iniciar 20000 trabalhos em paralelo; quando você recebe mais de 32.000 processos, as coisas começam a agir.

    

Answer 2

Não vejo por que isso não seria possível - o sistema certamente pode manipular 200 tarefas paralelas.

No entanto, quase certamente não é desejável, a menos que haja algum motivo específico para o número exato de tarefas executadas em paralelo. Isso parece improvável; a única razão pela qual eu poderia ver seria porque você precisa de todas elas ao mesmo tempo, porque elas precisam trocar informações ou trocar informações com algo mais de forma caótica e indeterminada (por exemplo, para testar um programa de servidor).

A razão pela qual não é desejável de outra forma é porque o estado ideal, em termos de eficiência, é para o sistema executar um número de processos igual ao número de núcleos de processador disponíveis. Como os processos, em certa medida, costumam envolver gargalos fora da CPU - por exemplo, E / S de disco - este número ideal generalizado varia de acordo com o número de núcleos + 1 até o número de núcleos * 2.

A razão pela qual esta é a eficiência ideal do estado é que se uma tarefa consome 1 milhão de unidades de tempo do processador, executar a mesma tarefa 10 vezes sequencialmente consome 10 milhões de unidades e executar a mesma tarefa em paralelo consome 10 milhões de unidades . No entanto, no último caso, se houver menos de 10 CPUs, há um custo adicional porque o sistema deve alternar constantemente de uma tarefa para outra.

É também por isso que geralmente um sistema com 2 x 2 Ghz é mais rápido que um sistema com 4 x 1 Ghz. A principal razão para a evolução dos sistemas multi-core é porque se torna cada vez mais difícil fabricar CPUs cada vez mais rápidas, e além de um certo ponto relativamente baixo, é impossível. Portanto, a solução é fabricar sistemas com mais núcleos de processador.

Em suma, se você precisa fazer 20 coisas o mais rápido possível e você tem 4 núcleos, a maneira mais rápida de fazer isso é fazê-los em 5 conjuntos de 4 ou 4 conjuntos de 5 para permitir o tempo ocioso de esperar no I / O. parallel permite que você alimente uma lista de comprimento indefinido, mas limita o número de tarefas executadas de uma vez (e observe que o padrão para esse número é o número de núcleos).

Há um tipo de exceção a isso, embora geralmente se refira a certos tipos de programas multithread (como um monte de programas separados, mas um programa que ocupa vários núcleos). Isso ocorre porque quando um programa pode fazer alguma coisa fazendo isso com ramificações relativamente independentes que precisam apenas coordenar ocasionalmente ("ocasionalmente" pode ser tão freqüente quanto 10 ou 20 vezes por segundo), é muito mais fácil e muitas vezes mais flexível , para projetar o programa para fazer isso em encadeamentos independentes do que desenhá-lo para efetuar o ciclo das tarefas de maneira arbitrária (asrícrona). Programas graficamente intensos e / ou interativos, como videogames e sistemas CAD, se enquadram nessa categoria.