OOPS

De CCSL
Ir para navegação Ir para pesquisar

Encaminhamento do trabalho:

  • Externo
 * definição de comunicações ponto-a-ponto não-bloqueantes (recepção com esperas por futuros)
 * interação e interface com Scalapack (tratamento das matrizes e operações)
 * estruturas tridimensionais (contêineres, topologias, modos de distribuição)
 * tratamento de malhas não estruturadas (deveria ser vinculado a um projeto)
 * introdução do conceito de tarefas e balanceadores de carga (utilização com Integrade)
 * procura por benchmarks para testes de ferramentas como o OOPS (?)
  • Interno
 * refatoração de Group (provavel divisão da classe em Group e CommunicatorWrapper, algo assim)
 * refatoração de DistributionBlocked (melhoria na implementação de um dos métodos)
 * extensão das modificações nas reduções (algumas alterações não foram feitas para todas as operações)
 * análise das classes e suas relações para utilizar padrões de projeto
 * definir operações de reduções para derivados de Sendable
 * manter testes
 * classes e métodos foram introduzidos sem documentação do Doxygen
  • a respeito da aplicação de dinâmica molecular
 * modificar a implementação atual para comunicação de vetores de coordenadas, e com isso eliminar várias comunicações pequenas.
 * refatorar o Main::executeOn com extract tudo (antes manter testes)
 * modificar a implementação de Sendable::pack e Sendable::unpack
 * verificar a possibilidade e executar novos testes em paralelo para a nova versão

Poderia ainda verificar a documentação já existente de Fortress e X10 para analisar o desenvolvimento de linguagens projetadas para aplicações científicas. Para outros encaminhamentos, deveria ser feito um levantamento de (novas) ferramentas relacionadas (até de antigas, como o KeLP e o Overture)

  • Workshop on Programming Models for Grid Computing deadline 10/12/2006
  • SugarLoafPLoP deadline 29/12/2006
  • SBRC 2007 - VI Salão de Ferramentas deadline 12/02/2007
  • até 17/10: discutir com o Fabio o encaminhamento dos trabalhos, já tendo verificado com o Walter a aplicação de caminhos.

