Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
dê seu feedback
post favorito
Dividir para Conquistar - Java Magazine 85
Programação Concorrente; mais especificamente, paralelização de algoritmos para aceleração do seu desempenho através do uso de várias CPUs ou núcleos de processamento. No artigo, focamos na conhecida técnica de “divisão e conquista”.
Java Magazine 85
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 85
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 85
Dividir para Conquistar
Acelerando seus algoritmos no mundo multi-core
Técnicas e novas APIs para extrair o melhor desempenho de multiprocessadores
Nesta coluna, o leitor veterano poderá se lembrar de vários artigos já publicados sobre paralelismo e concorrência; em geral focados na tecnologia da JVM (“Concorrência e a JVM” – Edição 11) ou em APIs (“Concorrência no Java 5” – Edição 20). Um pouco mais recentemente, a Edição 68 trouxe o artigo “Aplicações Concorrentes em Java” de Ronald Blanc Rocha. Mas achei que já estava na hora de voltar ao assunto, e também de tentar uma abordagem diferente.
O plano dessa vez é partir dos problemas em direção às soluções. Apresentaremos ao leitor alguns problemas clássicos de programação – algoritmos de busca e ordenação. Veremos como acelerá-los através de uma técnica específica (pattern?), a Divisão e Conquista; mostraremos o código necessário, implementado através da API java.util.concurrent. Poderemos assim aprofundar esta técnica, conhecer suas dificuldades e casos especiais, etc. de maneira prática e realista.
O Paralelismo resolve tudo?
Há alguns dias um colega disse: “Temos essa aplicação, assim e assado..., e processa 200 transações por segundo, mas precisamos chegar a 600 transações por segundo.” Brincando (mas nem tanto), comentei: “É muito fácil, use um servidor com 600 cores!”
A brincadeira é apenas parcial, pois um servidor com 600 núcleos não é mais ficção científica. Já se pode encontrar tal paralelismo numa só máquina; só não se trata ainda de algo acessível a qualquer data center. Mas chegaremos lá em pouco tempo. No entanto, assim como a contagem crescente de Gigahertz no passado, a atual escalada do multi-core não irá resolver todos os nossos problemas de desempenho. Problemas possíveis:
• As transações usam algum recurso compartilhado, por exemplo caches, dados de configuração, ou canais de output (até algo tão simples quanto um objeto Logger);
• Transações fazem lock de registros compartilhados num SGBD, forçando outras transações que também precisam do mesmo lock a esperar na fila;
• Mesmo sem nenhum lock, o SGBD não consegue executar mais que certo número de transações por segundo, pois o paralelismo de I/O de disco é limitado (se bem que isso tende a melhorar, com a tecnologia de SSD substituindo discos).
Por outro lado, minha sugestão, ainda que fosse viável, não seria garantia de solução. Estes problemas quase sempre aparecem quando a concorrência ultrapassa determinado limite. Então não adianta jogar mais CPUs no servidor, que não teremos melhoria da taxa de transações (ou requests, etc.) por unidade de tempo.
Divisão e Conquista: Alô Mundo
Problema: Localizar o maior valor num array gigante de dados desordenados
Este tipo de problema conduz facilmente à técnica paralela de “divisão-e-conquista”, que pode ser descrita genericamente de forma simples: divida seus dados em duas ou mais partes independentes, processe estas partes em paralelo, e no final unifique os resultados de cada parte. É uma excelente técnica quando esta divisão é possível, ou seja, quando os dados de entrada (ou transações concorrentes etc.) são fáceis de separar em partes independentes.
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
Acelerando seus algoritmos no mundo multi-core
Técnicas e novas APIs para extrair o melhor desempenho de multiprocessadores
Nesta coluna, o leitor veterano poderá se lembrar de vários artigos já publicados sobre paralelismo e concorrência; em geral focados na tecnologia da JVM (“Concorrência e a JVM” – Edição 11) ou em APIs (“Concorrência no Java 5” – Edição 20). Um pouco mais recentemente, a Edição 68 trouxe o artigo “Aplicações Concorrentes em Java” de Ronald Blanc Rocha. Mas achei que já estava na hora de voltar ao assunto, e também de tentar uma abordagem diferente.
O plano dessa vez é partir dos problemas em direção às soluções. Apresentaremos ao leitor alguns problemas clássicos de programação – algoritmos de busca e ordenação. Veremos como acelerá-los através de uma técnica específica (pattern?), a Divisão e Conquista; mostraremos o código necessário, implementado através da API java.util.concurrent. Poderemos assim aprofundar esta técnica, conhecer suas dificuldades e casos especiais, etc. de maneira prática e realista.
O Paralelismo resolve tudo?
Há alguns dias um colega disse: “Temos essa aplicação, assim e assado..., e processa 200 transações por segundo, mas precisamos chegar a 600 transações por segundo.” Brincando (mas nem tanto), comentei: “É muito fácil, use um servidor com 600 cores!”
A brincadeira é apenas parcial, pois um servidor com 600 núcleos não é mais ficção científica. Já se pode encontrar tal paralelismo numa só máquina; só não se trata ainda de algo acessível a qualquer data center. Mas chegaremos lá em pouco tempo. No entanto, assim como a contagem crescente de Gigahertz no passado, a atual escalada do multi-core não irá resolver todos os nossos problemas de desempenho. Problemas possíveis:
• As transações usam algum recurso compartilhado, por exemplo caches, dados de configuração, ou canais de output (até algo tão simples quanto um objeto Logger);
• Transações fazem lock de registros compartilhados num SGBD, forçando outras transações que também precisam do mesmo lock a esperar na fila;
• Mesmo sem nenhum lock, o SGBD não consegue executar mais que certo número de transações por segundo, pois o paralelismo de I/O de disco é limitado (se bem que isso tende a melhorar, com a tecnologia de SSD substituindo discos).
Por outro lado, minha sugestão, ainda que fosse viável, não seria garantia de solução. Estes problemas quase sempre aparecem quando a concorrência ultrapassa determinado limite. Então não adianta jogar mais CPUs no servidor, que não teremos melhoria da taxa de transações (ou requests, etc.) por unidade de tempo.
Divisão e Conquista: Alô Mundo
Problema: Localizar o maior valor num array gigante de dados desordenados
Este tipo de problema conduz facilmente à técnica paralela de “divisão-e-conquista”, que pode ser descrita genericamente de forma simples: divida seus dados em duas ou mais partes independentes, processe estas partes em paralelo, e no final unifique os resultados de cada parte. É uma excelente técnica quando esta divisão é possível, ou seja, quando os dados de entrada (ou transações concorrentes etc.) são fáceis de separar em partes independentes.
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
[Este post ainda não foi associado a uma sequência]
Você está em:
canal Java
Publicidade
Osvaldo Pinali Doederlein
Space do autor
é Mestre em Engenharia de Software Orientado a Objetos e Arquiteto de Tecnologia da Visionnaire Informática, trabalhando em projetos de software e prospecção tecnológica.
Space do autor
0
0
