aziebert

Sim, claro que o desempenho com 4M/4C será melhor que 2M/4C. Mas por quanto? É um risco que se corre, se o programa usar muita ALU, você pode perder muito pouco ou até ganhar desempenho, se usar muita FPU pode perder pouco ou muito; mas o consumo em 2M/4C será bem menor então a performance por watt deve ser sempre melhor usando essa estratégia. Como foi levantado antes, programas heavy multithread já estão preparados para usar mais do que 4 threads. Essa estratégia de agrupar os processos em poucos threads serve mais para a execução de programas que usam poucos threads (que tentem a não ser muito pesados) ou vários programas que usam apenas 1 ou 2 threads.

jonny: http://www.hardware.fr/articles/842-9/efficacite-cmt.html O techreport fez algo parecido, usando um bench de 4 threads eles compararam o desempenho na configuração padrão do Windows 7 (threads distribuidos aleatoriamente entre os núcleos = Turbo mal aproveitado), atribuindo processos a 1 núcleo de cada módulo (assim cada thread tem os recursos do módulo todo para si), a 4 núcleos de 2 módulos (o que implica em compartilhamento de recursos, mas melhor aproveitamento do Turbo, é como o Windows 8 funcionará): http://techreport.com/articles.x/21865 Uma observação interessante que fizeram no artigo, o scheduler melhorado do Windows 8 também trará benefícios para sistemas com mais de um processador, aproveitando melhor os núcleos de um processador antes de acordar o segundo, por exemplo, para economizar energia.

Sim, uma instrução por FPU por ciclo. Só usando FMA que é possível fazer duas instruções por ciclo por FPU. Mas até atualizarem o folding para usar FMA....

Já é quase como chutar um cachorro morto, mas o tom's hardware fez um comparativo de eficiência energética. A boa notícia (se é que pode ser considerada boa) é que o FX é um pouquinho melhor que o X6: http://www.tomshardware.com/reviews/fx-power-consumption-efficiency,3060.html http://www.xtremesystems.org/forums/showthread.php?275867-AMD-Bulldozer-Thread&p=4982049&viewfull=1#post4982049

Parece que é só um rebrand mesmo

Diego, ali no Brazos 2.0 a GPU da série 7000 é discreta (a GPU integrada da APU continua lá, porém desativada ou em hybrid power).

jonny, esse Brazos 2.0 é uma pequena atualização da plataforma. A plataforma do Wichita é a Decan. Interessante o chipset A68M com USB 3.0. @EduardoS se o folding tem baixa ILP e pesa mais em FPU o Bulldozer não deveria ser mais rápido que o SandyBridge ? Ou há muita dependência de instruções e no SB os threads se comunicam pelo cache L1 ?

O avanço foi bastante significativo.Não sei quanto do Folding é FPU ou ALU, meu palpite é que a maior parte envolve as ALUs, se não a diferença em relação ao X6 seria menor. Além da IPC alta nos Intel, o HT ajuda um bocado no Folding.

Ambos a 4GHz. Caiu de pouco menos de 3 minutos para pouco menos de 2 minutos por frame (1%). Então o tempo para fazer uma WU completa vai cair de +- 3 horas e meia com o X6 para menos de 2 horas com o BD. Houve uma boa melhora, mas os i7 ainda são bem melhores.

Aos curiosos por saber como o BD se sai no Folding@Home: http://www.xtremesystems.org/forums/showthread.php?276156-F-H-and-Bulldozer BIG ADV Project 2686 ~= 22k PPD Isso @ 4.9GHz Tenho medo da conta de luz do cidadão...

O HyperTransport tem multiplicador próprio, mas sua frequência tem que ser igual ou menor à do CPU-NB. Como todos os FX são desbloqueados, o multiplicador do CPU-NB também é desbloqueado, 2.2GHz (nos de 125w) é o clock padrão, nada impede que você possa aumentá-lo. Pelo que vi o CPU-NB do Bulldozer sobe até 2.6GHz com facilidade: http://www.madshrimps.be/articles/article/1000220/AMD-FX-8150-Bulldozer-CPU-Review/6#axzz1bQ239Nbs

Nav, no Bulldozer, assim como no Phenom, o CPU-NB tem seu próprio clock. No Bulldozer é 2.2GHz para os processadores de 125w e 2GHz para os de 95w. O cache L3 e o Hyper Transport trabalham ao clock do CPU-NB (portanto o HT trabalha a 4400GT/s, em vez de 5200GT/s).

