AMD Bulldozer / Bobcat / Zambezi - Plataformas.

[johannesrs]

@Nav: Eu tô errado, ou isso apontaria para o front-end do bulldozer? e ele como pior, ainda que por pouco, que nos Thuban????

@Ziebert: será mesmo que não vai ter nenhum ajustezinho da arquitetura? revisão, ok, mas algo tipo os venice que incluiram até SSE3 (não que precisemos de mais instruções agora) na mesma arquitetura será que também tá fora da mesa?

E Zie, tem um problema nos teus números. Se for assim, digamos um núcleo de SB com HT renderia 130% no máximo do núcleo SB sem HT. O BDZ um núcleo renderia 70%, mas o módulo todo deveria passar por quase nada com 133% (70% + 90%70%)... e não parece ser isso o que acontece...

[soullforged]

Nav, cada core teria duas ALU's, então seriam quatro por módulo.

Retirado o artigo: http://www.realworldtech.com/page.cfm?ArticleID=RWT082610181333&p=7

No artigo da Wikipedia consta o seguinte:

Each module has the following independent hardware resources [8][9]:

up to 2048 kB L2 cache per module (shared between the cores in a module)

16 kB four-way L1 data cache (way-predicted) per core and two-way 64 kB L1 instruction cache per module, one way for each of the two cores[10][11][12]

Two dedicated integer cores

- each consists of two ALU and two AGU which are capable for total of 4 independent arithmetic and memory operations per clock per core

Fonte: http://en.wikipedia.org/wiki/Bulldozer_%28processor%29

Grosso modo, cada modulo contem 2 integer cores dedidcados, e cada um deles possue duas alus e duas agus.

Se realmente esta conta tá certa eu deixo pro Ziebert e pro EduardoS.

[aziebert]

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.

[johannesrs]

Acho que um de nós não entendeu o outro nos números, zie.

Outra coisa, em FPU: então o Thuban tem 6 núcleos * 3 FPU = 18 FPU. Enquanto que o BDZ tem 4 módulos * 2 FPU = 8 FPU??????????

No SB nem sonho em entender a conta...

[aziebert]

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

[Nav01]

Eu estive muito pensativo quanto à eficiência das FPUs quando 04 threads são concentradas em 02 módulos, não a toa. Eu ainda não havia comentado aqui porque é difícil você argumentar algo sem um bom respaldo técnico de outras pessoas.

O que acontece é o seguinte: Em aplicações otimizadas para até 04 núcleos, se essas aplicações usam ponto flutuante intensivamente e o Bulldozer concentra o processamento em apenas 02 módulos (2CU, 4C), logo pode haver um gargalo da FPU, visto que serão 04 threads para 02 FPUs. Um tópico muito bem feito foi aberto por um novato do MadboxPC:

http://www.madboxpc.com/foro/topic/161318-la-verdad-sobre-el-amd-fxo-bulldozer/page__view__findpost__p__1571647

Seria muito difícil o SO reconhecer quando uma aplicação exigisse alta carga de ponto flutuante, então pensei na ideia de uma implementação no Overdrive da seguinte forma:

O Overdrive passaria a ter uma caixa de combinação com a opção de escolha por parte do usuário, contendo 02 opções: "Priorize o uso do turbo" e "Priorize o uso intensivo de ponto flutuante". O chato é que isso teria que ser feito de forma manual (teria que usar o Overdrive).

[EduardoS]

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

A grosso modo os testes do Sandra não dizem m**** nenhuma.

Esses testes que dizem "integer" usam as unidades MMX, não as unidades de inteiros.

Aqui ao menos usa a unidade de inteiros.

E a pergunta que fica no ar, que diabos o Sandra faz? Qual a tarefa que ele executa? Mandelbrot? Sem saber a tarefa é difícil julgar qualquer coisa.

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?

O que os benchs sintéticos fazem? É o mesmo que aplicações no mundo real?

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.

Cada núcleo possui duas ALUs, cada módulo dois núcleos, quatro ALUs.

Outra coisa, em FPU: então o Thuban tem 6 núcleos * 3 FPU = 18 FPU. Enquanto que o BDZ tem 4 módulos * 2 FPU = 8 FPU??????????

Tanto o Thuban quanto o Sandy Bridge em FPU por núcleo tem uma unidade de multiplicação e unidade de adição, o módulo do Bulldozer tem duas unidades FMAC, que podem fazer, multiplicações, adições e multiplicações fundidas com adições.

[johannesrs]

@Nav: Deixa eu ver.... a afirmação dele gira em torno de que um processo, que vai ser composto por partes de inteiros e partes de float, é "core bound" e, portanto, a menos que o SO identifique pra onde despachar o processo exatamente, iria dar *****, é isso?

Pergunta, isso já não deveria dar ***** também no HT? E o ponto mais complicado do BDZ em single não parecer ser inteiros ao invés de float???

@EduS: continua sendo 8 x 18... ou tu quer me dizer que FPU <> FPU numa mesma arquitetura?

