| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| | | Ultimamente ando bastante interessado nesta tecnologia, e devo dizer-te que... "ganda artigo óh meu!" :) Leitura recomendada.
|
| |
| | Promete... Transmeta, Alpha, etc etc etc... Tb prometiam muita coisa....Até sair, são promessas, apesar de prometer (!!!) coisas bonitas!
O Gildot é um site de notícias, onde se transcreve um conteúdo de uma notícia, quanto muito traduz-se e reporta-se a fonte.
by 4GR |
| |
| |
| | A minha ideia exactamente...
Isto deve ser doença, estou a concordar contigo :-)
Cumps, JB .. acusaram-O de pirataria, por ter duplicado uma cesta de pão e cinco peixes, e disseram: crucifiquem-No .. (Biblia do Século XXI) |
| |
| | | A diferenca e' que neste caso, ao contrario da Transmeta que teve mais "geek attention span" apenas porque contrataram o Linus Torvalds, a IBM esta' por traz disto. E a IBM ja' 'a uns anos que esta' a ver se arranja maneira de tirar o monopolio Wintel da cadeira.
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | A razão de existência do CELL é tornar a divisão de semicondures da IBM auto sustentável em vez de ser sustentada pelos pacotes chorudos de POWER+AIX.
|
| |
| | | Claro que a parte TEL pode ser ameaçada. Quanto à parte WIN impõe-se a pergunta sacramental: Correrá Linux? ;-) Francisco Colaço
Quem não faz, ensina; quem não faz nem ensina, faz metodologia. Quem não faz nem ensina nem faz metodologia, faz futurologia. |
| |
| | | O Alpha não se limitou a prometer. Embora seja uma arquitectura que presentemente ande um pouco pelas ruas da amargura, durante vários anos foi lider no segmento do number-crunching. All the best, Noviço
|
| |
| | Ainda hoje o Alpha bate um x86 em processamento de vírgula flutuante (em alguns testes que fiz, até um EV67 a 667 iguala um Athlon 2600+).
Mas é preciso ver porque é o Alpha tão bom nesta área, porque viola os standards do IEEE para o conseguir (se não acreditam, leiam a manpage do GCC).
--
Carlos Rodrigues
|
| |
| | Em boa verdade, os CPUs não respeitam ou deixam de respeitar o IEEE 754. Os CPUs só suportam isso melhor ou pior. No caso do Alpha, costuma ser para pior, mas acho que também depende do modelo.
A questão da conformidade ou não com o IEEE 754 coloca-se ao nivel dos compiladores. O GCC funciona na filosofia de usar o que der jeito. Provavelmente com o compilador da DEC consegues resultados conforme o IEEE 754. Isto na rara hipótese de alguma vez vieres a estar interessado em tal coisa..
|
| |
| | Não conheço todas as opções do compilador da Compaq, mas não me parece que ele faça manigâncias para melhorar a precisão dos resultados, já que dá sempre resultados superiores ao GCC em código que faça muito uso de operações de vírgula flutuante, mesmo quando se usa "-ffast-math" no GCC.
--
Carlos Rodrigues
|
| |
| | | Sim, a opção há-de estar lá bem escondida. :D PS: O IEEE 754 só foi adoptado no C99. Se tiveres um compilador mais antigo que não suporte C99, pode simplesmente não suportar.
|
| |
| | O GCC esforça-se sempre por ser exacto, no Compaq C é preciso passar: "-mieee-with-inexact". Mesmo assim o hardware não permite que isto seja feito de forma perfeita por nenhum dos compiladores.
--
Carlos Rodrigues
|
| |
| | Não, não esforça. Mesmo em x86, podes obter resultados mais conforme com -ffloat-store. Aliás, segundo o manual do GCC ele nunca não garante conformidade com o IEEE 754.
|
| |
| | fiz testes semelhantes com cálculo de matrizes e isso é verdade desde que não se ultrapasse o tamanho da cache do alpha (maior que a do athlon). por curiosidade, há cerca de 3 semanas estive em amena cavaqueira com o engineer manager (M. Lamere) da IBM (IBM Eng & Tech Services) que está a desenvolver o processador CELL, após uma palestra sobre a evolução da tecnologia de semiconductores (0.13um -> 65nm); fiquei a saber que em tempos ele trabalhou no processador alpha, quando ainda fazia parte da DEC...foi interessante ver o saudosismo e um brilho nos olhos do homem quando falou disso.
|
| |
| | A máquina que uso mais frequentemente como desktop em casa é Alpha -- é uma board "engineering-sample" (acho que nunca chegou ao mercado, ou pelo menos não em quantidades significativas) feita pela Samsung com um cpu EV68AL a 800MHz, à volta de um chipset da AMD.
É tão ou mais rápida que um AthlonXP com várias centenas de MHz a mais, e apesar de ter outras máquinas mais rápidas acabo sempre por usá-la para as tarefas do dia-a-dia (email, web, ouvir música, IM) -- os 8Mb de cache dão um jeitaço, de facto.
Só tenho pena de não haver binários do Skype para Alpha...
|
| |
| Artigo (Pontos:3, Informativo) |
| | Esse artigo não é grande coisa.
Mais interessante é isto e isto.
|
| |
| |
| | Obviamente, o CELL não vai afectar em nada a arquitectura dos PCs.
|
| |
| | E se o Cell tiver sucesso? Irá a Microsoft rasgar o seu acordo com a Intel e começar a lançar uma versão do seu sistema operativo que suporte estes processadores Cell? Ou vai caminhar a pés juntos com a Intel, para o que der e vier?
Bons tempos auguram para Linux, até pelo facto de que vão suportar inteiramente o Cell :-)
Paradoxo do ano: Microsoft Works!
Dominus vobiscum |
| |
| |
| | o Cell vai ter sucesso na PS3, a duvida é se tem em desktops/workstations/servers.
|
| |
| | Porque não? Tem tudo para triunfar. O devido marketing e funciona.
Paradoxo do ano: Microsoft Works!
Dominus vobiscum |
| |
| | é preciso que seja mto bom e barato.
parece que vai ser as duas coisas mas só vendo.
em principio até vão apostar no linux. se a apple tb mudar, talvez. :D
|
| |
| | Claro que o facto de as aplicacoes terem que ser reescritas nao tem nada a ver. Claro que isso nao custa bilioes (y2k anyone ?) e faz-se do dia para a noite...Geez... Leste o artigo ? Leste a parte do Cell vs PC ? A parte em que explica porque é que Amiga, RISC e outras plataformas superiores falharam ? Nao ? Vai lá ler com atenção (se tiveres tempo, dado que agora és um projecto de inginheiro mt ocupado ;))...
O Gildot é um site de notícias, onde se transcreve um conteúdo de uma notícia, quanto muito traduz-se e reporta-se a fonte.
by 4GR |
| |
| | | Claro que o facto de as aplicacoes terem que ser reescritas nao tem nada a ver. Actually... as aplicacoes per se nao teem que ser necessariamente reescritas. Depende do que definires como aplicacoes. Em muitos casos (no Linux em particular) pode ser apenas uma questao de portar o OS e criar compiladores que tirem partido da arquitectura. Claro que isto e' tudo dependente da estrategia que a IBM/Toshiba/Sony seguirem - que pode ate' ser uma de criar um mercado novo (PVR's, Consolas, Media-Centre's, etc.) separado das aplicacoes "normais" do dominio da Wintel.
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | *cof* Se não rescreves as aplicações não tens 250 GFLOP, só tens um processador PPC a 4GHz mas que é dual issue, in-order e com um pipeline bem comprido.
Aliás, ainda estou para ver como vão fazer para usar os SPE num sistema operativo normal.
|
| |
| | Não é preciso nenhuma re-escrita, apenas re-compilar a aplicação...
A re-escrita é a do kernel e bibliotecas/ferramentas de sistema.
Religion, the only confort left in a world splited by religion. (The Daily Show) |
| |
| | Só se usares assembly nas tuas aplicações, claro...
Religion, the only confort left in a world splited by religion. (The Daily Show) |
| |
| | Errmm, recompilar não vai provocar o uso mágico dos processadores vectoriais, a não ser com algum compilador "especial", da mesma forma que só com o compilador da Intel tens auto-vectorização para SSE.
--
Carlos Rodrigues
|
| |
| | Era bom era.. :)
Estou com um pulso lixado e não me apetece escrever muito, por isso espero que aprecies isto:
O CELL tem 3 aspectos importantes (todos ligados por um bus interno bem rápido):
* PPE: CPU PowerPC: 4GHz, 64 bits, Altivec/VMX. Mas é tipo Pentium4 ao extremo. Muitos GHz mas pouco trabalho por ciclo: apenas duas intruções por ciclo, não tem execução in-order, um pipeline bem longo. Enfim, a performace dele é um pouco duvidosa..
* Elevadas taxas de transferência em I/O e memória. Cortesia da RAMBUS. ;) Aqui não há muitas dúvidas, excepto sobre a possibilidade de enfiar no CELL quantidades de memória mais ao nível dos que temos PC. É cara e não se pode simplesmente adicionar mais um DIMM como nos PCs.
* 8 SPE: Processadores SIMD, que fornecem 250 GFLOP de single precision. A cena é que não formam um sistema SMP entre eles. Muito menos com o PPE. São umas coisinhas muito especializadas. Além de uma ISA própria, cada uma tem 32 kB de memória própria (local storage) e o único mecanismo de acesso à memória principal é transferência DMA do local storage memória principal. Dar-lhes uso vai requerer software escrito explicitamente.
|
| |
| | Queria dizer "não tem execução out-of-order".
|
| |
| | Então mas não é possível criar um compilador inteligente que pegue no código e "distribua tarefas" automaticamente pelos 8 SPE?
|
| |
| | Teoricamente.. A prática é que pode estar um bocado longe.. :)
|
| |
| | | Le o que eu disse: "pode ser apenas uma questao de portar o OS e criar compiladores que tirem partido da arquitectura".
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | | O RISC não falhou. Usas todos os dias, já que os cores dos P4 são RISC (depois há o CISC a estragar aquilo tudo. Se ligas um telemóvel provavelmente correrá ARM (RISC VAN NEWMANN) ou MSP430 (RISC HARVARD). Pelo contrário, o RISC impôs-se. Agora, se a Intel desse acesso abaixo da camada de código máquina... (raxx7, dá?) Francisco Colaço
Quem não faz, ensina; quem não faz nem ensina, faz metodologia. Quem não faz nem ensina nem faz metodologia, faz futurologia. |
| |
| | Tens razão e não tens razão... Falhou no mass market de desktop. Se bem me lembro, tinha sido proposto como killer architecture para tudo e mais alguma coisa. Conseguiu esses nichos de mercado, até pq faz sentido nesses nichos.
Mesmo que se esteja a impor agora, quantos anos já passaram desde que surgiu o RISC ? Mais de 10 ?
O Gildot é um site de notícias, onde se transcreve um conteúdo de uma notícia, quanto muito traduz-se e reporta-se a fonte.
by 4GR |
| |
| | ~20 anos. E foi a morte de quase tudo com 32bit ou mais. Fora dos PC/servers e dos mainframes da IBM, é raro veres um CPU de 32 bit que não é um RISC (ou um DSP). A XboX foi uma excepção bizarra que parece que vai ser corrigida na XboX2.
|
| |
| | | Na verdade, a ideia de que os x86 modernos são RISC por dentro tem muito que se lhe diga. Aliás, toda a diferenciação tem que se lhe diga hoje em dia. ;-)
Tradicionalmente, os CISC já recorriam à decomposição de instruções em microinstruções internas com motores de microcode. E os RISC dispensavam o microcode, executando directamente um conjunto de instruções mais simples.
Os x86 modernos têm descodificadores complexos que decompôem directamente uma boa parte das instruções (que são as que interessa usar, do ponto de vista de performance) e recorrem a um motor de microcode para o resto, que são mais complexas ou menos interessantes.
Os Athlon64 descodificam as intruções x86 em macroOPs(nomenclatura da AMD) que podem ser bastante complexas (uma única macroOP pode representar uma intrução x86 do género LOAD-OP-STORE, com um modo de endereçamento razoalvelmente complexo). Essas macroOPs serão ainda mais decompostas para serem enviadas para as respectivas unidades de execução.
As microOPs (nomenclatura da Intel) dos PentiumPro e derivados não devem ser muito diferentes. Já o Pentium4 deve utilizar microOPs mais elementares, mas não sei bem a que ponto. Creio que intruções LOAD-OP ou LOAD-OP-STORE estão fora de questão, mas não sei que tipo de endereçamentos são suportados.
Para complicar ainda mais esta questão, vários dos POWERx/PPC970 da IBM fazem o mesmo: decompor as intruções PowerPC em IOPs (nomemclatura IBM) um pouco mais simples (a maioria das intruções PPC decompõe-se numa IOP, mas algumas decompôem-se em duas). Quanto à possibilidade de aceder ao interior, os motores de microcode da Intel podem ser actualizados por software.. Mas alguém teria que fazer reverse engineering disso e o motor de microcode é lento.
|
| |
| | | Mas o RISC impôs-se naturalmente, por mérito próprio. Gasta menos energia, tem pipelines mais pequenos, etc. Infelizmente, todos violam o RISC nalguma coisa, o que não critico na especialidade. O PPC é um micro RISC que de RISC tem muito pouco. Uma coisa que adoro nos RISC é a ortogonalidade. Nos PIC e Scenix, quando fazes um if (teste), ou acertas e tens uma instrução de penalidade ou falhas e não tens penalidade, mas o PC = PC + 2. De qualquer modo, sabes que num teste vais executar a instrução seguinte dois ciclos depois, e podes contar com isso. Por isso eu digo, antes um Alpha a 667 Mhz que os PIV a 3 Ghz. Francisco Colaço
Quem não faz, ensina; quem não faz nem ensina, faz metodologia. Quem não faz nem ensina nem faz metodologia, faz futurologia. |
| |
| | | Desculpem, expliquei-me mal. O que quis dizer é que num teste a instrução seguinte é executada imediatamente, e normalmente é um JMP (um ciclo de penalidade). No caso de falha existe um ciclo de penalidade, pelo que as coisas vão dar ao mesmo. A próxima instrução ÚTIL é executada dois ciclos depois. Francisco Colaço
Quem não faz, ensina; quem não faz nem ensina, faz metodologia. Quem não faz nem ensina nem faz metodologia, faz futurologia. |
| |
| | Err.. essa questão de timings previsiveis tem mais a ver com a simplicidade do PIC.
Vais ali para o dito Alpha e toca a meter NOPs para melhorar a performance. :)
|
| |
| | | Como vemos, o Alpha viola todas e quaisquer regras RISC. Não critico isso, é uma questão de engenharia, e as regras podem ser violadas quando «valores maiores se alevantam.» Francisco Colaço
Quem não faz, ensina; quem não faz nem ensina, faz metodologia. Quem não faz nem ensina nem faz metodologia, faz futurologia. |
| |
| | A Microsoft anda na cama com a AMD por causa do suporte da Intel ao Linux...
Tonidosimpostos: "a firewall mais segura que conheço é o cinto de castidade!" |
| |
| | A noção de acordo entre a MS e a Intel já teve mais sentido... Ainda para mais tendo em conta a realidade do mercado de 64 bit "x86", em que a AMD dá as cartas. Ainda não foi há muito que foi anunciado o abandono da plataforma Itanium por uma série de (grandes) fabricantes, entre eles a Microsoft. O mercado muda, e de há uns anos para cá que a posição da MS tem sido de não se comprometer demasiado. Goste-se ou odeie-se a Microsoft, a verdade é que eles sobreviveram a pelo menos dois pontos de viragem do mercado (84-85 e 94-95), e estão vivos e de boa saúde. Não chegaram onde estão hoje sendo parvos.
Pornografias gratuitas... |
| |
| | Pelo menos esta tecnologia funcionou para os Replicators (Stargate SG-1). Ha inumeros artigos com arquitecturas inovadoras para processadores. Todos afirmam que serão a razão para a morte do x86...viu-se... Espero para ver (sentado)
|
| |
| |
| | Espero para ver (sentado)
O que vale é que o banco dá para muita gente :-)
---
Este espaço pode ser seu... |
| |
|
| | Um exemplo deste efeito ocorreu quando a Intel decidiu lancar os novos IA64 executando instruções 32bits em modo emulado (+lento).
A AMD ficou ganhou logo mercado quando referiu que os processadores AMD64 executavam instruções 32bits em modo nativo.
Por muito má e remendada que a arquitectura X86 seja, a inércia criada pela cota de mercado é monstruosa.
|
| |
| | Eu sou extremamente céptico quanto toda esta histeria em redor do Cell, simplesmente porque tenho memória e ainda me lembro da histeria em redor do "Emotion Engine", o CPU da PS2.
Eu concordo com o que o Linus Torvalds disse numa entrevista recente: a arquitectura é muito promissora em termos de capacidade, mas vai falhar em grande se não for fácil de programar.
A verdade é que ninguém vai querer ser o primeiro a fazer optimizações à mão às aplicações para tirarem partido dos cores vectoriais. Portanto, se tal não for trivial de fazer, ou melhor ainda, se o compilador não fizer isto na maioria dos casos, vai morrer da mesma forma que todos os outros supostos x86-killers.
Ora vejam o caso das extensões SSE/SSE2: estão agora em quase todos os x86 (SSE está em todos os Athlons, e SSE2 nos Opterons e Athlon64 - para além dos Intel, claro), e mesmo assim têm muito pouco uso (drivers das placas gráficas ou software optimizado à mão).
Outro caso é o do IA64, onde o compilador toma conta do trabalho chato, e mesmo assim é um flop para todos os efeitos.
Não, para a computação generalista não acredito que vá para além de um POWER4 com uma data de unidades AltiVec que têm de ser usadas "à mão", e assim vai falhar.
Mesmo que eu esteja apenas a ser pessimista, por mais capacidade de processamento que tenha não vai conseguir arrumar com o x86. A herança é demasiado pesada apenas o Linux vai ser portado para lá. Olhem o caso do x86-64: há tanto tempo no mercado e ainda não existe um Windows 64bit para ele, e é x86!!
--
Carlos Rodrigues
|
| |
| |
| | | Ora vejam o caso das extensões SSE/SSE2: estão agora em quase todos os x86 (SSE está em todos os Athlons, e SSE2 nos Opterons e Athlon64 - para além dos Intel, claro), e mesmo assim têm muito pouco uso (drivers das placas gráficas ou software optimizado à mão). A questão dos SSE's é completamente diferente. Existe muito código que é desenvolvido para Pentium MMX, mas que, por questão de compatibilidade, não usa SSE/SSE2. Na altura, a "guerra" entre a AMD e a Intel em nada contribuía para a uniformização do mercado. As aplicações para tirarem partido das vantagens dos cpus Intel e dos Cpus AMD tinham que suportar ambas as tecnologias, MMX/SSE e 3DNow!. Ora, na maioria das aplicações em que isso interessa, implica reprogramar as rotinas-base da aplicação em 2 arquitecturas diferentes, e até há bem pouco tempo, em assembly feito à mão. Não sei se alguma vez tentaste fazer código optimizado para P3 ou P4, mas aposto que para uma coisa razoavelmente complexa um compilador de C mediano faz melhor trabalho. Porquê? Por causa do branch prediction mecanism, dos stalls de instruções não cacheáveis e endereços de memória que não estavam alinhados a 32 bytes, por causa do pairing de instruções, por causa da velocidade do vento... Duas vezes, para 2 arquitecturas intercambiáveis mas com características de optimização diferentes, e com a desvantagem de muitas dessas características não serem retrocompatíveis. Algumas optimizações de P4 por exemplo produzem resultados horríveis em processadores anteriores, mas raramente optimizações anteriores (para pentium) provocam danos perceptíveis na performance do código.
Depois, há toda a questão do mercado de software. O mercado de software evolui de forma muito mais lenta que o mercado de processadores. Prova disso é que hoje se consegue fazer tarefas com equipamento mais antigo que na altura em que esse equipamento era topo de gama não se conseguia. Olhem o caso do x86-64: há tanto tempo no mercado e ainda não existe um Windows 64bit para ele, e é x86!! Não há necessidade premente de um Windows a 64bit quando as máquinas existentes a 64Bit de última geração correm a versão de 32 bit mais rápida que a generalidade das máquinas de 32 bit, sem o custo da eventual perda de estabilidade numa nova plataforma. Além disso, a estratégia da MS era ambígua até recentemente; tanto falavam em Itanium como em AMD64. E, digam o que disserem, e por mais ambições que a Microsoft tenha, neste momento o forte do mercado windows é o desktop; não me parece que vão comprometer a estabilidade (e a "imagem" das versões datacenter do 2003) para ganharem um punhado de utilizadores. Dentro de um ou dois anos, quando for comum a utilização de cpu's de 64 bit, não vai faltar software para eles, como hoje se passa com o SSE, que (sim, é verdade) é usado em tudo um pouco, desde drivers de impressoras a codecs de vídeo.
Pornografias gratuitas... |
| |