No Sandy Bridge, como o cache L3 funciona no clock dos núcleos, ele é alimentado pelo vcore. O Sandy Bridge tem 3 power planes: núcleos, GPU e System Agent (controladora de memória e PCIe). Os i5 e i7 LGA 1156 tinham apenas 2: núcleos e uncore (controladora de memória, cache L3 e PCIe). Mas o i3 LGA 1156 já tinha 3 power planes (mais um motivo porque não entendo porque a Intel não lançou o Sandy Bridge no LGA 1156, as placas H55 já tinham os 3 power planes). PS. as placas P67 também tem apenas 2 power planes: núcleos e system agent. O i7 LGA 1366 é uma zona. Tem 2 power planes para o processador: núcleos e uncore (cache L3, controladora de memória e QPI). Porém o próprio barramento QPI é alimentado pelo power plane do uncore (VTT), que também alimenta parte do X58 e ainda tem mais um pedaço que recebe alimentação de 3.3v que vem do conector ATX (24 pinos) e outro que compartilha alimentação com as memórias.... O Bulldozer, assim como o Phenom, tem 2: núcleos e CPU-NB (controladora de memória, HT e cache L3). O Llano também tem dois: núcleos e o resto: GPU/controladora de memória/PCIe. Ainda não ví nada concreto sobre o Trinity, mas é provável que tenha 3 também: núcleos, GPU e o controladora de memória/PCIe. Por isso serão lançadas placas FM2. Essa divisão permitirá um melhor controle sobre o Turbo. Mas o Trinity poderá funcionar em placas FM1, porém com Turbo limitado. Algo parecido aconteceu quando o primeiro Phenom saiu, em placas AM2 (não AM2+), por terem apenas um power plane pro processador inteiro, o gerenciamento de energia ficava limitado. Alguns fabricantes optaram por baixar o clock do CPU-NB (para 1.6GHz) e deixar que o cool 'n quiet variasse o vcore (o mínimo era 1.1v, o que é suficiente para o CPU-NB trabalhar a 1.6GHz), para garantir melhor economia de energia (ao custo de um pouco de performance). Lembro que a ASRock N68-S (e derivadas) era assim. Outros optaram por fixar o vcore (assim o vcore não cai quando o processador está ocioso, apenas o clock é reduzido) e manter o CPU-NB a 2GHz para não perder performance. Lembro que a Foxconn A6VMX era assim. Isso tudo porque o CPU-NB não podia mudar de clock em funcionamento. No Bulldozer o clock do CPU-NB pode ser alterado em tempo real (finalmente!).

A porção CPU e a GPU não precisam necessariamente consumir 50% da TDP cada. A soma do consumo máximo de cada pode ser superior à TDP, mas o gerenciamento de energia da APU pode privilegiar um ou outro. Por exemplo, se a GPU em full load consome 60w e os núcleos em Full Load consomem 60w, mas a TDP é 100w. Em jogos (onde a GPU é mais importante) a APU pode limitar um pouco o clock da porção CPU para poder manter a GPU trabalhando em clock máximo. Enquanto em aplicações 2D pesadas, quando a GPU está praticamente toda desligada (mesmo usando o Aero), a porção CPU pode usar uma fatia maior da TDP (que a GPU não está usando) para fazer Turbo em todos os núcleos.

Mas isso seria para o mercado chinês ou porque quase todas as fábricas (que atendem o mundo todo) ficam na China?

O Windows 7 ainda não faz isso, mas é justamente isso que a AMD recomenda e é o que o Windows 8 fará. Mas aplicativos multi thread que pesam muito em FPU provavelmente já são capazes de usar mais do 4 threads. Aqui eu não entendi, não é o processador que controla isso, é o SO.Quanto ao limite do Turbo, como todo FX é desbloqueado, teoricamente você pode configurar como quiser. Aqueles limites impostos pelo Overdrive devem ser uma forma de limitar o consumo. Mas devem haver outros programas (como o clássico K10stat) onde você pode alterar cada p-state do Turbo.

Nav, não é o processador que escolhe isso, é o SO. E ele não tem como "saber" se um programa usa mais ALU ou FPU.

soullforged, considerando que o Trinity tem apenas 2 módulos Piledriver e o Llano tem 4 núcleos K10. Ainda não sabemos exatamente o que a AMD mudou no Piledriver, mas assumindo que seja pouca coisa melhor que o Bulldozer (no máximo 5% a mais de IPC) o Trinity deve ser um pouco a muito mais rápido que o Llano em inteiros (tanto single thread quanto multi thread) e de um pouco mais lento a um pouco mais rápido em ponto flutuante. Por pior que seja, o IPC do Bulldozer/Piledriver é pouco inferior ao do Phenom, mas o clocks são bem maiores (principalmente sob consumo limitado, onde o K10 deve operar perto de 2GHz, enquanto o PileDriver deve operar perto de 3GHz). Em FPU, como são 2 módulos BD/PD vs 4 núcleos K10; o Trinity está em desvantagem em relação ao Llano, mas como as FPUs são bem mais fortes essa diferença deve ser pequena. Daí a analogia em relação ao X3 (a grosso modo, as FPUs de 2 módulos Bulldozer são equivalentes às FPUs de 3 núcleos K10, ao mesmo clock). Mas pense em X4 @ 2GHz (Llano) vs X3 a 3GHz (Trinity).

