Muitas coisas que existiram nos servidores foram para o desktop. Eu lembro quando numa empresa que trabalhava chegou um servidor novo da Sun com DVD-ROM. Nossa! Que sonho ter um desses no meu micrinho! Hoje por cem reais você tem um gravador de DVD.
Pois é, assim como HDs de grandes capacidades chegaram para nós míseros mortais, as máquinas multiprocessadas também chegaram.
A Lei de Moore que está presente nos últimos 30 anos está se tornando muito cara, portanto o crescimento horizontal é a solução mais viável.
Hoje temos os Core-Duo da Intel e o X2 da AMD, ambos dual-core.
Isso sem falar nos processadores 64 bits, que já são realidade para o desktop também. Existia uma limitação da arquitetura de 32bits de endereçar de maneira não emulada “apenas” 4Gb de memória.
A Intel inventou um jeito de mapear mais de 4Gb, mas o acesso físico mesmo continua limitado a 4Gb.
Agora, não com 64bits, mas apenas 40bits (apenas 8 bits a mais do 32, que é o que acontece com o AMD64) já podemos endereçar fisicamente 1 terabyte de memória física. Nesse mês na Revista do Guia do Hardware saiu um artigo do Carlos Morimoto simplesmente excelente falando sobre a arquitetura do AMD64. Para quem se interessa por esse assunto é uma leitura imperdível.
Para não fugir muito do assunto, só mencionei esse detalhe acima para falar também que hoje memória também já barateou muito e deixou de ser um problema para desktop. Alguém aí disse “área de swap”? Pois é, ela foi criada lá naquela época que tínhamos pouquíssima memória, hoje você consegue rodar uma máquina sem essa área, dependendo do que precisar fazer.
A multi-core computing veio para ficar e vai mudar a vida de nós desenvolvedores de sistemas.
Essa é a mesma opinião de Joshua Bloch, que quando falou nesse assunto numa entrevista do Java One 2007, fez com que eu pensasse mais sobre esse assunto.
Hoje os desenvolvedores de sistemas para web não se preocupam muito com threads, aplicações para web o desenvolvedor quase não trabalha com isso, ele apenas sabe que a aplicação dele roda num ambiente multi-thread e por isso toma os devidos cuidados em algumas situações (já experimentou trabalhar com Java numa classe que estenda HttpServlet e usar atributos para guardar informação ? Os resultados podem ser desastrosos, pois a classe é chamada por diversas threads e esse comportamento sua classe).
Então o contêiner que se vire se tiver um, dois ou dezesseis processadores, certo?
Ok, mas se hoje pensarmos num simples applet Java rodando num site, seria muito interessante se essa JVM instanciada para rodar esse applet fosse gerenciada por outro processador, não?
Hoje com o crescimento das aplicações da Web 2.0, o uso de uma engine (como o AJAX) na máquina cliente é cada vez mais comum, o que exibe um processamento local maior. Será que em breve, não poderíamos por exemplo, especificar que um processador roda essa engine para tratar o parse de XMLs e outro processador para as operações de rede?
Será que teremos um modelo diferente de trabalho disparando componentes no cliente para manipulação de arquivos, geração de imagens, som ou vídeo; gerenciados exclusivamente por um processador dedicado, deixando os restantes para trabalhar com o browser e outros aplicativos?
Se surgir uma linguagem que ajuste torne esse ajuste bem flexível ao programador, ela com certeza sairá na frente das outras ganhando mercado e se estabelecendo por um bom tempo.
E que venham os quad cores!
Fernando Boaglio, para a comunidade. =)