EduardoS

Será que os yields da Samsung podem subitamente cairem?

É uma coisa de... Sei la... Parece Karma... de repente algo que não tem nada a ver, por exemplo, um acordo judicial e os yields sobem de novo...

P.S.: alguém já estimou onde o 8170 ficaria em performance se for lançado nos clocks previstos em comparação com a concorrência E a seus pais?

Em MT deve ficar igual ao SB, em ST continuaria perdendo feio...

Sim, mais um detalhe. O Xbitlabs usa o LinX para estressas os processadores para o teste de consumo. Ele é praticamente um vírus térmico para a porção FPU do processador... mas é provável que a porção de inteiros do Bulldozer estava sendo pouco utilizada. Acho estranho eles não terem se atentado a esse detalhe.

Virus térmicos precisam ser escritos com a arquitetura específica em mente e, usam as instruções que mais consomem.

Se não me engano o código que roda nos AMD foi feito para os K-7 e reciclado desde então, ele é cruel com o K-7 e seus derivados realmente tirando tudo o que eles tem.

O que roda nos Intel foi feito para os Pentium III e esqueceram de atualizar, nos Core 2 e sucessores ele mal faz cóssegas.

E claro, no Bulldozer também fica sobrando recursos.

um pouco mais fraca que a de um núcleo Phenom, mas anos luz atrás do SandyBridge

O Sandy Bridge só tem 3 ALUs, igual aos Phenom, em força bruta os dois núcleos são praticamente equivalentes.

E mesmo com a arquitetura de pipeline longo, o processo de fabricação não está colaborando em termos de clock para compensar essas fraquezas.

Pois é, força bruta não é tudo, em termos de uso eficiente da força os Phenom pecavam, eles ficavam muito atrás do Sandy Bridge por não conseguir usar todo o armamento disponível, a AMD corrigiu isso no Bulldozer e corrigiu muito bem, o problema é que agora existem menos armas disponíveis e o clock não subiu para compensar...

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.

A unidade de inteiros pode realizar cálculos de ponto flutuante, o que ela não pode é executar instruções de ponto flutuante.

Um número de ponto flutuante é uma estrutura de dados a unidade de inteiros pode muito bem realizar cálculos a partir dessa estrutura, com uma porrada de instruções para se adequar ao formato, a FPU entende esse formato sem instruções adicionais.

Mas para um cálculo de ponto flutuante ser feito com as ALUs o software precisa conter as instruções para isso, não da para um software uma hora rodar na unidade de inteiros e outra hora na FPU.

Outra coisa, aposto que esse cache L2 enorme (2MB por módulo), foi uma decisão desesperada para tentar melhorar a IPC (isso e para agradar o pessoal dos servidores, seu principal público alvo).

Em time que está ganhando não se mexe... Quer dizer, no único time que está ganhando no bulldozer nãos e mexe...

Repetindo o que eu já disse em outros foruns, até agora o único benchmark em que o Bulldozer se saiu bem foi em compressão de arquivos que também é o benchmark desktop que mais depende do cache e subsistea de memória, se a AMD tivesse feito alguma cagada nesse aspecto os resultados seriam ruins.

Bom... Eu não tinha pensado nessa questão de diferença de processo nem de fábrica. Mas vale lembrar que os Bobcat/Ontario saíram em 40nm e são muito eficientes. Está certo que talvez a escolha do processo se dê por conta do IGP embutido na APU, mas é estranho o Llano não ter seguido essa tendência.

1) O Bobcat não passa de 1.6GHz, o Llano chega a 2.9Ghz;

2) O Ontario é ~ 20% CPU e 80% GPU, o Llano é 50% CPU e 50% GPU;

3) O Bobcat foi feito nas tão mal faladas ferramentas automáticas e com isso é fácil mudar ele de um processo para outro, o Llano foi feito na unha e da muito trabalho mudar de processo, quer dizer, tiveram que mudar de qualquer jeito, mas de 45nm SOI para 32nm SOI é muito mais fácil do que de 45nm SOI para 45nm Bulk ou 40nm Bulk, as estruturas (feitas na unha) no SOI são muito diferentes do que no Bulk, eles tiveram um trabalhão no passado para botar o Opteron no SOI.

