Altamir Gomes

LOL! Para se ganhar bolsas de pesquisa, especificamente. Mas caso torne-se o chefe de um departamento de P&D multibilionário antes de iniciar um doutorado, para que a concessão da bolsa mesmo? ;-) Ex., o Charlie pode viajar no barato de vez em quando mas é de confiança, caso contrário não seria confidente de tantas infos, o que infelizmente não é o caso de alguns dos próprios executivos dessas empresas de TI! Como ele faz muito o social, deve até ter visto o momento exato que algum figurão amoleceu a língua.

O Sr. Eng. Dirk "O Poderoso Chefão" Meyer optou por um mestrado na área de Administração. Conheço gente apenas com o diploma em Administração que bate qualquer Doutor Eng. em termos de aptidão técnica... e ainda por cima gerencia bem um negócio! Como se vê, saber gerenciar a confidencialidade das informações transeuntes é um requisito essencial que não é nada fácil e pode ser um pouco demais de responsabilidade, mesmo para Workaholics. Mas as festinhas aliviam ;-)

Opa, a ISA influencia sim na necessidade de se ter ou não mais regs. Por exemplo, arquiteturas com suporte a instruções de carga-e-execução (LE) e leitura-modificação-escrita (RMW) como a x86 diminuem bastante a pressão sobre o arquivo de regs, inclusive em código típico de jogos como multiplicação de matrizes, modulação de operações matemáticas transcendentais, armazenamento e recuperação de constantes, etc. Até recentemente, sim, mas a tendência é incluir recursos cada vez mais relaxados de processamento, como é o caso do ARM Cortex-A8, e atualmente o A9 MPCore. Pode ser mais adequado referirmo-nos às CPUs de consoles de última geração como strongly-ordered devido a alguns truques oriundos da filosofia fora-de-ordem (buffers intermediários, arbitração um algo sofisticada no acesso aos barramentos, etc.) que no entanto não as tornam CPUs fora-de-ordem de fato.

Existe um consenso de que em código x86, arquivos de 32-128 registradores não proporcionam nenhum ganho de performance dramático sobre 16. Já com 16 regs vs. 8, a maioria dos códigos de aplicativos apresenta uma melhora significativa. Claro, somando-se aí o fator de que as CPUs desses consoles apresenta quantidade menor de regs de renomeação e geralmente possuem buffers e esquemas de reordenação de instruções mais simples, o que exige por tabela maiores arquivos de regs arquiteturais, ou seja, acessíveis diretamente através da ISA. 8 regs colocam pressão excessiva sobre a máquina de execução fora-de-ordem. Partindo de 16 regs numa máquina weakly-ordered há um balanceamento já razoável destes recursos.

Levando a coisa no sentido de que os 8 registradores do x86 IA-32 são argumento contra, claro... com um register file de 16 fica muito mais difícil afirmar que o x86 não serve para consoles.

Maior quantidade de registradores de dados = arquitetura de CPU mais eficiente e rápida.

O importante para a AMD é emplacar sua arquitetura de GPU no XBox 3, pois a aparição do x86-64 nos consoles era já uma certeza, seja por esta ou pelas concorrentes. Os 16 registradores no modo 64-bit são O Argumento a favor do x86 nos consoles...

Da parte da AMD o produto está finalizado e já está sendo enviado para os OEMs. O produto só não está no mercado devido a pormenores e provavelmente veremos algumas ofertas na Newegg durante a sessão de vendas no Natal. Comparar os resultados das equipes de design dos Atom e BC é interessante pois a Intel, assim como a AMD, têm de usar os componentes e processos básicos disponíveis sofrendo de praticamente as mesmas limitações. Vence quem sintetizar o melhor design e fizer as escolhas mais sóbrias.

Os valores em idle divulgados são do sistema completo, nenhum review isolou o consumo individual dos núcleos da CPU. Vale lembrar que o objetivo setado para o BC não é ser campeão em performance absoluta móvel mas ser um dos mais eficientes em performance/Watt com um desempenho razoável e próximo do Turion. Sejamos honestos, neste quesito (o que a AMD se propôs a fazer) a ES testada esmagou os Atom e as versões moveis do Nehalem, proporcionou uma das maiores humilhações que a Intel sofreu desde o lançamento do Athlon ou do Opteron e serve como testamento de que a turma de Haifa, apesar de ser muito boa, ainda tem que comer muito capim para chegar no nível do time de design da AMD/ATi. Em nenhum dos testes os CPUs Intel fizeram frente à eficiência do concorrente. Resta saber se o produto final apresentado nos notes obterá esse mesmo desempenho.

Considerado que o Ontario será lançado para thins e netbooks e o Llano rodará a 3+ GHz em oposição a 1,4-1,8 GHz, o desempenho está razoável.

...isso desde 2007. Não tem novidade alguma mesmo, só para quem estava dormindo debaixo de uma rocha. Pelo menos, à parte, o JF acabou soltando o throughput por chip Interlagos das instruções AES (16 por ciclo de relógio vs. 6 do Westmere-EP), que no final das contas não tem nada a ver com ponto flutuante.

