ThiagoLCK

Se eles forem usar um processador convencional, parece uma ideia bem razoável. Os problemas são os custos, maiores para um dado desempenho, e a dificuldade de convencer a empresa de GPUs e a de CPUs a miniaturizarem a coisa, e a desenvolverem-na nas fábricas adequadas. Com a unificação ATI/AMD e a criação da GF, talvez essas dificuldades sejam mitigadas... Eu concordo com ele, um MBA ajuda muito mais que qualquer doutorado nisso. Doutorado é bom para pesquisa, e mais como diploma e experiência que como aquisição de conhecimento mesmo. Mas quem falou em doutorado? Se donos de terras e advogados podem se chamar doutor, porque não o diretor lá ? Acho que foi bem nas festinhas que esse acordo foi feito, hein...

Caras em nível mais baixo que isso em pelo menos uma grande transnacional ganham mais de 1 milhão de reais por ano. Se eu ganhasse isso, queria ser chamado de "Doutor Figurão Thiago", no mínimo... Um Audi legalzinho, umas garrafas de whisky Pure Malt e umas minifestinhas à Berlusconi também não iriam mal ...

Esses testes normalmente foram feitos com VAXes,.. OK, a similaridade existe, e a convenção de que o ótimo está entre 16 e 32 provavelmente é verdadeira com aplicações "convencionais"... enquanto o código de jogos, em um processador simples, me parece um alvo muito melhor para pelo menos 32 registradores. Principalmente registradores SIMD. De qualquer modo, qualquer que seja o caso, a diferença entre x86-32 e x86-64 é razoável, e a x86-64 é realmente melhor em alguns aspectos. Mas ainda acho as RISCs melhores... só que a ideia de usar um SB no console me parece muito atraente do ponto de vista econômico.

O que você rodará aí?

É possível, mas não acho que seria aceitável para a GF.

A IBM fabrica pouco, a GF seria suficiente para atendê-la. TSMC está fora de questão, por razões técnicas e estratégicas. De qualquer modo, isso é uma previsão de um analista... e analistas querem matar a IBM Micro há muito, muito tempo. Para falar a verdade, se o XBITLabs tirasse as citações esse artigo poderia ser um Ctrl+C, Ctrl+V de vários artigos de alguns anos atrás... no entanto, a IBM Micro continua, sinal de que: 1- É muito complicado vendê-la. Faz sentido... 2- A chefia da IBM (que não é de economizar nos cortes e spin-offs) sabe coisas que os analistas não sabem. Isso eu garanto! 3- Existem questões não-financeiras envolvidas, não é um negócio de pizzas, é a IBM... existem muitos acordos, até governamentais, sem contar a resistência interna dos funcionários e gerentes. 4- Todas as alternativas acima.

Bem, sim, você está certo. A Intel alterou o projeto do Northwood para considerar a variação das características dos transistores na pastilha: isso com certeza não saiu barato, é aquele esforço de menos de 0,1%. Realmente, sempre existe a possibilidade do "replacement gate" da Intel deixar de ser viável "mecanicamente" com mudanças estruturais do transistor... afinal, é uma estrutura 3D com uma relação altura/profundidade muito alta, o que complica bastante a situação de remoção e deposição. Aliás, eu tenho quase certeza que a maior parte dos protótipos atuais são construídos diretamente, no que poderíamos chamar de "gate-first", e diria que em boa parte devido a dificuldade de construção. Mesmo assim, eu ainda acredito muito mais no "gate-last" com os FinFETs (se algum dia usarmos FinFETs, do jeito que a coisa vai). E não estou sozinho. A Applied acredita mais, a TSMC também... e a Intel, que tem mais poder de pesquisa que todas os outros grupos, com exceção talvez do IBM Esporte Clube. Eu simplesmente não acredito na escalabilidade do "gate-first", a variação de Vt é muito difícil de controlar, e é de longe a pior coisa que pode acontecer com o transistor em termos de projeto... e FinFETs trazem vários problemas elétricos e de variação próprios, e tendem a ser construídos em escala muito menor que a atual. É bem possível que a demora se deva mais a problemas de produção... afinal, eles usam "gate-first"! Não, eu não resisti ... A capacitância de junção faz muita diferença para o consumo, se para a velocidade daí depende do bloco: consumo sempre importa, velocidade só importa se não houver algo mais lento ainda, como um transistor pequeno drivando uma linha gigantesca... Ele aumenta dramaticamente com tensão e temperatura, não com clock. Se você tiver boa refrigeração e mantiver a tensão baixa, pode variar a frequência bastante que não terá grandes problemas com leakage. Assim o Bulldozer pouco sofrerá com leakage, em relação a um projeto mais lento... Eu falo do conservadorismo do projeto elétrico... mas a Intel tem vários grupos em overlap, cada um pode demorar uns 5 anos para desenvolver os processadores, e só não mudam mais porque preferem continuar com a base da P6: a Intel gosta muito da P6 , as pessoas amam a P6, e mesmo as mudanças não tão disruptivas do Sandy Bridge que quebraram com a mesmice do núcleo dos Nehalems foram bem consideradas antes de aceitas.

