ThiagoLCK

O John Fruehe soltou em alguns comentários de seu blog algumas dicas interessantes sobre o Bulldozer... Aparentemente, ele "está disposto a apostar" que um Bulldozer Interlagos será mais de 50% mais rápido que um Magny Cours em aplicações single-threaded. Segundo, ele deixou bem claro (pelo menos para mim) que a vantagem de 50% do Bulldozer sobre o Interlagos é no SPEC, particularmente no SPEC INT rate. O que não ajuda tanto, mas permite prever que o Bulldozer Interlagos terá boa vantagem sobre o Westmere nisso. E pelo menos evita algumas quebras mais óbvias (por exemplo, T P C-C com SSDs)... OBS: Johannesrs, cuidado! Precisa de mais de 50% de reprovação ou você não conquista a meta anual ! Pelo menos é assim que parece funcionar com meus professores... EDIT: Esse Fruehe tá praticamente dando um "Tudo que você queria saber sobre o Bulldozer" nos comentários! Portanto cada módulo tem duas VFPUs de 128 bits a disposição, que podem ser utilizadas como uma VFPU de 256 bits... assim um Bulldozer de 8 núcleos terá a mesma capacidade de VFPU de um Phenom II X4 em aplicações sem FMACs... ainda tinha algum dúvida se não seria mais que isso.

Na verdade, um processador Bulldozer de 8 núcleos teria 4 "blocos" de ponto flutuante, cada um com, ao que eu saiba, duas unidades de ponto flutuante de 128 bits capazes de executar FMAs. Se seu código usar FMAs, isso significa o dobro de performance bruta por "bloco" de ponto flutuante em relação aos Phenoms atuais. Se não usar, significa a mesma performance bruta (mas existe uma lenda de que cada unidade FMA poderia se dividir em duas: uma FMUL e uma FADD). Como existe um "bloco" por módulo, o Bulldozer de 8 núcleos provavelmente perderia em ponto flutuante de um Phenom de 8 núcleos, mais ou menos dependendo de quanto você usa FMAs e de quanto inteiros importa para você. Lembrando que tudo isso é especulação. Não sei realmente como funcionará a unidade de ponto flutuante do Bulldozer. É bem provável, até por comentários de funcionários da AMD, que eu esteja subestimando muito o Bulldozer, pelo menos em códigos sem FMAs. Entendo. Mas imagino que na maior parte dos casos SIMD só valeria a pena se fosse muito mais fácil do que é hoje... O XBIT tá mal ultimamente. A fonte solta algumas coisinhas a mais... Eu tenho a impressão de que esse blog não acrescentou muito sobre o Fusion... todo mundo sabia que eles seriam mais lentos que 5970 . Eu mantenho minha estimativa: entre 5550 e 5570, provavelmente rodando os muitos SPs a uma frequência bem baixa para diminuir o consumo. MAS: Isso é interessante... e ele ainda disse nos comentários que a ideia é lançar o maior número possível de peças a tempo dos feriados de fim de ano.

Um documento da Intel absurdamente público esclarece a origem (sim, é um Larabee) e a performance bruta em FP: são 16 FLOPs por clock por núcleo em precisão simples, o que daria 614,4 GFLOPS em SP, presumivelmente metade disso em DP. Pela foto em outro documento da Intel (citado no documento acima) deve consumir a mesma coisa que uma GPU comum atual... menos de 300 W, mais de 250, diria. A única coisa que me intriga um pouco é essa história de que o cache é "shared". Eu chuto, pelas figuras, que a bagaça use um anel como o Larabee original... não consigo ver o "sharing" disso, mas checando notícias sobre o Beckton diria que o esquema deve ser similar ao dele e do Larabee mesmo, e eu é que tenho uma terminologia muito chata. O Larabee tinha. Essa coisa é um descendente do Larabee, não do SCC e do Petascale... embora ele deva usar alguma coisa de software e plataforma deles. Mas o hardware é o Larabee, apenas com um nome diferente. Não sei por que a Intel faria isso, mudar o nome ... OBS: como eu, com dois segundos de Google Fu e uma pesquisa na página da Intel, acho algum dado que alguns jornalistas profissionais não conseguiram localizar? http://www.hpcwire.com/features/Compilers-and-More-Knights-Ferry-v-Fermi-100051864.html Um artigo bem melhor... veja que ele responde todas as perguntas que você poderia ter sobre o KF na primeira página.

