EduardoS

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.

Decaimento atômico, neutrinos... Na prática medir qualquer coisa que não compreendemos direito resuta em números aleatórios.

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

Ainda não foi lançado... Está sendo entregue, só os grandes clientes e OEMs estão recebendo por enquanto, o lançamento mesmo ainda vai ter que aguardar.

E o que garante que com 32nm isso não vai se repetir? AMD != Intel, processo da AMD é diferente do processo da Intel, não da para comparar. Queria entender de onde vem tanta certeza...

Não complica! Esqueceu que dos 90nm para os 65nm os K-8 não subiram o clock? Aumentar o clock com redução na litografia está cada vez mais complicado, as vezes eles não conseguem... Que eu me lembre, o processo de 32nm possibilitou incluir alguns truques como power gates, não seria tão fácil portar o Bulldozer para os 45nm. E quando eles ainda tinham tempo para isso duvido que alguém imaginasse um processo de 32nm lento... Ah sim, isso além dos pontos que você citou...

Sim, mas não é possível aumentar a tensão indefinidamente. Vou tentar simplificar bastante, pensando nos estágios do pipeline, cada um deles faz parte do trabalho para processar as instruções, em cada estagio cargas elétricas passam por diversos transistores, muitos em paralelo, mas o que interessa por enquanto é o número de transistores que essa carga precisa passar em sequência, o tempo do clock é o tempo que a carga precisa para passar por essas sequencia, no Bulldozer reduziram bastante essa sequência reduzindo a quantidade de trabalho que cada estágio de pipeline faz, assim conseguem aumentar o clock mesmo que essa carga leve o mesmo tempo para passar de um transistor para outro no Bulldozer e no Llano. ps: BEM simplificado, não é 100% preciso...

O Turbo do Tuban já chega bem perto do limite do chip, não da para melhorar muito... Tudo isso foi possível com 1.4V... Colocar a Radeon foi fácil, passar dos 40nm bulk problemático da TSMC para os 32nm SOI HKMG problemático da GF foi um avanço, era só reservar parte do TDP. O Phenom II foi o problema, com 1.4V só conseguiram 2.9GHz, não da para aumentar ainda mais a tensão, sem aumentar mais a tensão não da para aumentar o clock. O que está limitando esses chips não é o TDP, é a velocidade do processo, o tempo que a carga elétrica demora para ir de um transistor a outro. Em notebooks o Llano não está mal e o processo da pra engolir, o problema é quando aumenta a tensão e o clock não acompanha. A ARM acha que é... Eu prefiro dar mais uns meses para a AMD e GF se acertarem, as apresentações da IBM tem sido promissoras. Com certeza por que? daria para por mais cache e mais núcleos, só não da para passar de 3GHz. A AMD não vai lançar algo pior, a questão é quanto melhor? Eles tem a seguinte situação: 1) Um núcleo rápido que só pode ser feito em 32nm; 2) Um núcleo lento que pode ser feito em 45nm ou 32nm; 3) Um processo rápido e beberrão; 4) Um processo lento e econômico; 5) O núcleo rápido só atinge 4.2GHz em 32nm; 6) O núcleo lento atinge 3.7GHz em 45nm e 3.0GHz em 32nm; 7) O núcleo rápido em 4.2GHz é mais rápido que o núcleo lento em 3.7GHz; 8) A área onde eles estão em maior desvantagem é performance single-thread. Não importa que o núcleo lento a 4.2GHz seja ou não mais rápido que o núcleo rápido em 4.2GHz porque o núcleo lento não atinge 4.2GHz. O núcleo rápido pode não ser tão rápido quanto eles gostariam, nem atingir clocks tão altos quanto eles gostariam, mas é o que eles tem e é melhor do que o atual, para financiar a melhora desse núcleo eles precisam vender, e eles vão fazer isso independente de se algum entusiasta acha que eles tem alguma obrigação moral ou não. Bit Manipulation Instructions, manipulação de bits, algum uso em criptografia, compactação de arquivos e sei la o que a AMD tinha em mente quando criou elas, provavelmente um cliente grande pediu e eles atenderam, não é algo que vá fazer grande diferença para o usuário final. Foi exatamente isso. Quando a Intel mudou para FMA3 um engenheiro da AMD falou que eles não mudariam também na primeira versão do Bulldozer porque o cronograma já estava muito em cima e que como a Intel já tinha alterado a especificação diversas fazes eles não tinham garantia nenhuma que depois que alterassem o chip a Intel não mudaria de novo.

