Shell Paralelo | PROGRAMAÇÃO

Quadro 2: Benefícios
Nos dois testes realizados, foi usada a abordagem do
lançador dinâmico demonstrada no artigo. No primeiro
caso, o script converteu 20 arquivos raw para o formato
TIFF numa máquina Intel Quad-core (Q9450 com 2.67
GHz e cache de 2x 6 MB L2).
Se os arquivos forem repassados para o ufrawbatch de
uma só vez, o programa leva 132 segundos (interagindo
de maneira autônoma pelos arquivos). O lançador dinâ-
mico e as variáveis PMAX=12 e PMAX=4 reduziram o tempo
de processamento de 134 segundos para 68 e 35 se-
gundos. A eficiência desse método com quatro proces-
sadores, portanto, é de aproximadamente 95 por cento;
ou seja, o tempo de execução caiu para um quarto.
A diferença entre essa abordagem e a paralelização es-
tática é sutil. A razão para essa pequena diferença é que
os arquivos originais são praticamente do mesmo tama-
nho. Dessa forma, todos os processadores são igual-
mente carregados.
muito bem (com tempos de execução de 207, 107 e 55
segundos, isto é, eficiência de 94 por cento nos quatro
processadores).
Na segunda execução, quando os arquivos estavam no
cache do servidor NFS, a diferença foi mínima comparada
ao teste local. Finalmente, a utilização de cinco proces-
sos auxiliares no lugar de quatro produziu resultados um
pouco melhores.
O efeito de mais processos auxiliares é mais acentuado
no caso de fluxos de dados mais “estreitos”. Contudo,
classificar os arquivos WAV em ordem decrescente oca-
sionou melhor resultado na conversão. No fim do proces-
samento, apenas um processador estava ocupado com
o último arquivo, o que causou uma alteração despropor-
cional no tempo final. É possível implementar mais melho-
rias, mas essas já bastam. No caso de simulações com-
plexas que levam horas ou dias, é recomendável testar
com outras otimizações.

O segundo cenário utiliza outro método para sobrecar-
regar o processador para converter arquivos WAV para
MP3, mas dessa vez com condições mais adversas. O
script lê e escreve num servidor NFS com uma cone-
xão de rede de 100 Mbps. Observações interessantes
sobre esse cenário são que, primeiro, o método escala
O equilíbrio de energia de um computador trabalhando
com carga máxima é um pouco melhor do que se ele tra-
balhasse em processamento sequencial com apenas um
núcleo. Contudo, economiza-se mais energia desligando
o monitor enquanto o computador está ocupado com
tarefas complexas de processamento.

com essa prática – seja lá o que isso
quer dizer – porque o Bash já pode
estar usando esses descritores inter-
namente. Como alternativa, pode-
se alterar o limite para o número de
canais (linha 4).
Há outras implementações possí-
veis. Por exemplo, o lançador e os au-
xiliares poderiam usar arquivos para
se comunicar. O lançador poderia
então escrever as tarefas em arqui-
vos específicos de cada auxiliar. Os
auxiliares verificariam a presença de
seu arquivo, processariam as tarefas
ali definidas e então os apagariam.
Na outra ponta, o lançador buscaria
os lançadores sem arquivos corres-
pondentes e saberia imediatamente
quais deles estão ociosos.
Obviamente, essa solução não
é das melhores, em razão da ne-
cessidade da verificação contínua
de arquivos.
Uma versão mais longa do exemplo
5 está disponível em [1]. Essa versão
ampliada suporta chamadas de dis-
patchWork na linha de comando:
$ dispatchWork c “doSomething”
➥file1 file2 […]
A versão ampliada também possui
comentários e outras opções para
teste que permitem ao administrador
monitorar os scripts.
Várias máquinas
Se a eficiência do processamento
paralelo na máquina local não for
suficiente, o mesmo princípio pode
ser aplicado a uma rede. Nesse caso,
um lançador de primeiro estágio
pode usar comunicação TCP/IP
para comunicar-se com lançadores
de segundo estágio em outras má-
quinas. Os lançadores de segundo
estágio comunicam-se então com
os auxiliares locais. Porém, essa
abordagem só é viável numa rede
suficientemente segura.
Conclusões
Com apenas algumas linhas de có-
digo, é possível utilizar as técnicas
demonstradas aqui para paralelizar
scripts shell já existentes e desfrutar
de benefícios potencialmente sig-
nificativos (veja o quadro 2). Outras
linguagens de script podem usar
essa abordagem; contudo, algumas
oferecem alternativas melhores.
Por exemplo, Python usa um fork
explícito (os.fork()) além dos pipes
(os.pipe()), o que permite soluções
de baixo nível muito próximas à
eficiência do C. ■
Mais informações
[1] Código-fonte do lançador
dinâmico: http://www.
linuxmagazine.com.
br/arquivos/lm51/
programacao_bash.tar.gz

Linux Magazine #51 | Fevereiro de 2009 77