Sim, isso é um fato. A Intel desenvolve processos excelentes, PARA A INTEL. Se você não tiver os recursos de projeto eletrônico e de processo deles, vai se ferrar. Nenhuma foundry jamais conseguiria convencer os consumidores deles a adotar as regras que a Intel adota, são bizonhas, o layout tem que ser todo regular, sob risco de falha geral. A Intel é a maior produtora de semicondutores e possui um número relativamente pequeno de produtos, não acho que tenha custo-benefício baixo para eles. Pelo contrário, o lucro da Intel com os x86s é excelente. Pelo contrário, ao que eu saiba ambos tem problemas, mas os problemas do gate-last parecem muito mais escaláveis... eu não acredito que o gate-first passe dos 20 nm. Os números que a AMD passou são de Drive Current, como você sabe o processo SOI precisa de menos do que os da Intel, e de qualquer modo com uma distância pequena "all bets are off", mesmo porque as medições são sempre realizadas em condições diversas. A maior vantagem em consumo do SOI é mais a menor capacitância de junção... o leakage de junção é secondário em processos atuais, embora menos em processos HK/MG. Não tenho tanta certeza se os processadores Intel não conseguiriam chegar a 4 GHz com uma refrigeração consideravelmente melhor, talvez com um projeto menos conservador em termos de número de estágios...

Os processos SHP (processos com SOI, para Llano e BDZ) sempre seguem os nodos padrão do ITRS: 45 nm, 32 nm, 22 nm. Os processos HP (para GPUs, SoCs, etc...) tinham dois nodos para cada nodo do ITRS, um "full" e outro "half": 90, 80, 65, 55, 45, 40... mas agora, graças a TSMC, os "full-nodes" foram extintos, e os "half-nodes" viraram os únicos nodos: 28 nm e 20 nm... Isso se refere a duas formas diferentes de implantar o gate metálico do HK/MG... para resumir, o gate-last tende a ter maior performance em corrente, principalmente dos transistores tipo P, mas é mais chato e caro de implementar, o gate-first tende a ter maior densidade (o que pode compensar a performance de corrente) e ter uma modelagem mais fácil, mas tem um monte de problemas com parasitas, que podem não afetar nesse nodo mas afetarão nos próximos. Enfim, a tendência é que todo mundo acabe convergindo no gate-last, mas nesse nodo qualquer um dos dois serve, o gate-last se tiver alguma vantagem nos PMOS é pequena... Só para explicar o funcionamento dos dois, o gate-first funciona do jeito óbvio: implanta-se o dielétrico de alto K, depois o gate de metal, e pronto. Foi desenvolvido principalmente pela IBM... é usado por ela e suas amigas, basicamente. O gate-last é mais complexo... você inicialmente implanta um gate de sacrifício de polissilício, que é usado durante todo o processo de fabricação do transistor. Somente no final, logo antes de fechar a lógica e começar a metalização, que você retira os gates de polissilício e implanta um gate de metal. O detalhe (que faz a diferença para o gate-last) é que você pode usar metalizações diferentes de acordo com o tipo de transistor... por isso os PMOS do gate-last são absurdos. O campeão do gate-last é a Intel. A TSMC usaria gate-first, mas acabou mudando para o gate-last...

