aziebert

estão falando que o BD quebrou o recorde mundial de frequencia ( atualmente em 8.3ghz) detalhes amanha. http://www.xtremesystems.org/forums/showthread.php?265710-AMD-Zambezi-news-info-fans-!&p=4947969&viewfull=1#post4947969 http://hwbot.org/benchmark/cpu_frequency/

Acho que o artigo em questão é esse Preview do SB-E: http://www.tomshardware.com/reviews/core-i7-3960x-x79-performance,3026.html

O mestre Hans já detonou esse teste:

Fiz uma pergunta rápida pro tio JF e ele respondeu: Como eu suspeitava, com o Turbo ligado o consumo tende a encostar na TDP.

@evandro se o Yield dos Llano é 50%, tem muito chip meia boca que pode virar X2. Ainda não justifica fazer um chip próprio pra isso.

@soullforged lembre que a AMD pode ser tão gananciosa quanto a Intel. Quanto ela detinha a coroa do desempenho, eram os FX que custavam 1000 dólares. E quando saíram os X2, o mais barato ainda custava mais de 300.

@sirroman não só o do eyefinity, ainda estou com esse artigo entalado na garganta: http://www.xbitlabs.com/articles/cpu/display/core-i3-2100t.html Se eles já tinham testado tanto a E-350 da Gigabyte quanto a da MSI e viram que a MSI consumia menos energia, porque usaram a GB no comparativo!? @jonny_br Piledriver é um refresh na arquitetura Bulldozer. Tanto o Komodo (CPU com até 10 núcleos, PCIe integrado, possivelmente 3 canais de memória) quanto o Trinity (APU com 4 núcleos e GPU VLIW4) terão núcleos Piledriver.

Eu parei de levar o Xbitlabs a sério faz tempo. Os caras estão tendenciosos demais, vivem fazendo notícias "repetidas" (recontando coisas que todo mundo já sabe, sem trazer nada novo) e basta sair um rumorzinho qualquer, eles já tomam como verdade e soltam como notícia... Parece que estão desesperados pra atrair audiência... Essa história do Komodo sair no AM3+ é um desses rumores. Seria legal se fosse verdade, mas eu duvido. A AMD tem planos agressivos de integração entre CPU e GPU (integrada ou discreta), como finalmente unificar o endereçamento de memória, etc. Para isso será necessário integrar o controlador PCI Express no processador (o que está/estava previsto para o Komodo). Pelo que eu entendi, a Global Foundries pretendia parar de fazer SOI já em 28nm, mas alguns clientes protestaram, então ele será opcional. Quem quiser, basta pagar os royalties pra IBM que fica tudo certo. O fato do Komodo sair com núcleos Piledriver e ainda em 32nm aponta que há certas deficiências na arquitetura Bulldozer que precisam ser revistos com certa urgência. Mas não me surpreenderia se ele já saísse em 28nm. Mas isso deve ficar pro final de 2012.

Felizmente não. Nos i7 o Windows sempre aloca processos ao primeiro thread de cada núcleo antes de começar a alocar processos ao segundo thread de cada núcleo. No BD, por enquanto, é cada um por si. Como se todos os núcleos fossem independentes (como em um Phenom II). Esse comportamento é um pouco "menos pior" para o Bulldozer que se ele usasse a mesma regra do i7, mas ainda não aproveita o Turbo corretamente, daí a necessidade do patch. Se fosse só isso, um BD em overclock com Turbo desligado já deveria ter um excelente desempenho. Mas meu palpite é que ainda há outros problemas. Além da questão da poluição do cache L1I que comentaram, vi gente falando que muitos programas, ao detectar que o processador é AMD, tomam um rumo "otimizado para AMD" que prevê um cache L1D de 64KB por núcleo (afinal, desde o primeiro Athlon é assim), mas o BD tem apenas 16KB de cache L1D por núcleo. E pra resolver isso só recompilando o programa com um compilador que implemente um caminho próprio para a arquitetura do Bulldozer...

Exato, mesmo com todos os núcleos em uso, se o uso for baixo, ele consegue subir um pouco a frequência. Mas para chegar ao clock máximo só com pelo menos a metade dos módulos ociosos e completamente desligados (em estado C6), então ele pode jogar o clock dos módulos em uso lá pra cima. Só uma coisa, não é o front-end que "direciona" instruções para um núcleo ou para os dois. Ele recebe as instruções de ambos núcleos, que serão necessariamente executadas pelos dois núcleos. (se uma instrução é do núcleo 1, ele vai mandar para o núcleo 1) Agora, é o SO que escolhe qual núcleo (de qual módulo) vai executar qual thread. Daí a necessidade de uma atualização para o Windows sabe qual núcleo pertence a qual módulo e em que situações é mais interessante agrupar os processos ou espalhar.

Depois que o Windows for atualizado, na mesma situação apenas uns 4 núcleos estarão com quase 100% de carga enquanto os outros permanecerão completamente desligados, assim o processador pode fazer Turbo nos núcleos que estão trabalhando.

@johannesrs A discussão está em torno da otimização agendador de processos do SO (que precisa ser atualizado para entender que é melhor concentrar procesos em poucos módulos, para manter os outros desligados e se beneficiar do Turbo) e poluição do cache L1I (de instruções, que é compartilhado por ambos núcleos dentro do módulo), onde entradas de instruções de um núcleo invalidam entradas de instruções do outro núcleo, fazendo que estas tenham que ser carregadas novamente (na melhor das hipóteses a partir do cache L2, na pior a partir da memória). Parece que já foi liberado um patch pro Linux. A MS deve ter um patch para o Windows pronto antes do lançamento.

Opa, obrigado pelas boas vindas. Dei uma procurada por esse bulldozer oc contest e nao achei nada... Parece que a primeira regra dele é: "you don't talk about the bd oc contest"

Mas de 6 (1 núcleo) para 36 (6 núcleos) E de 10 (1 núcleo) para 40 (4 núcleos) ambos escalaram de forma linear (100% por núcleo). WTH? Closed doors contest?

Buenas, acho que o teste do compilador é esse: http://www.dell.com/content/topics/global.aspx/power/en/ps3q02_arrian?c=us&l=en&cs=22 Aqui tem um outro artigo interessante sobre escala de desempenho de código sequencial e paralelo vs consumo, etc: http://software.intel.com/en-us/articles/the-new-era-of-tera-scale-computing/ Enjoy