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

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

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.

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

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

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

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. É o contrário, o Bulldozer possui um pipeline mais longo, com cada estágio sendo menor. 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?

Não, não conseguiriam, iriam bater nos 3.0GHz e chorar. 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... Talvez.

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? O trabalho dele é vender o produto, expor as qualidades, não é exatamente sair falando ladainha e prometendo o que não pode cumprir. Acho que era nitrogênio, helio líquido é um treco meio complicado... 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.

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

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?

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

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. Pela minha experiência sim, mas minha experiência é tendenciosa (ver adiante). 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. "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. 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 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 As ações cairam um pouco...

Não vi isso nos comentários, que trecho foi? Registradores SSE são os mesmos que os AVX128. 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. 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 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... 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. 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...