ViX, fazendo overclock no BD ele perde o turbo, considerou isso nas contas?

O custo I/O estimado não é baseado somente em leituras físicas, caso contrário o banco poderia acabar não decidindo pelo melhor caminho, por exemplo caso uma determinada página de índice esteja no buffer e um outro índice para a mesma tabela não.

Na hora de calcular o plano de execução ele não sabe que paginas estão no buffer ou não, se soubesse e escolhesse indice baseado nisso o indice mais adequado (caso estivesse no buffer) poderia não ser usado e não ir para o buffer nunca, o que prejudicaria queries futuras.

Mas indices quase sempre estão no buffer por serem usados com frequência.

De qualquer forma procurei aqui pra ver se achava algo, não achei nada que dissesse que a estimativa I/O é sempre de leitura física. Não posso afirmar que é ou não, mas posso afirmar que a estimativa exibida é a mesma que ele usa pra si mesmo.

É sempre lógica.

Então se o plano de execução "me enganou", ele enganou também o próprio banco de dados.

Para o banco de dados isso não faz muita diferença...

Ah, a opção para ver número de leituras físicas e lógicas é:

SET STATISTICS IO ON

E também pode te interessar:

SET STATISTICS TIME ON

Tem muito material na web sobre os planos de execução, gosto dese site:

http://sqlblog.com

Esse também tem bons materiais:

http://www.sql-server-performance.com

Após uma procura rápida:

http://sqlblog.com/blogs/joe_chang/archive/2008/03/29/execution-plan-costs.aspx

http://sqlblog.com/blogs/paul_white/archive/2010/08/04/iterators-query-plans-and-why-they-run-backwards.aspx

http://sqlblog.com/blogs/paul_white/archive/2010/07/29/inside-the-optimiser-constructing-a-plan.aspx

http://sqlblog.com/blogs/paul_white/archive/2010/07/29/inside-the-optimiser-constructing-a-plan-ii.aspx

http://sqlblog.com/blogs/paul_white/archive/2010/07/31/inside-the-optimiser-constructing-a-plan-part-3.aspx

http://sqlblog.com/blogs/paul_white/archive/2010/07/31/inside-the-optimiser-constructing-a-plan-part-4.aspx

Fora isso, não vejo aplicação real para zilhões de núcleos em um servidor cuja tarefa seja apenas banco de dados e geralmente 1 ou 2 bases por máquina (real ou virtual), pelo simples fato de que nenhum banco de dados até então consegue escalar linearmente com quantos cores estiverem disponíveis. Creio que haja um limite de escalonamento, a menos que um mesmo servidor sirva várias bases de dados, mas esse não é a realidade da maioria deles e mesmo se fosse, haveria o limite da memória.

Ele não precisa escalar linearmente, precisa escalar melhor do que um cluster, e isso eles fazem.

Uma base milhares de usuários, se o número de usuários dobra e para atender precisa quadruplicar o número de CPUs, bem, é pagar esse preço ou recusar os usuários extras, não tem para onde fugir.

Ah... A escalabilidade das bases mais famosas (Oracle, SQL Server, DB2) é aceitável, não é perfeita mas chega perto, é o que da investir bilhões nesse negócio...

hmm, os planos de execução me enganaram... ta certo.

Le a piada e ignora o post... O que você faz em um forum?

Terrível isso!!! Ao invés de o conjunto de instruções AVX trabalhar a favor, às vezes trabalhou contra o desempenho do BDZ.

E o pior de tudo é que isso reflete mais sobre programas do mundo real. Como os programas de teste sintético são bem otimizados, a perda de desempenho às vezes não aparece, ainda mostrando um pequeno ganho, no caso do Sandra.

