Dual Core: Quem ganha mais com isso?

ThiagoLCK · 31 de maio de 2006

Bom, pessoal, eu tenho a clara sensação de estar abusando na primeira semana ativa aqui, mas vamos lá:

Ultimamente, todo mundo tem visto os avanços dos multinucleados. Eles são a tendência da indústria! Mas será que valem a pena para nós?

Bom, eu acho que valem. Atualmente, eu não compraria uma máquina sem eles. Mas eu também acho que eles são horríveis. Feios, deselegantes arquiteturalmente . Mais ou menos como colocar dos motores no meu carro . E, por isso, eu passei um tempo inventando um jeito de criticá-los. E achei!

Os dual-cores, na minha opinião, não estão aí por causa da demanda por eles. São uma novíssima espécie de truque da indústria para maximizar seus lucros.

Antigamente, a indústria de INFO investia radicalmente na pesquisa. O IBM S/360, por exemplo foi o micro mais caro de se produzir da história. O maior, e mais caro projeto da sua década, depois do projeto Apolo. Ãh? Estranhou? Pois é, até hoje, em 40 anos, ninguém desenvolveu um micro tão caro, e tão revolucionário de se produzir.

Não que eu goste da IBM. Pelo contrário. Mas como é que ninguém mais desenvolveu uma arquitetura mais cara em 40 anos. Oras, Thiago (primeiro sinal de loucura geek:teclar sozinho ), naquele tempo as empresas relalmente desenvolviam coisas. Componentes soltos, arquitetura completamente diferente, tudo novo. Hoje em dia, faz-se tudo em CI´s sem otimização manual. Aliás, a DEC, última empresa do mundo a vender CPU´s otimizadas manualmente, chegou a tal ponto que teve que se vender para uma empresa muitas vezes menor que ela. Hoje em dia, com CPU´s de 1 bilhão de transistores, otimização manula é puro suicídio comercial. Mais ainda, hoje em dia, fazer uma CPU toda com lógica é loucura total. Você, mesmo, sem otimização manual, nuca vai achar uma ocupação pros milhões de transistores que você tem. Pelo menos não com o dinheiro que os acionistas te deram pra fazer a próxima arquitetura. O negócio é aproveitar esse espaço com algo que não precise de muita gente para criar: cache! Ao invés de ter que criar somadores parciais, e só tacar memória, mesmo que o desempenho aumente só meio por cento. De qualquer modo você não ia usar esses transistores! Então taque cache. Mais ainda, diminua o core tudo que puder, e aumente o clock!!! E, se puder, arrume uns técnicos de software (mais baratos) e faça umas SSE da vida.

Foi essa a ideia que norteou o pessoal até agora. Basta ver as diferenças entre PII e PIII, ou dentro da famílias criadas desde a invenção do P6 original (PPRO), no caso da Intel, e do K7(Athlon) no caso da AMD. Só muda o clock e a cache. O Coppermine era um Katmai com cache melhor, o Katmai era um Deschutes com mais clock, etc. Na AMD, o tbird só tinha cache melhor a oferecer, e os AXP eram quase a mesma coisa que os Athlons originais em questão de core. Mais cache, mais clock, mais SSE´s. Os P4, então! O que o NorthWood tem amais que o Willa. O que o Presttcot tem a mais que o NW. Cache, clock, instruções. E watts!

Só que os bons tempos do cache acabaram, os produtores não querem mais colocar instruções nos seus programas, e o clock alto só fez aumentar os problemas do "vazamento" de corrente (leakage).

O dual core, é a nova tentativa de ganhar mais grana com menos pesquisa. Um dualcore só precisa ser desenvolvido uma vez, mas vale por duas. É muito mais barato, melhora o aproveitamento dos caches e esconde um fato: elas não sabem mais o que fazer. Estão desesperadas. Mas, talvez, algum dia, a razão volte para essa indústria, e eles voltem a investir em fazer computadores, não monstros de 1025 cores!

EduardoS · 1 de junho de 2006

Concordo plenamente que colocar mais clock, cache e cores é mais fácil do que melhorar a arquitetura, e aposto que os engenheiros da AMD e Intel tambem concordam,

É muito fácil falar que precisa melhorar a arquitetura, mas botar as mãos na massa e realmente melhorar é difícil, a forma com que os programas são escritos hoje não ajuda, grandes sequências de instruções dependentes, isso não ajuda o processador a executar várias instruções em paralelo e ai fica difícil executar mais de uma instrução por ciclo.

ThiagoLCK · 1 de junho de 2006

A solução para isto é simples: RISC NELES!

Ou, algo ainda mais radical. Já que o problema principal da atualidade não é produzir um processador com muitas unidades de execução, mas aproveitá-las, vamos deixar a tarefa para o computador mais avançado e desenvolvido já criado: o cérebro humano.

Utilizando um assembly mais avançado, uma arquitetura melhor ou um interpretador em tempo real, podemos tirar a tarefa difícil de gerar IPC (medida que diz quantas instruções podem ser executadas no mesmo clock) das mãos do processador e colocá-la nas mãos dos programadores.

Mas não pensem que eu estou criticando os programadores. Na verdade, atualmente, todos nós já usamos núcleos RISC (muito mais rápidos, vide P55C contra P6), mas nossos programadores continuam escrevendo na velha x86 e PPC. Tá, tudo bem que a cada ano a x86 fica cada vez mais parecida com uma arquitetura ligeiramente racional (ser uma dessas ela nunca via ser), mas mesmo assim os nossos processadores fazem um bom ttrabalho de interpretação para convertê-las em instruções RISC. Se4 nós fazemos isso agora, porque não fazer amanhã, com uma arquitetura ainda mais avançada e simples que as RISC atuais. Pronto teríamos mais performance com menos salamaleques e a velha retrocompatibilidade.