@Zie: te respondo depois.

[jonny_br]

Ziebert, acho que teus números seriam melhor vistos assim:

Cada núcleo Sandy Bridge com HT => 130% ou se preferir 65% por thread.

Cada núcleo Bulldozer => 70%

isso dar ao Bulldozer uma ligeira vantagem em processar 8 threads, 7% sobre Sandy Bridge.

1º Problema é processar apenas um thread.

10% pró Sandy Bridge, o HT aqui não faz diferença.

2º Problema, processar 2 threads.

Bulldozer tem duas opções:

a) 70% + 70% usando um módulo, isso dar 60% em desvantagem contra Sandy Bridge pois não o O.S não aloca thread em HT quando tem núcleo físico disponível.

90% + 90% usando dois módulos, diminue a desvantagem contra a Sandy Bridge, porém é mais gastão e o O.S não sabe a diferença entre módulo e núcleo.

Resumindo: "se corre o bicho pega, se ficar o bicho come." para usuário final, Bulldozer deixa a desejar.

[Nav01]

@Nav: Deixa eu ver.... a afirmação dele gira em torno de que um processo, que vai ser composto por partes de inteiros e partes de float, é "core bound" e, portanto, a menos que o SO identifique pra onde despachar o processo exatamente, iria dar *****, é isso?

Pergunta, isso já não deveria dar ***** também no HT? E o ponto mais complicado do BDZ em single não parecer ser inteiros ao invés de float???

Em ST sempre há apenas 01 FPU para apenas 01 thread e a FPU é forte o suficiente para responder por apenas 01 thread.

No Sandy i7-2600K, há 04 núcleos físicos, além daqueles [exclusivamente] lógicos. A ordem natural é que se dê prioridade para os 04 núcleos físicos e, em caso de aplicações otimizadas para mais do que 04 threads os núcleos lógicos sejam usados a medida que sobra espaço de processamento nos núcleos.

Logo, em aplicações otimizadas para até 04 núcleos o Sandy levaria vantagem em aplicações que utilizem FPU intensivamente, a menos que no Bulldozer esteja configurado para utilizar 01 núcleo por módulo, o que faria com que as 04 FPUs fossem utilizadas.

[telminão]

Continuando com a onda de análises em torno do Bulldozer, o charged3800z24 membro do XS, está fazendo uma análise interessante, confrontando o Bulldozer FX 8120 contra um Thuban 1100t, a análise está sendo feita em cima do Windows 7 e no Windows 8, o legal dessa análise é que pode-se ter uma ideia a respeito do problema do Scheduler, e se realmente haverá ganhos de desempenho com a nova versão do Win8

segue o link é bom ficar atento pois, a análise ainda está no começo e vai levar alguns dias para ficar completa. Mas... já há um gráfico

http://www.xtremesystems.org/forums/showthread.php?276024-FX-8120-vs-1100t-stock-OC-and-Windows-7-vs-Windows-8

Óbvio que o Windows 8 ainda não está na versão final, então certamente teremos alguma variação até a versão final, mas... da para ter uma ideia de como as coisas poderão ser, ao menos com os processadores que estão saindo antes da próxima revisão.

[soullforged]

O que os benchs sintéticos fazem? É o mesmo que aplicações no mundo real?

Não sei meu amigo, é por isto que to perguntando...

Se as pessoas da área não conseguem dar razões finais para o problema, eu que entendo de informática o que aprendi nos fóruns da vida com certeza não sei.

[aziebert]

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

[Nav01]

Não sei meu amigo, é por isto que to perguntando...

Se as pessoas da área não conseguem dar razões finais para o problema, eu que entendo de informática o que aprendi nos fóruns da vida com certeza não sei.

Ele disse que o primeiro bench do Sandra que você postou usa MMX; não precisa nem se preocupar com aqueles números, eles não te dirão nada a respeito da força bruta das unidades de inteiros do Bulldozer.

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.

Sim, você está falando das unidades de execução. São bem mais fortes que as do K10, só que passa a compartilhar tais unidades. Ao invés de 256 bits disponíveis de FMAC e do MMX, tériamos 128 bits de FMAC e mais um MMX por thread. Pode ser que mesmo assim as FPUs do Bulldozer se sobressaiam ante os Phenom, porém contra os Sandy o compartilhamento das FPUs fica mais complicado, imagino eu.

[aziebert]

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

[soullforged]

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

Pera, Xande, você está dizendo que em termos de CPU Trinity e Llano serão a mesma coisa?

Ou seja, o lançamento não resolveria o problema de performance atual, que é o principal problema apontado pro Llano.

Se o próprio Llano já é produzido em 32nm então eu realmente não vejo lógica no lançamento do Trinity. Se for pra mudar apenas a parte GPU, poderia-se continuar usando o K10, e concentrar esforços e recursos em produzir um núcleo bulldozer melhor...

Prevejo futuro negro para a AMD.

[Diego Paladin]

