Computação de Alto Desempenho com Qualidade: Desafios e Perspectivas

Transcrição

1 Computação de Alto Desempenho com Qualidade: Desafios e Perspectivas Paulo Sérgio Lopes de Souza pssouza@icmc.usp.br Universidade de São Paulo / ICMC / SSC São Carlos Laboratório de Sistemas Distribuídos e Programação Concorrente Intel Innovation Week e 25 de setembro de 2014 Centro Universitário Senac São Paulo - SP

2 Agenda A Universidade de São Paulo em São Carlos Software com qualidade Teste de aplicações de alto desempenho Perspectivas futuras Conclusões

3 USP São Carlos Dados de Abril/2014 7,7k alunos de graduação e pós-graduação 522 Professores 23 Cursos de graduação 18 Programas de pós-graduação 5 Unidades: ICMC, EESC, IFSC, IQSC e IAU

4 Teste de programas concorrentes Pesquisadores Paulo S. L. Souza (LASDPC/ICMC/USP) Simone Senger de Souza (LABES/ICMC/USP) Júlio Cézar Estrella (LASDPC/ICMC/USP) Sarita Mazzini Bruschi (LASDPC/ICMC/USP) Márcio Delamaro (LABES/ICMC/USP) João Lourenço (FCT/UNL) Ed Zaluska (ECS/Soton) ~16 alunos (IC/ME/DO)

5 Agenda A Universidade de São Paulo em São Carlos Software com qualidade Teste de aplicações de alto desempenho Perspectivas futuras Conclusões

6 Software com qualidade A importância da qualidade no que fazemos! Como aferir qualidade no software? Sequencial Faz o prometido? (Foi feito o que se esperava?) Faz de maneira correta (Isso aí está certo?) Tem o desempenho esperado (Como é feito isso?)... manutenção, flexibilidade, usabilidade.

7 Software com qualidade O que é o Teste de Software? Teste Examina comportamento do programa Heurística: pode-se revelar defeitos quando se testa Como garantir que o código está correto? Objetivo do Teste => melhorar os casos de teste! Teste não é depuração! Depuração localiza causas que levam à falha Como escolher casos de teste? Critérios de teste e elementos requeridos

8 Software concorrente com qualidade Foco das pesquisas Encontrar defeitos difíceis de serem revelados em programas concorrentes Comunicação & sincronização entre processos Teste de software concorrente As mesmas preocupações do software sequencial e mais: Não determinismo - diferentes saídas para a mesma entrada Deadlock e starvation Diferentes paradigmas de comunicação e sincronização Escalabilidade Segurança Portabilidade...

9 Não determinismo recv(p0) P1 P0 P2 1 1 send(p1) 2 send(p2) 1 recv(p0) send(p0) 2 3 recv(-1) 2 send(p0) 4 recv(-1) Sincronizações: (1 0,1 1 ), (2 0,1 2 ), (2 2,3 0 ), (2 1,4 0 ) Sincronizações: (1 0,1 1 ), (2 0,1 2 ), (2 1,3 0 ), (2 2,4 0 )? 9

10 Agenda A Universidade de São Paulo em São Carlos Software com qualidade Teste de aplicações de alto desempenho Perspectivas futuras Conclusões

11 Teste de aplicações de alto desempenho Exemplo com passagem de mensagens GCD (Greatest Common Divisor) para três números para x = 1, y = 2 e z = 1 P 0 {gcd} x = 1, y = 2 {mgcd} P mestre y = 2, z = 1 x' = 1 y' = 1 P 1 {gcd} z = 1 (gcd) P 2 {gcd}

12 Teste de aplicações de alto desempenho Programa GCD para três números para x = 3, y = 6 e z = 4 Foi testado o suficiente? P 0 {gcd} x = 3, y = 6 {mgcd} P mestre y = 6, z = 4 x' = 3 y' = 2 P 1 {gcd} x = 3, y = 2 z = 1 (gcd) P 2 {gcd}

