EduardoS

e o consumo' date=' como podemos ter uma noção do consumo do processador? deve ter alguma relação [/quote']

Com os TurboCore, TurboBoost, Turbo sei la o que que tem por ai o consumo com o processador em 100% deve ser parecido com a TDP informada, o consumo com o processador IDLE só medindo.

TDP seria o máximo de calor que o processador pode "soltar"' date=' certo? [/quote']

Hoje em dia, não mais...

Hoje TDP só serve para calcular o tamanho do cooler.

Isso procede? É impossível para o AM3+ oferecer suporte a tri-channel?

Sim.

Mas por favor... Chega de falar nesse triple channel... Nem as versões iniciais do Sandy Bridge vão suportar isso...

20 ciclos é sacanagem, nem L2 tem essa latência... mas eu tenho a impressão de que é possível construir um scheduler para agendar para mais de 4 ciclos. E o cache L2 dos Nehalems chega a 9 ciclos, acho.

Se me lembro bem na medição foi 11, alguns reviewers "esqueceram" de considerar o Turbo na medição...

Aliás... é impressão minha ou a LSU do ponto flutuante só usa o L2? Foi dita alguma coisa sobre isso?

Boa pergunta, acho que já vi diagrama das duas coisas...

Agora ECC' date=' quem precisa disso em desktops? sinceramente, não faz falta[/quote']

Não faz falta mas também não atrapalha, Celerons e Pentiums suportam ECC, custava deixar os i7 com ECC também?

Ah, os Xeons com ECC são pouca coisa mais caros.

EduardoS, porque você acha que o cache de dados em 16KiB dedicado a cada uma das linhas da unidade de inteiros é um retrocesso?

Não é bem que eu ache que foi um retrocesso, só uma cosa que me deixa com o pé atrás, a grande vantagem dos processadores fora de ordem é lidar com latências imprevisíveis mas ainda assim, tem limite, o scheduler não consegue detectar mudanças na latência esperada das instruções tão rápido, o que pode acontecer com um L1 muito pequeno é o scheduler não agendar de forma muito eficiente deixando bolhas no caminho, as vezes um L1 maior com latência maior fica mais rápido justamente pelo scheduler conseguir agendar as instruções de forma mais eficiente, claro, aqui também existem limites, um L1 com latência de 20 ciclos vai ser lento e não tem muito o que o scheduler, as vezes precisa assumir o risco de mais "misses" para não aumentar muito a latência, se ele rodasse a uns 20GHz e só tivesse 8kB de L1 acho que ainda seria aceitável, nesse clock mesmo com um L1 pequeno também acho que seria difícil uma latência menor do que uns 10 ciclos, o agendador ainda teria que fazer mágica.

Mas... Isso é um problema que a AMD deve ter quebrado a cabeça para resolver, o BD foi feito para rodar em um clock maior que o K10 e para isso precisavam fazer alguns sacrifícios e resolver alguns problemas, o L1 é um desses problemas e não é fácil de resolver.

AGU - De acordo com Gabriel Torres, Store Address: Unidade de armazenamento de endereços, processa instruções que solicitam dados a serem escritos na memória RAM. Esta unidade é também conhecida como Unidade de Geração de Endereços (AGU, Address Generator Unit). Este tipo de instrução usa tanto as unidades Store Address e Store Data ao mesmo tempo.

Bem... Não exatamente, os processadores da Intel transformaram as AGUs/LS em Store Address, Store Data e Load Data/Address, cada instrução que solicita dados da memória principal usa a terceira unidade, cada instrução que grava usa as duas primeiras, a primeira e a última são unidades capazes de calcular endereços de memória, a segunda é capaz de enviar dados à memória (na verdade, à unidade LS) e a terceira é capaz de buscar.

Nos processadores da AMD, só tem as AGUs, e elas só calculam endereços, tanto para operações de escrita, quanto leitura, as operações em si são efetuadas pelas unidades LS, os K-7/8/10 possuem 3 AGUs, o que é um grande exagero já que nunca serão usadas ao mesmo tempo, mas elas são presas a uma ALU e não podem ser compartilhadas com outras, então esse exagero se faz necessário (de qualquer jeto, AGUs são baratas...), no Bulldozer o número de AGUs foi reduzida para duas, aparentemente separadas das ALUs (por isso as ALUs poderiam compartilhar a AGU se só existisse uma ou se existissem mais ALUs) e aparentemente também capazes de realizar tanto operações de escrita quanto leitura, mas isso ainda é incerto, pode ser que escrita e leitura tenha sido separadas como é o caso da Intel, ou do Bobcat...

porque " 2 AGUs independentes para apenas 2 ALUs é exagero".

Simplesmente porque AGUs não são tão usadas quanto ALUs, os processadores da Intel possuem 3 ALUs mas apenas 2 "AGUs", quer dizer, nem duas porque uma só serve para leitura e a outra pra escrita, e eles estão muito bem assim, o Bulldozer terá menos ALUs e o mesmo número de AGUs mas (aparentemente) AGUs mais poderosas.

Amigo, não tem ilusão... São dois núcleos que compartilham apenas o cache L2, e as unidades de ponto flutuante. Não são 1 núcleo e 2 threads. São dois núcleos. Pense neles como irmãos siameses que compartilham alguns orgãos mas têm cérebros independentes.

Ainda compartilham o front-end, cache de instruções decodificadores, preditor de desvios, etc.

Quando um engenheiro da Intel propôs algo assim por lá ele chamou o "módulo" de "núcleo", chamar de "módulo" ou "núcleo" é mais questão de marketing e licenciamento do que uma questão técnica, pelo que já vi da Intel qualquer coisa que compartilhe mais do que o cache é um núcleo só, outros são mais flexíveis.

Diria que esse é um mal sinal e que as versões para servidores terão pouco L3, se fossem monstros realmente bons para OLTP dariam mais importância ao Oracle, por outro lado a Oracle aumentaria o preço das licenças...

Eu mantenho minha previsão: Pelo menos 100% de desempenho em cima do Phenom X6 1090T.

Pela versão desktop de 8 núcleos? Quer apostar? Deixo minhas fichas nos 40%.

Evandro, a grande birra dos Phenons frente aos Cores é sua unidade de inteiros, que perde de forma nada elegante para aqueles. O redimensionamento dela só em questão de números já deve permitir um aumento de 33% (apenas em termos de adição de componentes) vs. AMD64.

A unidade de inteiros (escalares, que é as que tiveram o "aumento" que você citou) é pau a pau com os Cores, os dois possuem 3 ALUs, o Phenom 3 AGUs e não sofrem com read-modify-write e read-execute, os Cores possuem AGU/LS separada que pode executar instruções independentes mas sofrem com read-execute e especialmente com read-modify-write, a maior parte das instruções dessas unidades é mais rápida nos Phenom, em programas de criptografia em geral os Phenom se saem melhor (especialmente se o software em questão faz uso de mul e carry), e isso tudo comparando núcleo por núcleo e clock por clock.

Onde os Core realmente são melhores é no subsistema de memória, em especial o i7, o SMT deles ajuda mais a mascarar latências do que a preencher as unidades de inteiros e nos aplicativos geralmente colocados no pote dos "inteiros" (ex: web servers, compactadores de arquivo, compiladores) o subsistema de memória é mais importante do que as unidades de inteiros em si.

Por outro lado, além dos circuitos de pré-busca e da unidade de interios dos Cores serem muito bons, as instruções SSE4 foram um calo grande no calcanhar dos K10, até porque sabemos que uma coisa é a AMD propor um subset de instruções e ele ser adotado pelo mercado, outra coisa bem diferente é se o criador do subset for empresa azul...

SSE4.x quando muito ajuda em um benchmark escolhido dos reviews a dedo para mostrar que elas existem, tem poucas instruções, muito específicas, poucas realmente úteis e dessas a maior parte foi tão mal implementada nos Nehalem/Westmare que só ajudam em pouquíssimos casos.

E além do mais, a adoção delas foi baixa, ninguém sentiu falta delas quando a Intel deixou de fora das linhas mais baixas...

Pelo que deu a entender elas são unidades separadas que funcionaram inicialmente como 128bits, mas no caso de AVX se transformarão em uma de 256bits. Como o GT falou, parece que o AVX da AMD é mais completo que o da Intel por integrar também instruções do subconjunto SSE5 que estava sendo desenvolvido pela primeira.

Leve esse "se transformarão" com cautela, a AMD não disse como foi feito, ao invés de transformar duas unidades de 128 bits em uma de 256 bits é muito mais simples transformar uma instrução de 256 bits em uma de 128 bits... E a AMD já fez algo similar nos tempos do K-8.

Ah, o que essas unidades tem a mais é as FMAC, propostas nas SSE5, depois propostas pela primeira versão das AVX que depois foram alteradas (capadas...), as instruções que a AMD vai implementar são parecidas com a primeira versão, mas no prefixo XOP.

Eu meio que ando pensado diferente. Pelo menos no caso da unidade de interios, não tem como o sistema interpretar aquilo tudo como um só. O próprio SO se encarregará de tratá-la como cores independentes.

Pro SO isso é transparente, mesmo no caso dos i7 as unidades de inteiros serem compartilhadas não faz diferença nenhuma pro SO.

Não apenas isto. Tem muito mais coisa melhorada em reação ao núcleo do K10. A unidade de inteiros passou de 03 para 04 alus.

2 ALUs e 2 AGUs, mas independentes, na verdade esse é um ponto que eu gostaria de maiores esclarecimentos, 2 AGUs independentes para apenas 2 ALUs é exagero, TALVEZ elas possam fazer algo mais, é a única forma de não ser um exagero...

indicando que cada linha terá seu cache separado de 16KB

Em relação aos K10 núcleo por núcleo, clock por clock isso é um retrocesso, por outro lado deve permitir que o BD atinja clocks maiores.

Eu diria que apenas pelo dobro de núcleos, um quado modular zambezi já deveria ser cerca de 80%-100% mais poderoso que um Deneb de 04 núcleos, fora toda a modificação da arquitetura.

Perai, antes era 100% sobre um 1090T, agora 80%-100% sobre um Deneb? Bem... O chute agora parece mais realista...

ps: Toda a modificação da arquitetura não teve como prioridade aumentar a performance por núcleo por clock...

o LGA 1207 é o atual dos servidores?

Não, é a dupla G34/C32, o C32 foi feito baseado no LGA1207 mas os dois não possuem qualquer compatibilidade.

2 ALUs, 2 AGUs, L1I e todo front-end compartilhado e clocks maiores... É... O café servido na AMD parece normal e dentro do prazo de validade... Que pena...

Não gostei muito do L1D de 16kB, o scheduler vai mesmo conseguir mascarar a latência do L2?

sem querer ser pessimista, mas em ponto flutuante a batalha tá perdida, e para conseguirem ganhar no resto, os engenheiros tem de fazer melhor do que tão fazendo até agora.... Hà uma bela distáncia para os I7.

???

Tem certeza que você não está confundindo ponto flutuante com alguma outra coisa?

só eu que começo a achar que uma guinada desse tamanho pra inteiros em cpus é um pouco de excesso de confiança no poder do gpgpu?? afinal, ainda tem a questão da flexibilidade das mesmas!

Em muitos aspectos, GPUs são mais flexíveis do que os vetores das AVX, e ainda assim, nos casos difíceis de vetorizar MADD ainda é melhor do que vetores.

A área onde a AMD realmente precisa ralar pra incluir as GPUs na briga é em compressão de video.

Portanto cada módulo tem duas VFPUs de 128 bits a disposição, que podem ser utilizadas como uma VFPU de 256 bits... assim um Bulldozer de 8 núcleos terá a mesma capacidade de VFPU de um Phenom II X4 em aplicações sem FMACs... ainda tinha algum dúvida se não seria mais que isso.

8 operações... FMADD conta como duas? Bons tempos em que uma operação era o mesmo que uma instrução...

Agora ta mais perto da "FPU não ser fraca".

Adoraria ver um processador com muita força bruta mas do ponto de vista comercial acho que para o JF usar operações como instruções nessa só se alguém tivesse misturado cogumelos alucinógenos no café dos engenheiros que projetaram o Bulldozer...

Aparentemente, ele "está disposto a apostar" que um Bulldozer Interlagos será mais de 50% mais rápido que um Magny Cours em aplicações single-threaded.

Socket level... Multi-thread... Talvez seja melhor fazer o anti-dopping nos engenheiros da AMD antes de continuar os comentários.

mas não tem tanta coisa assim no mercado doméstico que use SIMD, ou tem?

Que usa ou que poderia usar?

Que usa - Não.

Que poderia usar - Sim.

E o mesmo vale para servidores.

Não, ninguém vai passar a usar só porque a Intel incluiu essas intruções e a MS incluiu os intríssicos, não é disso que eu to falando.

ah' date=' assim, só uma dúvida, AVX é uma instrução usada em ponto flutuante certo?[/quote']

Não, AVX é uma extensão das SSE (2, 3, S3, 4.1 e 4.2), agora com 256 bits e operadores não destrutivos, é usada tanto com ponto flutuante como inteiros vetoriais, por causa do modelo usado hoje as instruções de ponto flutuante escalares e vetoriais e inteiros vetoriais compartilham a mesma unidade enquanto os inteiros escalares ficam em unidades a parte, no caso do Bulldozer cada núcleo tem 4 unidades desses inteiros escalares e cada dois núcleos compartilham as unidades que executam ponto flutuante vetorial e escalar e inteiros vetoriais.

E ah, x87 foram as primeiras instruções de ponto flutuante integradas aos processadores x86 com precisão simples, dupla e extendida, MMX veio depois, mas eram instruções de inteiros vetoriais, 64 bits compartilhando os registradores da x87 (e por causa disso essa divisão de tarefas), depois a AMD lançou a 3DNow! com ponto flutuante vetorial (mas limitado a precisão simples e registradores 64 bits) compartilhando os registradores com as MMX, SSE veio depois, ponto flutuante de precisão simples em novos registradores, dessa vez com 128 bits e também adicionaram algumas instruções MMX que a AMD incluiu no primeiro Athlon, depois veio SSE2 trazendo precisão dupla e também trouxe as instruções MMX para os registradores SSE (XMM para os íntimos) ampliando-as para 128 bits, ai a AMD lançou a AMD64 duplicando o número de registradores gerais e SSE sem tocar nos da x87/MMX/3DNow!, marcando o início da obsolência desses últimos, depois SSE3 e SSSE3 apenas trazendo novas instruções, com SSE4.1 pararam de replicar as novas instruções para as MMX, elas são completamente obsoletas agora, ai a AMD ameça com SSE5 e nova codificação com operadores não-destrutivos e fundindo multiplicações e soma e por fim vem as AVX que duplicaram os registradores SSE (agora YMM para os íntimos) e os operadores não destrutivos e a fusão da multiplicação e soma em uma codificação nova.

Uffa... Resuminho simples não?

ps: To meio morto agora, pode ter erros bestas no post acima.

Alguém vai usar? Se eu fosse gerente e visse alguém usando daria uma baita bronca...

Se o compilador suportasse de forma mais inteligente, talvez, se essas instruções fossem melhor planejadas talvez os compiladores suportassem de forma mais inteligente.

As instruções SIMD da Intel parecem ter sido formuladas pelo Aaron e ele parece só se importar com compressão de video, praticamente para todo o resto falta "aquela" instrução.

No caso das AVX vai ser complicado mostrarem pra que vieram nos servidores...

Eu disse , estou oensando em clocks baixos e semelhantes aos atualmente utilizados ou até menores, nada de 4 GHz ou mais, mesmo que seja um processo de fabricação mais avançado.

Isso tem muito mais a ver com projeto do que processo.

Hoje a AMD compete com os 240mm² da Intel com 700mm², eles precisam melhorar a performance/watt/mm² e alterar o clock alvo é a maneira mais fácil de conseguir isso, se o Bulldozer fica com um tamanho de die mais razoável tipo 400mm² 50% mais performance que o MC vai ser excelente, terá sido muito melhor do que a Intel conseguiu na passagem dos 45nm para os 32nm, quer dizer, a AMD terá conseguido uma grande melhora arquitetural, se for outro monstrengo a AMD ta perdida...

Isso seria contraproducente na redução do consumo ...

Sabe que sou um dos que discordam disso... Estagios mais curtos exigem menos tensão, reduz clock e tensão do Power 7 para ficar nos 125W dos x86, ainda terá um clock mais alto e performance "apropriada".

A ideia é a seguinte: unidades de inteiros são baratas. O hardware para utilizá-las bem não é tão barato, por outro lado. A ideia é não utilizá-las bem mesmo. Com isso você obviamente economiza em hardware para facilitar o aproveitamento dos recursos, como hardware de execução fora de ordem, buffers de memória, etc. Em segundo lugar, você especula menos. Para terminar, como o front-end é desacoplado do back-end, em teoria é possível dimensionar o front-end de acordo com a média de ocupação do back-end, e com isso seu front-end fica bem menor do que o aparentemente necessário. O mesmo se aplica aos recursos de memória.

Com essa economia, você consegue colocar dois núcleos de inteiros em cada módulo, assim aumentando seu poder de fogo em aplicações otimizadas. Claro que isso exige que você aumente alguma coisa de capacidade nas partes compartilhadas: por exemplo, seu front-end tem que aguentar em média dois núcleos, assim como seu subsistema de memória. Mas por outro lado isso também tem vantagens: assim como em um SMT, em aplicações não-otimizadas você fica com um monte de front-end, memória e coisas compartilhadas para gastar em um único thread. A diferença, claro, é que seu processador não terá tantos recursos de execução, mas isso não deveria fazer tanta diferença.

Existem diversos "buracos" nessa minha teoria: ponto flutuante, mais dados sobre o funcionamento do front-end e do back-end, etc. Mas acho que faz algum sentido.

Sim faz sentido, quando junta dois núcleos nesse módulo as partes mais caras e menos sensíveis a latência deveria ser compartilhadas para aumentar a utilização dessas (que se preocupa se a utilização de unidades baratas fica em 10%?), a fpu que é uma dessas partes cara é compartilhada, apostava alto que o front-end do Bulldozer também seria mas informações mais recentes sugerem que não, e 4 unidades de inteiros apesar de baratas ainda parece muito para quem esteja tentando economizar transistores.

Se pensarmos em uma disputa Phenom II X6 x BDZ X8 usando aplicativos otimizados para multi-thread, eu espero pelo menos 50% de vantagem para o Bulldozer, provavelmente mais. Em aplicativos não otimizados para multi-thread, alguém poderia esperar uma vantagem de 12,5%. Mas isso não vai acontecer, por diversos motivos:

Nessa comparação existe um item contra o BDZ, o Magny Cours está no limite inferior da frequência/consumo, da para aumentar "muito" a frequência aumentando "pouco" o consumo e o X6 é um exemplo disso, não acredito que o BDZ já vai ser lançado tão perto desse limite ou seja, a vantagem das versões desktop deve ser menor.

Quem falou em clock a clock?

Que eu saiba ninguém citou clocks, existe margem para o Bulldozer ter a pena 1GHz com uma performance por clock brutal mas também tem margem para que ele atinja 4GHz com performance por clock ridícula, ninguém sabe qual o clock que ele foi projetado, pode ter sido 5GHz tipo Power6 ou 2GHz tipo Itanium 2, e não é isso que vai deixar o chip bom ou ruim.

Para quem vai apenas usar o processador o clock não faz diferença nenhuma, 50% mais rápido que o atual MC faz.

Ainda quanto a performance por clock do Bulldozer, dois núcleos compartilham unidades, quem faz isso procura economizar transistores e/ou reduzir o consumo ao invés de garantir uma boa performance individual do núcleo, um forte indício de que a performance extra por núcleo veio de clock extra.

Por outro lado cada núcleo tem 4 unidades de inteiros (adoraria, mas ainda duvido) o que não combina muito bem com econmizar transistores.

É impressão minha ou a AMD está fazendo cagada, ou ela tirou o super trunfo ?

Ou nós que não temos informações o bastante

Peraí, vou ver se entendi.

Você está dizendo que o Sandy é o atual i5 + o GMA feito de forma monolítica e só ?

(i7 + melhorias) + (GMA + melhorias), mas estou dizendo que a parte gráfica ocupa um espaço pequeno do die em relação ao atual i5 e por isso o desempenho não deve ser surpreendente.

OU que ele é monolítico com algumas melhorias ?

Ah... Ele é monolítico sim...

O leão no caso seria o bobcat e é ele que tem mais de 60 mm2 só de VGA ?

O leão é o Llano, ou melhor, a GPU desproporcional dele.

não' date=' pelo que entendi o leão seria o Llano e o gatinho o SB. O bobcat é para netbooks e coisas menores, acho que não entra na briga, esses ai tem consumo e tudo maior.[/quote']

É Talvez a comparação também seja válida para Bobcat vs Atom.

Hm... eu acho que cometi algum erro feio na medição, acabei de fazer a mesma coisa agora com uma foto um pouco menos ruim e consegui entre 74 e 83 mm², usando essa foto e considerando uma área de 9,69 mm² para o núcleo. Na verdade eu até já sei o que aconteceu: na foto menor a parte de vídeo parecia mais simétrica do que realmente é.

De qualquer modo, dá para estimar uns 185-200 mm² para o Llano, e claramente a pastilha não é mais que 45% GPU... na verdade, eu daria no máximo uns 40% ocupados pela GPU, o que equivaleria a menos de 85 mm².

A AMD está realmente aprendendo como fazer para confundir os outros... Esse die ai é diferente do primeiro que eu vi... Mas esse ai parece mais realista, fico com o seu chute.

O Sandy Bridge deve ser um salto similar ao que ocorreu entre Nehalem e Core

Anh... Core "1" e Core 2? Ou K-8 e K-10? O Sandy Bridge não parece realmente ter tanto a mais que o Nehalem.

eu mesmo acho que os 75-85 mm² do Llano são GPU demais para largura de banda de menos.

Não é só você

e a parte de memória, 42 mm² (e sim, isso é só uma estimativa).

Na parte de memória você incluiu os ROPs? As controladores reais não parecem ser muito grandes mas os ROPs ainda precisam existir no Fusion.

O Llano é feito em 32 nm SOI GF. Não dá para imaginar que isso não vá diminuir o Redwood pelo menos um pouco...

Ah sim, mas acho que a passagem pro SOI vai trazer mais ganho em clock/consumo do que área.

É claro que existe alguma possibilidade de que tenhamos uma Sideport escondida na pastilha, mas daí já sabemos como isso irá funcionar...

Sideport? Duvido.

Mas estou curioso pra saber o que vão fazer para lidar com tão pouca banda de memória.

Sim... mesmo que a Intel fosse muito boa em fazer GPUs, e a ATI ruim, 45 mm² contra mais de 60 mm² (eu chuto uns 65-70 mm²) seria uma briga difícil.

60mm²? Olhando de longe parece ter mais de 100mm², ainda não vi muitas discussões sobre esse tamanho e nada sugerindo "apenas" 70mm², argumentos defendendo esse "pequeno" Llano seriam interessantes

Outro detalhe é que a Intel voltou a latência de 3 ciclos para o L1 (o que pode ser devido a duzentas coisas, mas pelo menos indica que o SB não é um Nehalem meio mudado) e diminuiu um pouco a latência do L2 (o que não é nada difícil de prever). De qualquer modo, podemos esperar desse Sandy Bridge um monte de coisa, mas mais no mercado desktop de médio a topo-de-linha-que-alguém-compra, também conhecido atualmente como Core i5. Um mercado onde o IGP relativamente fraco integrado é meio que irrelevante, para dizer a verdade.

Dessa mudança de latências pessoalmente eu espero uma de duas coisas:

1) Clocks menores que o atual Westmare, a extensão AVX fortalece esse ponto;

2) Boatos falsos, ainda tem muita cara de Nehalem...

ps: Juntando o tamanho da IGP com o histórico da Intel com gráficos o confronto com o Llano vai ser tipo um leão contra um gatinho, se o Hedge fizer um bom trabalho de quebra essa IGP ainda apaga o brilho das AVX.

O problema principal é largura de banda e consumo, isso pode obrigar as GPUs topo a continuarem discretas.

O segundo caso vai continuar a ser um problema mesmo com as GPUs TOP sendo discretas, o que vem depois de GDDR5 512 bits? E PCIe uma hora será problema também, daqui a 10 anos as GPU terão que inventar uma forma mais eficiente de usar a banda de memória, o XBox 360 se vira com um "Frame Buffer" de eDram de 10MB...

Não, os 50% e 80% são em relação ao próprio Bulldozer, no Bulldozer dois núcleos compartilham recursos formando um módulo, esse módulo com dois núcleos é 80% mais rápido e 50% maior do que um núcleo que não compartilhasse recursos com ninguém.

Ao menos é isso o que eles dizem.

E em 1971 é lançado o primeiro microprocessador, com seus 4 bits...

E em 1980 vem o 8087.

Se for para olhar para traz e começar a ver todos os não-microprocessadores que existiram também vai levantar a discussão do que é 64 bits, o Cray 1 por exemplo, apesar dele ter registradores de 64 bits ele tinha registradores de endereço, de 24 bits.

quando as especificações do IEEE para PF 32-bit e 64-bit começaram a ser levadas a sério, empresas como a DEC e a MIPS já planejavam e desenvolviam processadores com executoras 64-bit para aritmética com inteiros e endereçamento.

Acredito que você saiba a diferença entre inteiros 128 bits e pf 128 bits não é?

E sabe também que PF de 64 bits existia muito antes dos processadores 32 bits não é? Então, uma coisa não tem nada a ver com a outra, DEC e MIPS se preocuparam com processadores 64 bits porque tava na cara que para o mercado deles (computadores com MUITOS processadores e memória) 4GB de memória virtual não dava nem pro cheiro.

Está havendo outra confusão aqui. Eu não disse que o AVX enquanto conjunto de instruções é inferior ao SSE5 e sim que a Intel estava um tanto despreparada para implementá-lo no silício enquanto a AMD demonstrava um espírito empreendedor à toda prova com a sua própria versão;

...

Posso afirmar tranqüilamente que o SSE original não venceu por ser efetivamente melhor mas porque a Intel tinha recursos de sobra para apresentá-lo e promovê-lo como tal para meio mundo e a AMD não.

Vou concordar com você sempre que disser que a Intel criou as SSE nas coxas, as pressas, que AVX foi mostrada as pressas para jogar areia nas SSE5, etc. Isso tudo é verdade, o problema é quando entra na parte que sugere que SSE5 era perfeito e não sei mais o que, esquece, a AMD publicou SSE5 com antecedência justamente para forçar a Intel a mostrar o jogo e conseguiram, mesmo na época da SSE vs 3DNow! essa última tinha desempenho melhor porque SSE no P3 foi mal implementada, não que realmente existisse uma grande vantagem a favor do 3DNow!.