WTFH? Não sei por que, mas acho que a IBM não vai vender sua divisão de chips para uma das mais perigosas concorrentes. A nVidia é uma empresa de GPUs, até existem aplicações disso em computação empresarial mas são bem restritas, a Oracle não vai pagar caro para tirar tudo. AMD tudo bem, essa sim dá para imaginar algo do tipo... mas acho bem difícil.

O Frequency Hoping Spread Spectrum foi inventado até antes... mas sinceramente, essa é a parte mais fácil da coisa. E ele não foi muito usado simplesmente porque não é lá tão bom para aplicações não-militares. Quanto ao PCI-E 3.0, desenvolver a especificação é mais um exercício político, a parte realmente complicada é criar opções de implementação viáveis e confiáveis. Tem muito teste a ser feito, e de nada adianta lançar algo mal-acabado, caro e pouco compatível.

Eu não confio totalmente nas impressões dele, mas ele provavelmente apenas pegou essa figura e comparou com a foto da pastilha em busca de algum lugar que batesse com ela. Como é uma foto da última metalização, a coisa fica mais complicada que o normal, mas nem tão mais complicada assim... Por enquanto o mais provável é algo similar a Llano/Bobcat/XBOX360... GPU em um lado, núcleos do outro e comunicação via XBAR ou L3, com núcleos idênticos uns aos outros. Mas a tendência é que no futuro os núcleos sejam diferentes... todos os núcleos x86 provavelmente suportarão a arquitetura inteira ou a maior parte (com FP, x86-64, etc), mas alguns deles sendo mais rápidos e maiores, outros mais lentos mas em maior número para aplicações paralelas, ou algo do tipo. Eu não sabia que dava pra ganhar dinheiro combinando o óbvio com bobagem... vou aproveitar. Convenhamos, o Fuad já deu o que tinha que dar há muito tempo. Não existe uma informação nova nos dois artigos. A GPU do SB está por enquanto no nível de uma HD5450 nos jogos testados, então podemos esperar que ela esteja no mesmo nível da GPU do Ontario, não do Llano. O Llano deve ter performance gráfica várias vezes melhor que a do SB. Ele terá muito mais SPs, para começar (uns 400, segundo a galera)... A GDDR5 usada pelas GPUs é completamente diferente da DDR5 que talvez será usada pelas CPUs daqui a mais de meia década... O Bobcat e o Bulldozer são arquiteturas diferentes.

O Hans de Vries fez uma comparação entre Ontario e Pineview. Não sei até que ponto está correta, até porque a imagem do Ontario é da última camada, não das primeiras... mas se for verdade a AMD certamente conseguiu uma densidade bastante boa. O tamanho da GPU parece bater com o tamanho esperado de um Cedar com algumas coisas retiradas. http://www.chip-architect.com/news/AMD_Ontario_Bobcat_vs_Intel_Pineview_Atom.jpg

Existem várias idéias... por exemplo, você poderia combinar alguns módulos de dois núcleos, similares aos atuais Bulldozers, com uma boa quantidade de cache e execução fora de ordem, com alguns módulos mais "leves", mais similares a um Atom otimizado ou um núcleo Niagara, com menos cache e suporte a multithreading. Ou incluir algum tipo de unidade SIMD acoplada a um núcleo simples para controle, similar a uma GPU ou Cell... Só se deve tomar cuidado com a compatibilidade (todos os núcleos x86 devem suportar a arquitetura inteira) e com a distribuição de recursos (nada muito complicado, a divisão entre os núcleos deve ser bem clara)... Por exemplo, eu não acredito que a sua ideia de diminuir a capacidade de ponto flutuante de alguns módulos valha tanto a pena atualmente... Mas no futuro, com módulos já diferentes uns dos outros, diferenciar por velocidade em PF será até óbvio, já que dependendo das características do núcleo e do mercado rodar PF pesado em um núcleo será besteira, e com módulos maiores e um maior número deles por pastilha, essa diferenciação começa a valer a pena.