Sim, mas em aplicações para servidores "normais" o ganho ainda seria pequeno... e só o fato de não poder rodar em algumas combinações de sistemas operacionais me parece mais que suficiente para desconsiderar a ideia e meter uma bica em quem considerou, SE minha aplicação fosse uma dessas aplicações para servidores "normais". Compressão de vídeo deve ser o alvo deles mesmo... mas não tem tanta coisa assim no mercado doméstico que use SIMD, ou tem? Compressão de vídeo é "o benchmarck" de SIMD doméstico atualmente.

No caso da comparação Bulldozer x Sandy Bridge sim, a diferença de projeto entre os dois é muito grande e eu não me surpreenderia tanto se um tivesse muito mais ou menos frequência que o outro. Eu acho que isso acontecerá... pelo pouco que a AMD forneceu de informações, eu diria que o Bulldozer terá 50% mais performance com mais ou menos o mesmo tamanho que o MC, mas escalado pelo processo novo. Isso daria os 400 mm² que você pediu . Eu não duvido que dê para fazer um processador com o mesmo consumo que os x86s atuais mas com mais estágios de pipeline... OK, não acho que seja nem de longe a melhor ideia, mas vamos ignorar isso porque minhas luvas de amianto ficaram em casa. Agora, aumentar frequência, isso com certeza aumenta o consumo... em programas otimizados, é quase sempre uma melhor opção aumentar o número de núcleos do que aumentar a frequência, se você só se preocupa com performance por consumo. Só que também temos de analisar performance por área, e nesse aspecto é muito mais complicado concluir alguma coisa generalizada. A ideia do CMP, combinada a mudança de processo, pode ajudar muito nisso. Eu li algumas informações do Citavia, ainda acho que não são tão conclusivas. De qualquer modo, pelo que entendi é bem provável que a AMD tenha desenvolvido o decodificador para suportar o dobro de performance em situações bem específicas, com instruções fáceis de decodificar, enquanto o caso geral se mantém com a performance normal de 4 instruções por ciclo. EDIT: Outra opção seria algum tipo de "trace cache"/"loop detector"... As unidades de inteiros, diria, estão ali para dar boa performance em aplicações single-threaded (que ocupam módulos inteiros com apenas um thread) e ao mesmo tempo aproveitar algum pico de ocupação em aplicações mais otimizadas... Se a AMD acha que vale a pena em relação ao (relativamente pequeno) gasto de área e ao (também pequeno, ainda mais com "clock gating") gasto de consumo, o único problema que sobra é a dificuldade em aumentar mais a frequência... e sim, essa é uma tentativa descarada de suportar minha hipótese do Bulldozer de baixa frequência. Esse é o Bulldozer X16, imagino que a AMD tenha diminuido frequência/consumo por módulo ao máximo com ele... afinal, quem compra um X16 não está muito interessado em performance por núcleo. Se fosse uma aplicação single-threaded, então o Bulldozer seria 50% mais rápido nessas condições, só isso, não precisa de divisões ... mas não é o caso, o Fruehe é especialista em marketing de servidores. Com certeza a aplicação em questão é multi-threaded, e das boas. Para algumas aplicações que dependem muito da performance teória do SIMD, sim. Mas na maioria acho que o aumento do número de núcleos e melhorias diversas, principalmente no subsistema de memória dominarão o embate. Provavelmente XOP+AVX. Respondendo a pergunta, tudo que roda com ponto flutuante e usa SIMD: coisas como codificação de vídeo, alguma bagaça em jogos, computação técnica bem otimizada, talvez mais alguma coisa... Alguém vai usar? Se eu fosse gerente e visse alguém usando daria uma baita bronca...