Nav, como eu falei lá em cima. Em FPU não há com o que se preocupar, mesmo com menos unidades o BD se sai muito bem. Acho que eu só vi um teste heavy multithread FPU onde o FX-8150 perdeu para o X6-1100, no resto todo ele anda colado no i7 2600k. Em programas "heavy single thread FPU" um núcleo tem a porção FPU do módulo toda para si. Programas heavy multi thread FPU é muito provável que já sejam otimizados para mais de 4 threads, aí há compartilhamento das FPUs entre os threads, mas o potencial total de FPU do chip é muito bom. Em "heavy multithread ALU" o Bulldozer se sai muito bem, superando o X6 por uma boa margem, encostando ou até passando o i7 2600k em alguns casos. O problema são cenários ALU que usem apenas 1 ou poucos threads. Aqui além do IPC baixo de cada núcleo, pode haver compartilhamento de núcleos dentro de módulos (o que não chega a ser um problema, pois o rendimento é 90%). Na verdade o problema é quando esse compartilhamento não acontece, pois o processador não pode usar o clock máximo do Turbo (a diferença de clock proporcionada pelo Turbo é mais que suficiente para compensar a perda pelo compartilhamento de recursos pelos núcleos de inteiros dentro do módulo). Isso só será resolvido no Windows 8, que vai agrupar mais os threads em poucos módulos para se beneficiar do Turbo. E não, não é possível escolher se um programa (vamos supor que ele use alguns poucos threads (1 a 4) mas exija mais das FPUs) vai rodar usando ambos núcleos de poucos módulos ou usando 1 núcleo de cada módulo. Ou o sistema é otimizada para uma estratégia ou para outra (não dá pra forçar um ou outro manualmente).

Nav, dois módulos BD têm ao todo 4 FPUs. 4 núcleos K10 tem ao todo 12 FPUs. As FPUs do Bulldozer são bem mais fortes, mas sim, 4 núcleos K10 ainda são mais rápidos que 2 módulos Bulldozer. No caso do Llano vs Trinity, por exemplo. Em heavy multithread o Trinity será UM POUCO mais lento que o Llano em ponto flutuante (pense no desempenho de um Athlon II X3, a menos que a AMD faça milagre no Piledriver a aumente o IPC em pelo menos 10%, aí ficam elas por elas). Mas em aplicações de inteiros deve dar no mínimo na mesma (afinal são 4 núcleos vs 4 núcleos). A arquitetura tem pipeline um pouco mais longo, mas mesmo sendo uma APU (a porção CPU e a porção GPU brigam para usar uma fatia maior da TDP), o Trinity deve trabalhar com clocks bem maiores (justamente pela arquitetura de pipeline mais longo, apesar do processo deficiente). Então o desempenho em heavy multithread de inteiros do Trinity deve ser no mínimo igual ao do Llano (clocks diferentes, mesmo consumo) e na pior das hipóteses um pouco inferior em ponto flutuante (a grosso modo equivalente ao de um Llano X3).

johannesrs, a grosso modo: 2 núcleos BD (1 módulo) = 180% de 1 núcleo BD (um núcleo trabalhando sozinho dentro do módulo). 2 threads SandyBridge (1 núcleo com HT) = 130% de 1 núcleo SandyBridge (um thread sozinho usando o núcleo todo). 1 núcleo BD ~= 70% de 1 núcleo SandyBridge. 2 núcleos BD (um módulo) ~= 95% de 2 threads SandyBridge (1 núcleo com HT) O problema é que como a arquitetura Bulldozer tem pipeline mais longo, o desempenho em heavy multithread é um pouco menor que o do SandyBridge ao mesmo clock e por enquanto o processo não permite que o BD atinja os clocks necessários para atingir seu desempenho ótimo. Se a AMD conseguisse atingir as metas de clock previstas para essa arquitetura (30% a mais que o clock dos Phenom), um FX-8000 top trabalharia a uns 4.5GHz (clock padrão, sem Turbo, mesmo com todos os núcleos trabalhando a 100%). Nessa frequência, o BD mastiga um i7 2600k (3.4GHz) com farinha em heavy multithread, provavelmente supera até o i7 990x (em stock, 3.4GHz). O problema é que como o desempenho single thread é baixo, mesmo com Turbo para uns 5GHz, por exemplo, 1 único núcleo Bulldozer (trabalhando sozinho no processador inteiro) ainda não teria o desempenho de um único núcleo SandyBridge (1 thread trabalhando sozinho no processador inteiro) aos 3.7GHz (clock máximo do Turbo do i7 2600k).

johannes, o frontend do K10 tem 3 decodificadores. O frontend do módulo BD tem 4 decodificadores (para atender ambos núcleos). Segundo a AMD, quando ambos núcleos dentro do módulo BD estão trabalhando em heavy multithread seu rendimento é cerca de 90% (em relação a apenas um núcleo trabalhando sozinho). É um ótimo rendimento, o problema não está no frontend compartilhado.

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

A rev 3.1 já é AM3+ (tem socket preto). Estranho que vários fabricantes anunciaram compatibilidade pelo menos de alguns modelos AM3 normais com os AM3+ e agora voltaram atrás sem dar explicações... 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).

Dick Trace, o problema é que além do consumo elevadíssimo (o BD @ 5GHz deve consumir perto de 300w) ele precisa ser mantido muito bem refrigerado, pois fica instável acima de 60ºC.