aziebert

A coisa está feia: X6 vs FX, ambos num watercooler fortíssimo com um belo overclock e o FX foi pouco melhor ou um bocado pior: http://www.xtremesystems.org/forums/showthread.php?276002-Compare-1090T-and-FX-8150

O Windows XP fazia isso, o Windows 7 não faz mais. Na dúvida basta fixar a afinidade para ver se muda alguma coisa... Quanto ao sistema de proteção do VRM, com o processador exigindo uns 300w é bem capaz dele chegar a uns 100ºC mesmo. O problema do overclock no Bulldozer é que além do consumo absurdo, ele precisa de temperaturas muito baixas. Manter um monstro desses a 60ºC é tarefa pra radiador de carro... Interessante o artigo, mesmo a 2560x1600 a maioria dos jogos ainda é CPU bound (também, com um 3-Way Crossfire de 6970 é meio difícil ter um gargalo de GPU). Onde realmente havia um gargalo de GPU a plataforma AMD foi capaz de tirar meia dúzia de FPS a mais, porque o AMD990FX tem 32 linhas PCIe "nativas", enquanto ASUS Maximus IV Extreme-Z usada no 2500k tem um nForce200 para oferecer 32 linhas PCIe a partir das 16 linhas que vem do processador (o que adiciona um pouco de latência na comunicação com as placas). Interessante também observar o teste de consumo. O sistema AMD obteve um melhor consumo em idle, provavelmente por causa do nForce200 na placa Intel. E o consumo foi bem próximo em full (rodando 3DMark 06), mas aqui como eu observei uma vez, acho que uma fatia maior do consumo correspondia às placas de vídeo no sistema Intel, simplesmente porque estavam em maior atividade (pois o processador era capaz de fornecer mais frames para as placas). A título de curiosidade, gostaria de ver o mesmo teste feito com um FX-4100 @ uns 5GHz e um i7 980x (pois o X58 oferece 32 linhas PCIe sem ajuda do NF200).

Meu, tem alguma coisa muito errada nesse processo de 32nm: http://www.legitreviews.com/article/1741/17/ O Llano A8-3850 de 2.9GHz consome pouca coisa a menos que o X4 980 (3.7GHz). gntdaniel, o Llano é uma APU (CPU e GPU no mesmo chip). Tem 4 núcleos K10 (como um Athlon II X4) e uma boa GPU, uma Radeon HD 6550. O A8 é a versão completa dele (4 núcleos e GPU com todos os 400SPs). O A6 é uma versão ligeiramente capada, com clocks um pouco menores e GPU com 320 SPs. Abaixo vem o A4, com apenas 2 núcleos e GPU com 160SPs. As placas mãe para ele tem socket FM1 (totalmente diferente do AM3) e custam em média o mesmo que as placas AM3 com chipset 880G.

Sim, a producao de Phenom ja deve ter parado. O foco agora é o Llano.

