EduardoS

Vejo que tentei simplificar demais... Onde está "operação" troque por "instrução", e no caso, eram apenas instruções de soma ou multiplicação. O número de operações é um pouco maior, como as unidades são SIMD e 128 bits da 4 operações por ciclo por FMA para precisão dupla (2 somas e 2 multiplicações) ou 8 operações por ciclo por FMA para precisão simples, o folding@home usa precisão simples e, ao contrário do Cinebench, usa vetores. Não cada FMA só executa uma instrução por ciclo mas uma das instruções que ela executa (a famosa FMA) faz multiplicações e somas.

50% mais GFlops.

Estou ciente de todos os porblemas do F@H quanto a benchmarks. ILP baixa significa dependencia de instruções é dentro da mesma thread. Com baixa ILP ambos deixarão unidades vazias, esperando que algumas instruções terminem, o SandyBridge tem latências menores que o Bulldozer por isso essas instruções terminam antes.

Hum... Uns 70% é FPU. Se o HT ajuda muito é um sinal de que o ILP (a "independencia" entre as instruções) é baixo e por isso o programa deixa unidades vazias, é um dos "melhores casos" para processadores estreitos como o Bulldozer, ainda assim o ganho de 16% por thread sobre o Thuban no mesmo clock apesar das latências mais altas da FPU foi impressionante, talvez esse ganho seja mérito do subsistema de memória, em relação ao Sandy Bridge eu esperaria um desempenho por thread por clock um pouco menor, alguém tem números?

Não leve os comentários do Cliff tão a sério...

Li a original e depois a notícia, a AMD falou uma coisa o jornalista escreveu outra... A AMD já tinha dito que pretendia entrar nesse mercado mas a competição com os Mac Book Air seria difícil.

Um transistor pode consumir de dois modos, consumo estático e dinâmico, O estático é o que ele sempre consome, é proporcional ao quadrado da tensão, "leakage" e tal, mas em geral é pequeno por transistor. O dinâmico é o que ele consome quando muda de estado, é proporcional ao quadrado da tensão e ao clock (número de mudanças de estado), esse é o principal. Caches não mudam de estado com frequência, então o consumo predominante neles é o estático, e o consumo estático é baixo, os 16MB de cache que o Bulldozer tem de L2 e L3 não devem consumir nem 10W, alias, esse é um dos motivos deles adorarem colocar mais cache em chips caros, caches consomem pouco então é uma forma fácil de aumentar a performance e performance por watt. E no caso da GPU, pelo clock e tensão mais baixa que o núcleo principal ela deve consumir bem menos, não da para comparar com o processo da TSMC porque esse não é SOI. Não encontrei o quote do Barts, enfim... Ele era mais eficiente porque era melhor balanceado, algo que também parece faltar no Bulldozer...

@Zie: te respondo depois. Vocês estão contando a "FMISC" como FPU, a FMISC não faz nada comparável às FMACS do Bulldozer, nessa comparação só pode usar a FADD e FMUL, quer dizer, duas FPUs por núcleo do K10. Exatamente. No Phenom se só existir somas ele fica limitado a uma operação por ciclo, se só existirem multiplicações também, uma operação ciclo, para atingir duas operações por ciclo só se for 50% soma e 50% multiplicação, no Bulldozer as FPUs fazem as duas operações, sendo só soma são duas por ciclo, só multiplicação duas por ciclo, qualquer proporção entre uma e outra são duas operações por ciclo.

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. O que os benchs sintéticos fazem? É o mesmo que aplicações no mundo real? Cada núcleo possui duas ALUs, cada módulo dois núcleos, quatro ALUs. 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.

