Tecnologia Intel HT e Java

Faz todo sentido, se a aplicação possuir bugs relativos a multi-threading eles são muito mais evidentes em máquinas HT que nas sem esse recurso.

poe a stacktrace pra gente ver… as vezes é a wrap de alguma outra bem conhecida.

OK. Vou levar alguns dias - estou de folga - para pegar estas informações onde trabalho - Metrô São Paulo. Obrigado por enquanto.

Ai está …

Exception in thread “Thread-317” Exception in thread “Thread-316” java.lang.Null PointerException

at gerenciador.DinamicSequence.consumeEvent(DinamicSequence.java:38)

at gerenciador.ConsumerEvent.run(ConsumerEvent.java:17)

java.lang.NullPointerException

at gerenciador.DinamicSequence.consumeEvent(DinamicSequence.java:38)

at gerenciador.ConsumerEvent.run(ConsumerEvent.java:17)

O DinamicSequence representa um gerenciador de eventos do simulador.

Senhores,
apenas para registrar: quando desabilitado o “recurso” HT, as exceções não ocorreram !

Então você já sabe que o seu programa não é thread-safe. Agora é só corrigir.

Hahahahaha… ai ai…

Acho que nem programas thread-safe são thread-safe.

Giuliano Mega:

Então você já sabe que o seu programa não é thread-safe. Agora é só corrigir.

Hahahahaha… ai ai…

Acho que nem programas thread-safe são thread-safe. ;)

A sim, provar que um programa é thread-safe deve ser tão dificil quanto provar que P=NP. Mas felizmente a nós basta fazer um programa ser suficientemente bom para que ninguém ache os bugs deles e não totalmente livre deles.

Eu tenho processador HT em casa
E tenho uma lista de programas que travam, logo de cara quando subo eles, incluindo o mozilla firefox e thunderbird.

Esse HT é um lixo.

É isso aí, paralelismo é um lixo. :mrgreen:

E viva os branch mispredictions em pipelines de duzentos mil níveis e as CPUs com consumo de aquecedor de parede.

Cara, se HT é um lixo, um dual core vai parecer 10x pior.

Achava que essa discussao (ainda nao muito popular, acho) sobre modelos de programacao que suportem melhor paralelismo/concorrencia (ie: nao dependa tanto da capacidade do programador mediano) era coisa para o futuro. Parece que a coisa eh mais urgente do que parece.

Sera que isso dara visibilidade para outras linguagens que adotam estrategias diferentes? Sera que vao trazer isso pro Java, como estao tentando fazer com linguagens dinamicas, ou vao martelar que isso deve ser corrigido com ferramentas de grandes fornecedores como o “IBM Concurrent Thread Verificator Tabajara”?

Marcio Kuchma

Achava que essa discussao (ainda nao muito popular, acho) sobre modelos de programacao que suportem melhor paralelismo/concorrencia (ie: nao dependa tanto da capacidade do programador mediano) era coisa para o futuro. Parece que a coisa eh mais urgente do que parece.

Sera que isso dara visibilidade para outras linguagens que adotam estrategias diferentes? Sera que vao trazer isso pro Java, como estao tentando fazer com linguagens dinamicas, ou vao martelar que isso deve ser corrigido com ferramentas de grandes fornecedores como o “IBM Concurrent Thread Verificator Tabajara”?

Marcio Kuchma

Java, Ruby, C/C++, C# (.net), Python e quase todas linguagens que estamos acostumados estão terrivelmente mal preparadas para nos permitir escrever programas paralelos facilmente.

Sim, esses assuntos estão explodindo em projetos de pesquisa, existem muitas coisas a serem feitas ainda nessa área, considerando que quando você quer paralelismo em ambiente muito distribuído é ainda mais complicado.

Escrever até que é fácil. O duro é testar e depurar.

Abraços,

Giuliano Mega:

Java, Ruby, C/C++, C# (.net), Python e quase todas linguagens que estamos acostumados estão terrivelmente mal preparadas para nos permitir escrever programas paralelos facilmente.

Escrever até que é fácil. O duro é testar e depurar.

