EduardoS

Na minha opinião só Sanjay Jha (Motorola) se salva nessa lista, antes falaram de um cara da Apple que parecia mais ineressante... Não lembro o nome agora e estou com preguiça de procurar... Mas enfim, qq tem na cabeça dos editores da EETimes? A maior parte da lista nunca vai ser um CEO e outros não trabalhariam na AMD nem sob tortura...

Ele devia estar rodando a algo próximo de 5GHz, talvez nem tanto, mas provavelmente acima dos 4 GHz, aqui a grande vantagem em cima dos Phenom II é que o BD chega aos 4GHz com um pé nas costas e sobra folego para subir ainda mais. Se for verdade o resultado é excelente para a AMD, se contarmos os núcleos do jeito que a Intel conta o Bulldozer de 8 núcleos é um quad core, mesmo em tamanho de silício dois núcleos BD tem o mesmo tamanho de um núcleo SB. A desgraça da AMD é o resto die que deve ser significativamente maior que o SB, isso da uma folga para a Intel.

Pessoal... Se fosse pressão de acionista as ações estariam subindo... Os acionistas não gostaram.

O original tinha apenas 8, não era RISC por isso não entra na minha listinha... 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. RISCs de console são processadores em ordem sem renomeação.

O Dreamcast foi o último console com processador RISC e 16 registradores ou menos, os que vieram depois tinha de 32 a 128 registradores, se isso for argumento continua sendo argumento contra x86-64...

Não, pela não necessidade de desenvolver um processador específico para jogos e nem precisar portar um SO e bibliotecas para uma arquitetura nova.

Argumento a favor? Quase todas as outras opções tem mais registradores... O maior argumento a favor é o custo de desenvolvimento do console, e é um p**a argumento.

Acho que o que ele falou é que' date=' a tendência é que, com o tempo o driver open source seja melhor que o proprietário. Na minha opinião quando um driver open source supera o proprietário é um claro sinal de que o fabricante deveria dar mais atenção e investir mais em seus drivers... Ele não se referiu a aplicativos single-thread...

Isso sem contar o L3' date=' o L3 deve ter mais meio bilhão, uns 1350 milhões de transistores por die. A versão de 12 núcleos é na verdade a versão de 16 núcleos, vai ter o mesmo número de transistores, a versão de 16 núcleos por sua vez são dois dies da versão de 8 núcleos, un 2,7 bilhões de transistores. Não, a culpa é da litografia, o Gulftown usa 32nm, o Deneb 45nm, o primeiro é duas vezes mais denso.

Pensei nisso agora... E uma fusão? A GF passa a ser 50% ou mais americana e as fabricas da IBM passam para a GF.

Há controvérsias! Mas que diferença faz para os processadores da AMD se dragões tem sangue quente ou frio?

Pessoal... Cuidado com boatos... Ainda mais vindo de tabloids on-line... A AMD não (segundo a tradição...) comenta boatos isso da margem para eles cresceram até o ponto de prejudicar a empresa e força-los a desmentir e acabam revelando a verdade, muitos boatos podem ser criados apenas com o intuito de arrancar alguma verdade quando o boato for desmentido. Uma fonte muito confiável dizer que a Apple não vai usar processadores AMD para depois uma outra fonte muito confiável dizer que vai parece ser o caso.

Bem... É novo em relação aos processadores atuais mas a AMD já repetiu isso 500 vezes, o JF sozinho foi umas 495 e só confundindo mais.

Encheu linguiça... Não aguento mais ler linguiça sobre essa FP e nem pessoas perguntando "Ahn? O que foi que ele disse?". O trabalho do JF é falar muito e dizer pouco, trabalho que ele executa com perfeição, de quebra ainda deixa um monte de gente confusa...

Eles tem a grana, mas duvido que tenham vontade de desembolsar.

Um falou maçã o outro respondeu pêra, se o JF não viajou na maionese ao menos surfou na salada de frutas...

