AMD Bulldozer / Bobcat / Zambezi - Plataformas.

[johannesrs]

@Nav:

1 - não entendi a tua discussão em cima dos caches. Meio que enroscou no meio. Tu acha que os problemas reportados nos caches não fazem sentido em função do desempenho dos programas de compactação, é isso????

2 - então, tu discorda do charlie e acha muito provável que seja problema no processo os problemas de clock e consumo, é isso?

3 - posso estar pirando, mas... esses escapes tentando ser reduzidos... alguém mais lembra da 4890?

[Nav01]

@Nav:

1 - não entendi a tua discussão em cima dos caches. Meio que enroscou no meio. Tu acha que os problemas reportados nos caches não fazem sentido em função do desempenho dos programas de compactação, é isso????

Não, exatamente o contrário. Vou tentar dar uma ajeitada no comentário anterior para melhor compreensão. Acho que o Charlie possa estar correto, pois embora o Bulldozer desktop tenha se saído bem nos testes de compressão de dados, acredito que isso se dê em função do L3, não do L2. Um módulo Zambezi não precisa ser exatamente idêntico a um módulo servidor.

2 - então, tu discorda do charlie e acha muito provável que seja problema no processo os problemas de clock e consumo, é isso?

Vamos dizer que eu discordo parcialmente. Acho que o número de transistores está alto, precisa ser reduzido a fim de consumir menos energia, mas acho que o processo está muito verde e isso certamente está afetando também o clock e o consumo.

Também deve-se levar em conta que os Sandy tem menos de 1 bilhão de transistores, mesmo com GPU. Os Sandy possuem muito menos cache que um Bulldozer. Levando-se em conta que os caches rodam na mesma frequência que os núcleos, ao se fazer overclock também o consumo elétrico proveniente dos caches aumenta. Um hexacore Gulftown overclocado (1,17bi de transistores), que possui cerca de 14MB de cache, juntando L1, L2 e L3, daria-nos uma ideia melhor se o consumo excessivo advém também do processo ou não. O Bulldozer, para efeito de comparação, possui 16MB de cache L2+L3.

Já comparar o consumo elétrico de um processador octacore com ~2bi de transistores com o sandy i7-2600K, um quadcore de 995mi de transistores é algo complicado. Cada módulo do Bulldozer consome 213mi de transistores. Um Bulldozer quadcore, então, teria cerca de 400mi de transistores a menos, ou seja, por volta de 1,6bi de transistores. Tudo bem que mesmo na versão quadcore o Bulldozer ainda consome muitos transistores, não a toa o fato de eu dizer que ainda há muitos transistores que deveriam ser eliminados dessa arquitetura. Se haviam previsto um octacore de 1,6bi de transistores e acabou resultando em ~2bi de transistores, tal diferença provavelmente foi consequência do uso das ferramentas automáticas.

O Sandy foi projetado de forma artesanal e tem uma GPU de 114mi de transistores, além de contar com um controlador de memória, PCI Express etc. Considerando-se que apenas os núcleos e os caches são submetidos ao overclock quando você altera o clock da CPU, o impacto naturalmente não é o mesmo do que na arquitetura Bullldozer.

Em suma, o trator parece mesmo uma máquina pesada, com muito ferro (só que no caso o material é silício). O processo de fabricação também está verde e precisa ser amadurecido. Provavelmente daqui há alguns meses veremos uma jaca madura.

[Guilherme FW Xavier]

Já tem FX-8150 no ML.

[telminão]

Já tem FX-8150 no ML.

Mais caro que o I7 2600k?

http://produto.mercadolivre.com.br/MLB-205072632-processador-intel-core-i7-2600k-quad-core-34ghz-8mb-lga1155-_JM

Não, obrigado

[lotuss]

Esse cara é um cara qualquer que tá nos EUA viajando, ele vai trazer um processador e revender. Ou seja, ele não é uma loja que trabalha com quantidade, impostos e tal.

[Pistigrilo]

A latência do cache L2 é horrível, partindo do pressuposto que tal latência é de 25-27 ciclos, enquanto a latência do L2 do Phenom II seria de uns 15-17 ciclos. Se você pega como exemplo a compressão de arquivos para defender a arquitetura compartilhada do cache L2, acho que tal argumento pertinente aos benchs não seja plausível. Os programas de compressão de arquivos se beneficiam muito do L3; isso nos leva a crer que o L2 estaria sendo subaproveitado em tal categoria de programas, seguindo a ordem natural de busca feita pelo preditor. É natural que se o preditor não encontra os dados no L2 o seu último recurso de busca (a nível de cache) seja o L3.