1) Não é fácil de fazer; 2) Algumas tentativas que houvi falar em outras arquiteturas foram um fiasco. Não me referi a você e nem a ninguém desse forum, mas ao Charlie que parece querer ensinar os engenheiros a fazer um processador, não é a primeira vez que ele fala mais do que deve. Estão em linhas com outros caches com mesmo clock e tamanho. Essa crítica acredito ser irrefutável... O segredo é não falar muito Não sei porque o Bulldozer é tão lento, se fosse para chutar (além da óbvia falta de clock) eu chutaria na falta de força bruta, mas não é algo que eu va insunuar que os engenheiros da AMD são incompetentes e que eu sei como consertar o Bulldozer. E o que mais me incomoda, o Charlie critica a primeira coisa que viu pela frente e que seria fácil de arrumar se fosse o problema (e, sendo assim, já teriam testado e arrumado...) sendo que testes me dizem que isso não é uma qualidade e não um problema... 12 ciclos para o Phenom II e 20 ciclos para o Bulldozer, mas o L2 do Bulldozer é maior e visa clocks mais altos. No fim, é o esperado. Compressão de arquivos se beneficiam muito de todos os caches. Ai que ta... Com 2MB de L2 ele quase sempre vai achar o que precisa no L2... Reduziria a latência em 2, 3 talvez 4 ciclos, não pela metade, e criaria mais trafico de snoop, quer dizer, se fosse tão simples, já teriam feito... Voltando ao ponto do L2, o Bulldozer tem uma estrutura de caches muitíssimo parecida com a do Pentium 4 Prescott, 16kB de L1 write-trought com 4 ciclos de latência e 2MB de L2 com 20 ciclos de latência (acredito que no P4 seja mais, algo como 27 ciclos), a lembrança do fiasco P4 faz achar que o Bulldozer é a mesma coisa, e na época até eu critiquei o cache do P4 (mas não foi só pelo cache) a estrutura também é pouco usual porque outros processadores tem 32 kb enquanto os antigos AMD tem 64kB, mas... O Bulldozer tem mais do dobro da performance de um Pentium 4 no mesmo clock no 7-zip, quer dizer, talvez quase três vezes mais, se o cache fosse problema um benchmark desses teria um resultado horrível, e parecido com o do P4 por causa das latência, mas não... O L1 do Bulldozer é pequeno (alta taxa de cache-miss) e a latência do L2 é alta (o que sugere uma penalidade alta), mas se considerar outras partes do chip: 1) No Phenom haviam muitos casos onde, quando uma operação ia para o L2 ela travava outras independentes, no Bulldozer isso quase nunca acontece; 2) No Pentium 4 uma instruções era enviada para as unidades de execução 6 ciclos antes de saber se os dados estarão disponíveis, no caso de um miss essas instruções precisavam ser reenviadas para execução ocupando o lugar de instruções úteis, no Bulldozer a instruções só é enviada para execução quando os dados estão disponíveis e ela não atrapalha ninguém enquanto espera; 3) Outras arquiteturas tem caches L1 maiores mas tem 2, 4 e até 8 threads por core, a quantidade de L1 por thread não é maior que no Bulldozer; 4) Finalmente, a quantidade de acessos simultâneos ao L2 no Bulldozer é muito alta. Conclusão, no benchmark que mais depende de um bom subsistema de memória (caches, unidades load/store, controlador de memória) mesmo bem abaixo do clock alvo o Bulldozer é tão bom ou até melhor que o Sandy Bridge, por que tanta crítica logo na área onde o Bulldozer é bom? Só por que a AMD fez diferente de tudo mundo e achou uma solução diferente (e por sinal, muito boa) para o problema?

Incrível como todo mundo agora virou engenheiro... Que tal partir do pressuposto que se algo fosse fácil já teriam feito? Depois um pouco mais de base para os argumentos...

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

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

1) Banda de memória não tem importância. 2) Do Nehalem para o Sandy Bridge quanto foi o aumento? Por que alguém espera mais quando é do 990X para o SB-E? Sem chance... Já pensou que eles são iguais aos Sandy Bridge, só com mais núcleos? É da mesma geração do Sandy Bridge, por que seriam criticados?

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. O Sandy Bridge só tem 3 ALUs, igual aos Phenom, em força bruta os dois núcleos são praticamente equivalentes. 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... 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. 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.

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?

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. É sempre lógica. 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 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...

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

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.

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

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

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.

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. 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! 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... 4GHz? Eu? Hum... O Bulldozer chegou nos 4GHz... Não mencionei 5GHz em algum lugar? Não era nova mas era a porcaria dos 65nm que nem com os K-8 conseguiam clock aceitável... 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. 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.

Falsa sensação de segurança... O gerador de números aleatórios será realmente bom se todos souberem como ele funciona e ainda assim ninguém conseguir advinhar qual o próximo número gerado. Alguns PRNG feitos via software conseguem isso...