Existem duas formas de tirar proveito das AVX, AVX256 e AVX128, o Bulldozer tem unidades de 128 bits e quando o software usa AVX128 existe um ganho, o problema é quando se usa AVX256, ai o Bulldozer quebra cada instrução em duas, se as duas fizeram algo realmente útil, ótimo, não existe perda de performance, se a segunda metade for especulativa ou inútil mesmo ai vem a perda.

Pelo pouco que o Sandy Bridge esse parece ser o caso.

Em BD quanto mais núcleo mais rápido será feito o trabalho do CPU, porém em BD o maior gargalo nunca é a CPU. Não importa quantos núcleos o CPU tenha, veja qualquer plano de execução (no SQL Server se tiver um por aí, selecione uma query qualquer e mande um CTRL + L) que você vai ver ele acusar I/O como sendo disparado o maior custo de qualquer query que você medir.

E os planos de execução te enganaram...

Cada operador tem um custo de CPU e de IO baseado no número estimado de linhas da tabela, esse custo é relativo (se não me engano a base é um Pnetium Pro 166MHz com um ou dois HDs SCSI da mesma época) e ignora o cache do SQL.

A maioria das queries que o plano de execução diz serem limitadas por IO não fazem qualquer IO, não lembro o comando de cabeça mas você pode ver o número de leituras físicas e lógicas em uma execução, as leituras lógicas é o que o plano de execução diz precisar, as físicas é quantas realmente foram necessárias, a diferença entre elas é o que veio do cache do SQL, no caso memória RAM.

Exame que fiz rápido aqui, para uma tabela VAZIA, o custo estimado de I/O ficou quase 30x maior que o estimado de CPU. Tá, a query era ***** e envolvia só um index scan,

Tai um exemplo de query limitada apenas pela CPU... A tabela está vazia, o SQL vai consultar o cache e descobrir isso, ai não vai acessar o disco, só usa um núcleo, mas é uma query ridiculamente leve

mas eu trabalho todo dia com querys cabeludas, todas devidamente indexadas e o custo I/O sempre dá mais alto, por sinal muito mais, por mais order by e group by que tenha.

JOINs pesam mais...

Order By no SQL é meio porco, se o número de linhas for muito alto ele terá que gravar no tempdb, as vezes isso não é realmente necessário, mas ele faz...

Isso de CPU com vários núcleos em servidor de banco de dados é meio ilusão. É importante e quanto mais melhor? Claro que é, mas se e somente se o custo de I/O não for o problema.

Claro que IO também é importante e é até comum empresas não suprirem a necessidade de IO, mas existem empresas que suprem essa necessidade e em muitos casos IO não é problema.

Pegue um site de e-commerce qualquer, ou um forum, esse forum, a quantidade de dados não é muito grande e em geral cabe na memória do servidor (quer dizer, é muito dado, mas a quantidade de memória cresceu muito mais que os dados), existe MUITO mais gente lendo do que escrevendo e de quebra, sempre um admin gosto de recursos de estatísticas (quem postou mais, quem respondeu mais, quem é mais adorado, mais odiado, produto mais vendido, etc) o resultado é um número significativo de bancos de dados que só acessam o disco para escrita, praticamente todas as queries são executadas lendo dados da memória e a única coisa para limitar o desempenho é a CPU.

E em virtualização, como ele se comportaria? Melhor que um X6? Melhor que um SB? Aguentaria rodar 8 máquinas virtuais (cada uma com um core)?

Até meu X4 aguente rodar 8 maquinas virtuais...

O desempenho em virtualização depende do desempenho dele no software que as VMs estiveram rodando.

Hoje a diferença entre um software rodando no metal e na VM é muito pequena, não da mais para tirar leite dessa pedra...

P.S.: agora, vamos convir que os resultados oscilam de um jeito tão esquisito que não tá nem dando pra entender...

Arquitetura nova diferente de tudo que existe, é natural que se comporte de maneira única e por isso os resultados vão oscilar muito de benchmark para benchmark.

Eu importei um vídeo de 500mb, o que na realidade é renderizar o filme para dentro do WMM

Não exatamente, a "renderização" (a compressão do video) ocorre quando se salva esse video em um formato diferente por exemplo.

