Francisco Heron de Carvalho Junior Rafael Dueire Lins Orientador

Apresentação em tema: "Francisco Heron de Carvalho Junior Rafael Dueire Lins Orientador"— Transcrição da apresentação:

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

2 Antecedentes 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: Haskell#: Lima, 2000 (tese de doutorado); 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; MPP’s (Massive Parallel Processors); Supercomputadores propriamente ditos; Cluster computing; Supercomputação com equipamento de prateleira (commodities); Excelente relação custo / benefício frente à MPP’s; Evolução do hardware e software; Aumento na escala de usuários (supercomputação para todos); Grid computing; Supercomputação geograficamente distribuída; Aplicações paralelas de grande escala e complexidade; 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; Programação paralela distribuída (explícita); Passagem de mensagens: Parallel Virtual Machine (PVM): ambientes heterogêneos; Message Passing Interface (MPI): ambientes homogêneos (clusters atuais);  Eficiência, portabilidade e escalabilidade : Primitivas de baixo nível como funções de bibilotecas;  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: 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; 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; O modelo #;
Análise de programas # com redes de Petri; Implementação (Haskell#); Avaliação de desempenho; Conclusões; Propostas de trabalhos futuros.

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

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

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

10 Programa # = Coleção de Componentes

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

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

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

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

15 Especificando Componentes Configuração #
2 1 3 4

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

17 Unidades e Interfaces Componentes compostos descrevem redes de unidades, que interagem por meio de canais de comunicação; Unidades (peças básicas): Abstração para entidades executáveis (generalização de processos); Interface 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; 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 coleção de portas (entrada ou saída); Uma expressão de ativação (comportamento): Formalismo: Expressão regular controlada por semáforos; Equivalência com redes de Petri rotuladas terminais; Descreve as sequências válidas de ativação das portas; … …

19 Comportamento de Unidades Combinadores da Expressão de Ativação
par a1 a2 …an : concorrência; seq a1 a2 …an : sequência; alt a1 a2 …an : alternativa; 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 entrada; signal s : incremento de semáforo wait s : decremento de semáforo

20 Comunicação via Lazy Streams
Sequências de dados com informação de mesma natureza; v1, v2, …, vn; Ao final, acompanha um terminador de stream (EOS); 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 *): EOS é acompanhado do aninhamento da stream terminada; Transmissão de <<<1>,<2,3>>,<<3,4>,<5,6,7>>>: [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
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; 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 <y & z> until <x & y & z> * l x *** [t] [[[t]]] z ** [[t]] y

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

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

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

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

26 Unidades Virtuais Unidade parametrizada por sua funcionalidade:
Não associada a um componente; Operação assign: Substituindo uma unidade virtual por uma unidade não-virtual; Preservação comportamental; 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); Mapeamento de processos aos processadores; Melhora capacidade de raciocínio sobre programas;

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

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

29 Sobrepondo Componentes Abstratos
pipe_line mesh … … l

30 Operações sobre Unidades Virtuais
Mecanismo de abstração; 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; 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; Semântica de ativação em redes de Petri;

31 Unificação de Unidades
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 wa<-a e cell<-a conectadas à portas distintas i j i wb<-b e cell<-b conectadas à mesma porta unify c d res b a wA a mm b c d res choice 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?} } wB cell

32 Fatoração de Unidades pipe[1] merge3 factorize pipe[2] pipe[3] s1 s4
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 <s1 & s2 & s3 & s4> someStrategy pipe[1] pipe[2] pipe[3] s1 s4 s2 s3 merge3 s2 s1 s3 s4 factorize

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

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

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

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

37 Esqueleto Torus …

38 [/ assign matrix_mult[i][j] to mm_grid[i][j] /] index i,j range [1,N]
… [/ assign matrix_mult[i][j] to mm_grid[i][j] /] 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.distributor assign mB to farmB.distributor assign mC to collector partition by ? DistributeMatrix partition by partition by ? CombineMatrix combine by combine by ?

39 Esqueletos 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; 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 Benchmarks
NASA Research at Ames, EUA; Kernels: EP, IS, CG; Extensivo uso de comunicação coletiva; Usadas nos benchmarks mostrados adiante; Aplicações Simuladas: LU, SP e BT; Padrão SPMD: Derivação de programas # a partir de programas MPI;

41 Implementação de IS IIS kr kl kb2 kb1 bst bs
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 ); IIS kr kl MPI_Alltoallv(key_buff1, send_count, send_displ, MPI_INT, key_buff2, recv_count, recv_displ, MPI_COMM_WORLD ); MPI_Allreduce(bucket_size, bucket_size_totals, NUM_BUCKETS+TEST_ARRAY_SIZE, MPI_INT, MPI_SUM, MPI_COMM_WORLD ); kb2 kb1 bst bs

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

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

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

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

