AMD Bulldozer / Bobcat / Zambezi - Plataformas.

Roberto91 · 30 de julho de 2011

990FX é igual a 890FX que difere do 790FX porque este tem A-Link um pouco mais apertado, o que causa perdas no desempenho quando o trafego no link está intenso entre o processador e dispositivos I/O (VGA, SATA, Audio, LAM, USB...). O A-Link no 990FX e 890FX é construído sob o protocolo PCI-E 2.0 o que daria o dobro da largura do 790FX, inclusive os outros 7** exceto o 740G.
Provavelmente só seja sentido ai caso monte Bulldozer em placas como: 760G + SB710; 880G + SB850; 990X + SB950, fazendo uso de RAID, Dispositivos USB 3.0 e CrossfireX. Em outras situações é como achar que deve gastar rios de dinheiro pra dobrar as pistas da SP-160 só porque em feriados o congestionamento é inevitável.

É a mesma situação encontrada nas soluções Intel mainstream, onde o DMI gargala.

Outra coisa, PCI-E 3.0, digamos assim, é a largura da ruas, talvez em um determinado momento uma VGA compatível com PCI-E 3.0 tenha um surto de usar toda a largura da rua para fazer uma passeata, não há como provar até o momento que uma VGA compatível com PCI-E 2.0 tenha feito tal façanha no link PCI-E 2.0.

Resumindo, não encuca com isso não, a largura extra do barramento PCI-E 3.0 é melhor aceito em outras aplicações, ex: Co-Processamento, Redes...

Em VGA é puro Marketing.

Mais uma vez obrigado pela explicação. Não faço uso de RAID, tão pouco CrossfireX, mas dispositivos USB 3.0 com certeza irei usar, então pelo que você disse não será perceptível (ao menos para mim). PCI-E eu sei que é puro MKT, principalmente no Mercado de VGAs.

FabioBz · 30 de julho de 2011

O controlador de memória dos Sandy&Júnior é DDR3 1333MHz. Esse é um dos motivos de o uso de memórias mais rápidas não trazer ganhos de performance substanciais...

Foi a primeira coisa que veio a minha cabeça, porém=>

...Luckily, there are additional memory multipliers that support DDR3-1600, DDR3-1866, and DDR3-2133 memory. Some motherboards include support for even higher memory multipliers, but we’ll confine our investigations to DDR3-2133 and below.

Nav01 · 30 de julho de 2011

Foi a primeira coisa que veio a minha cabeça, porém=>
...Luckily, there are additional memory multipliers that support DDR3-1600, DDR3-1866, and DDR3-2133 memory. Some motherboards include support for even higher memory multipliers, but we’ll confine our investigations to DDR3-2133 and below.

Eu penso que nos FSB nós não poderíamos usar essa expressão "Luckily" para memórias em overclock ao superar muito o barramento, afinal o barramento era um gargalo para as RAM.

Com o advento do HT (HyperTransport) e, posteriormente, com o QPI (QuickPath Interconnect) como resposta da Intel à AMD, o barramento, hoje mais conhecido como link, não é mais gargalo para as RAM. Assim, acredito que o suporte à multiplicadores de memória adicionais por parte da mobo não mais sofre com a limitação do barramento como antigamente.

Também por meio dos programas de benchmarking pode-se observar que a diferença pequena é em relação à exploração da RAM por parte de aplicativos no mundo real. Já em se tratando de testes sintéticos, pode-se observar que tais programas conseguem explorar muito bem RAMs com frequência até 2133MHz. Tudo bem que a escadinha dos gráficos não é agressiva, mas se pegarmos uma DDR3 1333MHz e compararmos diretamente com a DDR3 2133MHz, a diferença exibida nos gráficos é grande, exceto para o teste de escrita (nos testes de latência, leitura e cópia a diferença foi considerável). Tais resultados não teriam sido obtidos com a limitação dos tradicionais FSB.

Corrijam-me se eu estiver errado.

EDIT:

Vejam que interessante! O artigo passado pelo FabioBz (link aqui) também compartilha a mesma opinião minha acerca dos testes sintéticos, ou seja, eles consideraram o escalonamento do desempenho das RAMs satisfatório nos aludidos testes.

Contudo, é importante observar acerca dos resultados refletidos no mundo real, que na verdade foram decepcionantes. Mesmo fazendo overclock para 4,8GHz na CPU, a diferença obtida no mundo real foi ínfima entre RAMs de diferentes frequências, embora a requisição de dados tenha sido bem maior que em 3,5GHz.

Isso leva a crer que 4,8GHz nos SB ainda é pouco para que os aplicativos do mundo real (não aplicativos de testes sintéticos) possam explorar todo o potencial de uma DDR3 1333MHz. A explicação para isso deve ser o dual channel, creio. Ah, me lembrei do Evandro questionando: Pra que 3C? Pra que 4C?

