Fim das aulas! Foi rápido, mas foi bom enquanto durou! Depois de dois dias com bombardeios massivos de informação eu estou esgotado(dirigir mata também!), precisando de uma boa noite de sono! Mas antes, ao blog! Escrever enquanto as coisas ainda estão frescas na cabeça! Vou manter o mesmo esquema de ontem que parece que funcionou bem!
Arquitetura
Tenho para acrescentar aqui alguns detalhes técnicos que pude observar enquanto estavamos fazendo as pequenas aplicações para o cell.
1. O processador como um todo tem… 128 registradores de uso geral!!!!!! Comparado à arquitetura x86 (4 registradores) e com a x86_64 (8 registradores) a arquitetura cell obviamente tem muuuiiiito mais registradores!! Enquanto estavamos avaliando o desenpenho de um aplicativo (multiplicação de matrizes) foram usados 41 registradores… nem perto número total de registradores.
2. Cada um desses 128 registradores guardam 4 posições de 32bits cada (128bits no total), o que facilita as operações vetoriais.
3. Cada SPU tem dois pipelines! Um somente para funções aritiméticas outro para branchs, etc etc.
4. Os SPU não têm previsões de branch, então toda e qualquer previsação que seja feita e realizada via compilador = [
5. O cell está suportando executáveis até 256Kb… ou seja, se precisar de mais chore! Classes virtuais e Typedefs mal definidos podem causar vááários problemas!
Programação
Hoje tivemos contato com a vetorização de problemas, que pelo que entendi pode ser aplicado em poucos casos, mas que quando processado nos processadores cell têm um ganho de desenpenho de praticamente quatro vezes, se não mais. Todo esse ganho de desenpenho acontece por causa de uma característica da arquitetura que citei acima. Já que cada registrador apresentar 4 posições de um vetor, então, por exemplo, quando se quer somar dois vetores, as somas serão feitas entre blocos de quatro posições(ou seja a soma entre dois registradores). Além da soma existem várias operções entre vetores, que eu me lembre as aritméticas e as de seleção, porém existem várias funções nas bibliotecas nativas. Mas retomando,em outras palavras, na arquitetura x86 o atômo seria uma posição do vetor certo ? Na arquitura cell o atômo é um vetor de quatro posições.
O que nos leva a um problema! Se o atômo do cell é um vetor de 4 posições, como são feitas operações com inteiros simples, ou floats simples ?? Você deve estar imaginando, mas não quer aceitar… Sim… os inteiros(qualquer escalar de forma geral) são convertidos para vetores, os vetores são somados, e o vetor é convertido para int novamente! Veja, enquanto uma operação a+1 exige somente uma instrução para x86, para a arquitetura cell, são necessárias SEIS, isso mesmo SEIS, instruções. Agora imagine você um “FOR”, ele ficaria 6 vezes mais lento cada vez que sua repetição for executada! Agora amplie isso para todo uma aplicação, se em sua maioria ela fizer processamento de valores escalares, ela será bem mais lenta que a mesma aplicação rodando em x86. Viu? Cell não é bom para tudo, definitivamente.
Não sei se ficou claro no Post anterior, mas o PPE é equivalente a um PowerPC, mas o C, é o exatamente o mesmo que nós estamos acostumado, só algumas funções são diferentes por causa das bibliotecas. O mesmo se aplica ao SPE.
Conclusão
Continuo com a mesma impressão que tive ontem, Cell parece ser muito bom para algumas tarefas, as que podem ser subdivididas e processadas vetorialmente. Fora isso, esqueça Cell, os x86, x86_64 fazem muito bem o trabalho com programação escalar! Sobre a programação, também continuo a afirmar que o SDK está precoce! Mas tenho que admitir! Valeu a pena!
Pessoal Presente no TechnicalBrief
Intervalinho, hora de ler e-mails!
Ping-Pong no canto inferior direito da foto!
Feed-me (RSS)