Não é assim que funciona. Supondo que o Magny Cours tenha ganho uma pontuação de 100 (só para facilitar), o Bulldozer ganhou uma pontuação de 150. Se dividirmos a pontuação pelo número de núcleos (o que pode ou não dar um resultado útil, dependendo da aplicação, da plataforma e do processador), teremos que cada núcleo do MC conseguiu uns 8,3 pontos, e que cada núcleo Bulldozer conseguiu uns 9,4 pontos. Portanto, cada núcleo Bulldozer é aproximadamente 12,5 % mais rápido que cada núcleo MC, NESSA E SOMENTE NESSA situação que mediram. Sim. O pessoal daqui, por isso esclareci. Isso seria contraproducente na redução do consumo ... Claro que existe um ponto de ótimo, mas eu acredito que a melhor opção para obter boa performance de inteiros single-thread é aumentar os recursos de execução, investir na melhora do acerto médio nas especulações e ser mais conservador em todo o resto, principalmente frequência, especulação e front-end. Mas isso é só um chute mesmo. A ideia é a seguinte: unidades de inteiros são baratas. O hardware para utilizá-las bem não é tão barato, por outro lado. A ideia é não utilizá-las bem mesmo. Com isso você obviamente economiza em hardware para facilitar o aproveitamento dos recursos, como hardware de execução fora de ordem, buffers de memória, etc. Em segundo lugar, você especula menos. Para terminar, como o front-end é desacoplado do back-end, em teoria é possível dimensionar o front-end de acordo com a média de ocupação do back-end, e com isso seu front-end fica bem menor do que o aparentemente necessário. O mesmo se aplica aos recursos de memória. Com essa economia, você consegue colocar dois núcleos de inteiros em cada módulo, assim aumentando seu poder de fogo em aplicações otimizadas. Claro que isso exige que você aumente alguma coisa de capacidade nas partes compartilhadas: por exemplo, seu front-end tem que aguentar em média dois núcleos, assim como seu subsistema de memória. Mas por outro lado isso também tem vantagens: assim como em um SMT, em aplicações não-otimizadas você fica com um monte de front-end, memória e coisas compartilhadas para gastar em um único thread. A diferença, claro, é que seu processador não terá tantos recursos de execução, mas isso não deveria fazer tanta diferença. Existem diversos "buracos" nessa minha teoria: ponto flutuante, mais dados sobre o funcionamento do front-end e do back-end, etc. Mas acho que faz algum sentido. Se pensarmos em uma disputa Phenom II X6 x BDZ X8 usando aplicativos otimizados para multi-thread, eu espero pelo menos 50% de vantagem para o Bulldozer, provavelmente mais. Em aplicativos não otimizados para multi-thread, alguém poderia esperar uma vantagem de 12,5%. Mas isso não vai acontecer, por diversos motivos: 1- Como vários núcleos de inteiros estarão dormentes, cada aplicativo tende a ter um módulo para si, com todos os recursos compartilhados. Isso deve aumentar o desempenho em alguma coisa... 2- Por ter mais dois núcleos, núcleos mais rápidos, e uma plataforma similar, o BDZ X8 deve aumentar mais de desempenho quando diminuírem os threads, por questões de ocupação de subsistema de memória. 3- O Bulldozer deve ter uma implementação do Turbo mais decente, e cada núcleo consumirá menos. Tudo isso só deve valer para inteiros. Eu também não acredito em frequências mais altas, mas não as descarte... de qualquer modo "clock a clock" não é relevante. Foi confirmado que os Bulldozers para servidores manteriam a plataforma e o TDP dos atuais, se não me engano. Eles já disseram que esse tipo de coisa não irá acontecer, e para falar a verdade nem tem como acontecer. Dá para usar dois núcleos para executar uma thread, mas de forma extremamente dispendiosa com poucos resultados, e mesmo isso com um grande esforço. A Intel adora falar... 150% é 2,5 vezes mais desempenho, isso é completamente absurdo...

No mercado de servidores, eu diria que o Sandy Bridge não consegue encarar um processador 50% mais rápido que os atuais Magny Cours. O Magny Cours encara o Westmere em aplicações de servidores... Perder no "clock a clock" é irrelevante... se você tem o mais ou menos o mesmo consumo, o mesmo preço, o mesmo tamanho e uma plataforma parecida, o fato de você vencer seu adversário é o que importa. Se você quer fazer isso com o dobro da frequência ou com metade dela, aí é com você... Por exemplo, os Pentiums 4 Northwood "C" ganhavam claramente dos Athlon XP 3200+ em vários aspectos, e o fato de que um usava frequências muito mais altas não tirava os méritos deles. Sim... mas daí eles teriam de atrasar o lançamento. De qualquer modo, a perda de frequência foi a maior falha da arquitetura. Como eu disse, a 3 GHz o Phenom seria o melhor processador do mercado para quase tudo...

