| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
|
| | A maioria das espresas faz o mesmo. A AMD também evita termos como "IA-32" "MMX" "SSE" o mais que pode nos manuais. Ou a IBM que se refere às extensões compativeis com Altivec do PPC970 como VMX.
PS: A Intel é uma empresa, não tem vergonha. Tem accionistas que só pensam nos 95%+ de mercado x86 que detém e nas margens de lucro de 60%+ com que vende os CPUs.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| |
| |
| | Pragmatismo == dinheiro nestes casos.
Compreendo que o meu (nosso) espirito de orgulho latino nos levace a falencia antes de admitir que nao tinhamos razao.
## I should be working... |
| |
| | Boas.
"PS: A Intel é uma empresa, não tem vergonha."
Vá lá, os japoneses pelo menos têm-nos "no sitio", no que toca a "vergonha".
As empresas *grandes* têm esse defeito: são tão grandes que esmagam os próprios consumidores ignorantes.
@798, Nbk
|
| |
| | Claro que as extensões são as da AMD, a Microsoft deve ter feito pressão sobre a Intel acerca disso, duvido que eles estivessem dispostos a desenvolver um sistema operativo para duas arquitecturas x86 diferentes q.b., já basta os SSEx de hoje.
O licenciamento cruzado entre a Intel e a AMD permite que uma empresa copie o "Intruction Set" da outra caso entenda. Até há uns meses isto tinha beneficiado mais a AMD, agora as coisas mudaram. Existe um certo ponto onde a "dor de cotovelo" tem de dar lugar ao "engole o sapo"!
Os novos Athlon 64 são de facto geniais na sua estrutura, mais uma vez a inovação faz-se com inteligência e não com força bruta. Aliás este episódio agora faz-me lembrar o que aconteceu com a ATI vs. Nvdia. Será um presságio? :]
|
| |
| |
| | | ... a Microsoft deve ter feito pressão sobre a Intel acerca disso... Não fez pressão, disse-lhes claramente que não faria um Windows para uma 3ª arquitectura de 64bit ...já basta os SSEx de hoje. A AMD adoptou SSE/SSE2 como parte integrante da especificação AMD64. Por outro lado, x87, MMX, MMX.ext e 3dNow! não só não fazem parte como foram depreciadas. Em Win64 nem são suportadas. Adeus e não voltem. Existe um certo ponto onde a "dor de cotovelo" tem de dar lugar ao "engole o sapo"! Não é uma questão de dor de cotovelo. A Intel tem simplesmente estado a adiar o mais possivel o anúncio público de um CPU desta natureza para não perturbar a adopção dos Itanium. Os novos Athlon 64 são de facto geniais na sua estrutura, mais uma vez a inovação faz-se com inteligência e não com força bruta. Por acaso os CPUs da AMD são normalmante classificados como soluções de "força bruta", feitos para ter boa performance independentemente da qualidade do código, enquanto a Intel se pode dar ao "luxo" de conceber um CPU como o Pentium4 que requer código adequadamente optimizado.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| |
| | Os AMD são soluções de força bruta ? A tua definição de força bruta é o facto de terem boa performance com código não optimizado ?
Suponho que elegância para ti seja um pipeline de 20 ou 30 estágios e GHz a dar com um pau.
Se assim for, tens toda a razao.
|
| |
| | Não. O facto de serem soluções de "força bruta" é uma consequência do facto de a AMD não poder esperar que o código seja devidamente optimizado para os CPUs deles. A Intel pode. Isso significa que a AMD desenha CPUs para correr o código que há, enquanto a Intel desenha CPUs mais orientados para o código que pode ser feito.
Se comparares um Athlon64 com um Pentium4C, vais ver que o Athlon64 tem mais transistores e área, consome mais energia e a performance tende a ficar atrás do Pentium4C.
Claro que depois olhar para um Pentium4E e perguntas "estes 45M transistores extra são só para aquecer, não são?"
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| |
| | Se comparares um Athlon64 com um Pentium4C, vais ver que o Athlon64 tem mais transistores e área, consome mais energia e a performance tende a ficar atrás do Pentium4C.
Talvez porque nas comparações se usa sempre o Windows XP de 32bit e testes de 32bit, o que faz com que as vantagens do Athlon64 se diluam (especialmente os registos extra).
Claro que depois olhar para um Pentium4E e perguntas "estes 45M transistores extra são só para aquecer, não são?"
O controlador de memória integrado e registos extra consomem um bocado de espaço...
-- Carlos Rodrigues
|
| |
| | Primeiro, o facto de ser um processador de 64bit não justifica toda a diferença de transistores.
Segundo, em programas de 64bit também podes ser penalizado pelo facto de os ponteiros ocuparem o dobro da memória.
Terceiro, faltou-me ali um "depois de olhar para um Pentium4E". Os novos Pentium4E (0,09µm)têm uns 45M de transistores inexplicados relativamente aos Pentium4C(0,13µm), consomem energia como os diabos e não são mais rápidos que os Pentium4C.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| |
| | Por enquanto não são mais rápidos (tal como o P4 original não era mais rápido q o P3)... mas segundo parece têm melhor escalabilidade que os outros. Dá-lhes tempo.
http://www.anandtech.com/cpu/showdoc.html?i=1956&p=24
|
| |
| | "A AMD adoptou SSE/SSE2 como parte integrante da especificação AMD64. Por outro lado, x87, MMX, MMX.ext e 3dNow! não só não fazem parte como foram depreciadas. Em Win64 nem são suportadas. Adeus e não voltem."
Onde leste isso...?
As SSE/SSE2/MMX/3DNOW/3DNOW+ NÃO foram deprecated, e fazem parte quer do IA-32e quer do AMD64.
Ninguém com um QI de 2 dígitos deita fora todas as operações com memória só porque estão "fora de moda". Nunca fizeste nada em assembly, pois não...? Não... foram adicionaos os registos mmx8 ao mmx15 só porque não gostam do nº7...
Mas a mais cómica é a tua: "acabar com x87"... então fazes contas em quê...?
Ou não reparaste que o x86-84 não mexeu um BIT nas FPUs e que continuam a ser de 80bits...?
Para a próxima lê antes de mandares postas de pescada para o ar.
|
| |
| | | O que eu queria dizer é que a documentação da AMD para a plataforma AMD64 deprecia a utilização de x87/MMX/MMX.ext/3dNow! em favor de SSE/SSE2. As extensões SSE/SSE2 não só não foram depreciadas como foram feitas parte da especificação AMD64. Os novos registos são os XMM8-XMM15, que são operandos para SSE/SSE2.
Isto porque caso não saibas, SSE/SSE2 permite fazer quase tudo o que x87/MMX/MMX.ext permite, de forma mais ortogonal até. A única coisa que realmente se perde é aritmética de 80bit suportada por x87.
Para ler tens a FAQ da AMD.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| |
| | PS: Não são suportadas em aplicações a correr em Long Mode em Win64. Obviamente que aplicações de 32bit a correr no Legacy Mode podem continuar a usá-las.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| |
| | 3ª? pah, esquece o win no alpha...
---
Trolls, nem respondam porque não vos ouço.
Que Bush vos abençoe. |
| |
| | Isso está morto à anos e nunca foi verdadeiramente um OS de 64 bit...
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| |
| | Por acaso os CPUs da AMD são normalmante classificados como soluções de "força bruta", feitos para ter boa performance independentemente da qualidade do código, enquanto a Intel se pode dar ao "luxo" de conceber um CPU como o Pentium4 que requer código adequadamente optimizado.
Nunca tinha ouvido essa relativamente ao Pentium 4, até porque mesmo com código optimizado este continua a aplicar branch prediction e outras optimizações que fazem com que, mesmo em código optimizado para ele, os erros de previsão apareçam e provavelmente com uma frequência muito pouco reduzida, pois isto depende mais do que o código faz do que da forma como foi optimizado. No Itanium isto já não é assim pois a previsão simplesmente não existe.
E foi aqui que a Intel falhou. O Itanium fia-se demais no compilador para gerar código optimizado, o que na teoria até seria uma boa ideia mas na prática não é. Por um lado torna os compiladores excessivamente complicados e por outro o código resultante acaba por ser optimizado para um determinado cenário de execução, seja a optimização feita usando parâmetros estáticos do compilador ou guiada por um binário "instrumentado", enquanto que os branch predictions e afins são mais orientados para a execução do momento.
-- Carlos Rodrigues
|
| |
| | | Bem, branch prediction é de facto um aspecto que foi melhorado. Até porque sem optimização orientada por instrumentação é dificil fazer grande coisa a respeito disso em x86.
Mas há bastantes diferenças relativamente às preferências dos Pentium4 e Athlon64 em termos de instruções. Os Pentium4 preferem as instruções de uso geral e SSE vectorial mais simples. E ressentem-se um bocado do resto...
Os Athlon64 têm alguma preferência por instruções com alguma complexidade mas no geral são muito pouco esquisitos. E, ao contrário do Pentium4, suportam bem x87 e SSE escalar. Os Itanium também têm branch prediction. O que não têm é execução fora de ordem.
E a questão da optimização dos binários para um dado cenário de execução ou para parâmetros estáticos dos compiladores também é um tanto exagerada. Algumas pessoas conduziram testes informais e a conclusão que se tira é que um Itanium2 não beneficia muito mais de PGO que um Alpha por exemplo.
No fundo, técnicas como branch predicion e execução fora de ordem servem para contornar problemas de dependências que não podem ser adequadamene resolvidos pelo compilador.
Com os Itanium, a Intel não se limitou a arrancar isto dos processadores e esperar que os compiladores fizessem milagres, mas também introduziu mais possibilidades o compilador resolver estes problemas.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| |