O seu caso é muito especial, na utilização "normal" do WMM alguém primeiro importa fotos e alguns video e depois salva em formatos diferentes, o processo de importar fotos e video demora mais não muito, o de salvar demora pra valer, com isso toda otimização vai pra segunda parte enquanto a primeira é deixada de lado, empurrada com a barriga, feita nas coxas.

Um efeito colateral disso é a performance imprevisível da primeira parte, as vezes em uma CPU nova e supostamente mais rápida acaba ficando mais lenta.

Passei por isso como consultor quando um software ficou bem mais lento quando as pessoas migravam do Core 2 para o i7.

Pelo tamanho dos videos e o tipo de edição que você faz acho que sai do objetivo do WMM, um software melhor por menos de 50 dolares te renderia resultados MUITO melhores, a diferença entre um i3 2100 e um i7 2600 é de quase 200 dolares e não existe dinheiro para ir do 2600 para cima no WMM que é limitado a 4 núcleos.

Esse papo de CPU pra servidor é estranho.... queria saber a que tipo de servidor eles se referem, porque a maioria dos servidores que conheço são pra banco de dados, completamente gargalados por I/O. Não sei aonde encaixaria 16, 32 ou 1024 núcleos nesses casos aí. Parece que falar a palavra "servidor" está na moda nesses sites de reviews.

Também vejo servidores rodando sites, roteamento de ordens am plicações financeiras e... Bancos de dados que usam tudo o que o processador tem!

Ei... A IBM e a SUN tem monstros com 256 threads para rodar bancos de dados, a Intel chega a 80 threads com o Westmare-EX, esses caras realmente precisam de muitos núcleos!

Sim, já era, por parte da Intel tudo vai continuar como vem sendo, caro e caro. A boa notícia é que qualquer CPU meia boca está rodando com folga o que a maioria dos usuários precisa. Por isso a AMD tem que focar no médio segmento, pelo menos aí a concorrência não pode faltar. Quanto aos tops dos tops, who cares?

Olhando os reviews...

Cagada da AMD ter lançado isso ai... Dois módulo sem L3 ficaria melhor, não, não bateria nenhum i7, mas seria barato de fabricar e eles poderiam substituir os Athlon II X4...

Se vai ter 10% a mais no IPC, terão que ter clocks bem maiores, aqueles planejados anteriormende dos quais o EduardoS falou, coisa de 4 GHz.

4GHz? Eu? Hum... O Bulldozer chegou nos 4GHz... Não mencionei 5GHz em algum lugar?

Phenom I foi triste também. Quando descobriram o bug então... Mas ele tinha um crédito: não era uma nova litografia...

Não era nova mas era a porcaria dos 65nm que nem com os K-8 conseguiam clock aceitável...

Bem lembrado Evandro... 2900XT também não tinha desculpa... As fotos ainda mostravam ovos cozidos sobre o cooler. Nunca vou esquecer...

A 2900XT não foi tão ruim assim, fora os 6 meses de espera, ali foi mais uma questão de posicionamento errado, tanto que um simples shrink transformou em um sucesso.

Será que agora eles podem querer lançar um novo phenom as pressas?

Pra passar vergonha com um chip que não passa de 3GHz?

Ei pessoal... Vamos usar um pouco a cabeça, a AMD preferiu o Bulldozer ao Phenom III porque:

a) Porque não conseguiram um Phenom III melhor;

Porque são burros.

Suponhamos que eu faça o seguinte cálculo: 200 * 3 / 7. O resultado vai ser 85,71.... O cálculo, neste caso, vai envolver ALU e FPU ou apenas FPU?

Depende...:

1) Pode ser feito todo na FPU;

2) Pode ser feito primeiro na ALU e depois passado para a FPU;

3) Pode ser feito todo na ALU*.

*Esse item é o mais interessante, em geral se liga FPU a números não inteiros mas eles também podem ser feitos pelas ALUs, a unidade de inteiros é a "general porpouse unit", ela é capaz de fazer qualquer coisa, lidar com qualquer formato de dados, ela até emulava a FPU dos processadores que não a tinham, a FPU por outro lado foi criada para auxiliar com um formato de dados específico, ela é relativamente rápida para esse formato, mas só faz isso.