Ele talvez chegasse a 12,5% só na frequência, mas como aumentar os núcleos nesse caso? E se aumentassem os núcleos, como aumentar a frequência? 12,5% é muito para se tirar na microarquitetura... nenhum avanço do Core deve ter conseguido mais do que 5% de ganho em geral. Depende muito da aplicação. Mas não é mais que 50% na maioria... embora, obviamente, o consumo tenha caído. Erro... quando disse K8, queria dizer K10. 33%? Tem que ter muita melhoria para conseguir isso... de qualquer modo, essa comparação do JF foi feita para servidores, e deve ser encarada como tal. Não tem tanta relevância para desktops. Para servidores, um sistema com o mesmo custo e consumo e 50% mais performance é um avanço razoável. Diria que nessa escala existem muitas limitações externas sobre a performance, e de qualquer modo esse tipo de aplicação apresenta características diferentes em relação as que usamos. As análises teóricas consideravam que o Barcelona rodaria a uns 3 GHz... e aí ele trituraria o Core 2 muito bem.

OEM nenhum é instantâneo, os produtos sempre demoram. Não que isso torne menos ruim a ideia de perder o Q4... Isso só vale para servidores, além do mais o fato de ele poder usar 16 núcleos com mais ou menos o mesmo consumo e área é relevante... Se não me engano 16 núcleos significa 16 blocos de inteiros, ou seja, cada bloco de inteiros é 12,5 % mais rápido que um bloco de inteiros K8 em aplicações de servidores. Isso é bastante até...

Um jogo moderno não precisa de muita resolução para consumir bastante poder de processamento. Não... A principal responsabilidade delas é gerar os endereços quando esses precisam de alguma modificação. Por exemplo: for (i=0;i<100;i++) vetor1[i] = 30; Supondo que todo mundo saiba C... no caso, teremos um acesso a cada passagem do for, que terá de acessar uma posição de memória igual a posição anterior, mais i multiplicado pelo número de bytes do tipo de dado usado. Existem, na x86, instruções que fazem isso automaticamente, do tipo: ESCREVA ENDBASE,DESLOCAMENTO,ESCALA,DADO Que escreveria o DADO em um endereço igual a ENDBASE + DESLOCAMENTO * ESCALA. Para executar essas instruções rapidamente, existem as AGUs. Uma AGU é capaz de executar em uma única operação essa soma ENDBASE com DESLOCAMENTO * ESCALA... Existem outras funções para as AGUs. A x86 é relativamente complexa e possui vários modos de endereçamento, além de algumas coisas relacionadas a segmentos... o fato é que as AGUs são unidades especializadas em manipular endereços, de várias formas. 4 ALUs por núcleo, 8 ALUs por módulo, 6 AGUs por módulo, 3 por núcleo... o Phenom tem 3 ALUs e 3 AGUs por núcleo/módulo. Mas mesmo 4 ALUs é bastante, apenas poucos RISCs tem todo esse poder de processamento de inteiros, a maioria dos x86s tem 3 ALUs ou menos. AGU eles não colocaram mais porque de qualquer modo o cache consegue fazer no máximo 3 operações por ciclo (acho que duas escritas e uma leitura), e para falar a verdade 3 AGUs é uma baita quantidade de recursos de processamento de endereços, acho que só os AMDs mesmo tem isso (RISCs não tem AGUs). Se isso estiver correto, eles forçaram, pelo menos nas unidades... Existem 4 ALUs por núcleo, 8 por módulo... isso é muito. O poder de FPU é menor, apenas (segundo os dados, que como eu disse podem ser imprecisos) 4 de 64 bits por módulo, e não sabemos quantas de 128 e 256 bits... eu diria 4 de 128 bits, 2 de 256 bits. Como o SB provavelmente suporta duas operações de 64/128/256 bits por ciclo, e tem 3 ALUs, ele suporta menos operações de inteiros simples por ciclo em relação a um núcleo Bulldozer, mas suporta o mesmo número de operações de ponto flutuante em relação a um módulo Bulldozer... o que dá o dobro do poder em relação a um núcleo Bulldozer.