Pistigrilo · 30 de julho de 2011

No mundo real, ou seja, tirando os testes sintéticos de benchmarking, parece ser sim o principal motivo.
Sim, haveria limitação em 1333MHz; todavia não deve haver ganhos expressivos acima de 1600MHz, pois a melhora de desempenho já cai muito entre 1600MHz e 1866MHz, pelo menos no teste do Legit Reviews. É possível que as latências mais relaxadas das memo 1866MHz tenham impactado consideravelmente no resultado, resultando na na diferença de apenas 1GB/s no aproveitamento da largura de banda.

Vale ressaltar que os Llanos não chegam no momento sequer a 3,0GHz. Quando subir mais o clock a controladora de 1866MHz garantirá a boa margem.

Concordo contigo. Tem esse fato de os Llano ainda terem clocks medianos, na casa dos 2.0GHz. Se chegarem modelos mais parrudos no mercado futuramente, com uns 3.4Ghz (acho pouco provável, pelo menos a curto prazo), por exemplo, poderá fazer ainda mais sentido usar memórias mais rápidas. De qualquer forma, estamos na era da popularização das memórias DDR3 1600MHz. Talvez ano que vem 1866Hz fique mais comum e barato. Só o tempo dirá.

Eu penso que nos FSB nós não poderíamos usar essa expressão "Luckily" para memórias em overclock ao superar muito o barramento, afinal o barramento era um gargalo para as RAM.
Com o advento do HT (HyperTransport) e, posteriormente, com o QPI (QuickPath Interconnect) como resposta da Intel à AMD, o barramento, hoje mais conhecido como link, não é mais gargalo para as RAM. Assim, acredito que o suporte à multiplicadores de memória adicionais por parte da mobo não mais sofre com a limitação do barramento como antigamente.

Também por meio dos programas de benchmarking pode-se observar que a diferença pequena é em relação à exploração da RAM por parte de aplicativos no mundo real. Já em se tratando de testes sintéticos, pode-se observar que tais programas conseguem explorar muito bem RAMs com frequência até 2133MHz. Tudo bem que a escadinha dos gráficos não é agressiva, mas se pegarmos uma DDR3 1333MHz e compararmos diretamente com a DDR3 2133MHz, a diferença exibida nos gráficos é grande, exceto para o teste de escrita (nos testes de latência, leitura e cópia a diferença foi considerável). Tais resultados não teriam sido obtidos com a limitação dos tradicionais FSB.

Corrijam-me se eu estiver errado.

EDIT:

Vejam que interessante! O artigo passado pelo FabioBz (link aqui) também compartilha a mesma opinião minha acerca dos testes sintéticos, ou seja, eles consideraram o escalonamento do desempenho das RAMs satisfatório nos aludidos testes.

Contudo, é importante observar acerca dos resultados refletidos no mundo real, que na verdade foram decepcionantes. Mesmo fazendo overclock para 4,8GHz na CPU, a diferença obtida no mundo real foi ínfima entre RAMs de diferentes frequências, embora a requisição de dados tenha sido bem maior que em 3,5GHz.

Isso leva a crer que 4,8GHz nos SB ainda é pouco para que os aplicativos do mundo real (não aplicativos de testes sintéticos) possam explorar todo o potencial de uma DDR3 1333MHz. A explicação para isso deve ser o dual channel, creio. Ah, me lembrei do Evandro questionando: Pra que 3C? Pra que 4C?

É! Isso aí só me faz crer que o dual channel realmente foi uma coisa feita muito à frente do seu tempo (e olha que já é antigo nos PCs tops, pois já tinha placas para Pentium 4 e Athlon XP com suporte a ele), então até hoje não há muitos aplicativos que demandem mais banda de memória que o dual channel oferece. E se pensarmos na diferença de clock que as memórias tinham antigamente em relação ao processador e hoje, realmente percebe-se que diminuiu bastante (Basta pensar que um Pentium III de 1.4GHz suportava no máximo memórias SDR 133MHz e hoje processadores ainda na casa dos 3.0GHz acessam a memória a 1333MHz). É claro que tem toda aquela questão da latência e tudo mais, mas também o cache dos processadores aumentou muito (Pentium III = 256KB ou 512KB cache L2; Core i7 = 8MB cache L3), fora as melhorias no TLB e no aproveitamento desse cache, diminuindo a necessidade de o processador acessar a memória, mesmo que hoje haja aplicativos e sistemas operacionais bem pesadinhos. Tem também a questão do controlador de memória interno no processador. Como você bem lembrou o FSB é um gargalo horrível nos processadores que o usam (tanto que a Intel caprichou no tamanho do cache dos últimos Core2Quad [12MB L2] para compensar a perda de desempenho referente ao acesso de memória em aplicativos muito pesados). Mas eu penso que quem tem hoje um Core i7 com triple channel, talvez tenha um fôlego a mais para ficar com o PC daqui uns anos, pela possibilidade de no futuro os aplicativos serem melhor otimizados para aproveitá-lo. Isso é só uma possibilidade, mas é só pensar no camarada que comprou um Athlon XP com dual channel de memórias DDR 400MHz no passado que vamos ver que, talvez naquela época não fosse algo extremamente necessário, mas que hoje ajuda esse PC antigo ao rodar pelo menos tarefas simples, com programas atualizados (e consequentemente mais pesados e otimizados para essas tecnologias que na época dele). O negócio é só que a maior parte dos consumidores dessas novidades tecnológicas caras costumam trocar de PC todo o ano, mas quem comprar os PCs usados deles pelo menos vai ter esse fôlego na configuração.