Nav o que o Eduardo quis dizer é que a ALU também executa algumas instruções de ponto flutuante, da mesma forma que a FPU também executa algumas instruções de inteiros. Grande parte das SSEs e AVX são para manipulação de inteiros. Essa distinção não deveria existir mais, hoje temos instruções simples que são executadas pelas ALUs e instruções mais complexas, que são executadas pelas FPUs; independente de lidarem com inteiros ou ponto flutuante. Isso que permitiu à AMD dobrar a porção ALU e fazer um segundo núcleo dentro do "módulo"; são necessários muito menos transistores para a porção ALU que para a porção FPU. E sim, o frontend já manda direto pra FPU as instruções que devem ser executadas lá. Vale ressaltar que é quase um milagre que um núcleo Bulldozer com apenas 2 ALUs (contra 3 de um núcleo Phenom) e com arquitetura de pipeline longo ainda apresente quase a mesma IPC de um núcleo Phenom. Seria um verdadeiro milagre se conseguissem aumentar a IPC. Lembrem que o P4 só superou o P3 com 60% a mais de clock (1,6GHz contra 1GHz), aqui estamos falando de clocks praticamente idênticos (3.6GHz no BD contra 3.3GHz num X6, por exemplo, a diferença é de apenas 9%). Todo mundo está lembrando agora do Pentium 4 e seus problemas. Mas bem que a AMD poderia aproveitar mais algumas das (poucas) boas ideias da arquitetura. Como as ALUs "double pumped" (as ALUs do P4 trabalhavam ao dobro do clock do núcleo), isso já daria uma bela ajuda. E quem sabe também o trace cache, pois já que o frontend tem que decodificar instruções dos dois núcleos, se algumas instruções já estivessem decodificadas no trace cache, poderia pular etapas. Outra coisa, aposto que esse cache L2 enorme (2MB por módulo), foi uma decisão desesperada para tentar melhorar a IPC (isso e para agradar o pessoal dos servidores, seu principal público alvo). Os processadores AMD sempre se viraram muito bem com pouco cache (lembram que o Duron tinha apenas 64KB de L2 e rendia muito bem perto do Athlon XP Barton com 512KB ?). Portanto, EU ACHO, que seria melhor reduzir o cache L2 do BD, para uns 512KB por módulo. E torná-lo inclusivo no L3. Isso não deveria afetar muito a performance e além de reduzir bastante o tamanho do chip, ajudaria muito a reduzir o consumo. Não só por reduzir o número de transistores ativos, mas geraria boas oportunidades no gerenciamento de energia (por exemplo, o módulo poderia entrar e acordar do estado C6 com mais facilidade).

Nav, concordo com a réplica do Blameless, esse Xaero viajou na maionese. O sistema operacional vê 8 núcleos, cada um desses núcleos tem suas próprias unidades de inteiros. Até aí tudo bem. Cada dois núcleos compartilham uma porção FPU do módulo a que pertencem. Então se o SO aloca processos que usam bastante FPU para dois núcleos do mesmo módulo, haverá um gargalo pois a FPU terá que executar as instruções de dois threads na medida do possível. A porção FPU não é uma entidade separada dos núcleos (não existe um terceiro núcleo só de FP dentro do módulo), mas sim virtualizada ao sistema operacional, como se cada núcleo tivesse suas FPUs, porém a porção FPU de cada dois núcleos é a mesma (do módulo onde eles estão). Não sei se isso vai ajudar ou atrapalhar, mas aí vai. Imagine um núcleo com HT. Agora dobre o número de ALUs e reserve cada conjunto (cluster) para uso exclusivo de um dos threads. A porção FPU não teve esse tratamento, então deve executar as instruções de ambos threads na medida do possível. Pronto, isso é um módulo Bulldozer. Ao meu ver, o problema é que em vez de desenvolver um núcleo com 4 ALUs, depois duplicar o número de ALUs para que cada núcleo tenha 4. A AMD desenvolveu um núcleo com 4 ALUs e depois restringiu o uso de apenas duas para um núcleo e as outras duas para o outro núcleo e chamou isso de módulo... Nada contra essa organização, que é muito eficiente. O problema é que a porção de inteiros de cada núcleo ficou muito fraca (um pouco mais fraca que a de um núcleo Phenom, mas anos luz atrás do SandyBridge). E mesmo com a arquitetura de pipeline longo, o processo de fabricação não está colaborando em termos de clock para compensar essas fraquezas.

Nav, não é possível desligar individualmente um núcleo dentro de um módulo, apenas o módulo todo. O ajuste no BIOS para desativar um núcleo dentro do módulo apenas "esconde" o núcleo do SO, ele continua ativo e gastando energia (pouco, por estarem ociosos, mas ainda gastando). O Windows 7 não faz distinção entre os núcleos do Bulldozer, pra ele é como se todos os núcleos fossem núcleos completos. Então pra ele tanto faz qual núcleo escolher na hora de alocar um processo. Então a eficiência do Turbo depende unicamente da sorte. Vamos supor que o sistema está ocioso e eu abro um programa que usa exatamente 4 núcleos (ou 4 programas que usam apenas 1 núcleo, tanto faz). Se o Windows jogar esses threads em dois núcleos de um módulo e em dois núcleos de outro módulo, ótimo, o Turbo pode atuar com eficiência máxima. Mas como pro Windows todos os núcleos são iguais, as chances disso acontecer são relativamente pequenas. É bem provável que um processo caia em um núcleo de um terceiro módulo, assim o processador não pode aproveitar o estágio máximo do Turbo. O Windows 7 já sabe aproveitar corretamente processadores com HT. Mas só o Windows 8 saberá aproveitar corretamente o Bulldozer.

