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.

A qualidade do processo Intel tem dado resultados exatamente devido à customização trabalhosa feita transístor-por-transístor e muitas adaptações na moldagem das portas lógicas, até evitando uma necessidade de se fazer litografia por imersão. O problema é que essa customização toda tem um custo-benefício baixo porque deve ser refeita a cada novo nódulo, e o gate-last estará desabilitado após o nódulo 22 nm, portanto há apenas o gate-first como solução plausível para o futuro (ou seja, produção de circuitos de alta performance após 2013). A GF recentemente apresentou resultados bons no papel para o SOI+HK/MG 32nm, mas sem a divulgação de informações da parte da AMD como número de camadas de metal usadas, fan-out etc. do BD fica difícil assegurar que a GF conseguirá competir de fato com a Intel. Por hora, a decisão da AMD em perseguir velocidades de relógio mais elevadas é sinal de que ela desenvolveu a filosofia correta para se lidar com o SOI e lógica dinâmica ou mista (uma das idéias por trás da aplicação do insulador é justamente reduzir o vazamento e consequentemente a potência dissipada, e isso é ótimo para circuitos menos limitados em velocidade do que em TDP) e aproxima-se cada vez mais da IBM com os Power6/7.

O Llano me parece uma péssima opção para upgrades (ninguém sabe ao certo qual soquete ele usará), entretanto o vídeo integrado os torna mais interessantes para os desktops OEMs. De melhor, o que se viu nos previews do SB "caçando" o Westmere poderá se repetir com o Llano contra Thuban, dependendo das melhorias (menos cachê, porém mais "núcleo" e uma tremenda ponte norte para acomodar o vídeo). O Propus não faz feio e não há indício que o Llano mudará essa tendência.

Resumo da conversa TGB: Multicore is sweet. BC might do well if AMDers get more like Intel and pour some into extraneous and expensive R&D. JF: We rule with that (multicore, not R&D) but our competitor wouldn't admit it. Thinking massive multicore right now, problem is, we're still working out bugs in our 2-core BC prototypes. TGB: Yeah, and KISS rules too. Que viagem...

Não é bem que o JF tenha viajado na maionese. A resposta dele foi intencionalmente pouco compreensiva e bem por cima mesmo (para evitar a divulgação acidental de segredos industriais? "Missing "server" features" do BC pode significar corte nos barramento HT3.1, IOMMU, protocolo MOESI, "snoop filter", cachê L3 etc.). Ele deu a entender que esse corte não fará grande diferença em servidores de pouca utilização (digamos, armazenamento em rede caseiro, um banco de dados ou servidor de mídia pessoal, ou "website server"), o que já não será mais verdade nos datacenter de alta utilização.

Absolutamente. O diferencial é que o conjunto de instruções AVX que é suportado pelo SB não é o mesmo suportado pelo BD. Aplicativos otimizados para o BD precisam das instruções FMA4/XOP mais as PREFETCH/PREFETCHW (oriundas do 3dnow) para alimentar a unidade de ponto flutuante com velocidade máxima. As diferenças entre o SB e o BD neste caso são dramáticas, mas não se trata de uma solução ter superioridade definitiva sobre a outra.

