Altamir Gomes

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á ?

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? ;-)

Acho que foi bem nas festinhas que esse acordo foi feito, hein...

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 ;-)

Existe um consenso de que código x86 não é diferente de outros códigos, já quanto ao número de registradores não existe consenso nenhum, 32 é o número mais usado pela praticidade.

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.

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.

RISCs de console são processadores em ordem sem renomeação.

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.

Na prática nada disso faz muito sentido, porque se você for utilizar um Beckton, provavelmente seu problema não tem como limitador o desempenho de processamento de aplicativos independentes (nesse caso você usaria 2 sistemas Westmere)... normalmente é capacidade de memória mesmo.

RAS! O desempenho de processamento é o segundo item na lista dos interessados pelo Beckton, tenho acompanhado isso de perto...

P.S.: o GTK+ torna a programação para GUI uma moleza :-)

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.

A intel já ta com a mira nos 15nm... os 22nm são fixinha!

Não é bem assim. O volume de produção de 32nm da Intel ainda está baixo. Conseguir façanhas da eletrônica em laboratório é uma coisa, já fabricá-las em quantidade é outra completamente diferente.

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.

Se são vários grupos em overlap, se um deles criasse uma arquitetura totalmente diferente ou qualquer coisa bastante inovadora, não acabaria tornando parte das pesquisas dos outros grupos incompatíveis? Ou seja, para sair do P6 precisariam interromper com o tick-tock e reestruturar todos os grupos de pesquisa.

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.

Mais dentro do tópico, vocês sabem como funciona o R&D da AMD? tem alguma peculiaridade?

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.

E já que falaram da IBM, vocês acham que as relações mais próximas da IBM com a globalfoundries (se os rumores que eu vi forem verdade, claro) podem se traduzir em alguma parceria entre a IBM e a AMD ? (O que seria provavelmente muito mais benéfico para a AMD já que é a IBM tem capacidade de R&D muito superior) Ou vocês imaginam que é só a nVIDIA que vê a GF como "a fábrica da AMD"?

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.

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%.

E este ainda sofria de efeitos colaterais curiosos como o SNDS devido à eletromigração quando sob overclock a tensões elevadas

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...

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

Eu falo do conservadorismo do projeto elétrico...

O GTL+ que o diga!

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.

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.

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.

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.

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.

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.

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.

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...

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...

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.

O campeão do gate-last é a Intel. A TSMC usaria gate-first, mas acabou mudando para o gate-last...

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.

Creio que soullforged tomou linha de associatividade do Dcache por linha de pipeline, que são duas coisas distintas. As linhas de associatividade são um meio de particionamento da memória cachê de maneira a se permitir que diferentes localidades da memória principal fiquem replicadas sem que uma delas elimine e sobrescreva a outra. Um circuito chamado de TLB (Translation Lookaside Buffer) é o responsável por gerenciar esse particionamento e normalmente opera independente do arranjo das unidades de execução do processador.

Do ponto de vista do engenheiro de software e do desenvolvedor de compiladores, há fatores a se considerar como tipo de arquitetura de cachê inclusiva (os dados do L1D são replicados no L2, o que melhora o desempenho das transações de coerência de dados mas "rouba" espaço do L2) ou exclusiva (os dados do L1D não são replicados no L2, o que economiza espaço e alivia um pouco o consumo de energia elétrica mas piora o desempenho das das transações de coerência de dados) e a própria associatividade. Os Phenom e derivados utilizam atualmente um sistema de duas vias associativas e arquitetura de cachê exclusiva com um "victim buffer" o qual na prática limita a utilização do L1D para menos dos 64KB totais evitando assim que o buffer "empurre" constantemente os dados para fora do L1D. O Bulldozer possivelmente utiliza outro tipo de arquitetura de cachê inclusiva, pois o custo da replicação dos dados no L2 seria muito menor. O engenheiro da AMD pode confirmar esse detalhe. De qualquer maneira, ele não deve soltar muita coisa enquanto o "Acordo de não divulgação" dos parceiros da AMD não expirar.