Pera, Xande, você está dizendo que em termos de CPU Trinity e Llano serão a mesma coisa?

Ou seja, o lançamento não resolveria o problema de performance atual, que é o principal problema apontado pro Llano.

Se o próprio Llano já é produzido em 32nm então eu realmente não vejo lógica no lançamento do Trinity. Se for pra mudar apenas a parte GPU, poderia-se continuar usando o K10, e concentrar esforços e recursos em produzir um núcleo bulldozer melhor...

Prevejo futuro negro para a AMD.

Não acho a perfomance do Llano problemática, acho o consumo (logo eficiência) problemática, e infelizmente é onde o BDZ peca muito, difícil acreditar que o Piledriver não pecará também.

Sobre futuro negro, a AMD sobreviverá ao BDZ, mas se as coisas não melhorarem pelo menos naquele ritmo de 10~14% ao ano daquele roadmap, aí a casa cai.

Pensando otimisticamente, se o BDZ é isso tudo de ruim significa que tem muito espaço para melhorar.

[aziebert]

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

[Nav01]

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

Eu não estou dizendo em escolher programas. O Overdrive permite alterar ajustes no processador que são feitos via BIOS.

Suponhamos que você vai jogar durante 02-03 horas. Você poderá escolher previamente, via Overdrive, a otimização adequada para aquele cenário.

Vai codificar um vídeo de DVD dual-layer? Da mesma forma você poderia escolher a otimização adequada para esse cenário.

Todavia se a FPU dá conta do recado, estando o turbo funcionando beleza, de fato talvez não haja necessidade destes ajustes temporários.

[aziebert]

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.

[Dragum]

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

O BULLDOZER parece que vai se dar melhor sem o L3, que parece tomar um espaço desnecessário no die, principalmente nesse projeto de 4 blocos de 2M. Mas só se melhorarem a latência do L2, pois este é realmente muito lento, até comparado a K10, mesmo que seja mais "esperto" como o EduardoS falou. O L3 em sí, não ocupa tanto espaço, mas tem um monte de transistores ligando os 4 blocos de 2M que também serão aproveitados (né?).

Como o módulo em sí é pequeno, pode-se adicionar a Radeon e mesmo assim atingir clocks bons, como você citou.

Temo um pouco o fato do K10 perder pouco desempenho ao abdicar do L3. Espero que essa característica seja mantida, ou o trinity vai ser mais patético ainda.

[Nav01]

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.

Em um artigo do Rage3d dá para ver as opções de ajuste do Overdrive:

http://www.rage3d.com/reviews/cpu/amd_fx_8150/index.php?p=7#

Você vai ver que pelas screenshots dá para observar que tem como alterar a frequência dos núcleos individualmente, que nem você faria via BIOS. É disto que estou falando.

Interestingly, we found that AMD Overdrive only allows for a maximum of six cores to be Turbo'd, despite the all-core turbo mode being selected.

O problema é que na barra deslizante parece que não há como escolher o multiplicador em 0x. Em 19,5x a barra já estava muito à esquerda. Mas se a barra não vai até 0x eles poderiam implementar isso. 0x em qualquer clock base = 0MHz.

[aziebert]

Eu estive muito pensativo quanto à eficiência das FPUs quando 04 threads são concentradas em 02 módulos, não a toa. Eu ainda não havia comentado aqui porque é difícil você argumentar algo sem um bom respaldo técnico de outras pessoas.

O que acontece é o seguinte: Em aplicações otimizadas para até 04 núcleos, se essas aplicações usam ponto flutuante intensivamente e o Bulldozer concentra o processamento em apenas 02 módulos (2CU, 4C), logo pode haver um gargalo da FPU, visto que serão 04 threads para 02 FPUs. Um tópico muito bem feito foi aberto por um novato do MadboxPC:

http://www.madboxpc.com/foro/topic/161318-la-verdad-sobre-el-amd-fxo-bulldozer/page__view__findpost__p__1571647

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.

Seria muito difícil o SO reconhecer quando uma aplicação exigisse alta carga de ponto flutuante, então pensei na ideia de uma implementação no Overdrive da seguinte forma:

O Overdrive passaria a ter uma caixa de combinação com a opção de escolha por parte do usuário, contendo 02 opções: "Priorize o uso do turbo" e "Priorize o uso intensivo de ponto flutuante". O chato é que isso teria que ser feito de forma manual (teria que usar o Overdrive).

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.

[Nav01]

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.

Interessante! Quer dizer que o Overdrive só altera o multiplicador em relação ao p-state do turbo? Faz sentido, pois nas screenshots apareceu 19,5x (3,9GHz) e 21x (4,2GHz).

Havia imaginado que o Overdrive seria capaz de alterar o multiplicador do processador.

[Guilherme FW Xavier]

China já é responsável pelo consumo de 50% de processadores Llano:

http://www.digitimes.com/NewsShow/MailHome.asp?datePublish=2011/10/19&pages=PD&seq=212