AGU é Adress Generation Unit, ou Unidade de Geração de Endereços, uma unidade de execução que gera endereços (genial:)!). Ou seja, ela soma o endereço inicial, os deslocamentos, já escalados de acordo com o tamanho do dado, os índices de segmento, etc, e monta o endereço efetivo que será utilizado pela instrução. Em seguida, ela envia esses endereços "prontos" para a LSU (Load-Store Unit, ou Unidade de Escrita e Leitura), que efetua o resto da operação de memória, como escrever nos caches, preparar os dados, etc. No caso dos Phenoms existe uma LSU, que se não me engano tem capacidade para duas leituras de 128 bits, duas escritas de 64 bits, ou uma leitura de 64 bits e uma escrita de 128 bits por ciclo. Essa LSU é "abastecida" por 3 AGUs, que ficam anexas às 3 ALUs da parte de inteiros. Pode parecer estranho dividir essas tarefas em várias unidades, ao invés de colocar as AGUs junto com as ALUs. Mas a verdade é que desacoplar esse tipo de coisa é essencial, primeiro porque na x86 existe uma instrução que permite gerar um endereço efetivo sem utilizá-lo (a LEA), segundo porque aproveita melhor a "infra-estrutura" de transporte, reordenamento, decodificação, etc... e terceiro porque desacoplando você aumenta a flexibilidade do sistema e quarto porque as instruções x86 são tais que colocar tudo na LSU seria impossível, e se for para desacoplar é melhor desacoplar de forma definitiva mesmo. Se o TDP se confirmar, diria que o Bobcat terá melhor performance por watt do que o Atom, e isso com uma GPU melhor é bem interessante para netbooks (que é o mercado real do Atom, o resto é história).

Embora não tenha certeza se essas informações do Open64 são totalmente corretas (elas são setadas mais para obter o melhor resultado, não para dar informações), é um indício interessante... gostei muito, queria mesmo ver uma microarquitetura x86 "Take no prisoners!!!!", inovadora e visando bom IPC por parte da AMD . Na verdade, eu queria uma dessas vinda de qualquer um. Pentiums Pros e Athlons guaribados já estão me dando no nervo... Essas especulações são complicadas... bem, os resultados mostram que o Bobcat terá bom desempenho em BOINC, o que já é alguma coisa.

"Redwood equivalent" teria os 400 SPs, 8 ROPs e 20 TMUs... eu acredito em uma performance entre a 5550 (128 bits de DDR2-800) e a 5570 (128 bits de DDR3-1800, acho). Pela bizonhamente imensa quantidade de shaders, é provável que o gargalo seja a memória, então aposto mais na primeira opção. Note que a diferença entre as duas é grandinha, então nem me comprometo com essa previsão . Mercado das 5450 (placas "tapa-buraco", não muito melhores que IGPs rápidos), 5550 e 5570 (placas "sou melhor que um IGP, e só!")... não vejo por que ter uma dessas quando se pode adquirir uma GPU tão ou mais rápida junto com seu processador. E acho que as 5650 não deveriam ficar muito confortáveis não... mesmo com alguma vantagem em performance, o custo-benefício fica bem pior. Se você colocar a GPU do Fusion junto com sua 4200 em um octógono, não dou dois segundos para seu IGP. Mesmo com muito over... aliás, fazer over no Fusion não deve adiantar, memória é a chave aqui.

Tem que analisar algumas coisas. A tendência de AMD e Intel é que mantenham os Market Shares atuais, o que, no fim das contas, se você tiver fábricas, implica: 1- Mercado x86 aumentando rapidamente, para pagar os cada vez maiores custos de produção. Isso simplesmente não acontece... 2- Busca de novos mercados... mas isso é complicado, a AMD tem poucos recursos e uma situação instável em seu mercado principal, a Intel tem uma certa dificuldade em entrar em novos mercados, devido a sua tendência monopolista, e tem mais facilidade quando pode "anexar" o mercado ao seu mercado principal (IGPs, chipsets, wireless). A principal vantagem da separação das fábricas da AMD foi atirar boa parte dos custos para outros, que acabam obrigados a procurar novos mercados para ela, com mais recursos e situação financeira estável. O caso da Intel é diferente, eles tem o claro objetivo de "anexar" cada vez mais mercados, e para isso é essencial que a integração do sistema aumente cada vez mais, o que gera mais custos, o que exige mais mercado...

