EduardoS

A oscilação na bolsa de valores foi por causa dos boatos da venda da empresa, as FirePro não estão com essa bola toda...

O que da crédito aos boatos é que o volume foi muito grande para apenas boatos.

O que tira o crédito é que a venda ainda não foi desmentida, comum para frear a alta pré-venda.

NDA não vale para o que é comprado em loja.

Esses OEMs já apareceram aqui no tópico antes, pelo que me lembro.

como nenhum site de review teve a brilhante ideia de gastar 600 dolares, comprar a bagaça e fazer um review contra o i3?

Esqueram de anunciar o lançamento do Trinity desktop?

http://www.newegg.com/Store/SubCategory.aspx?SubCategory=10&name=Desktop-PCs

Ah, falei no sentido técnico (achei que tinha sido claro o suficiente). Como eu e você concordamos, simplesmente não tem como o Read mudar o que já tá tão avançado na rooadmap.

Minha resposta continua a mesma...

Os engenheiros trabalham para alcançar algum objetivo e o objetivo do Dirk claramente era servidores, nesse ponto o BD não precisa de muitos ajustes (talvez mais núcleos, mais cache voltar a um die por processador ao invés do MCM quando mudar o socket, mas nenhuma mudança em especial no núcleo), é mais o marketing que tem que funcionar direito.

Uma das primeiras coisas que aconteceu quando o Reed entrou foi a remoção dos dies com 10 núcleos do roadmap, não posso dizer que foi ele que mandou tirar mas esse die de 10 núcleos é algo que eu esperava do Dirk.

Salvo engano a AMD anunciou acordos com mais de uma empresa para que a licença para CPUs baseados em BDZ fosse por módulo ao invés de por núcleo. Parei de acompanhar isso.

Não conheço nenhuma, sabe de um exemplo?

Até o Steamroller acho que haverão muito poucas mudanças técnicas, até por falta de tempo. Então pode fazer o chute baseado no "What would Dirk Do?" xD que vai ter 99% de chance de estar certo.

O Dirk tentaria salvar o mercado de servidores, colocar mais núcleos, tentar conseguir mais parceiros, não é o que o Reed está fazendo.

Provavelmente Vishera era um projeto que a AMD estava fazendo já que foi alçado ao papel de "novo protagonista" ao invés do Komodo, acho muuuito difícil (para não dizer impossível) que a AMD conseguisse fazer ele do zero. Apesar de que a AMD ter falado na AFDS que conseguiu reduzir bastante o tempo de validação dos designs com uma estratégia cloud.

Em relação a tempo de desenvolvimento a AMD está sempre quebrando records... Mas não é o bastante para uma mudança drástica em um ou dois anos, usando uma fração do orçamento da Intel.

O problema é que o valor de mercado não espressa bem o valor real da empresa, se tivesse alguém interessado em comprar a AMD teria que desembolsar várias vezes mais que o valor de mercado.

E no caso da AMD, o eike pode esquecer, é emrpesa de tecnologia, o governo americano não vai deixar cair nas mãos de brasileiros.

Tudo que você falou parecem ser boas decisões de projeto.

Para o objetivo do projeto...

O que você achar que há de errado com o Bulldozer (e derivados)

O problema é que ele é um processador para servidores com 4 núcleos com vendas baixas em especial porque paga licenças como se tivesse 8 e que está sendo vendido em desktops e notebooks.

Sério, se ele estivesse no lugar certo e sendo vendido da forma correta ninguém reclamaria dele, mas essa bagunça que o marketing fez...

Para desktop acho que falta força bruta, quer dizer, mais ALUs e mais espaço no scheduller para instruções sem referencia a memória.

espera que seja corrigido ou o que você acha que poderia melhorar?

