A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Tese de Doutorado Francisco Heron de Carvalho Junior Rafael Dueire Lins Orientador Programação Paralela Eficiente e de Alto Nível sobre Arquiteturas Distribuídas.

Apresentações semelhantes


Apresentação em tema: "Tese de Doutorado Francisco Heron de Carvalho Junior Rafael Dueire Lins Orientador Programação Paralela Eficiente e de Alto Nível sobre Arquiteturas Distribuídas."— Transcrição da apresentação:

1 Tese de Doutorado Francisco Heron de Carvalho Junior Rafael Dueire Lins Orientador Programação Paralela Eficiente e de Alto Nível sobre Arquiteturas Distribuídas

2 Antecedentes Idéias de Lins (a partir do final da década de 80);Idéias de Lins (a partir do final da década de 80); –Linguagens funcionais paralelas; –Hierarquia de processos; –Integração à ambiente de prova (redes de Petri); –Prototipação rápida e simulação de programas; –Incorporação de bibliotecas encapsuladas; Desenvolvimentos anteriores:Desenvolvimentos anteriores: –Haskell#: Lima, 2000 (tese de doutorado);Lima, 2000 (tese de doutorado); Carvalho, 2000 (dissertação de mestrado);Carvalho, 2000 (dissertação de mestrado);

3 Motivações e Estado-da-Arte Computação de Alto Desempenho Consolidação da supercomputação distribuída;Consolidação da supercomputação distribuída;Consolidação da supercomputação distribuída;Consolidação da supercomputação distribuída; MPPs (Massive Parallel Processors);MPPs (Massive Parallel Processors); –Supercomputadores propriamente ditos; Cluster computing;Cluster computing; –Supercomputação com equipamento de prateleira (commodities); –Excelente relação custo / benefício frente à MPPs; –Evolução do hardware e software; –Aumento na escala de usuários (supercomputação para todos); Grid computing;Grid computing; –Supercomputação geograficamente distribuída; –Aplicações paralelas de grande escala e complexidade; Novas aplicações extrapolam computação científica;Novas aplicações extrapolam computação científica;

4 Motivações e Estado-da-Arte Ferramentas de Programação Paralela Paralelismo implícito é ineficiente e pouco escalável;Paralelismo implícito é ineficiente e pouco escalável; Programação paralela distribuída (explícita);Programação paralela distribuída (explícita); Passagem de mensagens:Passagem de mensagens: –Parallel Virtual Machine (PVM): ambientes heterogêneos; –Message Passing Interface (MPI): ambientes homogêneos (clusters atuais); Eficiência, portabilidade e escalabilidade : Eficiência, portabilidade e escalabilidade : –Primitivas de baixo nível como funções de bibilotecas; Modularidade, abstração, tratamento formal, etc.: Modularidade, abstração, tratamento formal, etc.: –Inadequação ao desenvolvimento de programas de grande escala; –Entrelaçamento de código; –Inadequação às modernas técnicas de desenvolvimento de software; –Simplicidade relativa !!!

5 Objetivo Desenvolvimento do modelo # para programação paralela distribuída como uma evolução à Haskell#, assumindo-se premissas advindas no panorama tecnológico emergente para computação de alto desempenho Tópicos Específicos: Tópicos Específicos: –Concepção do modelo #; Análise das deficiências de Haskell# original, proposição e avaliação de soluções, implementação de protótipos;Análise das deficiências de Haskell# original, proposição e avaliação de soluções, implementação de protótipos; –Uso de Redes de Petri para tratamento formal de programas #; –Implementar nova versão para Haskell# baseado no modelo #; –Implementar aplicações e avaliar desempenho; –Prototipação do ambiente # de desenvolvimento (VHT);

6 Estrutura Motivações e Objetivos;Motivações e Objetivos; O modelo #;O modelo #; Análise de programas # com redes de Petri;Análise de programas # com redes de Petri; Implementação (Haskell#);Implementação (Haskell#); Avaliação de desempenho;Avaliação de desempenho; Conclusões;Conclusões; Propostas de trabalhos futuros.Propostas de trabalhos futuros.

7 Estrutura Motivações e objetivos;Motivações e objetivos; O modelo #;O modelo #; Análise de programas # com redes de Petri;Análise de programas # com redes de Petri; Implementação de Haskell#;Implementação de Haskell#; Avaliação de desempenho;Avaliação de desempenho; Conclusões;Conclusões; Propostas de trabalhos futuros.Propostas de trabalhos futuros.

8 O Modelo # A premissa básica: Hierarquia de ProcessosA premissa básica: Hierarquia de Processos –Programação em dois níveis hierarquicamente distingüidos: –Paradigma de coodenação; Nível de Coordenação Nível de Computação Interface via lazy streams (não invasiva) Linguagem Sequencial (Haskell) Linguagem # (Configuração)