A grosso modo, o "The Great Buana" falou uma preocupação real quanto a usar uma arquitetura como o Bobcat para servidores, o "John Fruehe" entendeu errado e viajou na maionese... E detalhando o que o "The Great Buana" falou, ele disse que olhando um núcleo individualmente o Bobcat parece bom para servidores, mas para ficar competitivo precisaria de muitos núcleos do Bobcat e muito silício para ligar todos eles, todo esse silício extra pode tirar a vantagem que o Bobcat tinha inicialmente. De qualquer jeito, onde pegou os quotes?

Quem sabe no proxímo boato descobrem o tamanho do die... Mas esse pessoal ta demorando hein?

Depende... Não é assim que funciona...

Quando a GPU é rápida ela é muito rápida, mas quando ela é lenta ela é muito lenta... Deixa as FP no processador também, para a GPU deixe apenas os vetores, inteiros e de ponto-flutuante. A Intel jura que não mas é a maioria dos casos.

Tem uma área onde as CPUs são imbatíveis, algorítimos puramente sequenciais ou com um pouco de paralelismo mas muita dispersão, que é o caso do que a maior parte dos computadores no mundo faz o que vetores fazem (SSE e AVX) é aumentar o desempenho de algorítimos com muito paralelismo, mas nessa área as CPUs são muito ruins e as GPUs muito boas, SSE ainda é relativamente barato, AVX é caro, com a AVX a Intel começa a sair do terreno onde as CPUs são muito boas e querer brigar em um terreno onde as GPUs são muito boas. O risco disso é CPUs caras de fabricar porque incluem uma extensão que não serve pra nada... Mas não, GPUs não vão aposentar as CPUs que nem um carinha de olhos puxados sonha.

Os 256 bits que não foram adotados pela AMD e nem são unanimidade na Intel, mas a Intel não tem uma GPU que preste é ou isso ou entregar o mercado para a nVidia e AMD. Já as FMAC eram um tanto quanto óbvias, só deus sabe porque a Intel não adicionou antes... ps: Ainda da para salvar a x86, cria outro prefixo tipo AVX endereçando 32 registradores, os 16 mais baixos são as metades menos significativas dos registradores AVX, os 16 mais altos as metades mais significativas, precisão quadrupla e temos CPUs que complementam GPUs ao invés de tentar competir (em vão) no mundo paralelo.

Sim. Mas por favor... Chega de falar nesse triple channel... Nem as versões iniciais do Sandy Bridge vão suportar isso...

Se me lembro bem na medição foi 11, alguns reviewers "esqueceram" de considerar o Turbo na medição... Boa pergunta, acho que já vi diagrama das duas coisas...

Não é bem que eu ache que foi um retrocesso, só uma cosa que me deixa com o pé atrás, a grande vantagem dos processadores fora de ordem é lidar com latências imprevisíveis mas ainda assim, tem limite, o scheduler não consegue detectar mudanças na latência esperada das instruções tão rápido, o que pode acontecer com um L1 muito pequeno é o scheduler não agendar de forma muito eficiente deixando bolhas no caminho, as vezes um L1 maior com latência maior fica mais rápido justamente pelo scheduler conseguir agendar as instruções de forma mais eficiente, claro, aqui também existem limites, um L1 com latência de 20 ciclos vai ser lento e não tem muito o que o scheduler, as vezes precisa assumir o risco de mais "misses" para não aumentar muito a latência, se ele rodasse a uns 20GHz e só tivesse 8kB de L1 acho que ainda seria aceitável, nesse clock mesmo com um L1 pequeno também acho que seria difícil uma latência menor do que uns 10 ciclos, o agendador ainda teria que fazer mágica. Mas... Isso é um problema que a AMD deve ter quebrado a cabeça para resolver, o BD foi feito para rodar em um clock maior que o K10 e para isso precisavam fazer alguns sacrifícios e resolver alguns problemas, o L1 é um desses problemas e não é fácil de resolver.