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.
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.
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?
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.
