AMD Bulldozer / Bobcat / Zambezi - Plataformas.

[telminão]

http://forum.clubedohardware.com.br/boletim-1-065/p5221100#post5221100

Ítem 5..

Tomara que isso se confirme , como diria o Eriberto, eu e todas as torcidas do Brasil estão curiosas, quanto ao desempenho desses caras

[EribertoTorres]

Pombas, mas será que sai mesmo? O JF ou o Charlie comentaram algo reforçando isso? Já nem presto mais atenção em bench. Só acredito depois do lançamento e quando o GT dizer: alou galera, oficialmente saiu o trator. E de preferência quando ele poste um teste, ai eu acredito que ele existe. E realmente, o telminão definiu bem, eu e toda a torcida brasileira está na angustia esperando esse maledeto. Em todo caso, vou andar cotando uns X6 1090T

[Evandro]

http://www.xbitlabs.com/news/memory/display/20110905085324_JEDEC_s_New_DDR3_Spec_Supports_New_Types_of_Memory_Modules.html

JEDEC divulga novos padrões de pentes DDR3, não vi nada de clock maior.

http://www.techpowerup.com/151645/ASUS-Intros-E45M1-M-PRO-Fusion-Motherboard-with-AMD-E-450-APU.html

Asus solta placa-mãe bacaninha com o E-450.

[johannesrs]

A minha dúvida: se não é o processar, se não é as placas mãe...onde mais pode dar problema difícil de resolver???

[Hausak]

A minha dúvida: se não é o processar, se não é as placas mãe...onde mais pode dar problema difícil de resolver???

Relaxa... daqui a pouco eles vão perceber que estão testando com uma fonte com defeito.

[aziebert]

@johannesrs

CRoland @semiaccurate

Patches were recently posted on LKML to fix a cache aliasing issue, where IIUC the same shared library code mapped at different addresses for two processes in a module could cause excessive L1 instruction cache invalidation. It is possible that something similar is going on with Windows, but this is purely my speculation.

Those who care can find patches and comments with the keywords "f15h aliasing" using the search engine of their choice. The number they quoted was 3% performance penalty in "CPU intensive code" and more for microbenchmarks.

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.

[Ramon Neves]

A minha dúvida: se não é o processar, se não é as placas mãe...onde mais pode dar problema difícil de resolver???

Ainda sobrou o chipset, pode ser que ele seja o culpado...rsrs ja que não é o processador nem a placa mãe (bios)

[Nav01]

http://semiaccurate.com/forums/showthread.php?p=132311#post132311

Tradução da tradução da especulação..

Teve um cara que diz que viu os Bulldozer hoje, até tirou umas fotos e bateu papo com um figurão da AMD, e parece que tem sim um problema, mas não no chip e talvez não na plataforma, mas não vai dar pra arrumar antes do lançamento, então, mais uma vez, os primeiros reviews serão negativos.

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

Por um momento estava a pensar se havia desaprendido Português, pois se há um problema com o Bulldozer, mas não está no chip e nem na plataforma...

Cheguei a pensar que o problema era da "tradução da tradução", todavia observei depois que o Evandro citou justamente o comentário de um alemão e que, portanto, deve ter interpretado corretamente para o Inglês. Percebi pelo trecho inicial do comentário ("Ah, it's N1truX and he posted in my first language.."), mas também pode ser observado no perfil do cara ou pelo seu nick.

[arcmatrixnt]

no video postado pelo Telminão AQUI dá pra ver no zoom que o uso do processador fica em 27% no TOTAL dos 8 núcleos.

muito provavelmente com clock em 4.0~4.5GHz (não parece que o jogo consome todos os núcleos...)

será que dá pra comparar com um X6 (total de núcleos)??

isso pode dar uma ideia da folga do bdz:D ou do aperto:hehehe:

opa, atualizando:

Ele usa os seis núcleos, três dos quais ficam sempre acima dos 40%, com picos de 80% e três ficam acima dos 35% com picos de 60%. Fui verificar isso agora, a utilização máxima somando os seis núcleos foi de 67%, miníma de 49%. Mesmo em replay o uso dos núcleos foi de forma similar, como se estivesse em tempo real.

só faltou falar o clock, acho que no caso do Musketeer o pc dele tá no padrão com over do turbo.

[DS_skyl]

to acompanhando o tópico desde o início, está claro pra mim que o bulldozer será um pouco melhor que os PII em single thread, estou esperando ele lançar pra ver AMD brigar com a INTEL, mas provavelmente vou sair com a sandy nesse fim de ano...

[aziebert]

no video postado pelo Telminão AQUI dá pra ver no zoom que o uso do processador fica em 27% no TOTAL dos 8 núcleos.

muito provavelmente com clock em 4.0~4.5GHz (não parece que o jogo consome todos os núcleos...)

será que dá pra comparar com um X6 (total de núcleos)??

isso pode dar uma ideia da folga do bdz:D ou do aperto:hehehe:

opa, atualizando:

só faltou falar o clock, acho que no caso do Musketeer o pc dele tá no padrão com over do turbo.

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.

[Nav01]

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.

Assim imaginei, porém o Turbo que você se refere deve ser o "Super Turbo", pois os rumores dão conta de que o BDZ possui turbo para todos os núcleos rodando em cerca de 400-500MHz. Já o Super Turbo (com apenas alguns núcleos trabalhando) deverá trabalhar entre 800-1000MHz.

Porém a coisa parece ser mais bem interessante. O BDZ deve ter uma forma inteligente de economizar a utilização de núcleos e, assim, prover maior economia de energia ao desligar núcleos. Embora o DiRT3 seja otimizado para 06 núcleos, ao verificar que a tarefa não está exigindo muito processamento, então o "Front End" de cada módulo direciona as tarefas para apenas 01 núcleo (de cada módulo), passando-se a utilizar no máximo 04 núcleos em um BDZ octacore.

[aziebert]

Assim imaginei, porém o Turbo que você se refere deve ser o "Super Turbo", pois os rumores dão conta de que o BDZ possui turbo para todos os núcleos rodando em cerca de 400-500MHz. Já o Super Turbo (com apenas alguns núcleos trabalhando) deverá trabalhar entre 800-1000MHz.

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.

Porém a coisa parece ser mais bem interessante. O BDZ deve ter uma forma inteligente de economizar a utilização de núcleos e, assim, prover maior economia de energia ao desligar núcleos. Embora o DiRT3 seja otimizado para 06 núcleos, ao verificar que a tarefa não está exigindo muito processamento, então o "Front End" de cada módulo direciona as tarefas para apenas 01 núcleo (de cada módulo), passando-se a utilizar no máximo 04 núcleos em um BDZ octacore.

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.

[Mackoy Jubelli]

Só por curiosidade, alguem já fez uma retrospectiva e seus os primeiros post, vocês perceberam que já estão a quase 2 anos esperando, (pelo menos desde que foi criado o tópico). Calma gente só mais alguns dias, heheheh.... Sei que é OFF Topic, mas as vezes é bom dar uma relaxada, pra quem esperou 2 anos, o que é 2 semanas....(eu roendo as unhas, kkkkk)

[arcmatrixnt]

no video postado pelo Telminão AQUI dá pra ver no zoom que o uso do processador fica em 27% no TOTAL dos 8 núcleos.

muito provavelmente com clock em 4.0~4.5GHz (não parece que o jogo consome todos os núcleos...)

será que dá pra comparar com um X6 (total de núcleos)??

isso pode dar uma ideia da folga do bdz:D ou do aperto:hehehe:

opa, atualizando:

Ele usa os seis núcleos, três dos quais ficam sempre acima dos 40%, com picos de 80% e três ficam acima dos 35% com picos de 60%. Fui verificar isso agora, a utilização máxima somando os seis núcleos foi de 67%, miníma de 49%. Mesmo em replay o uso dos núcleos foi de forma similar, como se estivesse em tempo real. (Musketeer)

só faltou falar o clock, acho que no caso do Musketeer o pc dele tá no padrão com over do turbo.

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.

então podemos dizer que os clocks do bdz e um X6 1090T estariam muito próximos nessa "demo" devido esse bug, que parece ser uma necessidade de otimização forçada, sem ela o bdz não mostra a performance que tem.

[EribertoTorres]

Se o problema do trator é um patch para sistema operacional, menos mal, no Linux sai rapidão, e se a AMD depender da MS, pode se decepcionar, como já aconteceu no passado (quem lembra do Athlon 64? Testado com o Conectiva Linux 64 bits e a AMD esperando o Windows XP 64 bits para lançar o processador).

Vou aguardar mais duas semanas, agora os detalhes técnicos sobre a demora do trator eu curto, mas bench por hora, só quando sair o trator.

[Nav01]

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.

Caracas, faz sentido mesmo!

Estive revendo um artigo sobre o DiRT3, no AMD Blogs, e observei que os codemasters não direcionaram partes do código para um ou outro núcleo, ao contrário do que eu havia interpretado dantes; apenas manipularam as cargas de trabalho dos threads. Até pensei que se tratava de uma falta de conhecimento da minha parte no desenvolvimento de aplicativos, por não saber como direcionar as tarefas de um código para um ou outro núcleo. É que, pelo que entendi, o SO que se encarrega dessa tarefa.

Link do artigo: http://blogs.amd.com/play/2011/07/28/dirt-3-cpu-gpu-great-game-play/

JF citou problemas que podem refletir sobre os testes de benchmark do Bulldozer antes de seu lançamento, tais como o mencionado possível problema de otimização do SO:

Q. I saw a benchmark on xyz website. Is that how bulldozer will perform?A. No. Nothing posted before launch will be representative of actual performance. To get actual performance, you need:

Final production silicon

Final processor microcode

Final system BIOS

Final OS optimizaitons

Final drivers

An app compiled with the latest flags

A person who understands the app and configures the test properly