46 Implementação de IS is_unit[1] is_unit[4] is_unit[2] is_unit[3]
AlltoAllv Topology AllReduce Topology is_unit[4] is_unit[2] is_unit[3]

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

48 Implementação de IS IS is_unit[1] is_unit[2] is_unit[4] is_unit[3]
AlltoAllv Topology AllReduce Topology is_unit[2] is_unit[4] is_unit[3]

49 Implementação de IS IS IS Haskell Programming IS IS

50 Implementation of IS configuration IS<PROBLEM_CLASS, NUM_PROCS, MAX_KEY_LOG2, NUM_BUCKETS_LOG2, TOTAL_KEYS_LOG2, MAX_ITERATIONS, MAX_PROCS, TEST_ARRAY_SIZE> 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 <bs & kb>; 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, 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<DIM, COL_FACTOR, NA, NONZER, SHIFT, NITER, RCOND, ZVV> # () -> (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 <bs & kb>; 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<DIM>, w<DIM>: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; O modelo #;
Análise de programas # com redes de Petri; Implementação de Haskell#; Avaliação de desempenho; Conclusões; Propostas de trabalhos futuros.

54 Modelo # e Redes de Petri
Tradução da rede de processos para redes de Petri; Análise de propriedades formais de programas: INA (Integrated Net Analyser) e PEP; Avaliação de desempenho de programas: Redes de Petri estocásticas; SPNL e TimeNET; Antecedentes: Tradução OCCAM  redes de Petri (Lins & Maciel); Tracução Haskell#  redes de Petri (Lima); 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; Redes de Petri hierárquicas; Modelagem da ativação de portas: Porta individual; Agrupamentos de Portas (choice e não-choice); Semântica da escolha entre portas choice; Modelagem de agrupamentos aninhados; 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: Valor de dados; Terminador de stream em aninhamento k (EOS k); Necessário para modelagem de repeat … until; 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; 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; 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;

62 Análise de Propriedades Formais de Programas #
Estudos de Caso: Jantar dos Filósofos; (2 soluções) Simulação do Protocolo do Bit Alternado; Ferramentas: INA e PEP; 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: deadlocks; Justiça; Grau de paralelismo ou concorrência; Padrões comportamentais regulares

63 Jantar dos Filósofos Solução 1
Situação geral; Presença de agrupamentos de portas; 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: Modelando um processo filósofo; Introduzindo protocolo de finalização de streams; Conectando redes de Petri dos processos filósofos;

64 Jantar dos Filósofos Solução 2
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: Modelando um processo filósofo; Introduzindo protocolo de finalização de streams; Conectando redes de Petri dos processos filósofos;

65 Protocolo do Bit Alternado Solução Única
Pode ser visto como um esqueleto (não-total): Modelagem de protocolos de comunicação de canais; Unidades heterogêneas; Presença de streams com aninhamento > 1; Modelagem com redes de Petri; 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; O modelo #;
Análise de programas # com redes de Petri; Implementação de Haskell#; Avaliação de desempenho; Conclusões; Propostas de trabalhos futuros.

67 Compilador # 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); Processos # implementados como funções de alta ordem; Entrada: autômato de validação do processo. Induzido pelo comportamento de cada processo; Tipos de processos suportados: Assícronos (fluxo de controle): C, Fortran; Orientado a demanda pela saída: Haskell; Controlado pelo fluxo de entrada: Id;

