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 2014 24 e 25 de setembro de 2014 Centro Universitário Senac São Paulo - SP
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
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
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)
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
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.
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
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...
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
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
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}
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}
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
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
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
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
Teste de aplicações de alto desempenho Como aplicar o teste estrutural Modelos de Teste Critérios de Teste Ferramentas de Teste
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,...
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 )
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
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
Há interesse em teste para HPC?
Países mais influentes 23
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
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
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?
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
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
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
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
O que ela envolve? Metodologias de Avaliação e Seleção Parceiros na Indústria Teste de Software Programação Concorrente 31
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
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
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
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 2014 24 e 25 de setembro de 2014 Centro Universitário Senac São Paulo - SP