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.

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

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.

Não conheço nenhuma, sabe de um exemplo? O Dirk tentaria salvar o mercado de servidores, colocar mais núcleos, tentar conseguir mais parceiros, não é o que o Reed está fazendo. 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.

Para o objetivo do projeto... 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. 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.

Já vi muita gente falando muita coisa, sem dados. O L2 é bem aproveitado, o L3 basicamente só existe para sistemas multi-processados. 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.

E por que mudaria? 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

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.

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.

Até o momento a melhor é a do Agner Fog Quem disse? 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 é....

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

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.

O problema é esse dedinho pequeno... 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.

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.