Editando vídeo no Windows Movie Maker. Não é sempre que trava, mas é operação pesada. E trava a aplicação, ou demora a soltar, porque eu continuo trabalhando com os outros núcleos. Em geral, meus núcleos não passam dos 20%. Por isso que eu acho que ficar emparelhando uma porção de núcleos não é tão inteligente como manter uns quatro rodando com muito "torque".

Hum... Não sei se o i7 2600 vai te ajudar... 50% mais performance single-thread no benchmark que você viu, não necessariamente em tudo, nesse caso específico eu não teria muitas esperanças... A questão ai é o software...

Porque quando o meu PC trava, o gerenciador de tarefas indica um núcleo trabalhando 100% enquanto os outros cinco observam de braços cruzados, no 0%. No caso do i7-2600, esse núcleo travado nos 100% não teria mais 50% de folga antes de travar? Eu achei que sim, mas posso estar enganado.

Não... Se trava é software mal feito, o i7-2600 também travaria, no máximo destravaria mais rápido.

A propósito, que software é esse?

A maior parte dos programas nem é constituída de cálculos (mesmo que envolvendo inteiros), para ser sincero

Defina "cálculos"...

CPUs estão basicamente o tempo todo calculando, calculando endereços, posições, etc, todos esses cálculos são inteiros.

Como cálculos inteiros são simples as CPUs tem recursos de sobra e eles raramente são gargalo.

No Windows não tem nada disso (até onde sei, pelo menos).

Também tem, você não vê essas otimizações porque o código é fechado...

O EduardoS já falou, repetiu, e provavelmente vai repetir: o clock para a arquitetura do Phenom II, em 32nm, o atual processo, não passa de 3GHz. Com a arquitetura Bulldozer atinge 3,6GHz com o FX8150, com o TDP sugerido de 125W. Pelo que entendi, isso é assim por causa do processo em 32nm não estar bom, a arquitetura do Phenom utilizar mais estágios de pipeline que o Bulldozer e outros pormenores.

Bem...

1) É melhor considerar o clock máximo do turbo do que o clock stock, o máximo do turbo é realmente o máximo que a arquitetura atinge naquele processo de fabricação.

2) O Bulldozer tem mais estágios de pipeline, mas estágios mais curtos.

Isto mesmo, o Bulldozer possui um pipeline mais curto, então é natural que ele alcance frequências superiores.

É o contrário, o Bulldozer possui um pipeline mais longo, com cada estágio sendo menor.

O Pistigrilo e o Evandro estão batendo na tecla de que aquele Llano (Phenom II sem L3) não tem alcançado frequências superiores porque tem GPU no meio e, portanto, não se pode tê-lo como referência no processo de 32nm (segundo eles).

A GPU no meio poderia limitar a tensão máxima, limitar a TDP (que se reduz reduzindo a tensão), orbigar o uso de turbo para frequeências maiores, etc.

A questão é que, o Llano de 100W fica a 1.4V e só atinge 2.9GHz, A GPU não reduziu a tensão e se o problema fosse consumo a primeira coisa a fazer é reduzir a tensão, não tem turbo, se esse limite fosse por consumo o turbo poderia levar a CPU além disso, mas não tem.

E quanto a GPU em si, ela roda com fonte separada, em tensão e clock diferente do resto do chip, assim como a ponte norte, a ponte norte nunca limitou o clock da CPU, certo?

O processo está tão ruim que eles não conseguiriam ao menos os mesmos clocks dos Phenom II ?

Não, não conseguiriam, iriam bater nos 3.0GHz e chorar.

Pelo menos eles reduziriam o consumo e o custo teórico de fabricação, indo mais longe, poderiam fazer X8 e X12 desktops como tem pros servidores..

O problema do Phenom II X6 não é a performance multi-thread, é a performance single-thread, ter ainda mais multi-thread e menos single-thread não ajudaria em nada a AMD.