Proposta/Cronograma do Fabio de Plano de Trabalho:

  • até 22/9: apresentar seminário de 2 horas explicando em detalhes a arquitetura e implementação do OOPS e apresentando aplicação de dinâmica e desempenho (incluindo todas as versões (mais OO, menos OO). Não se esquecer de apresentar o mecanismo de envio de objetos.
  • também até 22/9: inserir o código no Eclipse CDT.
  • até 29/9: escrever documento de umas 6 páginas apresentando trabalhos relacionados, ressaltando diferenças com o OOPS e apontando oportunidades de contrinuições originais do OOPS.
  • em 10/10: seminário apresentando
  * nova implementação do Sendable (idéia do Walter) 
  * novos experimentos
     * cada ponto ser média de 5 execuções 
     * usar barras verticais para mostrar desvio padrão
     * separar um gráfico para MPIxOOPS gather e outro para reduce
     * overhead com a sobrecarga em porcentagem (média e desvio padrão)
  * código da aplicação refatorado com:
     * replace name
     * Extract Method (ler no livro Refactoring da biblioteca)
  • até 11/10: definir todas as funcionalidades adicionais que gostaríamos de oferecer aos usuários do OOPS e incluir uma estimativa do trabalho necessário para implementar cada uma destas funcionalidades. Incluir no XPlanner.
  • até 13/10: fazer um planejamento completo de todas as tarefas a serem implementadas, suas respectivas prioridades e separação em fases de desenvolvimento (versões do OOPS).



O objetivo inicial do OOPS é o de fornecer uma ferramenta para auxiliar a programação científica paralela. Esta ferramenta utiliza passagem de mensagens como modelo de programação paralela, e encapsula aspectos complexos de bibliotecas de passagem de mensagens, tais como o MPI, que é um padrão de biblioteca de passagem de mensagens bastante utilizado. Uma premissa é que o OOPS não adicione grande sobrecarga em relação a uma execução usando MPI diretamente, visto que a escolha pela programação paralela advém da necessidade de desempenho. Ainda não existe um consenso a respeito de quais técnicas são relevantes e nem sobre qual o nível de abstração que esse tipo de ferramenta deve fornecer. O que se propõe é um framework que se situa em uma posição intermediária no nível de envolvimento do programador da aplicação paralela: este deve se envolver com o paralelismo usando seu discernimento nas escolhas das estruturas mais apropriadas à sua aplicação, mas não se envolve diretamente nos seus detalhes de implementação. O OOPS utiliza processadores virtuais que podem ser organizados em grupos; fornece topologias de comunicações, contêineres distribuídos, modos de distribuição dos contêineres, possiblidade de comunicação de objetos, e intertopologias para comunicações entre grupos distintos de processadores.

Uma área desafiante para a programação paralela é a execução em grades computacionais. Com o uso das grades algumas características de programação paralela devem ser consideradas com maior peso, tais como, localidade dos dados/execução, latência nas comunicações, granulosidade das tarefas paralelas. Para satisfazer essas novas exigências, se faz apropriada a proposta de novos modelos de programação paralela para cobrir esses aspectos. A decisão de projeto do OOPS de manter o paralelismo explícito, possibilita que esses aspectos de localidade e granulosidade sejam tratados diretamente pelo programador, possibilitando que melhores resultados sejam alcançados.

ToDo:

Existem alguns pontos de especificações do OOPS que devem ser (re)definidos. Por exemplo, 

  # todos os resultados de reduções poderiam ser mantidas em todos os processadores envolvidos (resolveria algumas questões de implementação), 
  # definição de comunicações ponto-a-ponto não-bloqueantes (nesse ponto poderia ser verificada inclusive a recepção com esperas por futuros), 
  # separação da classe Group em duas (um grupo e um comunicador, este último para encapsular um comunicador MPI para ser utilizados pelas topologias e outras classes de comunicação) e reorganização de dependências (essa classe de comunicador é um wrapper para o MPI? verificar os padrões GoF), 
  # definir a extensão do uso direto do MPI pelas classes do OOPS, 
  # reimplementação de alguns métodos de DistributionBlocked, 
  # verificar a implementação das operações de recuções e distribuição/coleta usando as classes Sendable (talvez seja importante definir operações para atuar nesse caso), 
  # definição a respeito dos métodos de comunicação coletiva (ex. gather, gatherv, opções com all, ...) verificar quais aspectos podem ser definidos apenas com os parâmetros.

A página do OOPS deve ser (continuamente) melhorada: http://appl.ifsc.usp.br/oops . Deve ser disponibilizado o src do OOPS.

Teste de MPI sobre o Integrade e subsequente teste de OOPS sobre o Integrade. (verificar o mpich g2, o que existe para lam) Executar a aplicação de dinâmica molecular sobre o Integrade para averiguar o desempenho obtido.

Verificação das estruturas 3D que deveriam ser introduzidas para tratar do problema de imagens médicas (contêineres, distribuições, topologias) e a adequação de paralelismo para esta aplicação.

Estudo de paradigmas de programação paralela para grade. Proposta de novas estruturas para o OOPS que possam lidar com as necessidades impostas pela computação na grade, modelando o modelo de programação proposto.



Cronograma

  • Até 12/9 - Elaborar plano de trabalho

Este plano de trabalho deve responder as questões levantadas em:

http://www.ime.usp.br/~kon/ResearchStudents/dout-quest.html


slots online online casino free game internet casinos sites online slots bet online casino play casino games online casino net slots Casinos security online. Casino Games and variations.

Disponível em “https://ccsl.ime.usp.br/w/index.php?title=OOPS&oldid=473”