Então quando o Charlie sugere um L2 dedicado para cada núcleo, com 1MB cada, mesmo que isto custe um pouco mais de transistores, isso seria compensado pela redução da latência pela metade de ciclos. Talvez o termo "metade" seja um exagero, mas certamente reduziria bastante o tempo de busca. Tudo bem que cada cluster não teria mais o limite teórico de 2MB de dados para se beneficiar, mas considerando a latência exorbitante do L2 compartilhado, aparenta sim ser a melhor solução. Claro que isso também deva passar por testes e Charlie não teria condições de fazer isso, não sendo um engenheiro da AMD.

Pelo que o Charlie disse, os yields do Bulldozer são decentes, logo ele não acredita que o problema do alto consumo, quando submetido a altas cargas, seja do processo de fabricação e sim do projeto do Bulldozer. Ele reforça tal tese baseado no consumo do Bulldozer quando em estado de ociosidade, abaixo do consumo dos Phenom de 45nm. Todavia, eu penso que um processador está mais propenso à fuga de corrente quando submetido ao overclock, obviamente. E se um Bulldozer tem mais ou menos o consumo de um Phenom II quando em alta carga de trabalho (uns artigos reportam pouco mais, outros pouco menos) e você compara com o consumo exorbitante quando o Bulldozer é levado a overclock, não me vem na ideia outra coisa senão alta fuga de corrente elétrica.

Eu achei interessantes essas teorias acerca do cache do trator. E realmente está bem alta essa latência do cache L2.

Mais caro que o I7 2600k?

http://produto.mercadolivre.com.br/MLB-205072632-processador-intel-core-i7-2600k-quad-core-34ghz-8mb-lga1155-_JM

Não, obrigado

Nossa! Viu o tanto de interessados? Ou são fanboys cegos ou nunca leram os artigos e tópicos do Clube do Hardware sobre esse processador.

Está caro sim, mas é preço de lançamento. Aqui novidade sempre é cara. Os vendedores abusam da ignorância do público. Eu também nunca pagaria 800 "dilmas" num brinquedo desses. Eu ainda consigo simpatizar mais com meu Phenom II X6 do que com esses FX-"octa"-core.

[EduardoS]

Mestre, uma dúvida. Lembro que logo quando surgiram os primeiros detalhes sobre a arquitetura Bulldozer voltaram os boatos sobre o tal HyperThreading reverso. Vendo os dois clusters de ALUs e o frontend compartilhado me pareceu bem plausível que fosse feito algo nesse sentido (que um Thread pudesse aproveitar ambos clusters se o outro não estivesse em atividade). Conforme a carga dos threads fosse aumentando, cada thread reteria certa prioridade sobre seu cluster (imagino que algo assim já aconteça nas FPUs).

Você acha que é algo viável (creio que como a arquitetura é mais "estreita", pode se beneficiar mais de ILP fazendo isso) e relativamente "fácil" de ser feito? É uma carta que a AMD pode ter na manga? Provavelmente não para o Piledriver, mas quem sabe já para o Steamroller (2013).

1) Não é fácil de fazer;

2) Algumas tentativas que houvi falar em outras arquiteturas foram um fiasco.

Opa, desculpe EduardoS, não sou engenheiro

Não me referi a você e nem a ninguém desse forum, mas ao Charlie que parece querer ensinar os engenheiros a fazer um processador, não é a primeira vez que ele fala mais do que deve.

Agora, ele martela em dois pontos que todo mundo tá criticando: latência da L2 (se aqueles números estão certos, são de arrepiar!)

Estão em linhas com outros caches com mesmo clock e tamanho.

e a falta de clock, excesso de consumo, etc (toda a bronca do processo).

Essa crítica acredito ser irrefutável...

Eu assumo que sou leigo nesse assunto!

Mas você, EduardoS, percebe-se que sabe o que fala.

Do resto, muita gente falando besteiras, inclusive eu.

O segredo é não falar muito

Não sei porque o Bulldozer é tão lento, se fosse para chutar (além da óbvia falta de clock) eu chutaria na falta de força bruta, mas não é algo que eu va insunuar que os engenheiros da AMD são incompetentes e que eu sei como consertar o Bulldozer.