Abraços,

Até que não, usando breakpoints condicionais e AOP até que fica razoavel. O dificil ainda é conseguir paralelismo de forma segura.

Mas é justamente essa a questão. É muito difícil afirmar, num programa multithreaded (ou distribuído), que um caso de teste “testa” alguma coisa. Você teria que rodar o caso de teste de maneira a gerar todas as possíveis dependências entre threads (exponencial no número de threads) prá poder afirmar algo. Fora que é muito difícil coletar as dependências entre threads, envolve rastrear acessos à memória. Além de “lentificar” o programa, esse tipo de overhead pode ser não-uniforme e causar mudanças na execução do programa.

Isso me leva ao segundo problema. Como você debuga um programa que não é determinístico? Como você debuga um programa que muda de comportamento na presença do debugger?

Eu acho que estamos muito longe de termos técnicas eficazes de teste e depuração para sistemas multithreaded.

Abraços,

Olá

Me lembro que lá pelo fim da década de 80, se não me engano, começou este papo de paralelismo. Acho que as linguagens não tinham nada a ver com o assunto. Todos os artigos que li referiam-se a algoritmos. Na COPPE eles chegaram a construir um computador com vários processadores (acho que i860). Um dos aplicativos que usavam algoritmos paralelos servia para resolver enormes sistemas de equações usando Fortran.

[]s
Luca

Giuliano Mega:

O dificil ainda é conseguir paralelismo de forma segura.

Isso me leva ao segundo problema. Como você debuga um programa que não é determinístico? Como você debuga um programa que muda de comportamento na presença do debugger?

Eu acho que estamos muito longe de termos técnicas eficazes de teste e depuração para sistemas multithreaded.

Abraços,

Por isso que falei que essas linguagens são muito mal preparadas para programação paralela. Já existem mecanismos mais modernos como sistemas baseados em processos (Erlang) e memória transacional - existem protótipos tanto de STM e HTM.

Mas assim, realmente eu comprei o HT pensando que iria ser muito mais potente do que o normal, mas o aumento de performance dele é de 20%
ou até menos. Me arrependo de não ter comprado o Athlon 64, que estava quase o mesmo preço.

Agora uma dúvida: isso é coisa do processador ou da programação?

Como já disse, tenho uma pancada de programas que não funcionam, eu tenho que desabilitar o hyperthreading para funcionarem, como o pacote da macromedia inteiro, e do mozilla. Até já enviei um e-mail para o pessoal do bugzilla informando, e eles me responderam que isso é um problema a ser corrigido.

Mas não informam se o problema é da máquina ou do programador. Fico pensando como isso acontece.

Balarini, eu diria com 99% de certeza que o problema é de programação. Um monte de hipóteses mentais que funcionam bem em sistemas no estilo time-sharing caem por terra quando o paralelismo é real. Esses problemas são relacionados principalmente às garantias dadas pelo modelo de memória.

Então, louds, eu também acho que um conjunto de abstrações melhor iria bem, especialmente prá reduzir a sobrecarga cognitiva com picuinhas. O problema é que as características mais desagradáveis do paralelismo são intrínsecas a esse tipo de execução - não importa o modelo, uma execução paralela sempre vai ser parcialmente ordenada. Isso significa, prá todos os efeitos, que ela sempre vai ser não-determinística, a não ser que não haja comunicação entre os threads (no caso de memória compartilhada) ou nodos (no caso de sistemas baseados em passagem de mensagens).

Mas eu concordo que threads provavelmente são um modelo de concorrência bem furado e que, de fato, há um espaço muito, mas muito grande para melhora.

Abraços,

Você conhece como funciona Erlang ou o que é Transactional Memory?

Erlang usa o modelo de processos e passagem de mensagens para tornar paralelismo simples, isso não resolve o problema do não-terminismo no caso da troca de mensagens, mas acaba com todos embrólios ligados a memória compatilhada do uso de threads.

Memória transacional torna as operações do teu programa transacional, se uma operação do teu sistema der problema, você simplesmente da rollback nela. A maioria das implementações desse modelo usam concorrencia otimista e os resultados são muito interessantes.