O lançamento do BDZ está próximo, então vamos com calma, né pessoal! Benchmarks de desempenho real em breve!

[EduardoS]

É especulação da minha parte mas...

O Windows entende "HyperThreading", paa o Windows "HyperThreading" e um módulo do Bulldozer são a mesma coisa e quando existe "HyperThreading" ele distribui as tarefas primeiro para a thread 0 de cada núcleo e depois para a thread 1 de cada núcleo, no caso do Bulldozer a AMD chegou a conclusão de que é melhor primeiro encher cada módulo antes de passar para o próximo e pediu pra MS atualizar, não deve demorar, a propósito, alguém tem um link pra informações sobre o patch do Linux?

[Evandro]

Eduardo, acho que não saiu ainda..

http://semiaccurate.com/2011/09/06/what-is-going-on-with-glofos-32nm-process/

Processos em 32 e 28 nm da GloFo não estão bons, rendimento na casa dos 50%, tende a melhorar mas ainda é ruim.

http://www.xbitlabs.com/news/cpu/display/20110906133712_AMD_Reschedules_Launch_of_FX_Series_Chips_to_October_Changes_Launch_Lineup.html

Atraso pra Q4 (meio de outubro) confirmado ?!

Já começaram a ser despachados, mas a disponibilidade agora seria baixa.

Então pode ser um paper launch dia 19 e vendas mirradas até outubro..

[sirroman]

AMD promete um anúncio histórico dia 13. No exato dia de abertura da IDF...

http://amd-member.com/newsletters/DevCentral/FusionZone2011.html

Sério, se eu me lembrasse da IDF já teria dito que tava na cara que a gente não ia saber nada até lá...

---

Evandro, posta a notícia do 32nm no tópico das foundries. E ele só fala em problema no 32nm, inclusive diz que o 28nm SHP (novidade!) já tem as correções aprendidas com o 32nm.

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.

Eu ia dizer "é síndrome de HT" mas o EduardoS falou primeiro. xD

É especulação da minha parte mas...

O Windows entende "HyperThreading", paa o Windows "HyperThreading" e um módulo do Bulldozer são a mesma coisa e quando existe "HyperThreading" ele distribui as tarefas primeiro para a thread 0 de cada núcleo e depois para a thread 1 de cada núcleo, no caso do Bulldozer a AMD chegou a conclusão de que é melhor primeiro encher cada módulo antes de passar para o próximo e pediu pra MS atualizar, não deve demorar, a propósito, alguém tem um link pra informações sobre o patch do Linux?

Não é isso aqui n?

https://patchwork.kernel.org/patch/999102/

[Evandro]

AMD promete um anúncio histórico dia 13. No exato dia de abertura da IDF...

http://amd-member.com/newsletters/DevCentral/FusionZone2011.html

Sério, se eu me lembrasse da IDF já teria dito que tava na cara que a gente não ia saber nada até lá...

Anúncio histórico: o Bulldozer será cancelado, lançaremos um Thuban melhorado e em 28 nm.

Ou.. tem a ***** do bug TLB no Bulldozer.

Pessimismo / off

Tem cara de muita pompa e pouco resultado. Anúncio bom é como peido ninja, ninguém sabe de onde veio e ninguém aguenta ficar no lugar.

Evandro, posta a notícia do 32nm no tópico das foundries. E ele só fala em problema no 32nm, inclusive diz que o 28nm SHP (novidade!) já tem as correções aprendidas com o 32nm.

Postei, desculpe ter esquecido, mas achei que aqui também cabia.

[Nav01]

Não é isso aqui n?

https://patchwork.kernel.org/patch/999102/

Então já foi lançado o patch para Linux, não é isso?

[aziebert]

É especulação da minha parte mas...

O Windows entende "HyperThreading", paa o Windows "HyperThreading" e um módulo do Bulldozer são a mesma coisa e quando existe "HyperThreading" ele distribui as tarefas primeiro para a thread 0 de cada núcleo e depois para a thread 1 de cada núcleo, no caso do Bulldozer a AMD chegou a conclusão de que é melhor primeiro encher cada módulo antes de passar para o próximo e pediu pra MS atualizar, não deve demorar, a propósito, alguém tem um link pra informações sobre o patch do Linux?

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

[Gun'ss]

Então já foi lançado o patch para Linux, não é isso?

Pode ser que não tenha entrado pro mainline, tem que ver se vai vir no 3.1 ou no 3.2

[Pistigrilo]

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

Nossa! Esse negócio de diminuir o cache L1 está rendendo mais do que eu poderia imaginar. Mas sempre achei estranho esse negócio de diminuir o cache L1. Acho isso um tiro no pé, mas vamos aguardar para ver quando lançarem o danado do trator. Ao pensar nas "semelhanças" que o Bulldozer tem com o Netburst, dá até medo: cache L1 pequeno, cache L2 grande (e no caso do Bulldozer tem ainda um L3 grande), clocks nas alturas e essa polêmica toda em volta da arquitetura! Enfim! Vamos torcer para tudo dar certo no final, né?