AMD Bulldozer / Bobcat / Zambezi - Plataformas.

[Nav01]

Achei estranho o fato de afirmarem um possível incremento de desempenho em até 40%.

Com o turbo funcionando normalmente esperava de 10-15% de incremento de performance, porém um post no Overclock.net me chamou a atenção:

So let me get thsi straight...

After 4+ years in development, 1000's of hours of bug testing and redesigning area's of the CPU, months of final testing, engineering sample test phase with motherboards manufacturers and finally a launch..

They now realise there is something that can be fixed with a software patch that caused its performance issues????

Yeah, right.

If there's any ouce of truth to this, its that its not a patch at all. Its a workaround. This 'patch' will basically tell windows to only assign one core per BD module to concurrent threads until more than 4 threads are required.

If anything uses over 4 threads, it will perform exaclty the same. All they're doing is attempting to fix the scheduler issues via the OS.

Ou seja, o aumento de desempenho é para tarefas que demandem até 04 threads e os núcleos a serem usados, nestes casos, são apenas 01 de cada módulo. Trabalhar de forma espalhada entre os módulos traz um incremento de performance, por evitar compartilhamento de recursos. O problema é quanto ao funcionamento do turbo. Assim sendo, acredito que o desligamento dos núcleos possa se dar de modo individual, ao invés de ser por módulo. O front-end bem como o cache L2 de cada módulo vão estar consumindo um pouco mais de energia desta forma, porém o incremento de performance seria o mais relevante.

[aziebert]

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.

[kmbr]

acho que esta havendo um certo exagero nas criticas sobre esse lançamento, o processador é bom, acontece que do outro lado existe uma gigante chamada intel e um monstro chamado 2600K, isso não é tirar doce da mão de criança.

[johannesrs]

só uma coisa: alguém já viu um erro de registo (?????) dar um impacto tããão grande?????

E concordo, em todas as discussões envolvendo o linux falou-se de uns 7% de ganho no máximo... algum teste em linux mostrando esse efeito????

P.S.: a notícia mesmo é aqui: http://quinetiam.com/?p=2356

P.S.: Pra confirmar se tem algum fundo de verdade nisso afinal: alguém procura se existiu ou não esse tipo de problema no Cortex A8? E, outra... como nem o Charlie noticiou isso ainda?

E concordo: estranho isso estar no kubuntu, e não no kernel direto.

[lotuss]

Se você pegar um carro 1.0 e andar a 160kph o consumo também será absurdo.

Pois é, mas os FX são carros 3.0 que só chegam a 160 km/h na descida e numa rodovia bem asfaltada.

quanto o consumo do BDZ, a imagem abaixo contesta sua resposta:

E as três abaixo confirmam:

O consumo do BDZ só foi elevado quando o turbo entra - e já que não funciona direito, pode-se desativar na bios - ou quando em over. No dia a dia, o consumo fica normal como qualquer outro.

Ou você pode comprar um i5, que não tem turbo problemático, tem desempenho geral melhor e consome menos sempre.

acho que esta havendo um certo exagero nas criticas sobre esse lançamento, o processador é bom, acontece que do outro lado existe uma gigante chamada intel e um monstro chamado 2600K, isso não é tirar doce da mão de criança.

É pior núcleo a núcleo que os Phenom II. Como isso pode ser bom?

[Pistigrilo]

Uma coisa que acho absurda é darem suporte ao AMD FX em placas AM3 com chipsets NVIDIA pré-históricos (que alguém por aqui chamou "carinhosamente" de "placa-mãe chinelo") e não darem suporte a quem possui placas bem mais tops, com chipsets AMD 770/790X/790GX/790FX. Esse Bulldozer tem uma coisa mais estranha que a outra.

[Visitante]

E em outubro as ações da AMD perderam um terço do valor, que já era baixo.

[Nav01]

I see a lot of finger pointing and questioning...

Here is my current understanding:

In the past we have seen CPU drivers for windows (mostly XP, and mostly AMD.) This is NOT what is occurring here, its not some weird issue with the processor causing it (although it kind of is)

What is happening is this: The FX 8xxx series of processors has 4 cores, each core with TWO integer pipelines, effectively granting two processor cores for the price of one. (not "hyperthreading" effective, but almost literally additional core effective.)

This is all fine and dandy, except that when Windows (or Linux) goes to issue work to a core in the processor, it picks the core with the least load, and distributes things using a task scheduler. The problem here is that when a single pipeline on a bulldozer core is being utilized both cores are effectively "in use" even though Task Manager sees the cores appropriately, the task scheduler does not. This isn't really anybody's fault, but rather an oversight.

Standard CPU design from a by-the-book standpoint would never add a second integer pipeline to a single core. So nobody ever really thought to code a task scheduler that worked in that situation. So basically, AMD thought outside the box, and Windows got confused.