E o que mais me incomoda, o Charlie critica a primeira coisa que viu pela frente e que seria fácil de arrumar se fosse o problema (e, sendo assim, já teriam testado e arrumado...) sendo que testes me dizem que isso não é uma qualidade e não um problema...

A latência do cache L2 é horrível, partindo do pressuposto que tal latência é de 25-27 ciclos, enquanto a latência do L2 do Phenom II seria de uns 15-17 ciclos.

12 ciclos para o Phenom II e 20 ciclos para o Bulldozer, mas o L2 do Bulldozer é maior e visa clocks mais altos.

No fim, é o esperado.

Se você pega como exemplo a compressão de arquivos para defender a arquitetura compartilhada do cache L2, acho que tal argumento pertinente aos benchs não seja plausível. Os programas de compressão de arquivos se beneficiam muito do L3;

Compressão de arquivos se beneficiam muito de todos os caches.

isso nos leva a crer que o L2 estaria sendo subaproveitado em tal categoria de programas, seguindo a ordem natural de busca feita pelo preditor. É natural que se o preditor não encontra os dados no L2 o seu último recurso de busca (a nível de cache) seja o L3.

Ai que ta... Com 2MB de L2 ele quase sempre vai achar o que precisa no L2...

Então quando o Charlie sugere um L2 dedicado para cada núcleo, com 1MB cada, mesmo que isto custe um pouco mais de transistores, isso seria compensado pela redução da latência pela metade de ciclos.

Reduziria a latência em 2, 3 talvez 4 ciclos, não pela metade, e criaria mais trafico de snoop, quer dizer, se fosse tão simples, já teriam feito...

Voltando ao ponto do L2, o Bulldozer tem uma estrutura de caches muitíssimo parecida com a do Pentium 4 Prescott, 16kB de L1 write-trought com 4 ciclos de latência e 2MB de L2 com 20 ciclos de latência (acredito que no P4 seja mais, algo como 27 ciclos), a lembrança do fiasco P4 faz achar que o Bulldozer é a mesma coisa, e na época até eu critiquei o cache do P4 (mas não foi só pelo cache) a estrutura também é pouco usual porque outros processadores tem 32 kb enquanto os antigos AMD tem 64kB, mas...

O Bulldozer tem mais do dobro da performance de um Pentium 4 no mesmo clock no 7-zip, quer dizer, talvez quase três vezes mais, se o cache fosse problema um benchmark desses teria um resultado horrível, e parecido com o do P4 por causa das latência, mas não... O L1 do Bulldozer é pequeno (alta taxa de cache-miss) e a latência do L2 é alta (o que sugere uma penalidade alta), mas se considerar outras partes do chip:

1) No Phenom haviam muitos casos onde, quando uma operação ia para o L2 ela travava outras independentes, no Bulldozer isso quase nunca acontece;

2) No Pentium 4 uma instruções era enviada para as unidades de execução 6 ciclos antes de saber se os dados estarão disponíveis, no caso de um miss essas instruções precisavam ser reenviadas para execução ocupando o lugar de instruções úteis, no Bulldozer a instruções só é enviada para execução quando os dados estão disponíveis e ela não atrapalha ninguém enquanto espera;

3) Outras arquiteturas tem caches L1 maiores mas tem 2, 4 e até 8 threads por core, a quantidade de L1 por thread não é maior que no Bulldozer;

4) Finalmente, a quantidade de acessos simultâneos ao L2 no Bulldozer é muito alta.

Conclusão, no benchmark que mais depende de um bom subsistema de memória (caches, unidades load/store, controlador de memória) mesmo bem abaixo do clock alvo o Bulldozer é tão bom ou até melhor que o Sandy Bridge, por que tanta crítica logo na área onde o Bulldozer é bom? Só por que a AMD fez diferente de tudo mundo e achou uma solução diferente (e por sinal, muito boa) para o problema?

[soullforged]

EduardoS, segundo suas explicações, então, porque diabos (além da falta de clock óbvia) o bulldozer fica tão atrás do SB em operações single-thread?

[Nav01]

EduardoS, segundo suas explicações, então, porque diabos (além da falta de clock óbvia) o bulldozer fica tão atrás do SB em operações single-thread?

A resposta o Eduardo já disse:

Não sei porque o Bulldozer é tão lento, se fosse para chutar (além da óbvia falta de clock) eu chutaria na falta de força bruta, mas não é algo que eu va insunuar que os engenheiros da AMD são incompetentes e que eu sei como consertar o Bulldozer.

Segundo o Ziebert (e eu também) os núcleos de inteiros são muito fracos. A AMD vai lançar uma revisão (B3), com foco principal no fortalecimento de inteiros. Então se for esse realmente o problema (além do turbo que não está funcionando direito), o problema estará pelo menos amenizado com o aludido stepping. Quanto ao funcionamento correto do turbo, isso vai depender do patch da MS (o que acredito que não vai vir) e do lançamento do Windows 8.

O Ziebert disse que o Bulldozer tem apenas 02 ALUs contra 03 dos Phenom e dos Sandy, então quanto ao IPC seria muito difícil o Bulldozer batê-los. A solução seria atingir mais altos clocks. O Bulldozer está aproveitando bem as armas (isto é, suas unidades de execução e seus caches), o problema é que as armas são poucas (ou seja, menos ALUs). Quanto à FPU, não sei se precisa ser mais fortalecida, afinal agora ela agora é compartilhada.

[Tárik S.]

Não da para entender o processador tem mais núcleos não birlha nem por um momento!!!!!!

Será que tem alguma vantagem vamos supor que pegamos o FX e o i7 2600k rodamos um programa de burn em 7 threads (no caso do AMD 7 cores) deixamos um thread(AMD 1 core) livre em ambos, neste thread que esta livre( core na AMD) colocamos um programa de benchmark assim poderíamos concluir se em questão de rodar aplicativos em núcleos separados ou thread no caso da Intel qual seria mais eficiente?

[soullforged]

A resposta o Eduardo já disse:

Segundo o Ziebert (e eu também) os núcleos de inteiros são muito fracos. A AMD vai lançar uma revisão (B3), com foco principal no fortalecimento de inteiros. Então se for esse realmente o problema (além do turbo que não está funcionando direito), o problema estará pelo menos amenizado com o aludido stepping. Quanto ao funcionamento correto do turbo, isso vai depender do patch da MS (o que acredito que não vai vir) e do lançamento do Windows 8.

O Ziebert disse que o Bulldozer tem apenas 02 ALUs contra 03 dos Phenom e dos Sandy, então quanto ao IPC seria muito difícil o Bulldozer batê-los. A solução seria atingir mais altos clocks. O Bulldozer está aproveitando bem as armas (isto é, suas unidades de execução e seus caches), o problema é que as armas são poucas (ou seja, menos ALUs). Quanto à FPU, não sei se precisa ser mais fortalecida, afinal agora ela agora é compartilhada.

Perai. Os testes do Sandra mostram o bulldozer forte justamente em inteiros, ou estou viajando?

[Nav01]

Não da para entender o processador tem mais núcleos não birlha nem por um momento!!!!!!

Será que tem alguma vantagem vamos supor que pegamos o FX e o i7 2600k rodamos um programa de burn em 7 threads (no caso do AMD 7 cores) deixamos um thread(AMD 1 core) livre em ambos, neste thread que esta livre( core na AMD) colocamos um programa de benchmark assim poderíamos concluir se em questão de rodar aplicativos em núcleos separados ou thread no caso da Intel qual seria mais eficiente?

Seria o mesmo do que executar um teste com núcleos desabilitados e deixando apenas 01 ativado. Em alguns casos é possível que a diferença em single-thread seja pouca, mas geralmente se sai mal em single-thread.

O FX-8150 geralmente não bate o i7-2600K, mesmo porque é mais barato do que ele, mas existem algumas aplicações onde é possível o FX-8150 bater o i7-2600K.

Enfim, em vários cenários multithread o Bulldozer brilha, mas em single-thread ele é fraco.

[Nav01]

Perai. Os testes do Sandra mostram o bulldozer forte justamente em inteiros, ou estou viajando?

Em ponto flutuante o Bulldozer pontuou 250 contra 201 do i7-2600K.

Em inteiros o Bulldozer pontuou 145 contra 151 do i7-2600K.

Já o teste .Net Multimedia é menos relevante.

OBS: Considere também que são 04 FPUs do Bulldozer contra 04 FPUs do i7-2600K e 08 núcleos de inteiros Bulldozer contra 04 núcleos do Sandy. O Bulldozer só chegou perto do Sandy nos inteiros porque os 08 núcleos trabalharam em conjunto.