9 Conceito Primitivo: Componentes Entidades que caracterizam funcionalidades;Entidades que caracterizam funcionalidades; Podem ser classificados em:Podem ser classificados em: –Simples: Computações sequenciais; Conjunto de componentes simples = Meio de computaçãoConjunto de componentes simples = Meio de computação Programados na linguagem host (Haskell, no caso de Haskell#) ;Programados na linguagem host (Haskell, no caso de Haskell#) ; –Compostos: Computações paralelas; Conjunto de componentes compostos = Meio de coordenaçãoConjunto de componentes compostos = Meio de coordenação Programados na linguagem #, pela composição de outros componentes;Programados na linguagem #, pela composição de outros componentes; # Argumentos Pontos de Retorno

10 Programa # = Coleção de Componentes ####

11 Hierarquia de Processos Nível de Coordenação (#) # # # # # Nível de Computação ( ) Componente de Aplicação (raiz)

12 Em nível de computação:Em nível de computação: –Programação sequencial convencional; –Em Haskell# = Haskell; Em nível de coordenaçãoEm nível de coordenação –Linguagem #: configuração de componentes; –Descrição de topologias de processos; –Composição de componentes: Aninhamento de componentes;Aninhamento de componentes; Sobreposição de componentes;Sobreposição de componentes; Suporte a noção de esqueletos topológicos parciais;Suporte a noção de esqueletos topológicos parciais; Estruturando Programas # Próximos Slides!!

13 Nível de Coordenação Capturando a Essência da Programação Paralela Distribuída (passagem de mensagens) A Linguagem # (abstrações) Nível de Coordenação

14 Especificando Componentes Configuração # Processos interagem por troca explícita de mensagens recv a 1 x:=x send a 0 send buf 2 print a

15 Especificando Componentes Configuração #

16 Portas e Unidades unidade … … Portas de Saída Portas de Entrada

17 Unidades e Interfaces Componentes compostos descrevem redes de unidades, que interagem por meio de canais de comunicação;Componentes compostos descrevem redes de unidades, que interagem por meio de canais de comunicação; Unidades (peças básicas):Unidades (peças básicas): –Abstração para entidades executáveis (generalização de processos); InterfaceInterface –Classe de unidades que compartilham comportamento análogo; –Analogia: Interfaces estão para unidades, assim como: Tipos de dados estão para variáveis, em programas;Tipos de dados estão para variáveis, em programas; Classes estão para objetos em modelos orientados a objetos;Classes estão para objetos em modelos orientados a objetos; –Entidades primtivas, a partir das quais unidades são instanciadas;

18 Interface Uma interface é descrita por:Uma interface é descrita por: –Uma coleção de portas (entrada ou saída); –Uma expressão de ativação (comportamento): Formalismo: Expressão regular controlada por semáforos;Formalismo: Expressão regular controlada por semáforos; Equivalência com redes de Petri rotuladas terminais;Equivalência com redes de Petri rotuladas terminais; Descreve as sequências válidas de ativação das portas;Descreve as sequências válidas de ativação das portas; … …

19 Comportamento de Unidades Combinadores da Expressão de Ativação par a 1 a 2 …a n : concorrência;par a 1 a 2 …a n : concorrência; seq a 1 a 2 …a n : sequência;seq a 1 a 2 …a n : sequência; alt a 1 a 2 …a n : alternativa;alt a 1 a 2 …a n : alternativa; repeat a : repetição;repeat a : repetição; –until : condição de terminação (finalização de streams); –counter : número de repetições pré-fixado; –forever : infinito; ! pid : ativação de porta de saída;! pid : ativação de porta de saída; ? pid : ativação de porta de entrada;? pid : ativação de porta de entrada; signal s : incremento de semáforosignal s : incremento de semáforo wait s : decremento de semáforowait s : decremento de semáforo

20 Comunicação via Lazy Streams Sequências de dados com informação de mesma natureza;Sequências de dados com informação de mesma natureza; – v 1, v 2, …, v n ; – v 1, v 2, …, v n ; –Ao final, acompanha um terminador de stream (EOS); Portas stream:Portas stream: –Sempre ativadas no contexto de combinadores repeat; –Terminador de stream e condição de terminação de repetição; Múltiplos níveis de aninhamento (flag *):Múltiplos níveis de aninhamento (flag *): –EOS é acompanhado do aninhamento da stream terminada; –Transmissão de, >,, >>: [Val 1, Eos 3, Val 2, Val 3, Eos 3, Eos 2, Val 3, Val 4, Eos 3, Val 5, Val 6, Val 7, Eos 3, Eos 2, Eos 1];[Val 1, Eos 3, Val 2, Val 3, Eos 3, Eos 2, Val 3, Val 4, Eos 3, Val 5, Val 6, Val 7, Eos 3, Eos 2, Eos 1];

21 Comunicação via Lazy Streams interface NestingExample t # (x*, y**::t) -> (z***::t) behavior: repeat seq {x?; z! repeat seq { y?; z!; repeat seq {x?; y?; z!} until z } until } until z x y * ** *** [t] [[t]] [[[t]]] Em Haskell#:Em Haskell#: –Portas stream são associadas à listas nos argumentos e pontos de retorno do módulo funcional associado à unidade; –Daí o conceito de Lazy streams; –Intercalação entre computação e comunicação sem comprometimento da hierarquia de processos;

22 Especificação de Unidades Agrupamento de Portas Porta Individual

23 Função de Ligação g f +

24 Função de Ligação Agrupamentos choice f ! + f ! + … …

25 f ! ! ! Função de Ligação Agrupamentos não-choice f ! … ! ! …

26 Unidades Virtuais Unidade parametrizada por sua funcionalidade:Unidade parametrizada por sua funcionalidade: –Não associada a um componente; Operação assign:Operação assign: –Substituindo uma unidade virtual por uma unidade não-virtual; –Preservação comportamental; Esqueletos topológicos parciais ou componente abstratos:Esqueletos topológicos parciais ou componente abstratos: –Pelo menos uma unidade virtual em sua composição; –Composição por sobreposição e aninhamento; –Descrições topológicas de alto nível: Geração de código otimizado (uso de bibliotecas);Geração de código otimizado (uso de bibliotecas); Mapeamento de processos aos processadores;Mapeamento de processos aos processadores; Melhora capacidade de raciocínio sobre programas;Melhora capacidade de raciocínio sobre programas;

27 Configurando Componentes Abstratos …… assign cell # (s,l) -> (n,o) to pipeline.stage # l -> o pipe_line stage assign cell

28 Sobrepondo Componentes Abstratos …… pipe_line mesh stage … … assign cell assign mesh.cell # (s,l) -> (n,o) to pipeline.stage # l -> o

29 Sobrepondo Componentes Abstratos … …… mesh pipe_line

30 Operações sobre Unidades Virtuais Mecanismo de abstração;Mecanismo de abstração; Operações suportadas:Operações suportadas: –Unificação: n unidades 1 unidade; –Fatoração: 1 unidade n unidades; –Replicação: k unidades k*n unidades; Unidades à direita em qualquer nível de aninhamento;Unidades à direita em qualquer nível de aninhamento; Preservação comportamental:Preservação comportamental: –Sequências de ativação válidas na interface das unidades resultantes deve ser um sub-conjunto das sequências válidas nas unidades originais. Agrupamentos aninhados de portas;Agrupamentos aninhados de portas; –Semântica de ativação em redes de Petri;

31 Unificação de Unidades wA wB cell wa<-a e cell<-a conectadas à portas distintas i j i j i wb<-b e cell<-b conectadas à mesma porta i a mm b c d res choice unify c d res b b a a unit wA # FarmWorker unit wB # FarmWorker unit cell # GridElem … interface FarmWorker # in -> out behavior: seq {in?; out!} … interface GridElem # (l,u) -> (r,d) behavior: repeat seq { par {r!; d!}; par {l?; t?} } interface MatrixMult # FarmWorker a -> res, # FarmWorker b -> res, # interact like GridElem behavior: seq {a?;b?; do interact; res!} unify wA # a -> res, wB # b -> res, cell # interact to mm # MatrixMult connections a<>: choice

32 Fatoração de Unidades someStrategy factorize pipe[1] pipe[2] pipe[3] s1 s4 s2 s3 index i range [1,3] … factorize merge3 # [/s[i]/] -> o to [/pipe[i] # Pipe s[i] -> o/] connections o<>: someStrategy unit merge3 # Merge3 … interface Merge3 # Pipe s1 -> s4 # Pipe s2 -> s4 # Pipe s3 -> s4 behavior: repeat seq {par {s1?; s2?; s3?}; s4!} until merge3 s2 s1 s3 s4

33 Replicação de Unidades u2 u1 broadcast choice someStrategy1someStrategy2 replicate replicate 3 u1 # a -> (b,_), u2 # (_,c) -> d connections a<>: someStrategy1, b<>: someStrategy2, c<>: broadcast, d<>: choice a d b c x y u2[1] u1[1] u2[2] u1[2] u2[3] u1[3] a aa b bb d c d c d c x y x y x y

34 Esqueleto Farm distributor collector worker[1] worker[2] worker[N] ? ?

35 Esqueleto Pipe-Line … interface Pipe # in -> out behavior: repeat seq {in? -> out!} until pipe[1]pipe[2]pipe[N]

36 Esqueleto Mesh … … … … …… interface GridElem # Pipe l -> r # Pipe u -> d behaving as: repeat seq {par {r!;d!}; par {l?;t?}} until

37 Esqueleto Torus … … … … ……

38 partition by DistributeMatrix combine by CombineMatrix partition by ? combine by ? index i,j range [1,N] … [/ assign matrix_mult[i][j] # (al,bt) -> (ar,bd,res) to mm_grid[i][j] # (al,bt) -> (ar,bd,res) /] assign mA to farmA.distributorassign mB to farmB.distributorassign mC to collector index i,j range [1,N] … [/ assign matrix_mult[i][j] to mm_grid[i][j] /]

39 Esqueletos MPI Abstração das primitivas de comunicação coletiva de MPI;Abstração das primitivas de comunicação coletiva de MPI; –Tradução direta realizada pelo compilador; 13 esqueletos: Bcast, Scatter, Scatterv, Reduce_scatter, Scan, Gather, Gatherv, Reduce, Allgather, Allgatherv, Alltoall, Alltoallv, Allreduce;13 esqueletos: Bcast, Scatter, Scatterv, Reduce_scatter, Scan, Gather, Gatherv, Reduce, Allgather, Allgatherv, Alltoall, Alltoallv, Allreduce; Esqueletos podem informar ao compilador informações de alto nível sobre topologia da rede;Esqueletos podem informar ao compilador informações de alto nível sobre topologia da rede; –Geração de código otimizado; –Otimização da alocação de processadores; –Simplicicação da rede de Petri equivalente;

40 Implementação de NPB NAS = NAS Parallel BenchmarksNAS = NAS Parallel Benchmarks –NASA Research at Ames, EUA; Kernels: EP, IS, CG;Kernels: EP, IS, CG; –Extensivo uso de comunicação coletiva; –Usadas nos benchmarks mostrados adiante; Aplicações Simuladas: LU, SP e BT;Aplicações Simuladas: LU, SP e BT; Padrão SPMD:Padrão SPMD: –Derivação de programas # a partir de programas MPI;

41 Implementação de IS MPI_Alltoallv(key_buff1, send_count, send_displ, MPI_INT, key_buff2, recv_count, recv_displ, MPI_INT, MPI_COMM_WORLD ); MPI_Allreduce(bucket_size, bucket_size_totals, NUM_BUCKETS+TEST_ARRAY_SIZE, MPI_INT, MPI_SUM, MPI_COMM_WORLD ); MPI_Send(&key_array[total_local_keys-1], 1, MPI_INT, my_rank+1, 1000, MPI_COMM_WORLD ); MPI_Irecv(&k, 1, MPI_INT, my_rank-1, 1000, MPI_COMM_WORLD, &request ); kb2 kb1 bst bs kl kr IIS

42 Declaração de Interface interface IIS # bs* like IAllReduce # kb* like IAllToAllv # k like RShift behaviour: seq {repeat seq {do bs; do kb} until ; do k} k RShift IAllReduce IAllToAllv kb bs

43 Implementação de IS p[4] p[1] p[2] p[3] AllReduc e Topology unit bs_comm unit bs_comm as AllReduce(4, MPI_SUM, MPI_INTEGER)

44 AlltoAll v Topology p[4] p[1] p[2] p[3] unit kb_comm unit kb_comm as AllToAllv(4) Implementação de IS

45 p[4] p[1] p[2] p[3] k_shift unit k_shift as RShift(4) Implementação de IS

46 AlltoAll v Topology is_unit[4] is_unit[1] is_unit[2] is_unit[3] AllReduc e Topology Implementação de IS

47 … …… … is_unit[i] kb_comm.p[i] bs_comm.p[i] k_shift.p[i] unify bs_comm.p[i] # bs, kb_comm.p[i] # kb, k_shift.p[i] # k to is_unit[i] # IIS Implementação de IS

48 AlltoAll v Topology is_unit[4] is_unit[1] is_unit[2] is_unit[3] AllReduc e Topology IS Implementação de IS

49 IS Haskell Programming Implementação de IS

50 Implementation of IS configuration IS with use IS use Skeletons.Collective.AllReduce use Skeletons.Collective.AllToAllv use Skeletons.Misc.RShift index i range [1..NUM_PROCS] interface IIS # bs* like IAllReduce # kb* like IAllToAllv # k like RShift behaviour: seq {repeat seq {do bs; do kb} until ; do k} unit bs_comm as AllReduce(NUM_PROCS, MPI_SUM, MPI_INTEGER) unit kb_comm as AllToAllv(NUM_PROCS) unit k_shift as RShift(NUM_PROCS) [/ unify bs_comm.p[i] # bs, kb_comm.p[i] # kb, k_shift.p[i] # k to is_unit[i] # IIS as IS(PROBLEM_CLASS, NUM_PROCS, MAX_KEY_LOG2, NUM_BUCKETS_LOG2, TOTAL_KEYS_LOG2, MAX_ITERATIONS, MAX_PROCS, TEST_ARRAY_SIZE, bs.in, kb.in,k.in) -> (bs.out, kb.out, k.out) /]

51 Implementation of IS configuration CG # () -> (zeta, x) with use CG use Transpose use Skeletons.Collective.AllReduce index i range [1..DIM] index j range [1..COL_FACTOR] interface ICG # q** like ITranspose # r* like ITranspose # rho* like IAllReduce # aux* like IAllReduce # rnorm* like IAllReduce # norm_temp_1* like IAllReduce # norm_temp_2* like IAllReduce behaviour: seq {repeat seq {do bs; do kb} until ; do k} unit q_comm as Transpose(DIM, COL_FACTOR) unit r_comm as Transpose(DIM, COL_FACTOR) unit rho_comm as AllReduce(NUM_PROCS, MPI_SUM, MPI_DOUBLE) unit aux_comm as AllReduce(NUM_PROCS, MPI_SUM, MPI_DOUBLE) unit rnorm_comm as AllReduce(NUM_PROCS, MPI_SUM, MPI_DOUBLE) unit norm_temp_1_comm as AllReduce(NUM_PROCS, MPI_SUM, MPI_DOUBLE) unit norm_temp_2_comm as AllReduce(NUM_PROCS, MPI_SUM, MPI_DOUBLE)

52 Implementation of IS [/ unify q_comm.u[i] # q, r_comm.u[i] # r, rho_comm.p[i] # rho, aux_comm.p[i] # aux, rnorm_comm.p[i] # rnorm, norm_temp_1_comm.p[i] # norm_temp_1, norm_temp_2_comm.p[i] # norm_temp_2 to cg_unit[i] # ICG as CG(DIM, COL_FACTOR, NA, NONZER, SHIFT, NITER, RCOND, ZVV, q.x, r.x, rho.in, aux.in, rnorm.in, norm_temp_1.in, norm_temp_2.in) -> (q.w, r.w, rho.out, aux.out, rnorm.out, norm_temp_1.out, norm_temp_2.out) /] configuration Transpose(DIM, COL_FACTOR) index i,j range [1..DIM] index k range [1..COL_FACTOR] interface ITranspose (x::UDVector) -> (w::UDVector) behaviour: seq {w!; x?} [/ unit trans[i][j] # ITranspose groups (x, w :broadcast) /] [/ connect trans[i][j]->w[k] to trans[k][i]->x[j] /] [/ factorize trans[i][j] # w -> x to [/ u[(.i-1)*COL_FACTOR + k[.j]] # w -> x /] connections w<>:sum_arrays, x<>:split_vector /]

53 Estrutura Motivações e objetivos;Motivações e objetivos; O modelo #;O modelo #; Análise de programas # com redes de Petri;Análise de programas # com redes de Petri; Implementação de Haskell#;Implementação de Haskell#; Avaliação de desempenho;Avaliação de desempenho; Conclusões;Conclusões; Propostas de trabalhos futuros.Propostas de trabalhos futuros.

54 Modelo # e Redes de Petri Tradução da rede de processos para redes de Petri;Tradução da rede de processos para redes de Petri; Análise de propriedades formais de programas:Análise de propriedades formais de programas: –INA (Integrated Net Analyser) e PEP; Avaliação de desempenho de programas:Avaliação de desempenho de programas: –Redes de Petri estocásticas; –SPNL e TimeNET; Antecedentes:Antecedentes: –Tradução OCCAM redes de Petri (Lins & Maciel); –Tracução Haskell# redes de Petri (Lima); Versão anterior de Haskell#;Versão anterior de Haskell#;

55 Modelando Comportamento de Unidades …… … … … … … Expressão de Ativação Rede de Petri

56 Modelando o Comportamento de Unidades Regras de tradução para os combinadores;Regras de tradução para os combinadores; –Redes de Petri hierárquicas; Modelagem da ativação de portas:Modelagem da ativação de portas: –Porta individual; –Agrupamentos de Portas (choice e não-choice); Semântica da escolha entre portas choice;Semântica da escolha entre portas choice; Modelagem de agrupamentos aninhados;Modelagem de agrupamentos aninhados; Condição de terminação do combinador repeat;Condição de terminação do combinador repeat; –Natureza valor mais recente transmitido por uma porta stream; –Dependente do Protocolo de finalização sincronizada de streams;

57 Modelagem de Canais de Comunicação synchronous

58 Modelagem de Canais de Comunicação buffered

59 Modelagem de Canais de Comunicação ready

60 Modelagem da Natureza do Valor Transmitido em Streams Natureza do valor transmitido em uma stream:Natureza do valor transmitido em uma stream: –Valor de dados; –Terminador de stream em aninhamento k (EOS k); Necessário para modelagem de repeat … until;Necessário para modelagem de repeat … until; Em um canal, a natureza do valor enviado deve coincidir com a natureza do valor recebido;Em um canal, a natureza do valor enviado deve coincidir com a natureza do valor recebido; Restrições na ordem de transmissão de terminadores de streams;Restrições na ordem de transmissão de terminadores de streams; Protocolo de finalização de streams é inserido para cada canal;Protocolo de finalização de streams é inserido para cada canal; –Lugares e transições adicionais que modelam às restrições de streams;

61 Modelagem de Esqueletos A tradução direta de esqueletos pode ser usada para simplificar a rede de Petri gerada;A tradução direta de esqueletos pode ser usada para simplificar a rede de Petri gerada; Exemplo: Modelagem de esqueletos MPI:Exemplo: Modelagem de esqueletos MPI: –Cada componente de interface derivada de um esqueleto MPI é modelada por uma única porta cuja direção é indiferente –Uma interação coletiva é modelada como uma sincronização entre as porta de cada processo envolvidas na comunicação coletiva; Essa informcão é obtida a partir do aglomerado associado ao esqueleto MPI em questão;Essa informcão é obtida a partir do aglomerado associado ao esqueleto MPI em questão;

62 Estudos de Caso:Estudos de Caso: –Jantar dos Filósofos; (2 soluções) –Simulação do Protocolo do Bit Alternado; Ferramentas: INA e PEP;Ferramentas: INA e PEP; Técnicas:Técnicas: –Propriedades comportamentais e estrututurais; –Computação (parcial) de grafo de estados e grafo de cobertura; –Teste de alcançabilidade de marcações; –Teste de liveness; –Computação e teste de invariantes; Verificação de propriedades:Verificação de propriedades: –deadlocks; –Justiça; –Grau de paralelismo ou concorrência; Análise de Propriedades Formais de Programas # Padrões comportamentais regulares

63 Jantar dos Filósofos Solução 1 Solução 1Solução 1 Situação geral;Situação geral; Presença de agrupamentos de portas;Presença de agrupamentos de portas; Filósofos disputam talheres arbitrariamente:Filósofos disputam talheres arbitrariamente: –Ocorrência de deadlocks; –Solução assíncrona (canais bufferizados); –Justiça condicional (escalonamento fortemente justo); Modelagem com redes de Petri:Modelagem com redes de Petri:: –Modelando um processo filósofo; Modelando um processo filósofoModelando um processo filósofo –Introduzindo protocolo de finalização de streams; Introduzindo protocolo de finalização de streamsIntroduzindo protocolo de finalização de streams –Conectando redes de Petri dos processos filósofos; Conectando redes de Petri dos processos filósofosConectando redes de Petri dos processos filósofos

64 Jantar dos Filósofos Solução 2 Solução 2Solução 2 Filósofos estabelecem protocolo:Filósofos estabelecem protocolo: –Máximo paralelismo; –Justiça incondicional; –Ausência de deadlocks; –Comunicação síncrona (canais síncronos); –Não emprega agrupamentos de portas (simplicidade) Modelagem com redes de Petri:Modelagem com redes de Petri: –Modelando um processo filósofo; Modelando um processo filósofoModelando um processo filósofo –Introduzindo protocolo de finalização de streams; Introduzindo protocolo de finalização de streamsIntroduzindo protocolo de finalização de streams –Conectando redes de Petri dos processos filósofos; Conectando redes de Petri dos processos filósofosConectando redes de Petri dos processos filósofos

65 Protocolo do Bit Alternado Solução Única Solução Única Solução Única Pode ser visto como um esqueleto (não-total):Pode ser visto como um esqueleto (não-total): –Modelagem de protocolos de comunicação de canais; Unidades heterogêneas;Unidades heterogêneas; Presença de streams com aninhamento > 1;Presença de streams com aninhamento > 1; Modelagem com redes de Petri;Modelagem com redes de Petri;Modelagem com redes de PetriModelagem com redes de Petri Verificação de deadlocks;Verificação de deadlocks; –Empregando o teste de alcançabilidade marcações mortas a partir do grafo de estados não foram encontrados deadlocks;

66 Estrutura Motivações e objetivos;Motivações e objetivos; O modelo #;O modelo #; Análise de programas # com redes de Petri;Análise de programas # com redes de Petri; Implementação de Haskell#;Implementação de Haskell#; Avaliação de desempenho;Avaliação de desempenho; Conclusões;Conclusões; Propostas de trabalhos futuros.Propostas de trabalhos futuros.

67 Compilador # Implementado em Haskell:Implementado em Haskell: –Gerador de analisador léxico: Alex 2.0; –Gerador de parser : Happy 1.11; Geração de código Haskell com chamadas à MPI via FFI (Foreign Function Interface);Geração de código Haskell com chamadas à MPI via FFI (Foreign Function Interface); Processos # implementados como funções de alta ordem;Processos # implementados como funções de alta ordem; –Entrada: autômato de validação do processo. Induzido pelo comportamento de cada processo;Induzido pelo comportamento de cada processo; –Tipos de processos suportados: Assícronos (fluxo de controle): C, Fortran;Assícronos (fluxo de controle): C, Fortran; Orientado a demanda pela saída: Haskell;Orientado a demanda pela saída: Haskell; Controlado pelo fluxo de entrada: Id;Controlado pelo fluxo de entrada: Id;

68 VHT (Visual # Tool) Ambiente integrado para a programação #:Ambiente integrado para a programação #: –Programação visual; –Uso de XML como formato de intercâmbio; –Geração de código na linguagem # a partir das especificações visuais; –Integração à ferramentas de análise de redes de Petri; Geração de código PNML e SPNL;Geração de código PNML e SPNL; –Execução do programa e debuging; Integrado ao LAM-MPI;Integrado ao LAM-MPI; Possível integração a ferramentas de debugging de programas MPI;Possível integração a ferramentas de debugging de programas MPI; Em fase desenvolvimento (prototipação).Em fase desenvolvimento (prototipação).

69 Estrutura Motivações e objetivos;Motivações e objetivos; O modelo #;O modelo #; Análise de programas # com redes de Petri;Análise de programas # com redes de Petri; Implementação de Haskell#;Implementação de Haskell#; Avaliação de desempenho;Avaliação de desempenho; Conclusões;Conclusões; Propostas de trabalhos futuros.Propostas de trabalhos futuros.

70 Avaliação de Desempenho NAS Parallel BenchmarksNAS Parallel Benchmarks –EP, CG e IS; Ambiente de Hardware:Ambiente de Hardware: –Cluster de PCs: 8 Pentium IV 2GHz –RAM: 4 x 256MB, 2 X 512MB, 1 X 1GB –Fast Ethernet (100MBs). Ambiente de Software:Ambiente de Software: –Protocolo de rede: TCP/IP; –LAM-MPI 6.5.9; –Glasgow Haskell Compiler (GHC) 6.0; Uso de ferramentas de profiling para análise de custos;Uso de ferramentas de profiling para análise de custos;

71 Avaliação de Desempenho Restrições e Metodologia Diferenças entre as versões imperativa (C/Fortran) e funcional (Haskell) dos kernels;Diferenças entre as versões imperativa (C/Fortran) e funcional (Haskell) dos kernels; –Comportamento espacial (uso da memória); –Maior granularidade de processos Haskell: Ilusão de ser Haskell# muito mais eficiente que MPI;Ilusão de ser Haskell# muito mais eficiente que MPI; Metodologia:Metodologia: –Cáculo de tempo de execução e speedup; Cronometragem segundo os kernels originais;Cronometragem segundo os kernels originais; –Casos: Sequencial; Paralelo: 2, 4 e 8 processadores; –Uso de profiling para análise dos pontos de ineficiência; –2 Tamanhos de Problema para cada kernel: EP-1, EP-2, IS-1, IS-2, CG-1, CG-2;EP-1, EP-2, IS-1, IS-2, CG-1, CG-2;

72 Avaliação de Desempenho Curvas de Desempenho Curvas de Desempenho Curvas de Desempenho EP: speedup aproxima-se ao linear (ótimo);EP: speedup aproxima-se ao linear (ótimo); CG e IS merecem atenção especial:CG e IS merecem atenção especial: –Uso extensivo de comunicação coletiva; –Presença de funções de ligação; –Speedup não comporta-se linearmente: Mesmo efeito observado nas versões originais MPI;Mesmo efeito observado nas versões originais MPI; Rede de alta latência;Rede de alta latência; Cluster pouco sintonizado para execução em alto desempenho;Cluster pouco sintonizado para execução em alto desempenho; –GHC Profiling Tool: estudo dos custos do paralelismo;

73 Avaliação de Desempenho Curvas de Desempenho Curvas de Desempenho Curvas de Desempenho Custos observados:Custos observados: i.Computação efetiva (trabalho útil); ii.Avaliação de funções de ligação; iii.Marshalling (de valores Haskell a buffers MPI); iv.Sincronização e Comunicação (MPI); v.Gerenciamento Automático de Memória;

74 Análise de Custos (IS) Caso Procs. iiiiiiivv IS-1 SEQ 45,9%---54,1% 2 35,4%3,0%7,4%4,6%45,3% 4 37,6%3,0%7,2%11,0%35,7% 8 36,0%2,7%7,2%20,8%28,7% IS-2 SEQ 34,5%---65,5% ,3%2,8%6,8%11,7%38,9% 8 32,8%2,7%7,0%21,1%32,6%

75 Análise de Custos (CG) Caso Procs. iiiiiiivv CG-1 SEQ 90,2%---9,8% 2 79,1%1,5%2,1%4,7%7,7% 4 70,9%1,8%3,2%11,6%5,8% 8 57,5%3,5%5,6%24,0%2,7% CG-2 SEQ 84,5%---15,5% 2 68,5%1,2%1,7%10,8%11,6% 4 70,2%1,5%2,5%12,9%6,3% 8 61,1%3,2%5,1%19,5%4,5%

76 Análise de G.A.M. (IS) CasoNPROCS Eficiência de coleta Tempo de coleta Speedup coletor Speedup mutador IS-1 SEQ 38,1%112, ,1%72,81,51,4 4 29,3%28,14,02,7 8 25,9%15,17,44,2 IS-2 SEQ 41,4%247, ,9%168,01,41,3 4 34,4%70,53,52,6 8 27,5%31,97,74,1

77 Análise de G.A.M. (CG) CasoNPROCS Eficiência de coleta Tempo de coleta Speedup coletor Speedup mutador CG-1 SEQ 5,5%143, ,7%72,21,92,0 4 4,9%39,83,63,1 8 0,8%4,730,44,4 CG-2 SEQ 5,5%350, ,7%152,02,31,8 4 4,9%61,15,73,1 8 0,8%16,221,55,0

78 Análise de Speedup (IS) CasoNPROCSi + ii + iii + iv + v IS-1 22,11,91,61,51,2 44,13,83,22,62,5 87,57,05,94,04,4 IS-2 21,91,81,5-- 44,13,83,22,52,5 88,07,36,14,14,5

79 Análise de Speedup (CG) CasoNPROCSi + ii + iii + iv + v CG-1 22,02,01,91,81,9 43,93,83,63,23,2 87,97,46,74,95,3 CG-2 22,12,02,01,71,8 44,03,93,73,23,4 88,07,67,05,56,0

80 Influência da Coleta de Lixo Resumo Sobrecarga do G.A.M. diminui com o tamanho do problema:Sobrecarga do G.A.M. diminui com o tamanho do problema: –Maior localidade dos dados; –Efeitos de cache; –Nas medições, utilizou-se o tamanho ótimo da heap; –Algoritmos de coleta não se comportam linearmente; Mais processadores menor tamanho de problema por processador menor sobrecarga de gerenciamento automático de memória;Mais processadores menor tamanho de problema por processador menor sobrecarga de gerenciamento automático de memória; –Compensação do custo 3; –Pode-se assumir nulo o custo de run-time de Haskell#; OBS: Marshalling pode ser otimizado (dependente de GHC);OBS: Marshalling pode ser otimizado (dependente de GHC);

81 Estrutura Motivações e objetivos;Motivações e objetivos; O modelo #;O modelo #; Análise de programas # com redes de Petri;Análise de programas # com redes de Petri; Implementação de Haskell#;Implementação de Haskell#; Avaliação de desempenho;Avaliação de desempenho; Conclusões;Conclusões; Propostas de trabalhos futuros.Propostas de trabalhos futuros.

82 Conclusões O modelo # oferece um arcabouço de alto nível para programação paralela, em qualquer escala, sobre arquiteturas distribuídas, sem comprometimento inerente de eficiência;O modelo # oferece um arcabouço de alto nível para programação paralela, em qualquer escala, sobre arquiteturas distribuídas, sem comprometimento inerente de eficiência; –Advento de grid computing e cluster computing; Programas de larga escala e topologias complexas;Programas de larga escala e topologias complexas; –Total abstração entre os meios de coordenação e computação; –A noção de modularidade é levada ao extremo: Favorece e estimula a reusabilidade de componentes;Favorece e estimula a reusabilidade de componentes; Suporte a composição hierárquica;Suporte a composição hierárquica; Suporte à noção de esqueletos;Suporte à noção de esqueletos; Suporte à separação de módulos entrelaçados (aspectos);Suporte à separação de módulos entrelaçados (aspectos); –Suporte à programação em larga escala: Não torna complicada a programação em pequena escala;Não torna complicada a programação em pequena escala; –Tradução direta para MPI (eficiência e portabilidade); –Suporte multi-lingual; –Análise formal de propriedades e desempenho com redes de Petri;

83 Estrutura Motivações e objetivos;Motivações e objetivos; O modelo #;O modelo #; Análise de programas # com redes de Petri;Análise de programas # com redes de Petri; Implementação de Haskell#;Implementação de Haskell#; Avaliação de desempenho;Avaliação de desempenho; Conclusões;Conclusões; Propostas de trabalhos futuros.Propostas de trabalhos futuros.

84 Propostas de Trabalhos Futuros Técnicas de alocação de processos à processadores:Técnicas de alocação de processos à processadores: –Uso de esqueletos topológicos; Implementação de extensões # multi-linguais:Implementação de extensões # multi-linguais: –Módulos funcionais em C, Fortran, JAVA; –Adaptação ao problema em consideração; –Haskell é ideal para prototipação; Interfaces com bibliotecas científicas:Interfaces com bibliotecas científicas: –Bibliotecas, paralelizadas ou não, são largamente utilizadas em computação científica; PetsC, Lapack, IMSL, etc.PetsC, Lapack, IMSL, etc. –Abstração por meio de esqueletos topológicos parciais; –Modelo # oferece naturalmente tal capacidade;

85 Propostas de Trabalhos Futuros Ferramentas de alto nível para suporte à análise de propriedades formais com redes de Petri:Ferramentas de alto nível para suporte à análise de propriedades formais com redes de Petri: –Implementação no topo de INA e PEP; –Integração à VHT; Ferramentas de alto nível para suporte à análise e simulação de desempenho de programas com redes de Petri e simuladores de rede:Ferramentas de alto nível para suporte à análise e simulação de desempenho de programas com redes de Petri e simuladores de rede: –Implementações no topo TimeNET e NS (Network Simulator); Estudos comparativos;Estudos comparativos; –Integração à VHT;

86 Tese de Doutorado Francisco Heron de Carvalho Junior Rafael Dueire Lins Orientador Programação Paralela Eficiente e de Alto Nível sobre Arquiteturas Distribuídas

87 O Modelo # Ponto de Partida: Limitações de Haskell# Hierarquia de processos restringe expressividade:Hierarquia de processos restringe expressividade: –Dificuldade para expressar padrões iterativos de paralelismo; –Não permite intercalação de comunicação e computação; Reusabilidade restrita aos módulos funcionais;Reusabilidade restrita aos módulos funcionais; –Pouco poder composicional em nível de coordenação; … … 1. 1.Receber (portas de entrada) 2. 2.Efetuar computação (main) 3. 3.Enviar (portas de saída) ordem de leitura ordem de escrita

88 O Modelo #: Intercalação entre computação e comunicação: Essencial em muitos padrões de interação;Essencial em muitos padrões de interação; Como não comprometer a hierarquia de processos ?Como não comprometer a hierarquia de processos ? A solução está em Haskell:A solução está em Haskell: –O conceito de comunicação via lazy streams; Ativações de portas: linguagem recursivamente enumerável;Ativações de portas: linguagem recursivamente enumerável; Redes de Petri: subconjunto das ling. sensíveis ao contexto;Redes de Petri: subconjunto das ling. sensíveis ao contexto; Expressões regulares sincronizadas por semáforos;Expressões regulares sincronizadas por semáforos; –Equivalência com redes de Petri –Usadas na especificação do comportamento de processos; –A noção primitiva de interface;

89 O Modelo #

90 Motivações Até a década de 80Até a década de 80 –Supercomputação paralela restrita a grandes centros de pesquisa e indústrias; –Tecnologia de interesse estratégico de países desenvolvidos, sobretudo EUA; –Supercomputadores vetoriais e MPPs (alto custo). A partir de meado da década de 80 (Bell 2002)A partir de meado da década de 80 (Bell 2002) –Consolidação das arquiteturas distribuídas; –Cluster computing (Supercomputing for all); Supercomputadores construídos com hardware de prateleira;Supercomputadores construídos com hardware de prateleira; –Novas classes de usuários para supercomputação:

91 Motivações

92 Motivações Centros de pesquisa em diversas áreas:Centros de pesquisa em diversas áreas: –Matemáticos, físicos, engenheiros, biólogos, químicos, etc. –Alta demanda de desempenho e uso de matemática avançados; –Usuários leigos, com pouca habilidade em programação; –Poucos recursos para contratar especialistas; –Carência de programadores experientes em programação paralela eficiente sobre clusters para essas aplicações; Uso comercial e industrial tem se tornado comum:Uso comercial e industrial tem se tornado comum: –Bancos de dados de grande porte; –Sistemas de Mineração de dados; –Simulações em indústrias: Autombolística, aeroespacial, petrolífera, etc.;Autombolística, aeroespacial, petrolífera, etc.; Requisitos similares a computação científica;Requisitos similares a computação científica; –Aplicações de maior complexidade estrutural.

93 Motivações Carência por melhores ferramentas para o construção de programas paralelos eficientes;Carência por melhores ferramentas para o construção de programas paralelos eficientes; –Parallel Programming for all; –Tecnologia de programação não evoluiu com o aumento de complexidade das aplicações; Programação paralela é mais dificil inerentemente;Programação paralela é mais dificil inerentemente; –Linguagens hoje usadas em computação científica: Alta eficiência;Alta eficiência; Uso de primitivas de baixo nível intercaladas com o código que implementa as computações;Uso de primitivas de baixo nível intercaladas com o código que implementa as computações; pouco nível de abstração para lidar com aplicações complexas:pouco nível de abstração para lidar com aplicações complexas: Programs difíceis de manter e depurar;Programs difíceis de manter e depurar; Exemplos: MPI, PVM, HPF etc;Exemplos: MPI, PVM, HPF etc;

94 Objetivo Geral A proposta e implementação de um novo modelo para programação paralela explícita que atenda aos novos requisitos exigidos para o processo de desenvolvimento eficiente de aplicações complexas, as quais tem se tornado comuns, sobre as arquiteturas emergentes de supercomputação (clusters e constelações, em especial);A proposta e implementação de um novo modelo para programação paralela explícita que atenda aos novos requisitos exigidos para o processo de desenvolvimento eficiente de aplicações complexas, as quais tem se tornado comuns, sobre as arquiteturas emergentes de supercomputação (clusters e constelações, em especial);

95 Um novo modelo para programação paralela Adaptado às modernas técnicas de eng. de software;Adaptado às modernas técnicas de eng. de software; –Alto nível de abstração e modularidade; –Reuso de componentes; Alto desempenho, comparado à MPI;Alto desempenho, comparado à MPI; Simplicidade;Simplicidade; Expressividade e Generalidade;Expressividade e Generalidade; Análise de propriedades formais de programas;Análise de propriedades formais de programas; Fácil implementação no topo de MPI;Fácil implementação no topo de MPI; Portabilidade;Portabilidade;

96 O modelo # (Hash) Hierarquia de processos:Hierarquia de processos: –Mundo dos processos Mundo das computações Modelos de coordenação (coodernação vs. computação);Modelos de coordenação (coodernação vs. computação); –Execução paralela e computações (sequenciais) devem ser especificadas em etapas distintas do desenvolvimento do software paralelo; –A noção de mundo dos processos busca capturar a abstração do que chamamos de essência da programação paralela: Processos interagem e sincronizam por meio de comunicação;Processos interagem e sincronizam por meio de comunicação; No mundo dos processos, a ordem em que ocorrem as operações de comunicações é suficiente para descrever o comportamento de um programa paralelo;No mundo dos processos, a ordem em que ocorrem as operações de comunicações é suficiente para descrever o comportamento de um programa paralelo; A classe de comportamentos deve ser equivalente à a classe de comportamentos que podem ser descritos por redes de Petri;A classe de comportamentos deve ser equivalente à a classe de comportamentos que podem ser descritos por redes de Petri; Suporte a noção de esqueletos e composição hierárquica;Suporte a noção de esqueletos e composição hierárquica;

97 O modelo # (Componentes) Componentes: as peças básicas para compor programas paralelos sob modelo #;Componentes: as peças básicas para compor programas paralelos sob modelo #; Componente i1i1 onon o1o1 i2i2 o2o2 inin … … pontos de entrada Pontos de saída

98 O modelo # (Componentes) Componentes realizam uma tarefa específica;Componentes realizam uma tarefa específica; Existem dois tipos de componentes:Existem dois tipos de componentes: –Simples: Entidades de execução sequencial;Entidades de execução sequencial; Implementam computações;Implementam computações; Descritos em uma linguagem sequencial;Descritos em uma linguagem sequencial; –Compostos: Entidades de execução paralela (mundo dos processos);Entidades de execução paralela (mundo dos processos); Mecanismo hierárquico de composição de programas;Mecanismo hierárquico de composição de programas; Um componente composto define a aplicação:Um componente composto define a aplicação: –Componente de aplicação; –Como descrever componentes compostos ?

99 O modelo # (Interfaces) A noção primitiva de interfaceA noção primitiva de interface –Descrição comportamental de unidades paralelas; in* out x* y* ((x 2 )·(y//z)) z* 0-counter synchronized regular expression ( redes de Petri) (in ) · out Interface_A Interface_B

100 10 i1 o2 o1 unitA unitB merge d* e h f* c* a* b* Int [Int] Int (Int, Float) [Int] Interface_B Interface_A

101 O modelo # (Unidades) Duas questões vêm à tona:Duas questões vêm à tona: –Como definir o que uma unidade computa ? Unidades virtuais capturam somente o comportamento de comunicação da unidade em na rede;Unidades virtuais capturam somente o comportamento de comunicação da unidade em na rede; –Como componentes são integrados para compor aplicações ?

102 O modelo # (Unidades) Processos: unidades cuja computação é descrita por um componente simples;Processos: unidades cuja computação é descrita por um componente simples; –Processo são as unidades indivisíveis de programas dentro do modelo #; Clusters: unidades cuja computação é descrita por um componente composto;Clusters: unidades cuja computação é descrita por um componente composto; –Componentes podem ser aninhados a componentes; Composição hierárquica (aninhamento) de programas;Composição hierárquica (aninhamento) de programas; –Unidades podem ser entidade de execução paralela !!! –Capturando hierarquias de exploração do paralelismo; Constelaçãoes, cluster de multiprocessadores, etc.Constelaçãoes, cluster de multiprocessadores, etc.

103 O modelo # (Unidades) unitA CompA (pode ser simples ou composto) a* c b[1]* b[2]* 3 valor ignorado Argumento passado explicitamente

104 O modelo # (Unidades) Visão hierárquica de um programaVisão hierárquica de um programa Raiz é a unidade principal Unidades nas folhas são processos Units nos galhos são clusters

105 Esqueletos de Algoritmos Importante técnica de programação introduzida por Cole no final da década de 80;Importante técnica de programação introduzida por Cole no final da década de 80; Captura de padrões reusáveis de algoritmos, de forma a abstrair o programador das preocupações relativas a sua implementação eficiente;Captura de padrões reusáveis de algoritmos, de forma a abstrair o programador das preocupações relativas a sua implementação eficiente; –Foco em concorrência; Hoje, muitas linguagens suportam esqueletos:Hoje, muitas linguagens suportam esqueletos: –Caliban, SCL, Eden, P3L, etc. –Foco no algoritmo;

106 O modelo # (Esqueletos) Componentes com pelo menos uma unidade virtual são ditos componentes virtuais;Componentes com pelo menos uma unidade virtual são ditos componentes virtuais; –Esqueletos topológicos parciais; Os uso de esqueletos provê informações de alto nível sobre a topologia da rede de processos de um componente, permitindo:Os uso de esqueletos provê informações de alto nível sobre a topologia da rede de processos de um componente, permitindo: –Otimização na alocação de processos; –Melhor uso das primitivas de MPI Exemplo: esqueletos p/ abstração das primitivas de comunicação coletiva de MPI;Exemplo: esqueletos p/ abstração das primitivas de comunicação coletiva de MPI; –Maior poder para análise formal com redes de Petri;

107 O modelo # (Exemplos de Esqueletos) Esqueleto Pipe-Line:Esqueleto Pipe-Line: … pipe[1]pipe[2]pipe[N]

108 O modelo # (Esqueletos) Esqueleto Farm:Esqueleto Farm: distributor collector worker[1] worker[2] worker[N] ? ?

109 O modelo # (Esqueletos) Esqueleto Mesh :Esqueleto Mesh : … … … … ……

110 O modelo # (Esqueletos) Esqueleto Torus:Esqueleto Torus: … … … … ……

111 O modelo # (Operações sobre Unidades Virtuais) UnificaçãoUnificação –Compõe uma nova unidade a partir de um conjunto de unidades pré-existentes; FatorizaçãoFatorização –Toma uma unidade e a divide em várias unidades; –Inverse of unification; ReplicaçãoReplicação –Cria várias cópias de um única unidade; –Útil para operações de paralelismo de dados distribuído;

112 O modelo # (Operações sobre Unidades Virtuais) Uma unidade não pode participar em mais de uma operação;Uma unidade não pode participar em mais de uma operação; Unidades originais deixam de existir e são substituídas pelas unidades resultantes;Unidades originais deixam de existir e são substituídas pelas unidades resultantes; Comportamento das unidades originais é preservado; parcialmente pelas unidades resultantes;Comportamento das unidades originais é preservado; parcialmente pelas unidades resultantes; Esqueleto e operações sobre unidades virtuais, podem ser usados para construir a topologia virtual da rede de processos;Esqueleto e operações sobre unidades virtuais, podem ser usados para construir a topologia virtual da rede de processos; –Esqueletos podem ser sobrepostos e aninhados; –Topologias complexas podem ser definidas de uma forma mais abstrata, estruturada e incentivando o reuso de componentes.

113 O modelo # Em um programa válido no modelo # …Em um programa válido no modelo # … –… todos os canais são ponto-a-ponto; –… não existem unidades virtuais; Mas como substituir unidades virtuais por não-virtuais ?Mas como substituir unidades virtuais por não-virtuais ? –Unidade não-virtual podem ser nomeadas para ocupar o papel de uma unidade virtual, deixando esta de existir; –O comportamento da unidade nomeada deve ser compatível com o comportamento da unidade substituída; –Exemplo: Multiplicação de Matrizes (próximo slide);Multiplicação de Matrizes (próximo slide);

114 FARM TORUS partition by ? combine by ? partition by DistributeMatrix combine by CombineMatrix

115 A Linguagem Haskell# Uma implementação para o modelo #:Uma implementação para o modelo #: –Componentes simples descritos em Haskell; –Componentes compostos descritos em HCL (Haskell# Configuration Language); O uso de Haskell permite a ortogonalização entre os meios de coordenação e computação;O uso de Haskell permite a ortogonalização entre os meios de coordenação e computação; –Listas lazy são associadas aos pontos de entrada e saída; –Cada elemento da lista é um valor que trafega por um canal; Linguagens de configuração são ideais quando a noção de processo e canal de comunicação é explícita;Linguagens de configuração são ideais quando a noção de processo e canal de comunicação é explícita; –Simplicidade e alto grau de modularidade; –Paradigma bastante empregado em sistemas distribuídos; Atualmente, ausência ou fraco suporte à esqueletos;Atualmente, ausência ou fraco suporte à esqueletos;

116 A Linguagem Haskell# (Visão Geral de HCL) Coleção de declarações que definem um componente composto:Coleção de declarações que definem um componente composto: –Entidades: Interfaces, unidades, canais, índices, componentes usados;Interfaces, unidades, canais, índices, componentes usados; –Operações sobre unidades: Unificação, fatoração, replicação e nomeação;Unificação, fatoração, replicação e nomeação; –Ordem das declarações é irrelevante; Gerenciando grande número de entidades;Gerenciando grande número de entidades; –Parâmetros estáticos; –Notação indexada (índices e escopos de variação) ; –Expressões sobre índices, parâmetros e constantes;

117 A Linguagem Haskell# (Declarações HCL) Parâmetro Estático Ponto de Entrada Ponto de Saída Cabeçalho:Cabeçalho: –Nome do componente; –Parâmetro(s) estático(s); –Ponto(s) de entrada e/ou saída; Exemplo:Exemplo: component PIPE # in -> out with (…) -- declarações

118 A Linguagem Haskell# (Declarações HCL) Declarando componentes que serão usados:Declarando componentes que serão usados: –Organizados em uma biblioteca hierárquica; Exemplos:Exemplos:(…) use module MatMult use module ReadMatrix use module ShowMatrix use configuration Skeletons.Common.TORUS use configuration Skeletons.Common.MESH (…) Componentes Simples Componentes Compostos

119 A Linguagem Haskell# (Declarações HCL) Portas de Entrada Portas de Saída Declarando interfacesDeclarando interfaces –Portas, restrições comportamentais e comportamento; Exemplo:Exemplo: interface GridElem # (left,above) -> (right,below) behaving as Pipe # left -> right, behaving as Pipe # above -> below, behaving as: repeat alt { right! -> above! above! -> right! common: par {left?;above?} }

120 A Linguagem Haskell# (Declarações HCL) Declarando unidades;Declarando unidades; Exemplos:Exemplos: virtual unit worker # Worker inp -> outp unit random as Random seed -> rand_value # IRandom seed -> rand_value # IRandom seed -> rand_value [/ unit matmult[i][j] as MatMult (N,a,b,l,t) -> (r,b,c) as MatMult (N,a,b,l,t) -> (r,b,c) # IMatMult (a,b,l,t) -> (r,b,c)/] # IMatMult (a,b,l,t) -> (r,b,c)/] Unidade virtual Unidade não-virtual (notação indexada) index i,j range [1, N]

121 A Linguagem Haskell# (Declarações HCL) Declarando canais;Declarando canais; Exemplos:Exemplos: connect distributor->out to worker<-in connect worker->out to collector<-in connect * unitA->b[2] to merge<-f[1] buffered 10

122 A Linguagem Haskell# (Declarações HCL) Associando pontos de entrada/saída do componente para portas de entrada/saída das unidades;Associando pontos de entrada/saída do componente para portas de entrada/saída das unidades; Exemplo:Exemplo: bind unitA->b[1] to o1 bind pipe[1] <-in to in bind pipe[N]->out to out

123 A Linguagem Haskell# (Declarações HCL) wire function Operação de unificação;Operação de unificação; Exemplos:Exemplos: unify wA # a -> res, wB # b -> res, cell # (a,b) -> (c,d) to mm # MatrixMult (a,b) -> (c,d,res) connections choice a

124 A Linguagem Haskell# (Declarações HCL) Operação de fatoração;Operação de fatoração; Exemplos:Exemplos: index i range [1,10] factorize merge3 # [/s[i]/] -> o to [/pipe[i] # Pipe s[i] -> o/] connections some_strategy o

125 A Linguagem Haskell# (Declarações HCL) Operação de replicação;Operação de replicação; Exemplos:Exemplos: replicate 3 u1 # a -> (b,_), u2 # (_,c) -> d connections some_strategy1 a, some_strategy2 b, broadcast c, choice d

126 A Linguagem Haskell# (Declarações HCL) Operação de nomeação;Operação de nomeação; Exemplos:Exemplos: assign mB to farmB.distributor assign unidade_X # (a,_) -> c to pipeline.pipe[1] # a -> c

127 Evolução de Haskell# em relação a versão anterior Uma série de restrições tornavam Haskell# imprópria para especificação da maioria das aplicações relevantes;Uma série de restrições tornavam Haskell# imprópria para especificação da maioria das aplicações relevantes; A versão atual suporta maior expressividade;A versão atual suporta maior expressividade; –Consegue expressar um conjunto maior de padrões de interação entre processos, equiparado ao poder expressivo das redes de Petri P/T; –Intercalação entre comunicação e computação sem comprometimento da hierarquia de processos; Na versão anterior, processos não intercalavam comunicação e computação, uma suposição bastante restritiva;Na versão anterior, processos não intercalavam comunicação e computação, uma suposição bastante restritiva; Fortalecimento da hierarquia de processos;Fortalecimento da hierarquia de processos; Reuso de componentes à nível de coordenação;Reuso de componentes à nível de coordenação; –Somente módulos funcionais podiam ser reusados; –Suporte a esqueletos e componentes aninhados;

128 Trabalhos em Andamento para Conclusão da Tese Implementação de Haskell#;Implementação de Haskell#; –Geração de código MPI; Implementação dos esqueletos MPI;Implementação dos esqueletos MPI; –Tradução de código HCL para PNML (Petri Net Markup Language); Interface para ferramentas de análise de propriedadses formais de progrmas baseados em redes de Petri;Interface para ferramentas de análise de propriedadses formais de progrmas baseados em redes de Petri; –VHT (Visual Haskell# Tool); Atualmente sendo implementado em JAVA;Atualmente sendo implementado em JAVA; Suporte ao modelo # de programação;Suporte ao modelo # de programação;

129 Trabalhos em Andamento para Conclusão da Tese Avaliação da linguagemAvaliação da linguagem –Desempenho, expressividade e adequabilidade a aplicações científicas e de engenharia reais; –Benchmarks, comparando speedup de aplicações Haskell# com implementações MPI destas; NAS Parallel Benchmarks;NAS Parallel Benchmarks; –Aplicações reais, com o fim de avaliar a linguagem do ponto de vista da engenharia de software parealelo; Simulação de bacias petrolíferas;Simulação de bacias petrolíferas; Climate System Model (CSM);Climate System Model (CSM); Modificações sintáticas na linguagem ainda podem ocorrer eventualmente;Modificações sintáticas na linguagem ainda podem ocorrer eventualmente;

130 Trabalhos Futuros O desenvolvimento do ambiente Haskell# nos sugere uma série de trabalhos futuros, que extrapolam os objetivos da tese:O desenvolvimento do ambiente Haskell# nos sugere uma série de trabalhos futuros, que extrapolam os objetivos da tese: –Uso de simuladores de rede para simulação de programas e análise de desempenho (custo de comunicação), integrado ao VHT; –Exploração de paralelismo hierárquico, com a possibilidade de geração de código OpenMP para clusters alocados a um nó multiprocessado; Não há linguagens paralelas de alto nível que suportem essa funcionalidade [Bell 2002];Não há linguagens paralelas de alto nível que suportem essa funcionalidade [Bell 2002];

131 Trabalhos Futuros Cont.:Cont.: –Suporte multilingual, permitindo que outras linguagens, em alternativa a Haskell sejam usadas para programação dos componentes simples: Adaptabilidade a classes de aplicações;Adaptabilidade a classes de aplicações; –C e Fortran para computação científica, JAVA em aplicações comerciais, etc. Haskell poderia ser usada como uma linguagem de especificação, dentro desse contexto;Haskell poderia ser usada como uma linguagem de especificação, dentro desse contexto; Será Investigado o uso do paradigma de programação orientado a aspecto (AOP), para ortognalizar os meios de coordenação e computação na ausência de lazy evaluation;Será Investigado o uso do paradigma de programação orientado a aspecto (AOP), para ortognalizar os meios de coordenação e computação na ausência de lazy evaluation;

132 Trabalhos Futuros Cont.:Cont.: –Interface com bibliotecas científicas: Bibliotecas de uso científico são largamente usadas por cientistas de todas as áreas;Bibliotecas de uso científico são largamente usadas por cientistas de todas as áreas; –Usam os melhores algoritmos; –Implementações eficientes; –Implementações estáveis; –Podem ser paralelizadas ou não; Funções de bibliotecas científicas podem ser oferecidas como componentes do ambiente paralelo, de forma transparente ao programador;Funções de bibliotecas científicas podem ser oferecidas como componentes do ambiente paralelo, de forma transparente ao programador; Talvez incluiremos algo sobre isso na tese;Talvez incluiremos algo sobre isso na tese;

133 Estrutura da Tese Capítulo 1: Introdução, contextualização, motivação e objetivos ;Capítulo 1: Introdução, contextualização, motivação e objetivos ; Capítulo 2: Revisão de literatura estudada e introdução dos conceitos básicos usados ao longo do texto;Capítulo 2: Revisão de literatura estudada e introdução dos conceitos básicos usados ao longo do texto; Capítulo 3: Descrição da Linguagem Haskell# e de seu modelo de programação e implementação;Capítulo 3: Descrição da Linguagem Haskell# e de seu modelo de programação e implementação; Capítulo 4: Programação baseadas em esqueletos e seu emprego;Capítulo 4: Programação baseadas em esqueletos e seu emprego; Capítulo 5: Análise de propriedads de programas com redes de Petri;Capítulo 5: Análise de propriedads de programas com redes de Petri; Capítulo 6: Aplicações e avaliação de desempenho;Capítulo 6: Aplicações e avaliação de desempenho; Capítulo 7: Apresentação do ambiente VHT;Capítulo 7: Apresentação do ambiente VHT; Capítulo 8: Conclusões e linhas para futuro trabalhos;Capítulo 8: Conclusões e linhas para futuro trabalhos;

134 Conclusões Entrega da versão final para apreciação da banca: 15/12/2003.Entrega da versão final para apreciação da banca: 15/12/2003. Previsão de defesa: 15/02/2004Previsão de defesa: 15/02/2004 Entrega da versão final: 30/03/2004Entrega da versão final: 30/03/2004


Carregar ppt "Tese de Doutorado Francisco Heron de Carvalho Junior Rafael Dueire Lins Orientador Programação Paralela Eficiente e de Alto Nível sobre Arquiteturas Distribuídas."

Apresentações semelhantes


Anúncios Google