O pirada foi mais de brincadeira, não dá para defender a expressão. Agora, se quer saber o que acho das ações da Intel... isso será bem Off-Topic. Intel acredita-se capaz de manter a litografia de 193 nm com imersão por mais tempo que qualquer outro fabricante... e não é de hoje, eles também estenderam a litografia de 193 nm "seca" e a de 248 nm mais que a maioria. Isso tem objetivos, permite a eles lançar o processo mais rapidamente, ainda que talvez com maiores custos e rendimentos e densidades inferiores. É uma questão de aproveitar suas forças: os melhores engenheiros de processo, batalhões de engenheiros no projeto físico, etc. Agora, quando alguém monta um cronograma para 2015 contando com isso, eu penso que fica fácil de desconfiar que a Intel não está desenvolvendo sua tecnologia de litografia computacional e similares para lançar o 11 nm mais rapidamente, sem EUV, e com isso ganhar mercado. A Intel (ou, melhor, o pessoal de processo da Intel) está desenvolvendo toda essa tecnologia para manter o cronograma dela. Os caras que desenvolvem processadores contam com o cronograma, e por isso vão inventar algum jeito de desenvolver algo para o processo de 11 nm. E assim por diante... Uma vez eu li que as ações da Intel, com as correções monetárias, não tinham aumentado de valor nos últimos 10-15 anos. Não sei se isso ainda vale... mas acho que fica bem claro que a Intel não mudou muito de "Market Share" nesses anos, nem cresceu muito para fora do mercado de processadores x86. Entende o que quero dizer? Bom, por mim a Intel está de parabéns, excelente trabalho, o deles, assim como o da AMD (sobre a qual poderia dizer as mesmas coisas). Imagino que os funcionários de ambas concordam...

Benefício: 1- O menor comprimento de onda permite processos mais avançados sem apelar para múltipla exposição, que, basicamente, consiste em passar o wafer mais vezes pela máquina de litografia óptica para melhorar a resolução. A teoria é bem simples. Ao invés de fazer processos de 15 nm passando cada wafer 3 vezes por máquina com luz DUV 193 nm em imersão, e fazer processos de 11 nm passando cada wafer umas 5 vezes por máquina 193 nm imersão, você monta uma máquina com luz EUV 13 nm e resolve o problema em uma passada, na força bruta. Os problemas? 1- Produzir luz ultravioleta nesse comprimento de onda é #%&*%$%#$$$$$$. Atualmente, o melhor que se consegue (o melhor que os japoneses conseguem!) é uma fonte de 104 W, usando métodos heróicos de produção de plasma por laser. Os analistas dizem que 400 W seria suficiente para produção em massa. 400/100... 2- Produzida a luz, existem problemas materiais para todos os lados. Para começo de conversa, os "resists" (o material que recebe a luz na litografia óptica) são um problema, a luz EUV tem uma forte tendência a "chutar" as moléculas do wafer e as máscaras sofrem muito mais do que sob as fontes atuais. 3- Não existem ferramentas de inspeção adequadas. 4- As ferramentas tem de trabalhar no vácuo, não podem usar lentes, apenas espelhos... a verdade é que nada é transparente para luz de 13 nm. 5- Resolvido tudo isso, as ferramentas serão caríssimas, algo como o dobro das ferramentas atuais, que custam mais de 30 milhões de euros. O natural. Basicamente, a tendência é que todo mundo use EUV dos 15 nm para a frente, com a possível exceção da Intel, que é pirada e tentará manter as máquinas 193 nm até o processo de 11 nm. Isto é... se EUV chegar no prazo. Duvido muito. Planejavam EUV para 65 nm e até antes, há alguns anos... e cadê?

Pelo que disseram esse é o Ontario (Bobcat).