[Musketeer]

Pra quem interessar, teste do bulldozer em uma MSI AM3

http://ht4u.net/reviews/2011/amd_bulldozer_fx_prozessoren/index21.php?dummy=&advancedFilter=false∏%5B%5D=AMD+FX-8150+%5B3%2C6+GHz%2C+Turbo%2C+CMT%2C+DDR3-1333%2C+AM3%2B%5D∏%5B%5D=AMD+FX-8150+%5B3%2C6+GHz%2C+Turbo%2C+CMT%2C+DDR3-1333%2C+AM3%5D

[soullforged]

Em ponto flutuante o Bulldozer pontuou 250 contra 201 do i7-2600K.

Em inteiros o Bulldozer pontuou 145 contra 151 do i7-2600K.

Já o teste .Net Multimedia é menos relevante.

OBS: Considere também que são 04 FPUs do Bulldozer contra 04 FPUs do i7-2600K e 08 núcleos de inteiros Bulldozer contra 04 núcleos do Sandy. O Bulldozer só chegou perto do Sandy nos inteiros porque os 08 núcleos trabalharam em conjunto.

Você está invertendo as escalas.

Inteiro Mpix/s é a cor azul, que no caso do bulldozer está representado pela cor vermelho escuro. Inclusive a evolução em inteiros se mostra monstruosa frente ao Thuban.

O bulldozer pontuou 250 enquanto o SB pontuou 201.

Em ponto flutuante, o bulldozer pontuou 145.1 contra 152.3 do sandy bridge.

Isto de certa forma não entra na minha cabeça.

1) Se o bulldozer apresenta em benchmarks sintéticos como mais poderoso que o SB em inteiros e no mundo real a maioria das aplicações usa operações com inteiros, onde está problema?

2) O EduardoS ja mostrou que o sistema de caches do bulldozer é forte, e o benchmark do 7zip confirma isto, onde ele obtém resultados próximos ou superiores ao SB.

Dado estas duas informações, o que diabos falta pra ele se sair bem no resto?

[Nav01]

Você está invertendo as escalas.

Inteiro Mpix/s é a cor azul, que no caso do bulldozer está representado pela cor vermelho escuro. Inclusive a evolução em inteiros se mostra monstruosa frente ao Thuban.

O bulldozer pontuou 250 enquanto o SB pontuou 201.

Em ponto flutuante, o bulldozer pontuou 145.1 contra 152.3 do sandy bridge.

Isto de certa forma não entra na minha cabeça.

1) Se o bulldozer apresenta em benchmarks sintéticos como mais poderoso que o SB em inteiros e no mundo real a maioria das aplicações usa operações com inteiros, onde está problema?

É verdade, inverti as escalas. Considere que 250x201 a favor dos Bulldozer se deve à união das 08 unidades de inteiros e qualquer falta de paralelismo perfeito ou se uma aplicação for otimizada para menos de 08 núcleos, isso vai fazer uma grande diferença contra o FX-8150. Essas unidades de inteiros podem parecer fortes no Sandra, mas individualmente devem ser fracas sim.

[soullforged]

É verdade, inverti as escalas. Considere que 250x201 a favor dos Bulldozer se deve à união das 08 unidades de inteiros e qualquer falta de paralelismo perfeito ou se uma aplicação for otimizada para menos de 08 núcleos, isso vai fazer uma grande diferença contra o FX-8150. Essas unidades de inteiros podem parecer fortes no Sandra, mas individualmente devem ser fracas sim.

É um bom ponto a sua análise. O conceito de SMT da Intel aproveita partes ociosas do processador para dividir processos em trheads e processá-las com mais rapidez (até onde eu me lembre).

No caso do bulldozer, parece que as otimizações tem que ser feitas na unha para tirar proveito do poder de fogo.

Ao meu ver, o problema está mesmo no conceito de como o processador foi criado. Meu problema agora com ele permance quanto ao consumo. Se ele tivesse os resultados atuais consumindo o mesmo que o SB eu daria vários pontos, mas, custando mais, consumindo mais e só fazendo igual em multi-thread fica difícil escolher o bulldozer. Além de toda novela entre placas AM3 e AM3+ que por enquanto parece longe de acabar...