Não acho que tenha alguma mudança ou correção simples que vai trazer um grande ganho de desempenho pro Bulldozer por isso não espero muito, o caso da ALU por exemplo, não é fácil adicionar uma ALU e nem aumentar (muito, aumentar um pouquinho até que é fácil mas não ajuda) o scheduller, se eu fosse o chefe do setor meu objetivo seria aumentar a performance "desktop" para equilibrar melhor o chip e acho que esse seria o caminho, mas não consigo nem imaginar qual o objetivo da AMD hoje, o Dirk Meyer era mais previsível do que o Rory Reed.

O cache L1 continuou sendo 128KB por núcleo até o Phenom II e até o Llano. Mudou foi agora no Bulldozer e já vi outras pessoas falando o mesmo que eu citei: que isso gargalou o sistema.

Já vi muita gente falando muita coisa, sem dados.

O cache L1 é muito mais rápido que o L2 e o L3, aí mesmo que o Bulldozer/Vishera possuam o exagero de 16MB (L2+L3), isso não compensa um L1 minúsculo. E já vi também várias pessoas falando que o Bulldozer não aproveita bem esses 16MB que ele carrega nas costas. Será que pelo menos o Vishera vai aproveitar isso bem? Mas eu ainda acho que deviam aumentar o cache L1.

O L2 é bem aproveitado, o L3 basicamente só existe para sistemas multi-processados.

@EduardoS, qual sua opinião sobre o cache L1 ser write-thru com o L2?

Acho uma decisão pensada em sistemas multi-processados, o buffer de escrita é bem grande (4kB) então em desktops ele deve se comportar de maneira bem parecida com os caches write-back tradicionais.

Só quem pode te dar certeza é quem trabalhou no projeto, essas decisões não são tomadas aleatoriamente, ainda mais nos detalhes fáceis de mudar (ex: write-back ou write-through?), são feitas simulações e com o resultado dessas simulações e nos objetivos isso é decidido, pessoalmente não acho que em aplicações desktop haja alguma diferença significativa entre essas duas políticas de cache e se existe diferença acho que é a favor do write-back, e é tudo "acho" porque não fiz simulação nenhuma, e é isso que me incomoda em 99% das análises sobre o BD que existem na net, não é feita nenhuma simulação e nem coleta de dados, simplesmente olham o resultado de um benchmark sem nem se preocupar com o que aquele benchmark mede, constatam que o núcleo do BD é mais lento que o núcleo do Phenom II e sem qualquer esforço mental extra concluem que a perda de desempenho é porque o cache mudou como se essa fosse a única diferença entre os processadores.

E vou finalizar o post com o que eu acho sobre a filosofia do Bulldozer em sistemas-multiprocessados já que citei essa expressão duas vezes no post sem explicar o porque.

Primeiro o L3, em um sistema multi-processado quando um núcleo vai ler ou gravar alguma coisa na memória (ou botar aquilo no cache dele) ele primeiro tem que mandar uma mensagem para todos os agentes (quer dizer, outros processadores/núcleos) do sistemas de que ele vai ler/gravar naquela região para evitar que dois núcleos gravem na mesma região ao mesmo tempo (coerência, os detalhes ficam pra próxima, alias, acho que já tem um post ou artigo aqui no Clube do Hardware sobre isso), se existem 4 agentes no sistema temos cada núcleo enviando 3X mensagens para outros núcleos e no total 12X mensagens no sistema, se temos 16 agentes temos 15X mensagens por núcleo e 240X mensagens no sistema, se forem 64 agentes 63X mensagens por núcleo e 4032X mensagens no sistema... Um sistema multi-processado com o Opteron pode chegar a até 64 núcleos, se cada núcleo fosse um agente teria mensagem pra !#$%$#!, ao invés disso existe uma hierarquia, o nível mais baixo é o controlador de memória e L3 de cada die que formam um agente, esse agente vai trazer ou gravar na memória quando necessário, também vai gravar alguma coisa no L3 além de usar uma parte deste como filtro para saber para quem ele precisa mandar mensagem ao invés de mandar mensagens para todo mundo, e ele não vai se comunicar diretamente com todo mundo, apenas com os núcleos do próprio die ou com os controladores dos demais dies do sistema, nesse caso o L3 funciona como um cache desse agente, não exatamente como um cache do núcleo (e também acho que o fato do L3 e do controlador de memória rodarem em um clock próprio, diferente dos núcleos não é mera coincidência) e com esse nível na hierarquia já reduzimos o número total de mensagens em ~75%.