Mesmo com clock baixo se o Bulldozer aumentar a performance single-thread em 1% será o melhor que a AMD tem...

De novo.. por isso o Vishera está tão próximo, nem uma revisão ou duas vão salvar ?!

Talvez.

era mais fácil migrarem os Phenoms pra 32 nm do que ralar tanto pra fazer um chip novo.

Não, não era, a 3.0GHz o Phenom em 32nm não impressionaria ninguém...

Já perceberam que o "único" problema é só conseguirem atingir 80% do clock planejado?

Mas ele n tem influência nenhuma no resultado do bixin... Deixa o Tio JF quieto.

O trabalho dele é vender o produto, expor as qualidades, não é exatamente sair falando ladainha e prometendo o que não pode cumprir.

E haja "melões" para colocar hélio na CPU.

Acho que era nitrogênio, helio líquido é um treco meio complicado...

Alguém sabe se as versões de 6 e 4 núcleos serão os mesmos que os de 8, porém com módulos desativados?

São os mesmos.

Eu acho que o JF perde o emprego...

No lançamento da HD4870 ela não tinha desempenho superior a GTX280 mas mesmo assim a AMD conseguiu bons reviews, expor as qualidades do produto e explicar dificuldades no desenvolvimento ajuda a ganhar o coração do cliente, a grande grande maioria dos que criticam o suposto desempenho do Bulldozer tem CPUs com desempenho inferior.

Independente dos resultados no dia 12 o departamento de marketing não está ajudando.

K15?

K8 = A64

K9 = AX2

K10 = Phenom

K10.5 = phenom II

K11 = bulldozer?

K15 = Mãe diná?

Só pra ver se não to perdendo nada...

A nomeclatura "K-numero" não é mais usada pela AMD há muito tempo, além do codenome a AMD usa o número da família, que é:

0Fh - Hammer (K-8)

10h - Greyhound (Phenom/Phenom II)

11h - Hammer (K-8) com ponte norte do Greyhound

12h - Husky (Llano)

13h - Não existe... Superstição em hexadecimal??

14h - Bobcat

15h - Bulldozer

O "h" no final significa hexadecimal, onde 0Fh é 15, 10h 16, 11h 17 e 15h 21.

K15 é o resultado do Dick Trace juntando a antiga nomeclatura "K" com o número da família em hexadecimal...

Err... Resultados do Trinity...

Vejam a diferença, a AMD e seus parceiros já estão publicando resultados do Trinity meses antes do lançamento. Isso indica que confiam no seu produto e que ele será bom. É bom? mostra. É brochante? esconde e deixa passar despercebido o máximo possível. É assim que funcionam os lançamentos de CPU.

Uma outra teoria é a mistura de arrogância com falta de concorrência e mais o fato de que o Trinity não tem nada de novo...

O desempenho da CPU do Trinity é o Bulldozer com menos núcleos e menos clock que sai em alguns dias.

A GPU é a HD6970 com menos núcleos e menos clock, e é praticamente impossível a Intel superar com aquela HD3000...

Sem concorrência ninguém tem medo de ser aberto, só ver a Microsoft "dando" o Windows 8 um ou dois anos antes do lançamento.

EDIT: A propósito, cade o link para os supostos resultados?

O interessante é que ele chegou a dizer que quando os fps caiam de 60~62 para 57~59 ocorria o "lagzinho chato". Eu disse ao Joab que não tinha como ocorrer travadas em 57~59fps.

Já vi isso acontecer, a frequência do monitor é 60 hz, se o fps do jogo é maior do que isso cada quadro é exibido no máximo uma vez no monitor, se cai para 59 fps a cada 60 quadros um é exibido duas vezes, ou três, quatro (57 fps), cinco...

Não é algo que impossibilite o jogo, mas é chato, o movimento perde a fluidez, algo que deveria se mover em velocidade constante pela tela passa a mudar de velocidade...

P.S.: vem com essa que é por causa do curso que tu conhece a caixa do viagra, Xita! Ah, e antes que me esqueça: aproveite osd teus cabelos antes do doutorado, huahuahuahua!!!

