Re: Aplicações em multicore. [RESOLVIDO]

Obrigado Henrique, vou ler bastante a respeito.

De: Henrique de Moraes Holschuh <hmh@debian.org>
Para: Debian User Portuguese <debian-user-portuguese@lists.debian.org>
Enviadas: Quinta-feira, 1 de Setembro de 2011 17:04
Assunto: Re: Aplicações em multicore. [RESOLVIDO]

On Thu, 01 Sep 2011, Cleber Ianes wrote:
> Muito obrigado Fabricio.
> É exatemente isso que preciso, agora já tenho o "caminho" a seguir.

Seguem mais umas dicas:

0. Portar uma aplicação com elevado paralelismo para rodar em GPU, quando
possível, é praticamente a única resposta correta. O aumento de
performance é medido em ordens de grandeza.

1. Use o hwloc para sempre amarrar o processo em todos os irmãos HT ao
mesmo tempo.

E use o hwloc para amarrar o resto do sistema para longe daquele core e
de todas as suas threads. *Não* toque nos processos do kernel a menos
que saiba o que está fazendo, alguns precisam poder rodar na mesma CPU
que o seu processo para melhor performance em algumas syscalls.

Você quer que o processo possa rodar em todas as threads do core, e
quer manter outros processos longe de todas as threads do core. O
objetivo é manter os caches L2 e L3 do core quentes com o que o
processo precisa.

Dá para fazer tudo isso para cada thread do processo se necessário, mas
se você entregar várias "CPUs" para o processo, o kernel vai espalhar
as threads dele em todas essas CPUs sozinho.

2. Se o equipamento for NUMA (e se for servidor recente com mais de um
soquete, as chances são enormes de que seja), configure o BIOS/ UEFI
corretamente e use o numactl e o hwloc para aumentar a afinidade do
processo com a memória mais perto do processador onde ele irá rodar.

3. A única forma de ter certeza que você fez o que é melhor para a sua
aplicação é testando.

4. Se o processo faz muito IO de rede, pode ser necessário trabalhar
também na afinidade das interrupções.

5. Use um equipamento próprio para HPC se puder, e coloque tudo no
BIOS/UEFI para "performance", na tentativa de evitar que o firmware
fique desperdiçando performance fazendo besteira em SMM.

6. Use o schedtool para mudar o modelo de scheduling do processo para
o quer for realmente correto para ele. Provavelmente SCHED_BATCH.

7. Leve em conta a CPU que tem. Se o processo não precisa de todos os
cores, e o resto do sistema também não, é possível que desativá-los
permita que o auto-overclock de uma CPU Intel suba a performance da
aplicação, ou que diminua a pressão nos caches L3 ou a quantidade de
mensagens inter-CPU (IPIs). Tem um utilitário não empacotado, o
turbostat, distribuido no fonte dos kernel mais novos, capaz de medir o
"turbo mode" dos Intel.

AMD tem suas peculiaridades que são bem diferentes das dos Intel.
Infelizmente não as conheço bem para listar aqui.

8. Tudo isso (exceto a regra "0") não vai aumentar a performance de forma
estrodosa, a menos que tenha algo de muito errado para começo de
história, ou seja, muitas vezes não vale o esforço.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh

--
To UNSUBSCRIBE, email to debian-user-portuguese-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: [🔎] 20110901200458.GA12803@khazad-dum.debian.net" target="_blank">http://lists.debian.org/[🔎] 20110901200458.GA12803@khazad-dum.debian.net