Lembre que o pessoal do Xbit labs mede o consumo do processador com um amperímetro no conector ATX12v e o consumo do PC todo somando as correntes na saída da fonte. Praticamente todos os outros sites medem o consumo do PC todo antes da fonte (portanto o valor lido leva também o que a fonte desperdiça). Ambos métodos são válidos, pois medindo antes da fonte tem-se o valor real que a máquina consome da tomada (e os dados são consistentes porque todas as máquinas são testadas com a mesma fonte). Mas medindo depois da fonte tem-se o consumo real da máquina, já que a eficiência da fonte varia conforme a carga... Sim, mais um detalhe. O Xbitlabs usa o LinX para estressas os processadores para o teste de consumo. Ele é praticamente um vírus térmico para a porção FPU do processador... mas é provável que a porção de inteiros do Bulldozer estava sendo pouco utilizada. Acho estranho eles não terem se atentado a esse detalhe. Outros sites costumam usar o Prime95 para estressar o processador, que carrega mais a porção de inteiros. Mas acho que o ideal seria medir no Cinebench. Vocês viram se algum site testou também o consumo em jogos? De preferência com uma placa de vídeo single GPU (Radeon HD 6970 ou GeForce GTX 580)? Jonny, não aposte muito nesse consumo exibido pelo HW Monitor. Assim como nos i7, ele mostra um valor estimado, o mesmo que é usado pelo processador para ver se ainda há folga em relação à TDP, para ver se dá pra fazer Turbo ou não... Os sensores que o Llano usa para estimar o consumo já são muito mais precisos que os do i7, mas ainda não é o consumo real (não leva em consideração o vcore real, nem mudanças no clock base (overclock), apenas a atividade do processador...). O AIDA64 é capaz de ler o consumo real do processador, se sua placa mãe tiver um amperímetro no VRM.

Eu me confundi (ou vi os 20% em relação ao DIE todo), mas o Nav trouxe a informação correta (slide da AMD, se é que esses ainda tem alguma credibilidade) Quanto ao HT, segundo a Intel é menos de 5% no tamanho total do DIE http://software.intel.com/en-us/articles/how-to-determine-the-effectiveness-of-hyper-threading-technology-with-an-application/ Jonny, quanto ao consumo em idle, o BD tende a ser bem mais econômico que os anteriores por contar com Power Gates para desligar completamente os núcleos inativos e (finalmente) o CPU-NB pode ter seu clock reduzido. Quanto ao chipset, mesmo o 990FX é bem econômico, tem TDP de apenas 9.6w, mais uns 6w do southbridge. (Tenho que verificar isso, já vi uns falando em 9w e outros em 19w para o 890FX/990FX. Acredito mais nos 9w, o 890GX com GPU e tudo não passa de 22w). A vantagem dos SandyBridge ou do Llano, por exemplo é que o northbridge está integrado dentro do processador, portanto além de ser feito em 32nm (o 990FX é feito em 65nm ainda), seu consumo faz parte da TDP do processador. Para comparação, a TDP do X58 é 24w.