Bom... Talvez eu tenha viajado um pouco, mas acho que o que falei talvez tenha algum sentido.

FabioBz · 30 de julho de 2011

Espero que a arquitetura Bulldozer possa tirar melhor proveito das altas frequências de memória, seja dando suporte oficial pelo controlador embutido (de preferência) ou através dos multiplicadores da mobo.

Digo isso por ter em vista a plataforma AMD Bulldozer como minha futura plataforma.

Claro que primeiro vou esperar para ver se é a plataforma ideal, mas acredito que tendo essa melhoria com as memos de alta frequência, melhor integração com as GPUs (da prórpia AMD é claro) já será uma boa!

Se vier algo semelhante ou até mesmo superior ao Hyper Trending da INTEL, então será o ideal!

Zeca Pagodinho · 30 de julho de 2011

Concordo contigo. Tem esse fato de os Llano ainda terem clocks medianos, na casa dos 2.0GHz. Se chegarem modelos mais parrudos no mercado futuramente, com uns 3.4Ghz (acho pouco provável, pelo menos a curto prazo), por exemplo, poderá fazer ainda mais sentido usar memórias mais rápidas. De qualquer forma, estamos na era da popularização das memórias DDR3 1600MHz. Talvez ano que vem 1866Hz fique mais comum e barato. Só o tempo dirá.
É! Isso aí só me faz crer que o dual channel realmente foi uma coisa feita muito à frente do seu tempo (e olha que já é antigo nos PCs tops, pois já tinha placas para Pentium 4 e Athlon XP com suporte a ele), então até hoje não há muitos aplicativos que demandem mais banda de memória que o dual channel oferece. E se pensarmos na diferença de clock que as memórias tinham antigamente em relação ao processador e hoje, realmente percebe-se que diminuiu bastante (Basta pensar que um Pentium III de 1.4GHz suportava no máximo memórias SDR 133MHz e hoje processadores ainda na casa dos 3.0GHz acessam a memória a 1333MHz). É claro que tem toda aquela questão da latência e tudo mais, mas também o cache dos processadores aumentou muito (Pentium III = 256KB ou 512KB cache L2; Core i7 = 8MB cache L3), fora as melhorias no TLB e no aproveitamento desse cache, diminuindo a necessidade de o processador acessar a memória, mesmo que hoje haja aplicativos e sistemas operacionais bem pesadinhos. Tem também a questão do controlador de memória interno no processador. Como você bem lembrou o FSB é um gargalo horrível nos processadores que o usam (tanto que a Intel caprichou no tamanho do cache dos últimos Core2Quad [12MB L2] para compensar a perda de desempenho referente ao acesso de memória em aplicativos muito pesados). Mas eu penso que quem tem hoje um Core i7 com triple channel, talvez tenha um fôlego a mais para ficar com o PC daqui uns anos, pela possibilidade de no futuro os aplicativos serem melhor otimizados para aproveitá-lo. Isso é só uma possibilidade, mas é só pensar no camarada que comprou um Athlon XP com dual channel de memórias DDR 400MHz no passado que vamos ver que, talvez naquela época não fosse algo extremamente necessário, mas que hoje ajuda esse PC antigo ao rodar pelo menos tarefas simples, com programas atualizados (e consequentemente mais pesados e otimizados para essas tecnologias que na época dele). O negócio é só que a maior parte dos consumidores dessas novidades tecnológicas caras costumam trocar de PC todo o ano, mas quem comprar os PCs usados deles pelo menos vai ter esse fôlego na configuração.

Bom... Talvez eu tenha viajado um pouco, mas acho que o que falei talvez tenha algum sentido.