Conheci uns caras (uns 25 anos) que tinham outra teoria, eles diziam que cada noite era muito cara e só dava para aproveitar umas 2 horas, com viagra (no caso o genérico porque eles são mão de vaca) a noite fica só R$12,50 mais cara mas passa a durar 12 horas...

Os cálculos de natureza escalar são muito simples de serem processados, ante os cálculos de natureza vetorial?

Para o compilador é mais fácil deixar um cáculo escalar como escalar do que vetorizar ele e para o programador é mais fácil fazer tudo escalar do que com vetores.

Para o processador é quase que tanto faz, mas no cálculo vetorial ele faz diversas operações ao mesmo tempo, é por isso que existe MMX, SSE, AVX e todas as GPUs, é uma forma fácil de aumentar os gigaflops sem aumentar a complexidade do processador.

Pode-se afirmar que JF foi modesto em dizer que apenas 80% do que é processado vai para as ALUs?

Pela minha experiência sim, mas minha experiência é tendenciosa (ver adiante).

Ou você conhece alguns outros programas, fora os jogos, que requerem mais de 20% de uso da FPU? (desconsidere Folding@Home, software de natureza científica).

A maioria dos programas que usam FPU são de natureza científica...

Fora esses, alguns simluadores, CAD, renderização 3D, tratamento de imagens....

Não é tão fácil dizer, para cada tarefas existem muitos algorítimos, muitas soluções, as vezes alguns desses algorítimos usam ponto flutuante outras vezes inteiros.

Faço essas perguntas porque nunca fiz esses tais de 'profiles' (nem sabia antes que existe), mas como você já deve estar habituado com isso, talvez possa nos repassar algumas informações interessantes.

"Habituado"? Faz parte do trabalho, faço quando me pagam (exceto Cinebench, claro... Mas por "hobby" são exceções) e a natureza dos programas fica restrita, no meu trabalho bem mais do que 80% são inteiros, até os não inteiros usam inteiros para não perder precisão, outras áreas veêm bem mais ponto-flutuante.

E seria possivel eliminar a FPU dos núcleos, fazendo com que todo calculo de ponto flutuante fosse feito via GPU? Alocar alguns SPs para cada núcleo?

E nos casos de uso intenso de ambos, isso não seria muito prejudicial?

Não, quer dizer, não é possível tirar ponto-flutuante das CPUs.

Além do motivo da compatibilidade existe uma questão de performance.

O principal objetivo da CPU é minimizar a latência, fazer cada operação no menor tempo possível, o objetivo das GPUs é maximizar a quantidade de operações feitas em um período, com milhares em paralelo, GPUs são vetores e boas para códigos que usam vetores (tanto com números inteiros quando de ponto flutuante), mas são extremamente lentas com operações escalares, como exemplo, o Cinebench usa operações escalares e ficaria extremamente lento se essas operações fossem movidas para a GPU, talvez fosse possível alterar o algorítimo para fazer uso de vetores, talvez...

O que a Intel tem feito é adicionar vetores e aumentar o tamanho deles nas CPUs, e em passos pequenos, pessoalmente sou contra isso porque:

1) É difícil minimizar a latência E maximizar as operações por segundo;

2) Pequenos passos significa diversos tamanhos de vetores para otimizar, se é dificl otimizar para grande E pequeno ao mesmo tempo é ainda mais difícil otimizar para grande E pequeno E médio E grande-médio E pequeno-médio...

É mais ou menos a teoria: http://en.wikipedia.org/wiki/No_free_lunch_theorem

Só não sei se isso é específico do BD rodando AVX ou se é deficiência do conjunto mesmo.

Não sei mais detalhes para ter certeza, a princípio, não tem porque AVX rodar mais lento que SSE2, a menos que:

1) Ele esteja usando AVX256 ao invés de AVX128 e as unidades no Bulldozer são 128 bits;

2) Ele esteja usando inteiros com SSE2 e ponto flutuante com AVX128.

Pelo que entendi no contexto é o 1, nesse caso com ponto flutuante