13 Teste de aplicações de alto desempenho /* Master program GCD - mgcd */ main() { /*1*/ integer x,y,z, slv[3], buf[2]; /*1*/ read (x, y, z); /*1*/ spawn_process("gcd", NULL, 3, slv); /*2*/ buf[0] = x; buf[1] = y; /*2*/ send(slv[0], 2, buf); /*3*/ buf[0] = y; buf[1] = z; /*3*/ send(slv[1], 2, buf); /*4*/ recv(*, x); /*5*/ nb_recv(*, y); /*6*/ if ( ( x>1 ) && ( y>1 ) ) { /*7*/ buf[0] = x; buf[1] = y; /*7*/ send(slv[2], 2, buf); /*8*/ recv(*, z); /*9*/ else { /*9*/ finalize_process(slv[2]); /*9*/ z = 1; /*9*/ } /*10*/ print (z); /*10*/ finalize(); /*10*/ } /* Slave program GCD - gcd */ main(){ /*1*/ integer pid, x, y, buf[2]; /*1*/ pid = my_father(); /*2*/ recv(pid, 2, buf); /*2*/ x = buf[0]; /*2*/ y = buf[1]; /*3*/ while (x!= y){ ( x<y ) /*4*/ if /*5*/ y = y - x; /*6*/ else /*6*/ x = x - y; /*7*/ } /*8*/ send(pid,1, x); /*9*/ finalize(); /*9*/ } nb_recv chegando depois x = 1 y =? x = 1 e y = 2 z = 1 (saída esperada ) nó 5 m como nb_recv(*, y) - o correto era recv(*, y) {x=1, y=2, z=1} não revela o defeito {x=3, y=6, z=4} pode revelar o defeito

14 Teste de aplicações de alto desempenho /* Master program GCD - mgcd */ main() { /*1*/ integer x,y,z, slv[3], buf[2]; /*1*/ read (x, y, z); /*1*/ spawn_process("gcd", NULL, 3, slv); /*2*/ buf[0] = x; buf[1] = y; /*2*/ send(slv[0], 2, buf); /*3*/ buf[0] = y; buf[1] = z; /*3*/ send(slv[1], 2, buf); /*4*/ recv(*, x); /*5*/ nb_recv(*, y); /*6*/ if ( ( x>1 ) && ( y>1 ) ) { /*7*/ buf[0] = x; buf[1] = y; /*7*/ send(slv[2], 2, buf); x = 3 e y = 6 /*8*/ recv(*, z); /*9*/ else { /*9*/ finalize_process(slv[2]); /*9*/ z = 1; /*9*/ } /*10*/ print (z); /*10*/ finalize(); /*10*/ } z = 3 (esperava 1 ) nb_recv antes depois x = 3 y =? /* Slave program GCD - gcd */ main(){ /*1*/ integer pid, x, y, buf[2]; /*1*/ pid = my_father(); /*2*/ recv(pid, 2, buf); /*2*/ x = buf[0]; /*2*/ y = buf[1]; /*3*/ while (x!= y){ ( x<y ) /*4*/ if /*5*/ y = y - x; /*6*/ else /*6*/ x = x - y; /*7*/ } /*8*/ send(pid,1, x); /*9*/ finalize(); /*9*/ } nó 5 m como nb_recv(*, y) (o correto era recv(*, y) ) {x=1, y=2, z=1} não revela o defeito {x=3, y=6, z=4} pode revelar o defeito

15 Teste de aplicações de alto desempenho /* Master program GCD - mgcd */ main() { /*1*/ integer x,y,z, slv[3], buf[2]; /*1*/ read (x, y, z); /*1*/ spawn_process("gcd", NULL, 3, slv); /*2*/ buf[0] = x; buf[1] = y; /*2*/ send(slv[0], 2, buf); /*3*/ buf[0] = y; buf[1] = z; /*3*/ send(slv[1], 2, buf); /*4*/ recv(*, x); /*5*/ nb_recv(*, y); /*6*/ if ( ( x>1 ) && ( y>1 ) ) { /*7*/ buf[0] = x; buf[1] = y; /*7*/ send(slv[2], 2, buf); x = 3 e y = 2 /*8*/ recv(*, z); /*9*/ else { /*9*/ finalize_process(slv[2]); /*9*/ z = 1; /*9*/ } /*10*/ print (z); /*10*/ finalize(); /*10*/ } z = 1 (Saída esperada ) /* Slave program GCD - gcd */ main(){ /*1*/ integer pid, x, y, buf[2]; /*1*/ pid = my_father(); /*2*/ recv(pid, 2, buf); /*2*/ x = buf[0]; /*2*/ y = buf[1]; /*3*/ while (x!= y){ ( x<y ) /*4*/ if /*5*/ y = y - x; /*6*/ else /*6*/ x = x - y; /*7*/ } /*8*/ send(pid,1, x); /*9*/ finalize(); /*9*/ } nb_recv chegando depois x = 3 y = 2 nó 5 m como nb_recv(*, y) - o correto era recv(*, y) {x=2, y=4, z=6} não revela o defeito {x=3, y=6, z=4} pode revelar o defeito

16 Teste de aplicações de alto desempenho Como atacar esses desafios? Técnicas de Teste Quais técnicas existem? Funcional, Estrutural e Baseada em Defeitos Por que usar a estrutural? Oferece cobertura de código Detalhes da comunicação e sincronização Detalhes do fluxo de controle e dados em diferentes threads Não encapsular não determinismo inerente à IPC

17 Teste de aplicações de alto desempenho Como aplicar o teste estrutural Modelos de Teste Critérios de Teste Ferramentas de Teste

18 Modelos de Teste Parallel Control Flow Graph Representação de itens relevantes ao teste Essenciais para a qualidade do teste Afetam diretamente os custos da atividade de teste Exemplos: Grafos, MEFs, Redes de Petri,...

19 Critérios de Teste Exemplos Arestas de sincronização Definição e uso de variáveis em diferentes threads Elementos requeridos Nó n p1,t0 2 Aresta de sincronização (n 2 p0,t0, n 5 p1,t0 )

20 Critérios de Teste Nova Família Legados Fluxos de controle e dados all-nodes, all-defs, all-s-uses Voltados à HPC Fluxo de controle e comunicação/sincronização all-nodes-s, all-edges-s e all-s-cuses

21 Ferramenta de Teste Suporte à atividade de teste Ex: Chess (Microsoft), Contest (IBM) e ValiPar (ICMC/USP) Test input parallel program Instrumented program Graphs (i) and inheritor reduced CFGs ValiExec Test output CFGs ValiInst ValiElem Required elements Executed paths Data flow Information descritor ValiEval Testing criteria Covered elements Coverage

22 Há interesse em teste para HPC?

23 Países mais influentes 23

24 Abordagem de teste Quais abordagens foram pesquisadas? Teste determinístico 61 (18,26%) 10,78% 5,69% 1,50% 1% Teste de cobertura 85 (25,45%) 5,39% 1,50% 2,1% 17,96% Teste baseado na especificação 68 (20,36%) 10,78% 7,19% 2,10% 1% Teste baseado em defeitos 87 (26,05%) 9,28% 11,08% 1,80% 1,80% 4,1% 3,1% Geração automática de dados de teste 33 (9,88%) 6,29% 2,69% 0,60% 1% Abordagem Ferramenta Framework Benchmark Estudo Secundário 184 (55,09%) 107 (32,04%) 25 (7,49%) 6 (1,80%) 9 (2,69%) Taxonomia 3 (0,90%) Tipo de pesquisa

25 Quais ferramentas foram propostas? Abordagem de teste Teste determinístico 13 (13,4%) 1% 3,1% 4,1% 5,2% Teste de cobertura 15 (15,5%) 1% 7,2% 1% 3,1% 3,1% Teste baseado na especificação 24 (24,7%) 11,3% 10,3% 2,1% 1% Teste baseado em defeitos 35 (36,1%) 15,5% 16,5% 2,1% 2,1% Geração automática de dados de teste 8 (8,2%) 5,2% 2,1% 1% Java C/C++ C/MPI C/PVM C/Pthreads 37 (38,1%) 39 (40,2%) 5 (5,2%) 4 (4,1%) 10 (10,3%) Linguagem

26 Alguns desafios Disponibilizar infra-estrutura básica ao teste eficiente, robusta e flexível às necessidades Gerar automaticamente casos de teste Analisar critérios Eficácia para revelar defeitos, Relação de inclusão dos critérios Investigar aspectos complementares eficiência e custo Qual técnica de teste utilizar?

27 Agenda A Universidade de São Paulo em São Carlos Software com qualidade Teste de aplicações de alto desempenho Perspectivas futuras Conclusões

28 Perspectiva Futura Selecionar e avaliar técnicas e ferramentas de teste para HPC apoio à aplicação prática de técnicas / ferramentas para profissionais de teste 28

29 Motivação Teste estrutural Desenvolvimento dirigido a teste Satisfação do testador Custo para usar Injeção de defeitos Eficácia revelar defeitos Análise dinâmica Eficiência do uso Teste de mutação Teste baseado em busca Análise estática Análise simbólica Execução determinística Teste de cobertura Verificação formal Verificação preditiva Teste baseado na especificação Teste baseado em modelos Monitoramento Teste baseado em modelos Teste de alcançabilidade Detecção de violação de atomicidade Geração automática de dados de teste Teste ativo 14

30 Como avaliar técnicas de teste? Questões de Pesquisa A tecnologia é adequada no contexto industrial? Estudo de Caso na Indústria A tecnologia é adequada no contexto do processo de software? Estudo de caso no Processo de Software A aplicação prática da tecnologia faz sentido? Estudo de Observação A tecnologia é viável? Estudo de Viabilidade Linha do Tempo 30

31 O que ela envolve? Metodologias de Avaliação e Seleção Parceiros na Indústria Teste de Software Programação Concorrente 31

32 Agenda A Universidade de São Paulo em São Carlos Software com qualidade Teste de aplicações de alto desempenho Perspectivas futuras Conclusões

33 Conclusões Programação Concorrente com qualidade: É necessária nos dias de hoje e será também no futuro Está repleta de novos desafios maior demanda com novas arquiteturas necessidade de maior produtividade redução dos custos de manutenção explorar o desempenho de pico das arquiteturas Teste ainda é muito limitado complexidade e custo

34 Conclusões Há um caminho já percorrido Infra-estrutura básica para suporte a técnicas, critérios e modelos de teste Avaliações parciais quanto à cobertura, capacidade para revelação de defeitos Falta desenvolvimento mais próximo à indústria Inserção no processo de teste Adequação ao contexto industrial

35 Computação de Alto Desempenho com Qualidade: Desafios e Perspectivas Paulo Sérgio Lopes de Souza pssouza@icmc.usp.br Universidade de São Paulo / ICMC / SSC São Carlos Laboratório de Sistemas Distribuídos e Programação Concorrente Intel Innovation Week e 25 de setembro de 2014 Centro Universitário Senac São Paulo - SP