Não sei citar a fonte agora, mas acho que a própria AMD falou isso. Me refiro ao tamanho do núcleo/módulo. No die todo a diferença é menor porque há outros componentes de tamanho constante. edit: Como vejo que ainda há muita confusão quanto aos nomes, segue um resuminho: Bulldozer = arquitetura AMD de pipeline médio/longo com núcleos organizados em módulos (um módulo = dois núcleos de inteiros e porção FPU compartilhada para ambos núcleos). Orochi = chip com 4 módulos Bulldozer Zambezi = versão desktop do Orochi (é o que vem dentro dos FX) Valencia = versão servidor do Orochi (Opteron série 4000 socket C32) Interlagos = Opteron de 16 núcleos (dois chips Orochi) socket G34 Piledriver = atualização da arquitetura Bulldozer Llano = APU (CPU e GPU no mesmo chip) com 4 núcleos K10 (Phenom) e GPU de 400 SPs VLIW5 (arquitetura das Radeon até série HD 6800) Trinity = APU com 2 módulos Piledriver e GPU de arquitetura VLIW4 (Radeon HD 6900) Vishera = CPU com 4 módulos Piledriver Bobcat = arquitetura AMD de baixo consumo Ontario = APU de baixíssimo consumo (9w) com 2 núcleos Bobcat e GPU de 80 SPs VLIW5 Zacate = APU de baixo consumo (18w) com 2 núcleos Bobcat e GPU de 80 SPs VLIW5 (detalhe Ontario e Zacate são o mesmo chip)

Um último detalhe que só prestei atenção agora. Ali no artigo do site hardware.fr também compararam o ganho proporcionado pelo HT nos Sandy Bridge (diferença entre um i5 e i7 no mesmo clock), os dois núcleos a mais num Phenom II X6 em relação a um X4 e o "CMT" (clustered multithreading) do Bulldozer (esse esquema de ter dois núcleos de inteiros dentro de um módulo), a comparação foi feita rodando os testes com o segundo núcleo de cada módulo desligado ou com tudo funcionando normalmente. Isso fecha a conta do custo benefício. No SandyBridge, o HT custa 5% a mais de transistores e traz em média mais 20% de desempenho. No X6 os dois núcleos a mais custam 50% a mais de transistores e trazem em média 40% a mais de desempenho. E no Bulldozer duplicar os núcleos de inteiros custa 20% a mais de transistores e traz em média 50% a mais de desempenho. (* valores aproximados)