Oh not to mention that if the scheduler tries to run non-integer work on one of the integer only threads, the CPU returns an error and the command is re-queued and has to sit in line waiting to be executed again. Basically its a scheduler issue, and could definitely cause some HUGE impact in synthetic benchmarks and normal use. And even more issues in a cluttered server environment.

Xaero252, membro do Overclock.net, dando seus pitacos.

"Se o agendador tenta rodar um trabalho de não inteiros sobre um dos núcleos [somente] de inteiros, a CPU retorna um erro e o comando é re-colocado na fila, aguardando para ser executado novamente."

O comentário do Xaero252 chegou a ser rebatido apenas 01 vez, mas outro membro e o próprio Xaero replicaram a controvérsia. Núcleos somente de inteiros???

Ziebert, Eduardo, me ajudem aí ô!!!

Referências: Página 10; Página 11

[aziebert]

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.

[Nav01]

Mas considere a seguinte suposição:

Um cálculo envolvendo ponto flutuante é atribuído a um dos núcleos, que teoricamente só processa inteiros (na Wikipedia e o próprio Eduardo disse que a ALU é capaz de processar ponto flutuante). O aludido cálculo teria que ser agendado na FPU para depois proceder com o cálculo, partindo do pressuposto que os núcleos do Bulldozer só processam inteiros. Logo os dados teriam que ser realocados na fila para processamento pela FPU.

Só que aí é o caso: O SO não vê a FPU, vê um cluster como um todo, então quem deveria, em tese, separar isso seria o front-end. Logo não seria um problema do SO. Ou estou errado?

[aziebert]

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).

[CALINHO]

A produção de Phenom II parou? Ta praticamente escasso. Estava pensando em pegar uma AM3+ de 350 reais + Phenom II X6 1090T. Queria um 2500K e uma P67 boa que faz 5Ghz no ar, mas sai mais caro.

[aziebert]

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

[clerigotrevas]

pessoal, teria alguma chance da asus lançar uma atualização de bios (tirando aquela q ja foi lançada a um certo tempo) para o chipset 790X, dando suporte aos novos processadores? mesmo nao tendo gostado mt do q foi apresentado pela amd com o bulldozer, uma troca de plataforma nao seria legal para mim

[EribertoTorres]

Donos de Asus com soquete AM3, desanimem-se, parece que a gigante voltou atrás com a retrocompatibilidade.

http://www.chw.net/2011/10/tarjetas-madre-socket-am3-de-asus-no-soportaran-cpus-bulldozer-am3/

[clerigotrevas]

é acho q isso ja responde minha pergunta aseuhashuuie valeu eriberto! up de final de ano vai ser um ssd mesmo

[Hausak]

Donos de Asus com soquete AM3, desanimem-se, parece que a gigante voltou atrás com a retrocompatibilidade.

http://www.chw.net/2011/10/tarjetas-madre-socket-am3-de-asus-no-soportaran-cpus-bulldozer-am3/

Eriberto, posso estar enganado, mas pelo que entendi da Bios em questão e que foi circulada, esta versão em específico é somente para utilizar com os Bulldozer e não deve ser utilizada com outros processadores. Caso esteja com qualquer outro processador, a placa deve ser atualizada com qualquer outra versão anterior de Bios.

[jonny_br]

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...

E tu me fizestes lembrar do ThiagoLCK

[aziebert]

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.

[Nav01]

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%).

Uai, o Bulldozer não possui 02 ALUs para 1 FPU??? E a relação de ALU/FPU dos Phenom não é 1:1?

Agora é claro, possui recursos compartilhados e isso não traz a mesma agilidade de um processador com núcleos organizados de forma convencional. Como já demonstrado, a eficiência é bem superior ao Hyper-Threading, mas certamente as unidades de inteiros são fracas.

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).

Quanto a isso eu não sei. É válido ressaltar que 3-5% de desempenho a mais em uma coisa, mas alguns porcento em outra coisa fazem, no conjunto, um bom ganho. Alguns por cento de perda em algum bench é reflete em um marketing contra. Mas em contrapartida acho que caches grandes também delongam mais a consulta. Só o fabricante da CPU, por meio de testes práticos, para saber ao certo o benefício.

Lembre que os 02MB de cache são para suprir a demanda de ambos os núcleos (além da FPU).

decepcao desses novos processadores da amd --', galera gostaria de saber o que e esse Llano? ele e o que ? pra notebook?, pra server, pu pra pc desktoop.

Llano tem para desktop e para notebook.

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).

Não era isso que eu estava tentando demonstrar ao Jonny, que o Llano dele sem GPU a 3,5GHz teria uma classificação de 125W TDP? Já os Bullldozer de até 06 núcleos tem classificação TDP de 95W e ainda considerando que os hexacore possuem 10MB a mais de cache (14MB de cache L2+L3).