Só viajou na hora de falar dos Athlon XP com placas-mãe com suporte a Dual-channel. Como essa arquitetura ainda usava FSB e o processador só era capaz de processar dois bits por ciclo de clock, o FSB representava o maior gargalo para as DDR 400MHz em dual channel. Já o Pentium 4, com 4 bits por ciclo de clock, o resultado era um aproveitamento de mais de 80% da largura de banda oferecida. Claro, no mundo real, o aproveitamento dessa banda de memória talvez não fosse boa, mas o fato é que, num processador soquete A o dual channel era TOTALMENTE desnecessário (talvez com DDR200 fosse útil).

sirroman · 30 de julho de 2011

Espero que a arquitetura Bulldozer possa tirar melhor proveito das altas frequências de memória, seja dando suporte oficial pelo controlador embutido (de preferência) ou através dos multiplicadores da mobo.
Digo isso por ter em vista a plataforma AMD Bulldozer como minha futura plataforma.

Claro que primeiro vou esperar para ver se é a plataforma ideal, mas acredito que tendo essa melhoria com as memos de alta frequência, melhor integração com as GPUs (da prórpia AMD é claro) já será uma boa!

Se vier algo semelhante ou até mesmo superior ao Hyper Trending da INTEL, então será o ideal!

A própria arquitetura do Bulldozer é a resposta da AMD ao hyperthreading.

Só que ao invés de fazer com que 1 núcleo processe dois threads ao mesmo tempo, a AMD duplicou o n° de núcleos de inteiros (e, discutivelmente, de FP, mas ai já é mais complicado). Ou, como a AMD fala no PR dela, ao invés de fazer com que dois threads "fracos" que dividem todos os recursos do núcleo, ela tem dois threads "fortes" que são processados paralelamente sem compartilhamento de recurso (isso falando do processamento em si, outros componentes como cache são compartilhados sim).

Pistigrilo · 30 de julho de 2011

Só viajou na hora de falar dos Athlon XP com placas-mãe com suporte a Dual-channel. Como essa arquitetura ainda usava FSB e o processador só era capaz de processar dois bits por ciclo de clock, o FSB representava o maior gargalo para as DDR 400MHz em dual channel. Já o Pentium 4, com 4 bits por ciclo de clock, o resultado era um aproveitamento de mais de 80% da largura de banda oferecida. Claro, no mundo real, o aproveitamento dessa banda de memória talvez não fosse boa, mas o fato é que, num processador soquete A o dual channel era TOTALMENTE desnecessário (talvez com DDR200 fosse útil).