Agora quanto ao L2, primeiro, ao invés do controlador de memória falar com 8 núcleos ele só vai falar com os 4 L2 que existem no die, segundo, sendo write-through o L2 estará sempre atualizado e ninguém vai precisar importunar o L1 de dados (que geralmente está ocupado) para obter uma cópia dos dados.

Uma dúvida que tenho: o cache L1 do Vishera continuará pequeno como o do Bulldozer?

E por que mudaria?

Desde 1999, com o Athlon, a AMD tem generosos 128KB de cache L1 por núcleo em seus processadores. Eu enxergo esse cache L1 reduzido e ainda por cima compartilhado como um gargalo horroroso, de forma parecida como foram os Netburst da Intel (embora nesses a situação fosse ainda mais grave).

Processadores evoluem, em 1999 o cache L2 era externo, o scheduler do Athlon original suportava apenas 18 instruções, a unidade load/store não era 100% fora de ordem e por fim, na litografia os "fios" (wires) eram rápidos e os "portões" (gates) lentos, o L1 grande compensava.

Hoje o Llano é um dos poucos processadores atuais (que eu me lembre o outro é o Nano) com mais de 16kB por thread de L1, todos os outros tem 16kB ou menos, ex: Sandy Bridge: 16kB por thread, Power7 8kB por thread, UltraSPARC 2kB por thread, o motivo é o L2 foi integrado ao die, o scheduller aumentou, a unidade load/store é muito mais fora de ordem e por fim, os "fios" ficaram lentos, um L1 grande agora passa a limitar o clock ou aumentar a latência, a tendência é que o L1 continuar em 16kB por thread ou reduzir.

ps: Ao contrário do P4 nenhum processador hoje fica repetindo a execução de instruções quando ocorrem cache-misses, e a grande vítima no caso do P4 era o Hyper-Threading que na época não era prioridade de qualquer jeito, processador antigos com mecanismos diferentes dos atuais não servem como parâmetro.

8.7GHz com o BD original, mas já vi 9.0GHz em algum lugar...

Esperando pelos 10GHz

Se não me engano o decoder do Bulldozer pode decodificar 16 Bytes de código (por núcleo) em até 4 macro OPs por ciclo, ai vai depender da sorte de quantas instruções efetivamente existem nesses 16 Bytes de código (afinal as instruções x86 tem tamanho variável) e se elas são cobertas pelo fast path ou se terão que ir pro microcode.

O "fetch" é de 32 bytes, em um ciclo para um núcleo, no outro ciclo para outro, na média 16 bytes por ciclo por núcleo.

Eduardo, tem um comparativo da AnandTech entre os dois processadores aqui, sendo que em desempenho single thread a diferença é de 74%: http://www.anandtech.com/bench/Product/434?vs=551

As vezes as medidas estão erradas, ou quem as tirou errou, ou o equipamento de medição apresentou alguma falha ou... Enfim, erros acontecem, não sei exato quanto o IB é mais rápido que o SB, mas tenho certeza que o i7 3820 é mais rápido que o i3 2100 e sabendo disso, se o benchmark me mostra um resultado diferente posso dizer sem medo de errar que tem algo errado nesses números:

http://www.anandtech.com/bench/CPU/38

Acho que o Contiusa está falando desse link aqui: http://www.it.anandtech.com/show/5057/the-bulldozer-aftermath-delving-even-deeper/9

O IPC exageradamente baixo do Bulldozer pode indicar (mais um) erro na medição.

E desempenho "por core" não importa quando a definição, tamanho ou threads de cada "core" variam entre os dois processadores, um módulo do Bulldozer é comparável a um núcleo do Sandy Bridge, os dois tem mais ou menos o mesmo tamanho.