Acho que o segundo cluster de inteiros era +20% de transistores = 80% mais desempenho. +5% de transistores = 20% de desempenho é o Hyper Threading. Não necessariamente otimizados para mais que 4 núcleos, mas podem se beneficiar de alguma forma de mais núcleos. Quanto a espalhar os processos pelos núcleos disponíveis. O Windows 7 já "estaciona" os processos nos núcleos, em vez de ficarem pulando de núcleo em núcleo. Isso resolveu o problema da perda de desempenho com o Cool n' Quiet no Phenom I, onde os núcleos tinham clock independente. No caso do Bulldozer, por enquanto o Windows não faz distinção entre os núcleos. Pra ele todos são núcleos individuais, como os núcleos de um Phenom, por exemplo. Nos processadores com HT (i7 e afins) o Windows vai alocando processos ao primeiro thread de cada núcleo antes de usar o segundo, para evitar perdas de desempenho. Mas no Bulldozer o ideal é que ocorra o contrário: que o Windows ocupe o primeiro e o segundo núcleos de um módulo antes de acordar os demais, pois assim pode se beneficiar mais do Turbo. Muitos ficaram com medo disso, achando que o desempenho de um núcleo (dentro de um módulo BD) seria muito afetado quando o segundo núcleo do mesmo módulo também estiver trabalhando. Mas não, o impacto é pequeno. Um programa que usa dois núcleos por exemplo, usando os dois núcleos de um módulo, roda pouca coisa mais lento que se estiver usando o primeiro núcleo de um módulo e o primeiro núcleo de outro módulo. E mesmo sem considerar o Turbo ou o desligamento de módulos, usando os dois núcleos de um módulo se gasta menos energia que usando dois núcleos de dois módulos (um de cada). Então podemos aproveitar os recursos de gerenciamento de energia avançados em nosso favor. Portanto ao usar apenas dois núcleos em um módulo, os demais módulos podem permanecer completamente desligados e o Turbo Core pode aumentar o clock do módulo que está trabalhando. Essa diferença de clock não só deve compensar o pequeno impacto no desempenho (pelos dois núcleos terem que brigar por recursos dentro do módulo), como deve proporcionar um desempenho melhor que ao usar um núcleo de cada módulo a um clock menor. @Nav, por desativar núcleo de um módulo me referia à opção de desativar o segundo núcleo dentro de um módulo; através de um ajuste no BIOS da placa. Tornando um FX-8 em um processador quad-core simples (4 módulos, total de 4 núcleos); seria como desativar o HT num i7, tornando-o um i5. Tudo bem, pode-se fazer isso justamente para investigar a diferença de desempenho entre rodar um programa usando apenas um núcleo de cada módulo (assim o núcleo tem o módulo todo para si) e usando ambos núcleos de um módulo (ou alguns módulos). Por exemplo, para rodar um programa que utiliza 4 núcleos em 2M/4C ou 4M/4C. Mas não vejo nenhuma vantagem prática em fazer isso, pois se estaria abrindo mão de metade do potencial de inteiros em programas multithread (que, como vimos, vários podem se beneficiar de mais de 4 núcleos). Fazendo isso também não se ganha nada em programas single thread, pois se o segundo núcleo de um módulo não está trabalhando, ele não atrapalhará o primeiro. Como levantaram no teste do site hardware.fr (tabela anexa abaixo) artigo original (em francês) aqui: http://www.hardware.fr/articles/842-9/efficacite-cmt.html Observem que os únicos casos onde se teve um pequeno ganho de desempenho ao desativar o segundo núcleo de cada módulo foi em alguns jogos e a diferença foi pequena (5% ou menos). Esse é o cenário que temos hoje com o Windows 7, pois como ele não sabe que os núcleos são irmãos dentro de módulos, joga os processos por aí de qualquer jeito. Supondo 4 threads: um em um núcleo de um módulo, outro em um núcleo de outro módulo e os outros dois nos dois núcleos de outro módulo, por exemplo. Assim só o quarto módulo está ocioso, podendo ser desligado. O processador poderá subir um pouco o clock, mas não poderá chegar ao Turbo máximo (que só é possível quando pelo menos metade dos módulos está desligada). Isso só vai funcionar bonitinho no Windows 8. Aí sim, numa tabela como essa abaixo, nos jogos veremos mais de 100% tanto na primeira coluna quanto na terceira, pois como haverá menos módulos em uso, o processador poderá operar com um clock mais alto. Claro que programas muito pesados continuariam perdendo um pouco mais de desempenho ao rodar nos dois núcleos dentro de um módulo (principalmente por competirem pelo uso das FPUs), mas esse tipo de programa já deve estar preparado para aproveitar mais do que 4 núcleos, portanto são casos onde veríamos um belo ganho na primeira coluna de uma tabela como essa de baixo.

O Trinity é uma APU e terá núcleos Piledriver. Quanto aos testes, desativar um "núcleo" de dentro do módulo é inútil. Os poucos casos onde realmente se perde desempenho a diferença é pequena e o Windows 8 será capaz de reverter a situação (fazer com que o processador ganhe desempenho nelas graças ao melhor uso do Turbo). Claro que um 4M/4C vai ser mais rápido que um 2M/4C ao mesmo clock, a questão é por quanto. E vale lembrar que a AMD não vai fazer um processador desktop com 8 módulos (para eles compararem com 4M/8C).... Depois vou ler com calma, esse review está muito bom. @mad e outros, aqui tem resultados do Llano A8 e do FX-4100 no meio, por aí dá pra estimar como será o Trinity.

Acho que cortando o clock da memória dá pra simular a ausência do L3. Falando nisso, é bem possível que o Trinity não tenha Cache L3.

jonny_br, se quer estimar o desempenho do Trinity, pegue um BD, desative dois módulos (deixe-o com 2M/4C), jogue para uns 4GHz e compare com o Llano a uns 3.5GHz.

128 bits? pode continuar sonhando. O sideport do 790GX é de 32 bits (pode ser preenchido com apenas um chip de memória), porém é um tanto quanto inútil. Acho que o sweet spot é 64 bits, com 2 chips de memória GDDR5 @ uns 4GHz. Mais a banda da controladora de memória do processador já deve dar um resultado interessante.