Evandro, eu postei alguma explicação sobre a unidade de ponto flutuante neste tópico mas o assunto foi rolando até ela ficar muito para trás, é melhor eu postar uma nova. O grande diferencial da FPU do BD é a capacidade de processar operações de multiplicação-e-acumulação fundida (FMAC). Isto jamais foi mantido em segredo e todos já devem saber disto. Porém, ninguém de fora da AMD sabia como as unidades de execução individuais da FPU serão estruturadas. Foram consideradas 2 possibilidades básicas: a) A criação de uma ponte para unificar indivíduos. Esta especulação surgiu devido a um papel que a AMD publicou sobre construção de unidades FMAC a partir de uma ponte que une multiplicadores (representados por MUL) e acumuladores (representados por ADD) equipados com suas portas individuais, utilizando a saída da unidade de adição (ADD). O consumo de energia durante operações de multiplicação ou adição individuais é baixo mas a área da FPU aumenta em mais de 40%; Throughput de pico por ciclo de relógio (por FMAC): 1x 128-bit M + 1x 128-bit A, ou 1x 128-bit FMA (2-2 operações/ciclo); 0,5x 256-bit M + 0,5x 256-bit A, ou 0,5x 256-bit FMA (1-1 operações/ciclo); Ilustração do exemplo (a): (claramente feita "nas coxas" :-P) A velha e boa FMAC clássica. Neste caso há uma penalidade no consumo de energia (nas operações de multiplicação ou adição individuais) pois tanto as operações quanto os dados dependentes têm de obrigatoriamente percorrer um caminho mais longo até a saída. A AMD ao que tudo indica preferiu este arranjo; Throughput de pico por ciclo de relógio (por FMAC): 1x 128-bit M, ou 1x 128-bit A, ou 1x 128-bit FMA (1-1-2 operações/ciclo); 0,5x 256-bit M, ou 0,5x 256-bit A, ou 0,5x 256-bit FMA (1/2-1/2-1 operações/ciclo); Ilustração do exemplo (: Como o BD possui 2 FMACs, ele será capaz de processar 1 instrução FMA (2 operações) de 256-bit por ciclo de relógio. Sans FMA, o desempenho continuará limitado a 1 instrução que é capaz de executar apenas 1 operação, ou seja, metade do desempenho possível com o FMA. A título de comparação, o throughput de pico por ciclo de relógio do SB é: 1x 128-bit M + 1x 128-bit A (2 operações/ciclo) 1x 256-bit M + 1x 256-bit A (2 operações/ciclo) Agora simplificando, o desempenho em ponto flutuante nos programas antigos e atuais não otimizados para o BD seria melhor no caso (a) e pior no caso (, enquanto que nos programas otimizados para o BD (suporte a FMA4) o desempenho em ambos casos seria similar. O SB notoriamente também não se sairia excepcionalmente bem na execução de programas não-otimizados para AVX.

Voltando ao assunto sobre a FPU do BD, está quase confirmado que estará equipada com unidades de execução FMAC clássicas (daquelas "beberronas", mas o "power gating" embutido deve aliviar o caso), e executará um máximo de 2 uops para operações com pacotes de 128-bit de inteiros mais 2 uops para pacotes de 128-bit ponto flutuante por ciclo de relógio. Juntamente com as instruções FMA4, isto é muito bom para as operações sobre registradores XMM, entretanto, ao operar sobre os registradores YMM (AVX) o desempenho de pico para 2 núcleos do BD sem as FMA4 será a metade da capacidade para 1 núcleo do SB da Intel (você não leu isto errado). Ou seja, a AMD preferiu economizar espaço na área do die para a FPU e investir nos demais recursos do processador. Não acho que seja uma ideia ruim caso o retorno do investimento valha a pena na prática.

Mas é para duvidar mesmo do que eu escrevo. Vale também criticar, contestar e apontar erros. Absurdo seria eu me auto-declarar portador da verdade absoluta e incontestável de todas as épocas. Você "desqualificou" o que eu escrevi porque eu pratiquei o humanamente possível: para você eu deveria (e somente eu, nem o Eduardo, nem o criador deste tópico ou as postagens que antecederam as minhas e tampouco você mesmo) com toda a naturalidade do mundo afirmar com certeza inatacável exatamente o que os micro e quem sabe também os nanoprocessadores futuros conterão, quando serão lançados e talvez até mesmo a que preço e disponibilidade. Possivelmente você enxergou na minha persona alguma entidade sobrenatural digna para se render culto e infalível. Caso seja esta a sua intenção, na minha consciência e condição de simples ser humano modestamente declino a oferenda. Foi o Eduardo quem, em primeiro lugar, respondeu a uma postagem minha e não o contrário. Não fui eu quem fugiu do assunto mas ele quem atacou um ponto que a princípio sequer levantei. Eu tratei a origem do problema para a comercialização em larga escala de processadores de 128-bit dentro dos seguintes aspectos, e limitada somente a estes: 1- A viabilidade técnica e econômica para sua implementação; 2- O interesse do mercado em adotar o produto; Portanto, segundo a sua lógica, estaria certo que eu desviasse da minha linha de raciocínio original para adotar outra linha concorrente a qual implicitamente descartei desde a minha primeira postagem, tornando desta maneira as respostas cada vez mais caóticas e indigestas para o usuário leigo e até mesmo caindo em patente contradição. Quanto à questão se a — usarei aqui a nomenclatura do Eduardo — "bitagem" das unidades de inteiros influencia a de PF e vice-versa, ainda posso argumentar que as unidades de PF mais antigas vinham em co-processadores e não compartilhavam do die do processador, tornando a questão do balanceamento da "bitagem" entre as unidades internas do processador irrelevante. Quanto aos microprocessadores atuais, uma análise detalhada é muito mais pertinente aos próprios engenheiros responsáveis pelos designs e será melhor respondida por eles. Olha, se você não compreendeu na totalidade o que escrevi sobre isso, então aviso-lhe que eu já tratei essa questão desde seus aspectos técnicos mais elementares até o marketing envolvido, sendo este último a influência decisiva nas aquisições de hardware de nove entre dez usuários de microcomputadores.

Não de acordo com a Wikipedia: O IEEE somente padronizou o formato de ponto flutuante de precisão simples em 1985, onze anos após lançado um processador de 128-bit. Antes da padronização, mal dá para discutirmos pois não havia base alguma para uma comparação: se o processador usava ponto flutuante de verdade, ponto fixo ou combinações de ambas as coisas, se os tamanhos da palavra eram potências de 2 ou variações, ou mesmo as diferenças na quantidade de bits reservada para o sinal, expoente e mantissa para tamanhos de palavra idênticos. Execução confiável de PF é muito mais complicada de se implementar do que de inteiros. No caso dos números inteiros, basta combinar blocos funcionais para se obter execução por hardware de formatos 256-bit, 512-bit, 1-Kbit etc. com alto índice de reaproveitamento dos circuitos. A parte ruim: estender uma arquitetura antiga e obsoleta para comandar tudo. Eu não disse que o SSE5 enquanto conjunto de instruções era perfeito mas que foi uma iniciativa bem-executada à luz da época, principalmente tendo em vista as restrições que a codificação compatível com SSE impõe aos opcodes e como a AMD extraiu o máximo que pôde. Assim como o 3dnow foi outra iniciativa mais simples e viável apenas para sua época. Existe uma coisa importante que é a liberação de recursos (budget de transístores) para se construir microprocessadores de uma determinada geração. Há coisas que funcionam melhor em certas gerações (o que os engenheiros gringos chamam de sweet spot) e outras que são problemáticas. Um microprocessador corre até mesmo o risco de sofrer em termos de características aparentemente desvinculadas das escolhas erradas, tais como velocidade máxima atingível, influências parasíticas, vazamento e consumo de energia. Se você quiser insistir que alguma empresa tomaria o tempo de seus engenheiros para especificar um conjunto de instruções, simular e verificar se as futuras microarquiteturas funcionam direito com essas instruções e até liberar para o público um simulador completo apenas para fazer um reconnaissance do adversário e jogar tudo fora voltando atrás caso ele não tivesse nada nas mangas será a sua opinião. De resto, não vou discordar só por discordar mesmo porque o Bulldozer ainda está distante... acho entretanto que este tópico formou uma boa pilha de informações para se analisar.

Bem, acredito que Eduardo está certo em pontos e eqüivocado em outros. Não disse em momento algum que ele está errado em cem por cento ou que eu estou certo em cem por cento porque seria absurdo, a não ser que eu possuísse uma bola de cristal e adivinhasse com exatidão tudo o que acontecerá daqui para frente. Tanto as postagens dele quanto as minhas contém especulações dentro do possível. No mais, Dick converteu os meus predicados da ideia em anunciados sobre fatos. Segue citação do que eu disse em várias postagens. "...minha especulação declara..." "Como não sei o que testaram lá e nem a quantos GHz, não posso afirmar nada..." "...isso aí cheira a truque de marketing para manter a indústria aquecida. Não há necessidade alguma de fabricarem processadores com unidades de inteiros de 128-bit..." "Aparentemente a AMD está..." "...uma informação que a Microsoft não confirmou mas tampouco desmentiu. Ou se algum representante desmentira de fato, fê-lo tão timidamente que acabou indicando que pode haver algo dessa espécie..." "...posicionando-a como uma opção viável dependendo das possibilidades de mercado..."