Nav, por outro lado, as unidades não parecem tão fracas individualmente se você comparar com os resultados de inteiros do Thuban.

Por exemplo, onde o Thuban com 6 núcleos pontua 85, o Bulldozer pontua 250. Ou seja, 3x vezes mais com o aumento de 25% nos núcleos, o que me leva a crer que o buraco pode estar mais embaixo, pois nem o Thuban com folga o Bulldozer consegue superar.

Deixa ver se a revisão B3 resolve alguma coisa ou algum patch do mal, porque continua muito confuso, analisar o BDZ.

[Nav01]

Nav, por outro lado, as unidades não parecem tão fracas individualmente se você comparar com os resultados de inteiros do Thuban.

Por exemplo, onde o Thuban com 6 núcleos pontua 85, o Thuban pontua 250. Ou seja, 3x vezes mais com o aumento de 25% nos núcleos, o que me leva a crer que o buraco pode estar mais embaixo, pois nem o Thuban com folga o bulldozer consegue superar.

Deixa ver se a revisão B3 resolve alguma coisa ou algum patch do mal, porque continua muito confuso, analisar o BDZ.

Eu estive analisando os resultados e vi que se o Bulldozer brigasse com 07 núcleos ainda ganharia do i7-2600K no teste de inteiros.

Eu não conheço intrinsecamente o Sandra e por isso não posso arguir algo contra tal software.

De fato está meio confuso sim e certamente deve haver outras coisas envolvidas (além do mal-funcionamento do turbo, claro).

[EribertoTorres]

Mais um teste, dessa vez dos chilenos do CHW.net e a mesma coisa, fail total

http://www.chw.net/2011/10/el-primer-bulldozer-amd-fx-8150-black-edition-zambezi/

Memórias em 1600 MHz, exceto pela placa-mãe e processador, o demais é tudo igual.

[dudaskank]

Pra quem interessar, teste do bulldozer em uma MSI AM3

http://ht4u.net/reviews/2011/amd_bulldozer_fx_prozessoren/index21.php?dummy=&advancedFilter=false∏%5B%5D=AMD+FX-8150+%5B3%2C6+GHz%2C+Turbo%2C+CMT%2C+DDR3-1333%2C+AM3%2B%5D∏%5B%5D=AMD+FX-8150+%5B3%2C6+GHz%2C+Turbo%2C+CMT%2C+DDR3-1333%2C+AM3%5D

só para ajudar, pra quem não sabe Alemão (acho que é alemão rs)

http://translate.google.com.br/translate?hl=pt-BR&sl=auto&tl=pt&u=http%3A%2F%2Fht4u.net%2Freviews%2F2011%2Famd_bulldozer_fx_prozessoren%2Findex21.php%3Fdummy%3D%26advancedFilter%3Dfalse%26prod%255B%255D%3DAMD%2BFX-8150%2B%255B3%252C6%2BGHz%252C%2BTurbo%252C%2BCMT%252C%2BDDR3-1333%252C%2BAM3%252B%255D%26prod%255B%255D%3DAMD%2BFX-8150%2B%255B3%252C6%2BGHz%252C%2BTurbo%252C%2BCMT%252C%2BDDR3-1333%252C%2BAM3%255D

[jonny_br]

Mais um teste, dessa vez dos chilenos do CHW.net e a mesma coisa, fail total

http://www.chw.net/2011/10/el-primer-bulldozer-amd-fx-8150-black-edition-zambezi/

Memórias em 1600 MHz, exceto pela placa-mãe e processador, o demais é tudo igual.

O interessante deste bench ai é que a maioria que rum processador para Games, os caras aplicaram os filtros e o desempenho nos dois games testados foi exatamente o mesmo para os 3 processadores.

[johannesrs]

Só uma pergunta: ok, eu entendo que o bulldozer tenha menos ALUs que os parentes e concorrentes... mas como diabos tu "reforça" uma unidade?????

Edit: tô começando a me perder.... ALU e núcleos de inteiros, assim vocÊs me matam.... um "núcleo de inteiros" é composto por que unidades? E, sim, o BDZ tá um inferno de analisar e descobrir de onde vem. Nesse ponto, parece que o Charlie estaria certo, "Morte de 1000 cortes"... Quando o problema é em mais do que um ponto, é virtualmente impossível apontar exatamente quem é o culpado.

[wencelldta]