68 VHT (Visual # Tool) 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; Execução do programa e debuging; Integrado ao LAM-MPI; Possível integração a ferramentas de debugging de programas MPI; Em fase desenvolvimento (prototipação).

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

70 Avaliação de Desempenho
NAS Parallel Benchmarks EP, CG e IS; Ambiente de Hardware: Cluster de PC’s: 8 Pentium IV 2GHz RAM: 4 x 256MB, 2 X 512MB, 1 X 1GB Fast Ethernet (100MBs). 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;

71 Avaliação de Desempenho Restrições e Metodologia
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; Metodologia: Cáculo de tempo de execução e speedup; 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;

72 Avaliação de Desempenho Curvas de Desempenho
EP: speedup aproxima-se ao linear (ótimo); 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; Rede de alta latência; 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
Custos observados: Computação efetiva (trabalho útil); Avaliação de funções de ligação; “Marshalling” (de valores Haskell a buffers MPI); Sincronização e Comunicação (MPI); Gerenciamento Automático de Memória;

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

75 Análise de Custos (CG) i ii iii iv v CG-1 SEQ 90,2% - 9,8% 2 79,1%
Caso Procs. i ii iii iv v 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 84,5% 15,5% 68,5% 1,2% 1,7% 10,8% 70,2% 2,5% 12,9% 6,3% 61,1% 5,1% 19,5% 4,5%

76 Análise de G.A.M. (IS) IS-1 SEQ 38,1% 112,3 - 2 36,1% 72,8 1,5 1,4 4
Caso NPROCS Eficiência de coleta Tempo de coleta Speedup coletor Speedup mutador IS-1 SEQ 38,1% 112,3 - 2 36,1% 72,8 1,5 1,4 4 29,3% 28,1 4,0 2,7 8 25,9% 15,1 7,4 4,2 IS-2 41,4% 247,7 38,9% 168,0 1,3 34,4% 70,5 3,5 2,6 27,5% 31,9 7,7 4,1

77 Análise de G.A.M. (CG) CG-1 SEQ 5,5% 143,1 - 2 5,7% 72,2 1,9 2,0 4
Caso NPROCS Eficiência de coleta Tempo de coleta Speedup coletor Speedup mutador CG-1 SEQ 5,5% 143,1 - 2 5,7% 72,2 1,9 2,0 4 4,9% 39,8 3,6 3,1 8 0,8% 4,7 30,4 4,4 CG-2 350,5 152,0 2,3 1,8 61,1 5,7 16,2 21,5 5,0

78 Análise de Speedup (IS)
Caso NPROCS i + ii + iii + iv + v IS-1 2 2,1 1,9 1,6 1,5 1,2 4 4,1 3,8 3,2 2,6 2,5 8 7,5 7,0 5,9 4,0 4,4 IS-2 1,8 - 8,0 7,3 6,1 4,5

79 Análise de Speedup (CG)
Caso NPROCS i + ii + iii + iv + v CG-1 2 2,0 1,9 1,8 4 3,9 3,8 3,6 3,2 8 7,9 7,4 6,7 4,9 5,3 CG-2 2,1 1,7 4,0 3,7 3,4 8,0 7,6 7,0 5,5 6,0

80 Influência da Coleta de Lixo Resumo
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; Compensação do custo 3; Pode-se assumir nulo o custo de run-time de Haskell#; OBS: Marshalling pode ser otimizado (dependente de GHC);

81 Estrutura Motivações e objetivos; O modelo #;
Análise de programas # com redes de Petri; Implementação de Haskell#; Avaliação de desempenho; Conclusões; 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; Advento de grid computing e cluster computing; 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; Suporte a composição hierárquica; Suporte à noção de esqueletos; 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; 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; O modelo #;
Análise de programas # com redes de Petri; Implementação de Haskell#; Avaliação de desempenho; Conclusões; Propostas de trabalhos futuros.

84 Propostas de Trabalhos Futuros
Técnicas de alocação de processos à processadores: Uso de esqueletos topológicos; 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: Bibliotecas, paralelizadas ou não, são largamente utilizadas em computação científica; 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: 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: Implementações no topo TimeNET e NS (Network Simulator); Estudos comparativos;

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

87 O Modelo # Ponto de Partida: Limitações de Haskell#
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; Pouco poder composicional em nível de coordenação; … Receber (portas de entrada) Efetuar computação (main) Enviar (portas de saída) ordem de leitura escrita

88 O Modelo #: Intercalação entre computação e comunicação:
Essencial em muitos padrões de interação; Como não comprometer a hierarquia de processos ? A solução está em Haskell: O conceito de comunicação via lazy streams; Ativações de portas: linguagem recursivamente enumerável; Redes de Petri: subconjunto das ling. sensíveis ao contexto; 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 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 MPP’s (alto custo). 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; Novas classes de usuários para supercomputação: É importante atentar ao fato de que aplicaçoes científicas nesse nicho

91 Motivações

92 Motivações 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: Bancos de dados de grande porte; Sistemas de Mineração de dados; Simulações em indústrias: Autombolística, aeroespacial, petrolífera, etc.; 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; “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; Linguagens hoje usadas em computação científica: Alta eficiência; 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: Programs difíceis de manter e depurar; 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);

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

96 O modelo # (“Hash”) Hierarquia de processos:
“Mundo dos processos” “Mundo das computações” 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; 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; 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 #; … i2 in Componente i1 pontos de entrada … Pontos de saída o1 on o2

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

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

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