Os reviewers devem fazer comparações clock por clock, mas apenas a título de curiosidade. As arquiteturas são muito diferentes, desempenho por clock não quer dizer nada. Acho que as comparações mais relevantes são um FX-8 top (8150) contra i7 2600k e i5 2500k e um FX-8 low (8100) contra um i5 baixo (tipo o 2400), um Phenom II X6 top e um Phenom II X4 top. Por estarem na mesma faixa de preço. A título de curiosidade também dá pra jogar o i7 980x e um i7 950 ou 860 no meio. Acho que o pior é ainda não termos certeza de quais "leaks" estão na direção certa. Esses últimos dias de espera são os piores.

Evandro, não tenho números agora, mas lembro que no lançamento do Phenom II comentaram que o Cache L3 maior deu uma boa ajuda, principalmente em jogos.

Bom dia pepessoal, assumindo que os resultados sejam reais, o FX8 obteve resultados melhores que os um sistema Dual Opteron Quad Core em muitos casos: http://www.amdzone.com/phpbb3/viewtopic.php?f=532&t=138556&sid=a0c66b506696ed3fa88998be4c66b407&start=1600

wencell, se sua placa tiver uma saída DisplayPort, sim (dá pra usar adaptador de DisplayPort para DVI, por exemplo, se você não tiver um monitor com entrada DisplayPort, desde que o adaptador seja "ativo", pode ser single link (um link suporta até 1080p) como esse). O DisplayPort é obrigatório porque a GPU só suporta duas saídas "legacy" (VGA, DVI ou HDMI) simultaneamente. Da terceira pra cima, só com DisplayPort.

Acho que ainda não leva isso em consideração. Se tudo se confirmar, considerando os preços, será um excelente custo benefício. Especialmente para jogos. Preço de i5, desempenho "na pior das hipóteses" igual ao do 2500k, bem perto do 2600k, superando-o em alguns casos. Ainda estou receoso quanto à performance em single thread. Mas o jeito é esperar...

Pra começar bem o sábado: chew rodando Star Craft II a mais de 7GHz. Also... boobs! http://www.xtremesystems.org/forums/showthread.php?275753-Brian-%28chew%29-has-a-little-fun..Starcraft-2-at-over-7GHz-stable!

Nice find! Bate com o que falaram quando saiu o patch pro Linux (de 4 a 5%). Porém, isso chama atenção para outra coisa. Lembram daqueles slides vazados pelo donanimhaber? Parece que eram oficiais mesmo, mas a AMD inverteu os resultados do 2600k e os do FX: http://semiaccurate.com/forums/showpost.php?p=137221&postcount=217 slide vazado: slide apresentado agora no TFE em Taipei: edit 2: Uia, olha o watercooler ai gente: http://semiaccurate.com/forums/showpost.php?p=137278&postcount=266

LordLow, toda placa com socket preto é AM3+, portanto oferecerá suporte total, independente do chipset. No caso da ASUS, a vantagem das placas com chipset da série 900 é que já trazem BIOS EFI e VRM digital. Quanto a placas AM3 que receberão atualização de BIOS para suportar processadores AM3+; ainda não se sabe exatamente que tipo de limitações podem sofrer... Nas Gigabyte, por exemplo, não será possível ler a temperatura do processador: http://www.gigabyte.com/products/product-page.aspx?pid=3756#ov

Gostei da teoria, sirroman. Se mesmo que de forma inconsciente nosso cérebro entra em um modo de "maior concentração" ao ver imagens de ~60fps nossos sentidos/reflexos ficam mais aguçados, permitindo reagir mais rápido, mas também aproveitar melhor melhor a experiência (e a adrenalina, etc), tornando a jogatina mais satisfatória. Claro que não é todo tipo de jogos se beneficia disso, como o Evandro falou. Para um jogo de tiro ou corrida eu considero 60fps praticamente obrigatórios, mas para um jogo de estratégia não faz tanta diferença ou podem até atrapalhar (considerando esse modo de maior atenção, nosso cérebro ficaria mais preocupado em reagir rápido do que em calcular melhor as decisões, justamente o contrário do objetivo desse tipo de jogo).