Você está invertendo as escalas.

Inteiro Mpix/s é a cor azul, que no caso do bulldozer está representado pela cor vermelho escuro. Inclusive a evolução em inteiros se mostra monstruosa frente ao Thuban.

O bulldozer pontuou 250 enquanto o SB pontuou 201.

Em ponto flutuante, o bulldozer pontuou 145.1 contra 152.3 do sandy bridge.

Isto de certa forma não entra na minha cabeça.

1) Se o bulldozer apresenta em benchmarks sintéticos como mais poderoso que o SB em inteiros e no mundo real a maioria das aplicações usa operações com inteiros, onde está problema?

2) O EduardoS ja mostrou que o sistema de caches do bulldozer é forte, e o benchmark do 7zip confirma isto, onde ele obtém resultados próximos ou superiores ao SB.

Dado estas duas informações, o que diabos falta pra ele se sair bem no resto?

Tua informação acima me deixou encabulado acerca de se sair bem no resto, cache L2 e L3 ele tem bastante (até de sobra), gostei bastante da parte que ele se sai bem em Multi-trhead, mas em Single ele se sai muitas vezes péssimo, seria problema na plataforma ou na litografia da GF em 32nm?

Os Bulldozers não são um FAIL total como andam dizendo em diversos sites, grupinhos em redes sociais e tudo mais, acho que se a AMD parar pra analisar profundamente o que está acontecendo, pode reverter a situação dos FX. Um die gigante nós temos, cache's bem gordos também temos, nova litografia também, o que precisamos mais? ;D

[Nav01]

Nav, por outro lado, as unidades não parecem tão fracas individualmente se você comparar com os resultados de inteiros do Thuban.

Por exemplo, onde o Thuban com 6 núcleos pontua 85, o Bulldozer pontua 250. Ou seja, 3x vezes mais com o aumento de 25% nos núcleos, o que me leva a crer que o buraco pode estar mais embaixo, pois nem o Thuban com folga o Bulldozer consegue superar.

Deixa ver se a revisão B3 resolve alguma coisa ou algum patch do mal, porque continua muito confuso, analisar o BDZ.

UPDATE: O fato de o Bulldozer ter se saído bem melhor que o Thuban no teste de inteiros no Sandra não quer dizer necessariamente que a unidade de inteiros daquele seja mais forte que as ALUs deste último.

O front-end é responsável pela pré-busca e predição de dados, além de carregamento dos dados nos caches. Se o front-end não for bem eficiente, pode sobrar recursos nas unidades de execução, pois estas teriam que ficar aguardando a chegada de novas instruções a serem processadas, ou até mesmo pode ocorrer invalidação de dados, obrigando as unidades de execução a reprocessar as instruções.

É sabido que o front-end do Sandy é muito mais eficiente que o front-end dos Phenom, logo é mais sensata a comparação do Bulldozer vs Sandy para sabermos se as unidades de inteiros do Bulldozer são fortes ou fracas, por não haver um nível de disparidade grande entre a eficiência dos front-end de ambos.

Só uma pergunta: ok, eu entendo que o bulldozer tenha menos ALUs que os parentes e concorrentes... mas como diabos tu "reforça" uma unidade?????

Edit: tô começando a me perder.... ALU e núcleos de inteiros, assim vocÊs me matam.... um "núcleo de inteiros" é composto por que unidades? E, sim, o BDZ tá um inferno de analisar e descobrir de onde vem. Nesse ponto, parece que o Charlie estaria certo, "Morte de 1000 cortes"... Quando o problema é em mais do que um ponto, é virtualmente impossível apontar exatamente quem é o culpado.

Pois é, gostaria de tirar essa dúvida com o Ziebert ou com o Eduardo. Eles dizem que o Bulldozer possui 02 ALUs, porém nos artigos em espanhol que eu tenho lido eles falam muito das ALUs como sendo cada uma das unidades de inteiros. Segundo tais sítios, um módulo Bulldozer é composto por 02 ALUs, isso considerando 02 threads; ou seja, para cada thread 01 ALU. Se o Sandy possui 03 ALUs em apenas 01 núcleo, isso significa que são 03 ALUs para 01 thread. Concluindo com base nisso, seriam 03 ALUs do Sandy contra apenas 01 do Bulldozer.