sirroman, passo a pergunta sobre a FP do Bulldozer pois já falei muito disso neste tópico, se continuar parecerei um bitolado No aguardo das possíveis respostas do Thiago e do Eduardo.

Não sei... desconfio que sim pois o management da Intel prefere isolar bastante os grupos e cobra foco e objetividade máximos. Até mesmo dentro de cada equipe há uma grande tolerância pela opção de cada um de ficar quieto no próprio canto; já o management da AMD não gosta que ninguém fique isolado, procuram incentivar a comunicação de grupos distantes entre si, bastante conversa fiada pelos corredores, muita animação etc. e os grupos na AMD também são mais compactos e em menor número e portanto mais fáceis de se gerenciar, o que lhes permite "afrouxar as rédeas" e se entenderem melhor. P.S.: o ambiente na AMD lembra um pouco a Digital Equipment Corporation, que foi uma das empresas mais inovadoras na área de computação mainstream de todos os tempos. A AMD faz muitas parcerias para a lida com processos de fabricação. Foi importante na época do Athlon K7 para conseguirem as interconexões de cobre com a Motorola e depois o SOI graças à IBM. Na parte de projetos, eles contam com a experiência de veteranos das séries RISC 29K, do Alpha 21264 e da empresa NexGen absorvida pela AMD. O trabalho (ou milagre, se preferir) que eles já fizeram com células e componentes padrão, comuns, e processos de fabricação de segunda mão, é inigualável e impressiona até mesmo veteranos da Intel: os AMDers são verdadeiros artistas do design de microprocessadores. Acredita-se que o top-tier da empresa seja responsável pela introdução das novas uarchs (K6 NX686, K7 Argon, K8 Sledgehammer etc.) e outras equipes secundárias fiquem com o trabalho de melhoramentos. Ainda há uma aproximação entre as duas, pois a AMD é uma das proprietárias da GF, e além disso a proximidade e a identificação com a IBM já fazem parte da cultura da empresa.

E este ainda sofria de efeitos colaterais curiosos como o SNDS devido à eletromigração quando sob overclock a tensões elevadas Sua definição está tecnicamente correta, não há relação fundamental entre velocidade de relógio e vazamento de corrente. Atrapalha na prática que somente a melhoria na refrigeração e a queda na tensão da fonte (sem as devidas otimizações no layout e no Vt) obrigam a certas limitações e pior ainda para a velocidade caso os transístores tenham de ser trocados por outros de chaveamento mais lento. Diferentemente, se nada é melhorado no circuito, a temperatura no die é mantida e as tensões continuam as mesmas, os efeitos negativos durante a elevação da velocidade se fazem sentir. Portanto, os dois são inimigos declarados mesmo que não se conheçam O GTL+ que o diga! Essa foi (deve ser pelo menos a ducentésima quinqüagésima terceira vez que todos lêem a frase a seguir) uma lição que a Intel aprendeu com o fracasso da Netburst. Entretanto, mesmo com alguns anos de lambuja e overlap, a Intel tem suas limitações e seus grupos são manejados em respeito às deadlines do "Tick-Tock". O fantasma da deadline tem assustado tanto essas equipes, que as inovações de projeto mais significativas que elas conseguiram são o controlador de memória integrado, o barramento CSI e a melhoria no protocolo de coerência... apenas em 2008 graças ao empurra-empurra. Tá certo que a AMD fez a mesmíssima coisa ao reaproveitar as idéias do K7 até dizer chega, exceto que as inovações mais significativas vieram bem antes, em 2003.

Eu deveria ter escrito "tem um custo-benefício baixo com relação às customizações mais comuns, caso estas fossem viáveis para a Intel", pois foi esse o sentido que eu intencionei. Algumas fontes relatam que haverá mudança para os FinFETs ou Trigates após 22nm. O gate-last pode não se tornar inviável utilizando as estruturas atuais de devices, o problema ocorrerá caso desvantagens em termos de desempenho reforcem a opção em desabilitá-lo e adotar o gate-first com outras estruturas. O que me preocupa mais é a adequação dos circuitos reais para operação. Como se sabe, os responsáveis pelo projeto e pelo processo dos BD e Llano não são mais os mesmos, e com tantos rumores sobre demoras... Bem, acredito que menor capacitância de junção seja decisiva para estabilidade do circuito em velocidades mais elevadas de operação e a contenção do vazamento seja importante sob as mesmas velocidades elevadas, já que este aumenta dramaticamente com a elevação da velocidade de relógio. Quanto ao conservadorismo da Intel nos projetos, ocorre que a adoção do "Tick-Tock" permite uma janela de tempo menor para mudanças super-radicais. Em um ano altera-se o processo, com alterações leves na uarch e no ano seguinte outra uarch melhorada tem de obrigatoriamente estar pronta e preparada para utilizar o mesmo nódulo de processo. A AMD pelo visto já deve ter percebido essa fraqueza.