101 O modelo # (Unidades) 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; Como componentes são integrados para compor aplicações ? THE BUILDING BLOCKS OF HASKELL# PROGRAMS ARE COMPONENTS. COMPONENTS CAN BE COMPOSED (HCL) OR FUNCTIONAL MODULES (HASKELL). FUNCTIONAL MODULES ARE THE SEQUENTIAL UNITS… Um transparência diz que programas Haskell# são compostos a partir de componentes. No outro slide, mostra um componente composto (primeiro o diagrama, depois o código HCL) e no outro um componentes simples (programa Haskell)…

102 O modelo # (Unidades) 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; Componentes podem ser aninhados a componentes; 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. THE BUILDING BLOCKS OF HASKELL# PROGRAMS ARE COMPONENTS. COMPONENTS CAN BE COMPOSED (HCL) OR FUNCTIONAL MODULES (HASKELL). FUNCTIONAL MODULES ARE THE SEQUENTIAL UNITS… Um transparência diz que programas Haskell# são compostos a partir de componentes. No outro slide, mostra um componente composto (primeiro o diagrama, depois o código HCL) e no outro um componentes simples (programa Haskell)…

103 CompA (pode ser simples ou composto)
O modelo # (Unidades) unitA 3 CompA (pode ser simples ou composto) Argumento passado explicitamente valor ignorado b[1]* a* b[2]* THE BUILDING BLOCKS OF HASKELL# PROGRAMS ARE COMPONENTS. COMPONENTS CAN BE COMPOSED (HCL) OR FUNCTIONAL MODULES (HASKELL). FUNCTIONAL MODULES ARE THE SEQUENTIAL UNITS… Um transparência diz que programas Haskell# são compostos a partir de componentes. No outro slide, mostra um componente composto (primeiro o diagrama, depois o código HCL) e no outro um componentes simples (programa Haskell)… c

104 O modelo # (Unidades) Visã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; 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: Caliban, SCL, Eden, P3L, etc. Foco no algoritmo;

106 O modelo # (Esqueletos)
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: 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; Maior poder para análise formal com redes de Petri;

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

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

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

110 O modelo # (Esqueletos)
Esqueleto Torus: …

111 O modelo # (Operações sobre Unidades Virtuais)
Unificação Compõe uma nova unidade a partir de um conjunto de unidades pré-existentes; Fatorização Toma uma unidade e a divide em várias unidades; Inverse of unification; Replicaçã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; Unidades originais deixam de existir e são substituídas 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; 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 # …
… todos os canais são ponto-a-ponto; … não existem unidades 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);

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

115 A Linguagem Haskell# 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; 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; Simplicidade e alto grau de modularidade; Paradigma bastante empregado em sistemas distribuídos; 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: Entidades: Interfaces, unidades, canais, índices, componentes usados; Operações sobre unidades: Unificação, fatoração, replicação e nomeação; Ordem das declarações é irrelevante; 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: Nome do componen te; Parâmetro(s) estático(s); Ponto(s) de entrada e/ou saída; Exemplo: component # in -> out with (…) -- declarações

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

119 A Linguagem Haskell# (Declarações HCL)
Portas de Entrada Portas de Saída Declarando interfaces Portas, restrições comportamentais e comportamento; 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)
Unidade virtual Unidade não-virtual Declarando unidades; Exemplos: virtual unit worker # Worker inp -> outp unit random as Random seed -> rand_value # IRandom seed -> rand_value [/ unit matmult[i][j] as MatMult (N,a,b,l,t) -> (r,b,c) # IMatMult (a,b,l,t) -> (r,b,c)/] Unidade não-virtual (notação indexada) index i,j range [1, N]

121 A Linguagem Haskell# (Declarações HCL)
Declarando canais; 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; 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; 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; 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; 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; 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; 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; Fortalecimento da hierarquia de processos; 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#; Geração de código 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; VHT (Visual Haskell# Tool); Atualmente sendo implementado em JAVA; Suporte ao modelo # de programação;

129 Trabalhos em Andamento para Conclusão da Tese
Avaliaçã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; 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; Climate System Model (CSM); 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: 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];

131 Trabalhos Futuros 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; 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; 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.: Interface com bibliotecas científicas:
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; Talvez incluiremos algo sobre isso na tese;

133 Estrutura da Tese 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 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 5: Análise de propriedads de programas com redes de Petri; Capítulo 6: Aplicações e avaliação de desempenho; Capítulo 7: Apresentação do ambiente VHT; 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. Previsão de defesa: 15/02/2004 Entrega da versão final: 30/03/2004