@Ziebert, poderia nos esclarecer isso direito? O Bulldozer teria mais do que uma ALU em cada uma das suas unidades de inteiros? Alguns artigos mencionam cada uma das unidades de inteiros no Bulldozer como sendo 01 ALU (que são os núcleos, segundo a AMD).

[aziebert]

Nav, a revisão B3 é referente apenas ao processo de fabricação, devem conseguir extrair uns MHz a mais, baixar um pouquinho o consumo, mas só. Revisão na arquitetura só no Piledriver.

soullforged, se não me engano o Sandra já foi otimizado para AVX, FMA, XOP, etc. Então ele é capaz de aproveitar o BD ao máximo.

Programas heavy multihread que forem atualizados para suportar essas novas instruções verão um belo ganho de desempenho tanto nos SandyBridge quanto nos BD, aí sim o BD deve superar o SandyBridge.

Tárik, se você carregar 7 threads em cima de um i7, esse 7º thread rodará sozinho em um núcleo, portanto terá o núcleo todo para sí. Digamos que ele rodará com desempenho 100%.

Mesmo ocupando 100% do núcleo, algumas unidades de execução ainda ficarão ociosas. O objetivo do HT é justamente aproveitar essas unidades.

Então ao carregar um outro programa no 8º thread do processador, ainda tem um pouquinho de CPU sobrando lá, mas digamos que esse 8º thread vai rodar com cerca de 30% do desempenho (em relação a ter o núcleo todo disponível).

30% no máximo, o ganho do HT varia de 5% a 30% com média de 20%.

Fazendo a mesma coisa num FX-8000. Cada thread tem um "cluster" (núcleo) de ALUs próprio, então aquele 8º thread terá seu núcleo físico disponível. E o impacto no desempenho quando ambos núcleos dentro do módulo Bulldozer trabalham ao mesmo tempo é pequeno. Então o rendimento daquele 8º thread será 90% do desempenho de um thread rodando sozinho (tendo todos os recursos do módulo a sua disposição, esses 10% de perda são devido ao compartilhamento do frontend, concorrência no acesso ao cache L2, etc; o que é um rendimento excelente).

Na parte FPU a coisa funciona +- como no i7, ambos threads podem aproveitar as FPUs do módulo na medida do possível. (como ambos threads de um i7 podem aproveitar as FPUs do núcleo na medida do possível).

Quanto a FPU não há com o que se preocupar, as FPUs de um módulo Bulldozer são praticamente equivalentes às FPUs de um núcleo SandyBridge (se não mais, pois suportam FMA, que o SandyBridge ainda não suporta). Só há algumas situações (instruções AVX de 256 bits) onde as FPUs do BD perdem desempenho, mas essas não são muito usadas.

Só reforçando, as FPUs de 4 módulos Bulldozer são mais fortes que as FPUs de 6 núcleos K10 e equivalentes às FPUs de 4 núcleos SandyBridge.

O problema é que 100% do desempenho de inteiros de um núcleo BD (supondo um thread usando um núcleo dentro do módulo, enquanto o outro thread/núcleo está ocioso) equivale a cerca de 70% do desempenho de um núcleo Sandy Bridge (também supondo um thread rodando inteiros dentro de um núcleo Sandy Bridge (enquanto o segundo thread está ocioso)).

Nav, cada "núcleo" (cluster/porção ALU) de um módulo Bulldozer tem 4 unidades: 2 ALUs e 2 AGUs (Address Generation Units). A porção FPU do módulo é composta 2 FPUs de 128 bits mais 2 unidades de MMX.

Cada núcleo K10 tem 6 unidades no pipeline de inteiros, 3 ALUs e 3 AGUs. A porção FPU do núcleo é composta por 3 FPUs de 128 bits (que também suportam MMX).

Cada ALU roda instruções diferentes, no BD as funções da terceira ALU foram integradas às outras duas.

Cada núcleo Sandy Bridge tem ao todo 9 unidades de execução conectadas a 3 dispatch ports (enquanto nos AMDs os pipelines de inteiros e ponto flutuante são separados, nos Intel todas as instruções caem no mesmo buffer para serem enviadas às respectivas unidades de execução). Em cada port você tem uma ALU, uma unidade de SSE e uma FPU, cada unidade roda instruções diferentes (a ALU de uma port roda instruções diferentes da ALU de outra port).

Para referência: http://realworldtech.com/page.cfm?ArticleID=RWT082610181333&p=7