Existem aí uns 4 tipos de IGP AMD no mercado, que são praticamente intercambiáveis para a maior parte dos usuários. Se o cara realmente quer opções, hoje ou amanhã ele terá de comprar uma GPU discreta, não adianta... mas, por outro lado, o Llano vai te dar uma opção bastante interessante... Eu acho que você não viu a pastilha do Llano (a não cortada podrera, não a bonita cortada): aquela bagaça tem mais shaders do que você jamais irá utilizar em um IGP. A parte de GPU é bizonhamente grande em comparação com o resto, dá fácil para chutar uns 60 mm² de IGP, o que permite a qualquer malaco de Lego enfiar um quarto de Evergreen (400 shaders, DX11, 8 ROPs, 20 TMUs e 2 controladores GDDR5 de 32 bits cada que você não irá incluir). Isso equivale a uma 5670, só que com muito menos largura de banda... o que significa que você jamais vai usar os 400 shaders, mesmo com SidePort. Ou seja, para que mais em um IGP? Felipe da Motta, é fácil desativar núcleos de processadores, se necessário. O mais complicado é fazer com que o consumo caia a zero, mas dá para conseguir algo bem próximo disso de forma bem simples.

Desenvolver os chips em blocos, que poderiam ser integrados facilmente... a ideia é ter um bloco de GPU, um bloco de controlador de memória, um bloco de HT, um bloco de SouthBridge, um bloco de núcleo, etc, e poder montar um produto juntando várias combinações dessas coisas. A questão é que qualquer bagaça com uma XBAR/Anel pode fazer isso... só é complicado integrar coisas quando estão ligadas por caches, barramentos especiais e coisas do tipo: fazer uma nova XBAR maior não é nenhum desafio, só ocupa espaço, e um anel é ainda mais fácil. O Llano, que provavelmente será o produto 32 nm SOI lançado esse ano (se algum for), é composto de uma GPU e alguns núcleos Phenom modificados... O Bulldozer provavelmente será lançado em 2011, já com a nova microarquitetura com os módulos de dois núcleos. Normalmente começam a testar, certificar e melhorar em rendimento do processador um ano (GPUs são testadas em meses ) antes do lançamento (pouco depois do "tape-out"). Mas uma coisa é teste interno, isso só vaza se a empresa quiser... testes com parceiros, e depois testes por publicações que costumam vazar alguma coisa.

A GF sempre disse que daria para lançar o processo até Q32010 (em Risk Production), e inclusive afirmou que só estava lançando nessa data para se alinhar com o cronograma da AMD (inicialmente o processo estava marcado para RP em Q12010). Mas a AMD não queria/podia lançar o processador em 2010, talvez por falta de capacidade de produção e maturidade do processo da GF, talvez por problemas de projeto e validação dela mesmo, talvez pelos dois. O processo de foundry de verdade da GF é o bulk... em 40, 28 e 22 nm é que eles começarão a tentar arrancar clientes. Não... o Bulldozer/K11 é bem diferente dos K10 atuais. Não se engane muito com essa história de modularidade, tudo quanto é chip com XBAR é modular, e para uma mudança no nível do Bulldozer o núcleo acaba mudando completamente. Até mesmo mudar uma latência de L1 de 3 para 4 ciclos ou o contrário demanda muito trabalho em cima da microarquitetura... O Bulldozer talvez esteja sendo testado, mas acho que não por pessoas "leakáveis", normalmente esses vazamentos acontecem mais próximo do lançamento. Quem será possivelmente lançado em 2010 é um K10 melhorado, o K11 continua para 2011, se não me engano.

Acho meio difícil que consigam. Mas pelo menos para OEMs e revendores o Llano pode chegar. Natal seria excelente, por causa da sazonalidade, mas aí entra todo um problema de produção... 5 anos não é nada velho para uma microarquitetura x86 nova... está na média, na verdade. O K10/Phenom/K8L/Barcelona demorou uns 3 anos, mas foi uma mudança bem menor e teve a validação acelerada. O Pentium 4 demorou algo como 6 anos, mas era uma microarquitetura complexa, com SMT, de implementação difícil e muitos problemas no desenvolvimento. O Sandy Bridge é uma mudança relativamente pequena, diria, mas mesmo assim acho que está em gestação há no mínimo 4 anos.