Com relação a Erlang, sou um completo ignorante. Transactional Memory eu já li a respeito.

Pois é, threads e memória compartilhada sempre me soaram como um troço meio sem futuro. Aliás, threads preemptivos em máquinas monoprocessadas são, além complicados, ineficientes. Não sei como funciona o modelo do Erlang, mas fiquei curioso. Você poderia me indicar uma fonte legal prá eu dar uma olhada?

Memória transacional me soou como um esquema legal para garantir atomicidade sem comprometer o desempenho com locking mas, corrija-me se eu estiver errado, não me parece resolver o indeterminismo resultante da ordem de acesso aos segmentos de dados compartilhados (a ordem das transações afeta o resultado). Também me pergunto se é assim tão menos complexo do que sincronização usando locks, tirando as questões ligadas ao modelo de memória e aos deadlocks. Bizarro. Parando prá pensar um pouco, me parece que podem rolar uns livelocks.

Abraços,

A melhor referencia ao Erlang é o próprio site http://erlang.org/. Threads podem ser tão eficientes quando um modelo orientado a eventos, teve um paper a um bom tempo no LtU sobre a unificação e equivalência dos dois.

A sacada o Erlang é que se trata de uma linguagem puramente funcional que usa green-threads para implementar uma abstração de processos extremamente escalavel.

Memoria transacional usa sempre optimistic locking, que resolve os conflitos fazendo rollback nas transações que conflitem com as demais já comitadas. As garantias de execução são basicamente as mesmas de um banco relacional. Dá para dizer que TM é o ACID dos bancos sem o D de durable já que usa memória ram. As soluções de software não são muito rápidas, porém as com auxilio de hardware possuem performance excelente.

La li comentarios a respeito de que linguagens da familia Lisp e ML facilitam o desenvolvimento de solucoes nesse contexto. Mas sem conhecer as linguagens na pratica, fica complicado formar uma opiniao. Alguem sabe dizer se realmente elas tem vantagem nesse aspecto?

Marcio Kuchma

Nunca brinquei com Erlang nem com TM, mas fiquei curioso pra saber o que vcs acham dos recursos de linguagens como a Io, onde todo o processamento assincrono eh baseado em Futures.

Marcio, linguagens funcionais e semelhantes tem 2 coisas que tornam programação paralela muito simples. Uma se restringe a classe de linguagens puramente funcionais, na qual todas variaveis podem ser atribuidas somente uma vez, isso resolve a maioria dos problemas relacionados ao uso de memoria compartilhada. Outra é suporte continuações, programação usando CPS (Continuation Passing Style) é bem interessante por sua escalabilidade inerente.

CV, pelo que eu li de IO, que foi bem pouco, a linguagem possui primitivas para chamadas assincronas (com futures opcionais) e suporte a corrotinas. Corrotinas são um caso particular de continuações. A parte de chamada assíncrona me parece meramente cosmético, mas posso estar perdendo algo.

Eu particularmente me sinto muito mais confortável com green threads (ou co-rotinas) para implementar servidores (em máquinas monoprocessadas) do que com eventos. Eventos me causam uma sensação de fratura de fluxo incômoda. Me lembro do paper ao qual você se refere, acho que se chama “Why Events are A Bad Idea” ou coisa assim.

Também me lembro das limitações de green threads toda vez que uso o squeak e a interface trava porque alguém esqueceu de dar yield.

Tenho a impressão de que TM é mais intuitivo no quesito visibilidade. Tenho dúvidas com relação ao desempenho - me vem à cabeça, de imediato, como implementar os mecanismos de visibilidade de forma eficiente (todos os segmentos compartilhados têm semântica de volatile?).

Então, CV, eu não conheço IO. Me chamou muito a atenção o fato da linguagem ser baseada em protótipos, que é um negócio que eu curto prá caramba. Já usei muito futures para sincronização (principalmente com objetos distribuídos) e acho que são muito úteis, mas não acho que tenho nada de muito inteligente a dizer a respeito.

Abraços,