[soullforged]

Pois é, as ações refletem tudo.

Chegaram perto dos 9 dólares no início do ano, e estão abaixo de 5 dólares agora. Prevejo tempos difíceis novamente, a menos que o novo CEO reorganize a casa com força.

[EduardoS]

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.

Virus térmicos precisam ser escritos com a arquitetura específica em mente e, usam as instruções que mais consomem.

Se não me engano o código que roda nos AMD foi feito para os K-7 e reciclado desde então, ele é cruel com o K-7 e seus derivados realmente tirando tudo o que eles tem.

O que roda nos Intel foi feito para os Pentium III e esqueceram de atualizar, nos Core 2 e sucessores ele mal faz cóssegas.

E claro, no Bulldozer também fica sobrando recursos.

um pouco mais fraca que a de um núcleo Phenom, mas anos luz atrás do SandyBridge

O Sandy Bridge só tem 3 ALUs, igual aos Phenom, em força bruta os dois núcleos são praticamente equivalentes.

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.

Pois é, força bruta não é tudo, em termos de uso eficiente da força os Phenom pecavam, eles ficavam muito atrás do Sandy Bridge por não conseguir usar todo o armamento disponível, a AMD corrigiu isso no Bulldozer e corrigiu muito bem, o problema é que agora existem menos armas disponíveis e o clock não subiu para compensar...

Um cálculo envolvendo ponto flutuante é atribuído a um dos núcleos, que teoricamente só processa inteiros (na Wikipedia e o próprio Eduardo disse que a ALU é capaz de processar ponto flutuante). O aludido cálculo teria que ser agendado na FPU para depois proceder com o cálculo, partindo do pressuposto que os núcleos do Bulldozer só processam inteiros. Logo os dados teriam que ser realocados na fila para processamento pela FPU.

A unidade de inteiros pode realizar cálculos de ponto flutuante, o que ela não pode é executar instruções de ponto flutuante.

Um número de ponto flutuante é uma estrutura de dados a unidade de inteiros pode muito bem realizar cálculos a partir dessa estrutura, com uma porrada de instruções para se adequar ao formato, a FPU entende esse formato sem instruções adicionais.

Mas para um cálculo de ponto flutuante ser feito com as ALUs o software precisa conter as instruções para isso, não da para um software uma hora rodar na unidade de inteiros e outra hora na FPU.

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).

Em time que está ganhando não se mexe... Quer dizer, no único time que está ganhando no bulldozer nãos e mexe...

Repetindo o que eu já disse em outros foruns, até agora o único benchmark em que o Bulldozer se saiu bem foi em compressão de arquivos que também é o benchmark desktop que mais depende do cache e subsistea de memória, se a AMD tivesse feito alguma cagada nesse aspecto os resultados seriam ruins.

[Visitante]

Prevejo a intel deitando e rolando nos preços, bom pra mim que quando dar um up mando AMD.

[Nav01]

Nessa screenshot abaixo o Phenom II X1100T desempenha o SuperPi 2% mais rápido que o Bulldozer. Sabemos que o SuperPi é um teste single-threaded.

A questão é que se se trata de um software single-threaded, teoricamente o fato de 07 núcleos estarem ociosos seria o suficiente para o Bulldozer acionar o turbo e chegar a frequência de 4,2GHz de forma constante.

Segundo The Stilt, membro do XS, o turbo do Bulldozer está falhando até na execução de tarefas single-threaded. Ele acredita que o Windows esteja espalhando a carga entre os núcleos e assim o SuperPi não é executado com a agilidade que deveria ser teoricamente desempenhada caso o processador estivesse rodando a 4,2GHz.

I´ll give you an example what currently happens:

A FX-8150 (Turbo Core enabled) running at stock settings, SuperPI (a single threaded software) is being executed:

Because there is load only on one thread (in theory) the Turbo Core feature boosts couple cores up to 4.2GHz while the rest are operating at 3.6 - 3.9GHz frequency. What currently happens is that Windows is unable to put the load (SuperPI) on the boosted core (4.2GHz) but throwing the load between the cores.

And executing such program (or any program actually) is naturally faster when it is executed on a core operating at 4.2GHz rather on one which is operating at 3.6-3.9GHz.

Link da página: http://www.xtremesystems.org/forums/showthread.php?275873-AMD-FX-quot-Bulldozer-quot-Review-(4)-!exclusive!-Excuse-for-1-Threaded-Perf./page5

[Visitante]

Não sei se já postaram isso, mas eis uma comparação entre um Bulldozer e um Sandybridge overclockados o máximo possível e usando três HD6970 em Crossfire.

http://www.tweaktown.com/articles/4353/amd_fx_8150_vs_intel_i7_2600k_crossfirex_hd_6970_x3_head_to_head/index1.html