Publicado em: Parallel Computing Volume 40, Issue 7, July 2014, Pages 328–343
DOI:10.1016/j.parco.2013.09.006
Esse trabalho apresenta um modelo de programação paralelo e distribuído no qual o desenvolvedor só necessita dividir o algoritmos em tarefas e os dados de entrada em chunks, cabendo ao ambiente de execução tratar a distribuição dos mesmos. No início da execução, um programa mestre serial fatia a entrada em chunks, que são objetos somente leitura com identificador único. O usuário também define objetos tarefas, informando qual o tipo de chunk é esperado como entrada e qual vai ser produzido na saída. Um escalonador distribui as tarefas entre os recursos (cores ou máquinas) junto com seus respectivos chunks, que são a partição dos dados na qual a tarefa irá executar. Um tarefa, ao executar, pode produzir um novo chunk ou uma nova tarefa. Seja qual for o objeto gerado, ele é registrado no programa mestre. Esse registro não involve a transferência total do chunk, apenas seus meta-dados. Se a tarefa seguinte for executada no mesmo recurso, o chunk já está no local, não havendo transferência. Caso a tarefa que vai precisar do chunk gerado esteja em outro recurso, a transferência é feita diretamente entre o recurso que executou a tarefa geradora e o recurso que irá executar a tarefa que consome o chunk. A arquitetura define dois serviços em execução em cada worker, o Chunk Service e o Task Service. O primeiro cuida da transferência e registro dos chunks. O segundo cuida da sincronização entre as tarefas. Toda comunicação é feita por MPI. Como os chunks e tarefas podem ser criados e registrados dinamicamente, esse paradigma se encaixa muito bem na implementação de algoritmos paralelos recursivos e hierárquicos. Não há comunicação direta entre as tarefas, mas sim transferências de chunks, que podem exigir comunicação com o processo mestre antes de acontecer. O que é interessante no contexto de nuvens e elasticidade é que como uma tarefa pode gerar uma nova tarefa, dependendo de como foi definida, seria possível criar máquinas virtuais para essas novas tarefas. Haveria o overhead de criação, mas no lugar de criar uma por tarefa, poderia ser utilizado um pool de VMs para lidar com novas tarefas. Esse pool cresceria ou diminuiria observado a utilização das máquinas atuais. A limitação é que aplicações fortemente acopladas, de granularidade fina, talvez não se encaixem no modelo. Enfim, parece um misto de Bag-Of-Tasks e Map-Reduce, mas com a possibilidade de comunicação (com overhead) entre as tarefas pela transferência de chunks, caso seja necessário.
Post a Comment
Nenhum comentário:
Postar um comentário