Nav01

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

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. Quanto ao consumo do Bulldozer, segue o trecho do artigo do Charlie: 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.

Isso é a Lei da procura e da oferta. A AMD deve estar penando muito com o processo da GF em 32nm (baixos yields). Há pouco tempo atrás fui ver na Newegg e só havia 03 unidades de FX-6100 (limite de 03 por consumidor). Dei uma recarregada na página e agora tem apenas 02. Os outros Bulldozer estão fora de estoque.

No teste de overclock do TweakTown deveriam ter desabilitado 04 núcleos, pois em jogos não há necessidade de mais que 04 módulos e está havendo um problema onde os núcleos não estão sendo desligados por falta do patch no agendador do SO. Nos fóruns estão dizendo que as melhores mobos para o Bulldozer estão sendo ASRock e MSI. ASUS e Gigabyte com problemas (alegam que o problema provem da BIOS). Todavia achei um review onde usaram uma ASRock e outro review onde usaram uma MSI e, em ambos os casos, o over foi levado a apenas 4,6GHz (usando 08 núcleos de forma estável "NOS BENCHS").

Depende. Sabendo-se que em algumas situações o turbo está atrapalhando, ao invés de ajudar e que com o patch do agendador do SO você poderá contar de forma mais consistente com o turbo, que no caso do FX-8150 vai até 600MHz, só esse patch deve dar um incremento estimado entre 7 e 13% (segundo o que eu vi no fórum do XS). O FX-8170 deve ficar de forma mais consistente entre o i5-2500 e o i7-2600 e superará os Phenom II X6 1100T e o X4-980 também de forma mais consistente, mesmo porque o stepping dele será o B3.

Aquele não sei, mas o problema de invalidação de dados do cache L2 é real e já existe patch para o Linux. Duro é oficializar. Mas para quem quiser compilar o patch: http://www.spinics.net/lists/linux-tip-commits/msg13140.html O processo certamente é o responsável por não ter já saído lançamentos com frequência mais alta, como o FX-8170, e também pelo alto consumo elétrico. Porém o funcionamento melhor do turbo depende de patch no agendador do SO. Parece que a MS não vai lançar o patch para o Windows 7, então os BDZ terão turbo otimizado apenas para edições posteriores, como a do Windows 8. Quanto ao Linux, a comunidade é extensa entre as diversas distros e certamente providenciarão um patch.

Quando o FX-8170 for lançado, deverá sair também a revisão para os demais processadores recém-lançados. Sobre o turbo, o Evandro respondeu antes de mim.

Revisão B3 a caminho: http://www.ozeros.com/2011/10/amd-prepara-stepping-b3-para-bulldozer/ Realmente... Havia dado atividade nos demais núcleos, mas agora observei que era o F@H rodando. Encerrei o software e agora deu certo. Mas por que o F@H aparece como se estivesse espalhando na versão Windows (single-threaded)? Considere que em tal processo não ativiei a afinidade para 01 núcleo.

O over foi limitado pela mobo: Fonte: Neoseeker No oZeros conseguiram algo mais decente, com o cooler stock: Fonte: oZeros 5,0GHz com o cooler padrão, debaixo do verde processo de 32nm.

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

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. 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). Llano tem para desktop e para notebook. 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).

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?

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

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

Vai ver que mexeram no kernel da distro. Claro que não vai ser a versão oficial do kernel, mas como o código é aberto, eles podem fazer isso.

Os processos ficam na memória RAM e na memória virtual; o cache do processador serve apenas para adiantar a busca dos dados. O processador trabalha com microoperações; se houver delay, é um tempo desprezível. Entenda que o que já foi processado, simplesmente já foi processado, não havendo necessidade de migração.

O correto é que o agendador otimizado para o Bulldozer agregue processos em um mesmo módulo, enquanto o nível de processamento estiver sendo baixo. Para que o agendador espalharia os processos em vários módulos enquanto apenas 01 já estaria dando conta do recado? Se a MS fizer diferente, tenho por mim que estarão fazendo mal-feito.

Boa parte do dia as pessoas passam com o computador em meia/baixa carga de trabalho. E sempre que isso ocorre o agendador poderá desligar um ou mais módulos. Se estiver usando uma aplicação single-threaded, por exemplo, 03 módulos poderão ser desligados em um octa-core, economizando muita energia.

No Xbit o Bulldozer consumiu menos: De qualquer forma, o agendador do Windows 7 não reconhece módulos, apenas núcleos, e com o Windows 8, além da melhoria do processo em 32nm, além de novas revisões, o Bulldozer ainda se tornará mais eficiente em consumo elétrico.

Ou seja, pressupondo que a GPU consuma 20W (tudo bem que está desativada), a CPU deve consumir por volta de 80W em stock. Over de 3,5GHz - 2,9GHz stock = 600MHz. 600MHz a mais rendeu um TDP de 111W. 110W em relação a 80W corresponde a um incremento de consumo na ordem de 37%, isso para um over de 600MHz. Um Llano sem GPU a 3,5GHz daria para ser lançado hoje com TDP de 125W. Já comparando-se o FX-8150 com o Phenom II X6 1100T, temos os seguintes consumos em watts: O consumo elétrico do FX-8150 se saiu melhor que o consumo do Phenom II X6 1100T (diferença de 34W). E ainda consideremos que o Windows 7 não tem um agendador apropriado para o FX-8150. Em over eles fizeram uma mistureba estressando a placa de vídeo junto, todavia a diferença de quase 40W também se deve ao maior overclock imposto sobre o FX-8150. Opinião do Neoseeker: Agora é nítido como os Sandy economizam muito mais energia que o Bulldozer (e naturalmente do que os Phenom) quando são "overclockados". Referência: neoseeker

Alguns benchs onde o Turbo Core está se desempenhando pior que sem o turbo (ou seja, 600MHz pelo ralo): Fonte: oZeros

Não entendi, o próprio Ziebert falou em dados provenientes da AMD, como assim Intel???

- Em jogos o Bulldozer segura o tranco, mas SB dá conta de processar mais frames por segundo; - Em compressão de arquivos, vai depender do software. No 7zip, por exemplo, o FX-8150 só perde para o i7-2600K; - Em Codificação de vídeos, também vai depender do software. Se for bem otimizado para MT, como o HandBrake e o MainConcept, o FX-8150 só perde para o i7-2600K.

5% em relação ao die; 12% em relação ao módulo. Referência: Wikipedia

Algo que eu estava imaginando baseado naqueles reviews pré-lançamento é que o desempenho de inteiros está meio fraco. O CMT não está trazendo os 80% prometidos, mas logicamente é muito melhor do que o HT. Um artigo do Semiaccurate diz que está previsto um novo stepping para o Q1/12, para prover uma melhora de desempenho especialmente sobre os inteiros. Aí não sei se a melhora vai ser sobre os núcleos individuais ou sobre o CMT. Eis o artigo: http://semiaccurate.com/2011/09/07/bulldozer-finally-shipped-last-week/