Concorrência pode ditar a próxima grande revolução no modo de programar

Olá

[quote=Andy giveth, and Bill taketh away]
No matter how fast processors get, software consistently finds new ways to eat up the extra speed.
Make a CPU ten times as fast, and software will usually find ten times as much to do (or, in some cases, will feel at liberty to do it ten times less efficiently).[/quote]

[quote=Moore’s Law]
The observation made in 1965 by Gordon Moore, co-founder of Intel, that the number of transistors per square inch on integrated circuits had doubled every year since the integrated circuit was invented. Moore predicted that this trend would continue for the foreseeable future. In subsequent years, the pace slowed down a bit, but data density has doubled approximately every 18 months, and this is the current definition of Moore’s Law, which Moore himself has blessed. Most experts, including Moore himself, expect Moore’s Law to hold for at least another two decades.[/quote]

A lei acima muitas vezes foi expandida para prever o crescimento exponencial do clock dos processadores. Mas agora parece que este crescimento não vem se dando muito rapidamente. Se em 2001 alcançamos 2 GHz não era para a gente já estar na casa de 10 GHz?

Nos últimos 30 anos os projetistas de CPU aumentaram o desempenho investindo em 3 áreas:
1 - velocidade de clock (velocidade da CPU)
2 - otimização de execução (várias, inclusive reordenação de reads e writes)
3 - cache

Fora algumas características de otimização, nenhuma das áreas acima tem muito a ver com o modo como escrevemos nossas aplicações. Mas atualmente há novos modos de se aumentar o desempenho das CPUs que podem modificar o modo como vamos escrever nossas aplicações:
4 - hyperthreading (2 ou + threads em paralelo na mesma CPU) -> vantagem só para aplic. multithread
5 - multicore (2 ou + CPUs em um chip) -> vantagem só para aplic. multithread
6 - cache

Programar para aproveitar as vantagens dos novos processadores é o desafio que se apresenta. É claro que os custos de desenvolvimento serão maiores. A fase de QA será muito mais exigida. As famosas race conditions são difíceis de debugar. Os testes de stress serão mais ainda necessários.

Para saber de onde tirei estas considerações leia:
The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software

O que o Rickard Öberg acha do artigo anterior

[]s
Luca

Isso é uma coisa pra se preocupar, mas eu IMHO acho que antes de termos esse tipo de problemas já teremos encontrado um caminho para garantir que nossos programas tirem o maximo dos CPUs sem elas causarem maiores danos a aplicação.

Alias, para processadores Dualcore pode-se aplicar os mesmos principios usados em uma aplicação q rodara em um ambiente bi-processado, ou estou muito enganado?

Não há praticamente distinção entre o processamento efetuado por processadores dual-core (como o Pentium D) e por múltiplos processadores. Se você olhar o diagrama lógico de um chip desses vai ver que quase tudo é duplicado, e para efeitos de programação, tudo se passa como se a máquina fosse mesmo multi-processada.

Portanto o problema já está aparecendo AGORA.

Na verdade os problemas de processamento paralelo já apareciam, em menor escala, com as máquinas “hyperthreaded”; só que não tão claramente que em máquinas multiprocessadas (usando dual-core ou não).

Se você tem alguma graninha já pode comprar um processador dual-core e montar um ambiente multiprocessado por uma fração do preço que se pagava por usar 2 ou mais processadores em uma motherboard especial.

As famosas race conditions, que o Luca falou? thingol

Toda evolução tem seu preço.
O benefício do multicore (IMHO) é muito maior do que os problemas.
Rodar um Antivírus, ouvir uma musiquinha e programar sem aqueles gargalos deve ser algo muuuito bom…
Mas a programação cooperativa tá longe de ser algo fácil…
E o novo Kernel Linux já virá com suporte ao Cell…