O desempenho multi-thread é parecido com leve vantagem para um ou outro dependendo do benchmark, o calcanhar de aquiles do Bulldozer é o desempenho single-thread que é muito inferior ao do Sandy Bridge.

Denis, existe uma diferença bem grande entre o que o Fuad acha e o que a AMD divulga, oficialmente a AMd ainda não divulgou nada sobre os Vishera.

E pessoalmente duvido que o Fuad esteja certo.

Gostaria muito de uma analise profunda da arquitetura BDZ ( alguem indica um ? ) para entender aonde foi a mancada do BDZ ( srsrs alem de usar soft edge ).

Até o momento a melhor é a do Agner Fog

Core i7 3770K tem 1,4 bilhão de transistores 22nm ( apesar que internamente nem tudo é 22 nm )

Quem disse?

FX-8150 tem 1,2 bilhão de de transistores a 32 nm e se fosse 22nm seria possivel chegar a 1,7 ou 1,8 bilhão quem sabe.

Enquanto a AMD não contratar alguém que saiba contar não vai dar para acreditar nos números de transistores que eles divulgam...

De qualquer jeito, mais núcleos ou mais cache não vão melhorar tudo o que BD precisa, não vai ser fácil assim.

Pois é....

Anyway, sorte da moto, e a nokia já tem dona, a M$. A rim ainda não se sabe, talvez o fígado compre...

A RIM já se vendeu para a MS.

Nem sabia que dava para comprar Bobcat sem placa-mãe...

O Kaveri usa o núcleo Steamroller que é a evolução do Piledriver

"Os itens são bens de capital (máquinas e equipamentos para produção) e bens de informática."

será que vamos ser beneficiados MESMO?

Não, os bens de informática são só alguns componentes eletrônicos e equipamentos para a área médica, meros consumidores não serão diretamente afetados.

neste desempenho capenga, não teria um dedinho do FPU?

O problema é esse dedinho pequeno...

No Sandy é quase 100% sem HT.

E quase 0% entre um quad core com HT para um quad core sem.

O Cinebench tem um ILP alto, é só olhar pelo Sandy Bridge, com uma única thread ele já quase esgota os recursos da FPU, ai com duas threads o ganho é pequeno.

No Bulldozer com duas threads por módulo o desempenho no Cinebench até que não é ruim, um módulo tem basicamente os mesmos recursos de um núcleo do Sandy Bridge então o desempenho para o módulo está dentro do esperado, mas rodando apenas uma thread o desempenho do Bulldozer é muito ruim, o software tem ILP, a FPU tem recursos sobrando mas mesmo assim ele é lento, aqui o Bulldozer falha em extrair o ILP existente, se ele conseguisse extrair esse ILP o desempenho single-thread no Cinebench aumentaria muito mesmo com a "Produtividade multi-core" caindo, ah, extraindo melhor o ILP o desempenho do módulo com duas threads também aumentaria mas bem menos que o desempenho com uma thread, e não, o single-thread não chegaria no IPC do SandyBridge, o cluster de inteiros não tem unidades de execução suficientes para isso, mas chegaria perto e o clock mais alto poderia resultar em um desempenho competitivo.

ps: Tudo o que escrevi nesse post se refere ao Cinebench, outros aplicativos podem se comportar de forma diferente.

ps2: A maioria dos outros aplicativos são diferentes, o Cinebench é uma exceção.

Me baseando do Cinebench R11.5, um que melhor mostar a Produtividade do chip:

FX-8150 => Single 1pt, Multi=> 6pts, isso é bem interessante..BDZ perde apenas 25% de escala em Multi-threads (8/6).

Especificamente nesse caso não é uma vantagem, é um problema, a escalabilidade muito boa (o que você chamou de "Produtividade") ai é o resultado de um desempenho single-thread muito ruim.

Só lembrando... É boato, nada oficial confirmado sobre os Vishera...

A MIPS é inexistente em servidores, ela só compete com a ARM em embarcados e está rapidamente perdendo espaço.