A GF sempre falou que estaria com o processo "pronto" até Q32010, a AMD que tinha um cronograma para 2011. Claro que um processo "pronto" não significa produção em larga escala, mas essa é exatamente a área onde os árabes ajudarão bastante... De qualquer modo, com um produto mais testado e conhecido, e produção inicialmente menor, não vejo por que não começar logo a usar os 32 nm... mesmo porque a parte 2 da FAB36/FAB1 só serve para SOI, que apenas a AMD usa...

Aumentar a largura de banda de memórias, usando paralelismo, páginas, bursts maiores e frequências de transferência elevadas, nem é tão difícil... o complicado é que não parece ser o suficiente, e a cada aumento do número de bits estamos caminhando rapidamente em direção a um POWER7 com GDDRxs . Além disso, esse esquema não se presta a integração dos controladores de memória, porque tem muita latência e pouca granularidade... vários controladores de 32 bits com bursts de uma linha de cache não são uma boa ideia.

Isso já acontece com celulares, existe um SoC que controla quase tudo, muitas vezes até processamento de rádio em banda base e alguns circuitos auxiliares de sinal misto (interface entre analógico e digital) e analógicos. Na verdade, a tendência é que isso aconteça também para PCs. A questão é que, segundo a Lei de Moore, o número de transistores que minimiza o custo relativo em um chip dobra a cada dois anos... ou seja, a cada dois anos se torna econômico colocar o dobro de coisas em um chip. Há 10 anos, um Core 2 Quad seria impossível de construir em um chip, e um SoC como os atuais seria no mínimo um chip imenso, lento, de baixo rendimento e altíssimo custo, maior até do que o custo dos vários chips necessários para "substitui-lo" (um processador rápido, uma GPU boa da época, chipset, controlador de display, Super I/O para embutidos, etc). Hoje, um Pentium III seria antieconômico, devido a sua inadequação em aproveitar o grande número de transistores e o desempenho que os processos atuais oferecem... e um DragonBall seria um alfinete escondido no meio do pacote, que custaria mais caro que o chip ... No fim das contas, a tendência aponta que daqui a alguns anos teremos tudo incorporado em um só CI, se a Lei de Moore continuar na ativa. O problema principal é largura de banda e consumo, isso pode obrigar as GPUs topo a continuarem discretas.

Acho difícil, no máximo ajudariam em mão de obra mesmo. Os Phenoms atuais já tem dois controladores de memória, com um canal cada... os Bulldozers com certeza terão dois também. Os Bulldozers G34 terão 4, mas o G34 é apenas para servidores 2S/4S mais "densos". O P4 é um processador complicado de entender, porque ao contrário dos K7/K8/K9/K10/Barcelona/Athlon/Phenom e dos P6/Core/Nehalem/Pentium II/Pentium III/Core Duo/Core ix a arquitetura dele é diferente do "padrão Intel", cheia de "truques" que não poderiam existir na P6, como o "Trace Cache", ALUs rodando ao dobro da frequência, etc. A Bulldozer também será bem diferente do "padrão AMD", ou seja, dos K8s. Por isso muitas coisas ainda são pouco claras... por exemplo, é difícil saber como funciona o esquema dos módulos e núcleos, o que é compartilhado e por quem, e por isso você acaba semi-prevendo uma performance que pode ser bem diferente da real. Da mesma forma que no P4... Sim, e de fato no soquete G34 a AMD aproveitou que o MCM contém dois chips com 2 controladores cada e montou um soquete de 4 canais... mas para consumidores normais eles parecem achar que dois canais são mais que suficientes, e diria que são... Então... com certeza o fato de usar 3 canais não ajuda nem um pouco a conseguir a largura de banda máxima em situações reais. Ao que eu me lembre, para facilitar a implementação, a Intel usou uma solução meio porca (mas de baixa latência e fácil desenvolvimento) na hora de distribuir os dados entre os canais, o que significa que um dos canais deve passar boa parte do tempo parado. No fim das contas, como eu disse, a solução é mais para aumentar a capacidade... Com 4 canais a coisa fica mais fácil... é só usar um comparador de 2 bits para conseguir uma excelente distribuição dos dados nos canais. Mas o 4º canal custa dinheiro em relação a um sistema de 3 canais. De qualquer modo, para conseguir ocupar tudo isso, só com monstros de 8 a 12 núcleos como os Nehalem-EX ou Magny Cours... é largura de banda demais para um processador de desktop.