Quanto ao SJ: sem comentários, porque não bato em adversário tombado. Agora, sério: o q tá acontecendo com as ações dela hoje?? E será q a Apple vai fazer jus a fama de ultra-oportunista e vai lançar, por exemplo, uma versão especial do iphone com uma image do Jobs desenhada em relevo pros fãs órfãos???

As ações cairam um pouco...

Mas pelo que entendi dos comentários do desenvolvedor do X264 o BD é um pouco lento para executar SSE e AVX.

Não vi isso nos comentários, que trecho foi?

Uma coisa interessante é que o BD suporta FMA (Fused Multiply ADD) nos registros de SSE.

Registradores SSE são os mesmos que os AVX128.

Outro detalhe que chamou atenção é que operações MOVE (pelo que eu entendi ele se refere a mover dados de um registro a outro) são "de gratis". Isso seria uma novidade exclusiva do AVX, mas o BD faz também para outras instruções.

Essa é uma otimização que existe desde o Barcelona (e desde o Barcelona, só para a FPU), antes das AVX as instruções x86 eram destrutivas, quer dizer, depois de executadas o resultado era salvo em um dos registradores de origem e o valor anterior era perdido, para manter esse valor se usava um MOV antes, o que fizeram no Barcelona é, se existe um MOV seguido por uma instrução que usa o registrador de destino como origem e destino ele junta as duas instruções sem latencia adicional, é meio que uma macro-fusion, mas sem economizar decodificador, e isso era importante no Barcelona (e Bulldozer!) porque a instrução MOV tem uma latencia maior que o habitual, são dois ciclos.

As AVX128 são não destrutivas por isso não precisam dessa otimização, e essa otimização não elimina os ganhos em usar AVX128, a eliminação de MOV usam dois decodificadores onde as AVX128 só usariam um.

O problema é que o compilador mais usado é feito pela Intel, ele pode simplesmente "esquecer" de implementar algumas otimizações para processadores concorrentes, mesmo que elas já sejam suportadas. E a Intel vai muito se preocupar em implementar otimizações que só o concorrente suporta né...

Não, o compilador mais usado é feito pela Microsoft, e esse não inclui muitas otimizações para processadores da Intel e nem da AMD...

A forma como o compilador da Intel identifica e gera as otimizações é vergonhosa, pessoalmente diria criminosa, a EU também não gosta, mas o FCC dos Estados Unidos achou que tudo bem desde que a Intel escreva uma observação na caixa...

O que vejo como ideal seria que todo mundo adotasse como padrão o GCC, por exemplo. E que AMD e Intel fizessem elas mesmas as bibliotecas de otimização para os seus processadores.

O GCC é uma porcaria e o desenvolvimento dele uma zona, dos compiladores atualmente em uso acho que só o da MS faz menos otimizações que o GCC...

Outra dúvida: a AMD faz/comercializa compiladores? Pergunto porque sei que a Intel o faz e seus compiladores tem um ajuste mínimo de códigos que otimiza os mesmos para utilizarem as instruções existentes no processador.

A AMD já teve o AMD C Compiler, hoje eles mantem o desenvolvimento do Open64 mas só para Linux (apesar de uma versão para Windows ser a melhoria mais solicitada essa não parece ser uma prioridade para a AMD...), e é esse que eles usam para mandar resultados para o Spec.

Código que não utiliza SSE2, o compilador se encarrega de minimamente fazer o código utilizar essas instruções, dando uns 10% a mais de desempenho no código não-otimizado.

Isso todos os compiladores fazem, se o programador habilitar o uso dessas instruções...

O problema é que a real vantagem das instruções SSE e AVX é vetorização, quase todos os compiladores suportam auto-vetorização (exceto MS), poucos fazem minimamente bem.

Vetorização para realmente valer a pena depende do suor do programador.

Ah, quanto a pergunta se FMA ajuda no dia a dia, FMA só serve para ponto flutuante, o meu processador só ve ponto flutuante quando estou jogando, mas isso não quer dizer que jogos se beneficiarão muito dessas instruções...