Realmente os ganhos eram pequenos, mas existiam sim ( https://www.clubedohardware.com.br/artigos/DDR-Dual-Channel-Aumenta-o-Desempenho/405/1 ). Mas naquela época os programas não eram otimizados para aproveitar bem altas taxas de transferências de dados pela memória. Fora que qualquer aumento de desempenho, mesmo que seja na casa dos 5% a 10%, já ajuda o PC a ter mais fôlego quando fica obsoleto. E foi isso que eu quis dizer.

Zeca Pagodinho · 31 de julho de 2011

Realmente os ganhos eram pequenos, mas existiam sim ( https://www.clubedohardware.com.br/artigos/DDR-Dual-Channel-Aumenta-o-Desempenho/405/1 ). Mas naquela época os programas não eram otimizados para aproveitar bem altas taxas de transferências de dados pela memória. Fora que qualquer aumento de desempenho, mesmo que seja na casa dos 5% a 10%, já ajuda o PC a ter mais fôlego quando fica obsoleto. E foi isso que eu quis dizer.

... neste óptica é realmente interessante. Na época não valia a pena, a diferença de preço entre uma placa-mãe com suporte a Dual Channel e uma boa placa sem suporte era muito grande. Se o cara já tivesse em mãos uma placa dessas, comprar um módulo mais era negócio. Comprar um produto desses em segunda-mão, a um preço mais em conta, valia bem a pena, até para um futuro mais distante, como comentaste.

jonny_br · 31 de julho de 2011

Real World Technologies faz uma prévia avaliação entre Sandy Bridge - E e Bulldozer (Interlagos).

http://www.realworldtech.com/page.cfm?ArticleID=RWT072811020122&p=3

FabioBz · 31 de julho de 2011

A própria arquitetura do Bulldozer é a resposta da AMD ao hyperthreading.
Só que ao invés de fazer com que 1 núcleo processe dois threads ao mesmo tempo, a AMD duplicou o n° de núcleos de inteiros (e, discutivelmente, de FP, mas ai já é mais complicado). Ou, como a AMD fala no PR dela, ao invés de fazer com que dois threads "fracos" que dividem todos os recursos do núcleo, ela tem dois threads "fortes" que são processados paralelamente sem compartilhamento de recurso (isso falando do processamento em si, outros componentes como cache são compartilhados sim).

Sim sim, eu li o artigo Por Dentro da Arquitetura AMD Bulldozer aqui do fórum, a questão é saber como será na prática, se é realmente funcional e comparável ao Hyper Threading e o que isso vai impactar no preço final!

jonny_br · 31 de julho de 2011

Sim sim, eu li o artigo Por Dentro da Arquitetura AMD Bulldozer aqui do fórum, a questão é saber como será na prática, se é realmente funcional e comparável ao Hyper Threading e o que isso vai impactar no preço final!

Fábio, entenda assim:

Hyper threading => Duas tarefas para cada funcionário realizar em seu escritório.

Arquitetura Modular => Duas tarefas para cada escritório com dois funcionários. Pena que se vier uma tarefa, um funcionário trabalha e o outro olha.

Modular é mais caro pra produzir, tem tudo pra ser mais econômico em termo de consumo elétrico, e, mais eficiente. Porém é só teoria, em uma tarefa bem paralelizada, os funcionários podem disputar a mesma ferramenta o que causaria perda da eficiência.

Claro, pode ser explicado de maneira mais técnica, mas eu vejo dessa forma, numa linguagem mais simples.

sirroman · 31 de julho de 2011

Sim sim, eu li o artigo Por Dentro da Arquitetura AMD Bulldozer aqui do fórum, a questão é saber como será na prática, se é realmente funcional e comparável ao Hyper Threading e o que isso vai impactar no preço final!

Teoricamente, em trabalhos altamente paralelizados a técnica do BDZ é bem superior à do HT. Na melhor das hipóteses o HT aumenta a performance em até 30%, tendo vezes que incorre até em perda de performance.

O problema é que não tem como saber a performance final do CPU só olhando a arquitetura. Dá para saber as vantagens e desvantagens (por exemplo, em floating point que use AVX o Sandy deve varrer o chão com o BDZ), mas o resultado final só quando vazar algo.

FabioBz · 31 de julho de 2011

Teoricamente, em trabalhos altamente paralelizados a técnica do BDZ é bem superior à do HT. Na melhor das hipóteses o HT aumenta a performance em até 30%, tendo vezes que incorre até em perda de performance.
O problema é que não tem como saber a performance final do CPU só olhando a arquitetura. Dá para saber as vantagens e desvantagens (por exemplo, em floating point que use AVX o Sandy deve varrer o chão com o BDZ), mas o resultado final só quando vazar algo.

Para que a tecnologia Hyper Threading fosse bem aplicada, sistemas operacionais e programas tiveram de ter instruções específicas para dar suporte e poder aplicar essa tecnologia em sua plenitude.

Algo a respeito da tecnologia dos Bulldozer já foi comentado? programas terão de ser otimizados para essa nova tecnologia ou ela será compatível com as instruções de sistemas operacionais e sofware aplicativos otimizados para Hyper Threating? Ou ainda será algo do tipo "plug and play" não necessitando instruções específicas nos sistemas operacionais e programas para que funcione?

Nav01 · 31 de julho de 2011

Fábio, entenda assim:
Hyper threading => Duas tarefas para cada funcionário realizar em seu escritório.

Arquitetura Modular => Duas tarefas para cada escritório com dois funcionários. Pena que se vier uma tarefa, um funcionário trabalha e o outro olha.

Se vier uma tarefa apenas, em qualquer processador multicore apenas um núcleo irá trabalhar, independente da arquitetura. Se houver um aplicativo otimizado para multitarefa, então as tarefas serão distribuidas pelo agendador de tarefas embutido no processador.

Modular é mais caro pra produzir, tem tudo pra ser mais econômico em termo de consumo elétrico, e, mais eficiente. Porém é só teoria, em uma tarefa bem paralelizada, os funcionários podem disputar a mesma ferramenta o que causaria perda da eficiência.
Claro, pode ser explicado de maneira mais técnica, mas eu vejo dessa forma, numa linguagem mais simples.

Teoricamente, em trabalhos altamente paralelizados a técnica do BDZ é bem superior à do HT. Na melhor das hipóteses o HT aumenta a performance em até 30%, tendo vezes que incorre até em perda de performance.

Na verdade pode haver alguma perda de desempenho em tarefas altamente paralelizadas quando a FPU é altamente requisitada. Convém, porém, ressaltar que HyperThreading não utiliza processamento paralelizado e sim compartilhado em multithreading (multitarefas), pois o núcleo lógico não utiliza frequência independente e sim emprestada. Como a utilidade do HT é prover multitarefas, logicamente as tarefas são executadas em paralelo, porém a falta de frequência própria nos núcleos lógicos não abrange todo o conceito de processamento paralelo, onde cada núcleo pode fornecer sua plena capacidade de trabalho simultaneamente. Com base nisto, pode-se afirmar, como o Sirroman disse, que em trabalhos altamente paralelizados a técnica do BDZ é bem superior à do HT.

A eventual perda de desempenho na FPU é devido ao fato de esta ser compartilhada por módulo, mas é exatamente por isso que há economia de energia e de custos (em relação ao multicore convencional, não ao hyperthreading). Para testes sintéticos de benchmarking, como SuperPI, seria muito interessante 02 FPU para cada módulo, mas a FPU compartilhada entre 02 núcleos vai otimizar o processamento de ponto flutuante entre núcleos, tendo em vista que tal unidade, no mundo real, passa boa parte do tempo ociosa.

O problema é que não tem como saber a performance final do CPU só olhando a arquitetura. Dá para saber as vantagens e desvantagens (por exemplo, em floating point que use AVX o Sandy deve varrer o chão com o BDZ), mas o resultado final só quando vazar algo.

O Bulldozer irá suportar o AVX, pelo que eu saiba, inclusive com algumas instruções adicionais ao AVX dos SB.

Pistigrilo · 31 de julho de 2011

Espero que a arquitetura Bulldozer possa tirar melhor proveito das altas frequências de memória, seja dando suporte oficial pelo controlador embutido (de preferência) ou através dos multiplicadores da mobo.
Digo isso por ter em vista a plataforma AMD Bulldozer como minha futura plataforma.

Claro que primeiro vou esperar para ver se é a plataforma ideal, mas acredito que tendo essa melhoria com as memos de alta frequência, melhor integração com as GPUs (da prórpia AMD é claro) já será uma boa!

Se vier algo semelhante ou até mesmo superior ao Hyper Trending da INTEL, então será o ideal!

É especulado que o IPC dos Bulldozer seja superior aos dos Phenom II, ou seja, um Bulldozer com quatro núcleos a 3.2GHz seria mais rápido que um Phenom II X4 955 BE, por exemplo. Mas isso ainda é especulação. não tem como termos certeza disso. Esperamos que venha um bom produto para bater de frente com a Sandy. Dessa forma, pensar em um Bulldozer com oito núcleos, clock de 3.9GHz e turbo de 4.5GHZ parece bastante promissor. Quanto ao HT, o Bulldozer não o terá, como os colegas já te falaram, mas sim uma coisa melhorada, uma espécie de "dupla de núcleos incompletos", que teriam pelo menos em tese um aproveitamento superior ao HT. Ao invés de a AMD lançar um processador de quatro núcleos com HT (oito núcleos virtuais), preferiu lançar um com oito núcleos físicos, sendo que cada núcleo desse trabalharia em dupla, pois são "incompletos". Mais ou menos isso. Ao meu ver essa abordagem parece promissora, mas vamos esperar o lançamento para dizer algo concreto.

Obs.: a explicação do colega jonny_br comparando núcleos a funcionários achei perfeita. Huahuahuha!

jonny_br · 31 de julho de 2011

O Bulldozer irá suportar o AVX, pelo que eu saiba, inclusive com algumas instruções adicionais ao AVX dos SB.

Foi o que ele disse? a diferença é que ser requerido, o BDZ tem FPU de 256bits (128x2) enquanto que o Sandy simula FPU, é isso Sirro?

FabioBz · 31 de julho de 2011

Foi o que ele disse? a diferença é que ser requerido, o BDZ tem PFU de 256bits (128x2) enquanto que o Sandy simula PFU, é isso Sirro?

Sobre AVX sim=> https://www.clubedohardware.com.br/artigos/Por-Dentro-da-Arquitetura-AMD-Bulldozer/2063/2

A arquitetura Bulldozer, além de ser compatível com as instruções x86, suportará os seguintes conjuntos de instruções adicionais:.

*SSE4.1 e SSE4.2

*AVX (Advanced Vector Extensions ou Extensões de Vetor Avançadas) com dois subconjuntos adicionais, chamados XOP e FMA4

*AES (Advanced Encryption Standard ou Padrão de Criptografia Avançada)

*LWP (Light Weight Profiling ou Perfil “Peso Leve”)

Sobre o FPU, seriam as unidades FP mostradas nessa imagem?=> https://www.clubedohardware.com.br/fullimage.php?image=41224

(Fiquei curioso também.)

sirroman · 31 de julho de 2011

Para que a tecnologia Hyper Threading fosse bem aplicada, sistemas operacionais e programas tiveram de ter instruções específicas para dar suporte e poder aplicar essa tecnologia em sua plenitude.
Algo a respeito da tecnologia dos Bulldozer já foi comentado? programas terão de ser otimizados para essa nova tecnologia ou ela será compatível com as instruções de sistemas operacionais e sofware aplicativos otimizados para Hyper Threating? Ou ainda será algo do tipo "plug and play" não necessitando instruções específicas nos sistemas operacionais e programas para que funcione?

Seguinte, não é necessário usar algum tipo de instrução específica para usar o HT. De complexidade a mais, só existe no OS, que "reconhece" o HT e os núcleos virtuais e então torna eles acessíveis aos programas (ou seja, qualquer programa que use mais de um thread pode, teoricamente, tirar vantagem do HT) e dentro do próprio CPU, onde se faz a mágica de distribuir as instruções de uma forma eficiente.

Pelo que eu entendo, ninguém faz código de programa otimizando ele "para HT", se faz o código "para ser multi-threaded" ou até "para CPU Intel".

A vantagem do HT é que, se o código não for muito "bem feito", ele ainda vai ter ganhos de performance. Tanto que tem muita gente que fala (até aqui, lááá atrás) que quanto melhor paralelizado, menor performance o programa terá com o HT, já que menos recursos de cada núcleo estarão "sobrando" para que o núcleo virtual faça algo de útil.

Na verdade pode haver alguma perda de desempenho em tarefas altamente paralelizadas quando a FPU é altamente requisitada.

Não tem nada na arquitetura que leve a isso, até onde eu sei. O que tem é o fato de que, se o programa usar AVX ele não terá nenhum salto de performance.

Nesse caso, se você partir do pressuposto que o programa vai usar AVX, o que pode acontecer é como quando usamos um programa com 2 threads em um CPUs com 1 núcleo. O CPU vai processar da mesma forma que faria se o programa não fosse paralelizado: eu não vejo isso como "perda" de desempenho.

A eventual perda de desempenho na FPU é devido ao fato de esta ser compartilhada por módulo, mas é exatamente por isso que há economia de energia e de custos (em relação ao multicore convencional, não ao hyperthreading). Para testes sintéticos de benchmarking, como SuperPI, seria muito interessante 02 FPU para cada módulo, mas a FPU compartilhada entre 02 núcleos vai otimizar o processamento de ponto flutuante entre núcleos, tendo em vista que tal unidade, no mundo real, passa boa parte do tempo ociosa.

Cada módulo vai ter dois núcleos de inteiros e dois de FP (128bits), a diferença é que qualquer um dos núcleos pode acessar tanto "a sua" quanto a unidade FP "do outro", somando as duas e fazendo com que trabalhe em modo 256bits.

O Bulldozer irá suportar o AVX, pelo que eu saiba, inclusive com algumas instruções adicionais ao AVX dos SB.

Foi o que ele disse? a diferença é que ser requerido, o BDZ tem PFU de 256bits (128x2) enquanto que o Sandy simula PFU, é isso Sirro?

Sim, sim. Enquanto cada núcleo do BDZ terá uma unidade FP de 128bits, elas só podem trabalhar em modo 256bits (AVX) conjuntamente (o módulo inteiro). Na Sandy cada núcleo tem uma unidade FP que trabalha tanto em 128bits quanto em 256bits.

A questão é que (aqui sim) o programa tem que especificamente usar AVX, o que requer que seja compilado de novo e tal.

Então se compararmos um CPU com 4 núcleos BDZ e outro com 4 núcleos Sandy, se o programa não usar AVX, a performance teoricamente seria a mesma (4 de 128bits para cada lado), enquanto se o programa usar AVX, a Sandy terá o dobro da performance teórica do BDZ (2 de 256bits de um lado, 4 do outro).

A performance do BDZ *com* ou *sem* AVX é teoricamente a mesma.

Sobre o FPU, seriam as unidades FP mostradas nessa imagem?=> https://www.clubedohardware.com.br/fullimage.php?image=41224
(Fiquei curioso também.)

Sim.

O marketing da AMD fala que o BDZ vai oferecer a mesma performance com e sem o AVX, ou seja, "ninguém perde performance se não fizer a atualização do programa", o que eles chamam de "Flex FP". xD

Nav01 · 31 de julho de 2011

Cada módulo vai ter dois núcleos de inteiros e dois de FP (128bits), a diferença é que qualquer um dos núcleos pode acessar tanto "a sua" quanto a unidade FP "do outro", somando as duas e fazendo com que trabalhe em modo 256bits.

Pelo que o Gabriel Torres disse, cada módulo só tem 01 FPU, conforme citação abaixo:

A arquitetura Bulldozer tem apenas uma unidade de ponto flutuante, que é compartilhada entre os dois “núcleos” disponíveis.

Link: https://www.clubedohardware.com.br/artigos/Por-Dentro-da-Arquitetura-AMD-Bulldozer/2063/5

O artigo é de ago/2010, talvez esteja desatualizado ou foi informaçãoo errada mesmo. Tô vendo que o GT deve estar me deixando mais por fora da arquitetura Bulldozer do que dentro.

Sirro, quais as suas referências WEB???

EDIT:

Eu imagino que você tenha confundido a FPU com as suas unidades de execução, que são 02 MMX e 02 FMAC de 128 bits. Se confirmada a confusão, persisto em afirmar que nenhum núcleo terá a sua própria FPU, mas sim o módulo que terá a sua própria.

Imagine o diagrama postado pelo FabioBz sob o panorama de um módulo inteiro. Em seguida imagine 01 núcleo do lado esquerdo e 01 núcleo do lado direito em relação à FPU, composta pelas citadas unidades de execução. você vai observar claramente que a FPU é única (em termos de módulo), porém compartilhada entre os threads (núcleos) à sua esquerda e à sua direita.

sirroman · 31 de julho de 2011

EDIT:
Eu imagino que você tenha confundido a FPU com as suas unidades de execução, que são 02 MMX e 02 FMAC de 128 bits. Se confirmada a confusão, persisto em afirmar que nenhum núcleo terá a sua própria FPU, mas sim o módulo que terá a sua própria.

Imagine o diagrama postado pelo FabioBz sob o panorama de um módulo inteiro. Em seguida imagine 01 núcleo do lado esquerdo e 01 núcleo do lado direito em relação à FPU, composta pelas citadas unidades de execução. você vai observar claramente que a FPU é única (em termos de módulo), porém compartilhada entre os threads (núcleos) à sua esquerda e à sua direita.

Ah, sim, sim! Estava me referindo às unidades de execução, da mesma forma que no BDZ só faz duplicar as unidades de execução dos inteiros e chama de dois núcleos (tá, tem o agendador e etc, etc). Tecnicamente você deve estar correto, foi mal pela confusão na nomenclatura.

Mas, para mim, a questão é que tanto essas unidades de inteiros quanto as de FP estão acessíveis não na razão de módulo, mas na razão de núcleo. Caso contrário, se o programa não usar AVX, metade da FPU ficaria essencialmente parada, o que não é o caso.

Ou seja, repito o que eu disse antes: não vejo nada na arquitetura (claro que eu sou leigo nisso e só falo por tudo que eu vi nesse tópico e em matérias sobre a arquitetura) que leve a crer em uma *perda* de performance em programas altamente paralelizados.

Pelo contrário, joga 8 threads pesados em FP, sem AVX, que o FX-8000 segura tranquilo. E se o programa utilizar AVX a performance teórica é a mesma pelos próprios ganhos do AVX.

Enfim, é exatamente por essa organização que a Sandy deve varrer o chão com o BDZ em FP em AVX.

jonny_br · 31 de julho de 2011

Sirro, define melhor o 'varrer o chão", se estou entendendo é como comparar um Athlon x2 a um Pentium HT.

sirroman · 31 de julho de 2011

Sirro, define melhor o 'varrer o chão", se estou entendendo é como comparar um Athlon x2 a um Pentium HT.

Rapaz, tá lá atrás o pessoal falando do pico de performance teórica. A Sandy tinha o dobro. O ponto principal é que enquanto em inteiros deve melhorar bastante, o FP não acompanhou: se o BDZ perder em FP, isso será "esperado", saca?

Nav01 · 31 de julho de 2011

Mas, para mim, a questão é que tanto essas unidades de inteiros quanto as de FP estão acessíveis não na razão de módulo, mas na razão de núcleo. Caso contrário, se o programa não usar AVX, metade da FPU ficaria essencialmente parada, o que não é o caso.

Também acredito que o processamento se dê por núcleo.

Ou seja, repito o que eu disse antes: não vejo nada na arquitetura (claro que eu sou leigo nisso e só falo por tudo que eu vi nesse tópico e em matérias sobre a arquitetura) que leve a crer em uma *perda* de performance em programas altamente paralelizados.

Rapaz, tá lá atrás o pessoal falando do pico de performance teórica. A Sandy tinha o dobro. O ponto principal é que enquanto em inteiros deve melhorar bastante, o FP não acompanhou: se o BDZ perder em FP, isso será "esperado", saca?

Teoricamente, não vejo porque os Sandy terem maior desempenho que os BDZ na FPU. Em monotarefas, a FPU do BDZ estará disponível, no caso, apenas para 01 thread.

Já se considerarmos o processamento paralelizado, sabemos que o processamento de ponto flutuante deve se dar por meio de uma FPU para cada 02 núcleos, entretanto os Sandy também usam apenas uma FPU para 02 núcleos lógicos (com HyperThreading).

Note que o que estou querendo dizer é que para 08 núcleos, por exemplo, os Bulldozers dispõem apenas de 04 FPUs, o que em tese processa menos que se fossem 08 FPUs, porém Sandy tem apenas 04 FPUs também (núcleos lógicos não se conta).

Todavia, não espero que o Bulldozer tenha FPU superior ao Sandy, apenas não tenho bases teóricas para concluir que a FPU do SB seja superior e, portanto, não posso antecipar nada a respeito.

EDIT:

Ou você está se referindo à diferença de desempenho da FPU apenas no tocante à utilização de instruções AVX???