Exatamente. O lado irônico é que a AMD, Intel e IBM também sofrem com isso quando algum patent troll ataca...

Com certeza não, seria um vexame. Entusiastas mas sabem o que é VT-d... Além do mais a maior parte dos componentes para entusiastas não suporta VT-d, nesse mercado não é algo realmente importante.

Exceto que a AMD não conseguiria clocks mais altos em 32nm... Ainda mais em 2010. Há dois itens muito importantes para um bom processador: 1) Um bom projeto. 2) Um bom processo da fabricação. O 1 ainda é uma incógnita, mas o 2 está sendo uma verdadeira pedra no sapato da AMD...

Isso eu tinha visto, a pergunta é, que cálculo estão fazendo? É uma sequencia de divisões? Multiplcações? Drystone?

Erro meu, refiz a conta e é realmente 77%. Depende do algorítimo e instruções usadas mas os que eu marquei em vermelho tradicionalmente usam inteiros. O primeiro não da para saber; O segundo com certeza só usa inteiros; O terceiro depende, se for AES ele talvez use as instruções de aceleração, como o Tuban foi mais rápido duvido que use, se não for AES não tem aceleração, ai é só inteiros. E por fim o quarto depende, tradicionalmente é feito com inteiros, mas pode usar as (raramente usadas) instruções de manipulação de strings com prefixo REP, as novas instruções de strings SSE4.2 ou SSE2 mesmo. Tirando a criptografia (que por sinal, o Tuban foi mais rápido) todas as outras dependem muito da unidade de load store que era a principal deficiência do Tuban, se reais esses testes indicam que elas melhoraram muito. A criptografia é só um teste para ver quem tem mais ALUs, com três por núcleo e 6 núcleos o Tuban deixa os outros pra trás, normal. Depende, como é o calculo? Fiz um profile rápido no Cinebench R11.5, muito parecido com o Cinebench 9... Em um Phenom faz em média mais ou menos 1,3 instruções por ciclo (de no máximo 3) e 40% dessas instruções vão para a FPU, mas são instruções escalares, não vetoriais. Os números são baixos, isso não é suficente para saturar nem a unidade de inteiros e nem de ponto flutuante e nem decodificadores do K-10, nem do Bulldozer e nem do Sandy Bridge, saber porque o Sandy Bridge não ganha quase nada com o HT e Bulldozer ganha muito com o segundo núcleo do módulo não é tarefa fácil... Provavelmente são fatores diferentes, e mais de um fator em cada caso. Nenhum programa usa só FPU, o SuperPi usa bastante, que eu me lembre mais de 50% das instruões vão para a FPU, não da para ter certeza que p que deixa os processadores da Intel tão rápidos é a FPU. De qualquer jeito é um programa antigo, mal feito e ultrapassado e que nem para calcular milhões de casas decimais de Pi ele serve, programas mais novos fazem o mesmo trabalho em 1/10 do tempo, menos ainda quando usam todos os núcleos do processador...

Hum... Todas? Na justiça processo por conjunto de instruções nunca deu em nada, o que epga são as patentes e ai um processador com a arquitetura XYZ pode infringir patentes da Intel (ou IBM, AMD, VIA, Oracle, Apple e... Microsoft...), se ele tiver um desempenho remotamente competivo então povavelmente infringe.