Cell Architecture Explained: Introduction

[Tafinho]

1º Sabem o k é 1 jogo?

Um jogo é dificil de pararelizar devido á imprisibilidade dos acontecimentos e a uma maior dependescias entre instruções.
Isso n é resolvido com 1 compiler magico mas sim pelos programadores, embora isso aumente a quantidade de bugs e tempo perdido.

As gráficas actuais são 16x paralelas. Se achas qque os jogos não podem ser paralelizáveis é contigo.

Principal programador da Epic Tim Sweeney ( a desenvolver 1 dos 1 motores multithread - Unreal Engine 3)

"Auto-parallelization of C++ code is not a serious notion. This falls in the same category as the Intel compiler's strip-mining optimizations and other such tricks, which are designed to speed up one particular loop in one particular SpecFP benchmark. These techniques applied to C/C++ programs are completely infeasible on the scale of real applications."

Experimenta fazer o grafismo de um jogo em C++.

3º Sabem o k se pode pararelizar?
A maior parte n pode se pararelizado, devido a sua natureza imprevisível ou a sua linearidade.

"For multithreading optimizations, we're focusing on physics, animation updates, the renderer's scene traversal loop, sound updates, and content streaming.We are not attempting to multithread systems that are highly sequential and object-oriented, such as the gameplay."

Isto é quase o jogo inteiro. Mas segundo isto um jogo já *É* paralelizável.

"You definitely don't want to execute your 150,000 lines of object-oriented gameplay logic across multiple threads - the combinatorical complexity of all of the interactions is beyond what a team can economically manage."

Já viste os servidores de Everquest e de todos os outros massive multiplayer que andam por aí? Devem ser todos single CPU single core.

3º Sabem programar?
Na minha modesta experiência já constatei a dificuldade de criar varios paths para manter varios cpu's permanentemente ocupados.
Manter os 2 cores a 100% seria impossível neste momento, mas com o tempo os programadores vão melhorando, mas vai demorara muito tempo e ao principio só os big names é k iram aproveitar essa tecnologia.

Em Cell ainda não, mas espero lá chegar.

 

[Xpirit]

Confirma-se aquilo que pensava. Leem, leem mas não compreendem.

Um jogo não se resume ao gameplay, infelizmente. Se assim fosse haveria muita gente a fazer jogos. Esta é a parte que menos custos computacionais tem e é logica banal. Não são precisos *n* cores para fazer comparações do tipo. Se fulano A fizer B (tocar num butão) então C.

Há o rendering em suma a imagem, há a fisica e o controlo de milhares de objectos, há o som, há os efeitos especiais. Tudo isto é paralelizável.

O gameplay, storyboard ou what ever não é fácil de paralelizar. É o que dizem quase todos os programadores de jogos. É verdade e no meu post disse que o que não se consegue paralelizar corre bem num core ***** P4 ou AMD64 actual. O custo computacional do gameplay é ridículo comparado com o resto. Não é por acaso que as pessoas gastam muitas dezenas de contos em placas gráficas. O mais difícil é a renderização da imagem e essa já é paralela há imenso tempo. Como o Tafinho disse, é actualmente pelo menos 16x paralela. Se assim não fosse ainda andarias a jogar tetris em vez de Doom3.

As referências a auto-paralelização são para rir. Ele está a referir-se ao OpenMP suportado pelos compiladores da Intel, por exemplo. Não é assim que se vai lá. O problema dos programadores de jogos é que nunca pensaram em paralelo e vão ter que aprender, mudar e não é de um dia para o outro.

Já tenho 3 anos de experiência em paralelização e devo dizer que a forma de programar é diferente. A forma de resolver os problemas é ligeiramente diferente. O raciocínio necessário para desenvolver é diferente.

Voltando ao Gameplay. Mesmo isto é paralelizável. Diria mesmo, altamente paralelizável mas vai levar tempo. Se o mundo em que vivemos é por natureza paralelo, onde todos nós pensamos, actuamos e vivemos em paralelo é natural que um jogo que pretenda simular a realidade
também o seja. O problema é que estamos no limiar de uma mudança radical na forma de programar e vai haver resistências.

Já ví muita coisa em 20 anos de alguma experiência no mundo do jogos.
Muita coisa mudou desde dos jogos do Spectrum onde praticamente faziamos tudo desde do código para a renderização da imagem, o próprio audio tinha que ser inventado e de um beep tinhamos que fazer música.
Fazer motores gráficos para o Spectrum e mais tarde para Comodore ou Atari é que davam luta. Quem não se lembra de jogar pela primeira vez o Elite. Enfim. Hoje com as inúmeras API's que existem é mais fácil. Afinal deve-se usar o que se foi descobrindo e desenvolvendo nos últimos 20 anos.

Já há alguns anos que os jogos são essencialmente *desenho*, *bonecada*, *som* e gameplay, mas aquele que se faz no papel. A história. Em Portugal não se fazem jogos por falta de programadores mas por falta de designers, músicos, etc.

O advento do *dual-core* vem trazer para a ribalta os programadores, felizmente, para quem gosta desta arte.

 

[|Oc|CRASH_OVer]

Tafinho olé!

zaron... basta olhar para a arquitectura das graficas e ver que é tudo aos pares.
E se achas impossivel, a Saturn e Ps2 funcionam dessa maneira.... e os jogos pelo pouco que posso reparar, estao impecaveis.
Se reparares a Ps2 é um Gpu ela propria... 1 mips core + vectores independentes. Os jogos sao pararelizados de raiz na ps2.
O cell é um ***** + 8 unidades (como a ps2)... eu digo que o trabalho ja vai a meio caminho na pararelização dos jogos a este nivel de hardware.

 

[Xpirit]

.Em Cell ainda não, mas espero lá chegar.

Temos que arranjar uma Dev machine.

 

[Nemesis11]

Em relação às modificações no PPE:

Qual é a probabilidade de algumas software houses, mais pequenas, só "conseguirem" usar o PPE por uma questão de simplicidade, recursos, tempo, etc, e por causa disso a Ibm/Sony está a melhorar a performance do PPE?

 

[Zar0n]

O problema e k vcs tão a confundir o k o GPU faz com o k o CPU faz.

As gráficas actuais são 16x paralelas. Se achas qque os jogos não podem ser paralelizáveis é contigo.

Experimenta fazer o grafismo de um jogo em C++.

Mas o k é k as gráficas têm a ver com o k o CPU faz?

Já viste os servidores de Everquest e de todos os outros massive multiplayer que andam por aí? Devem ser todos single CPU single core.

Que é k 1 servidor dedicado tem a ver?
Tem k gerir os varios users? Ai sim os multicore brilham como em outras aplicações server.

O CPU esta a fazer coisas como o gameplay, AI, fisica, etc.
Na parte dos GPU as historia é muito diferente mas isso não tem a ver com o DC.

Eu nunca disse k era impossível ter ganhos, mas estes exigem mais esforço aos programadores, e demoram mais tempo, e nem todas a editoras se podem dar a esse luxo.

A maior parte tem prazos muito apertados, e como se tem visto cada x os jogos sem mais inacabados e com mais bugs.
Basta ver k dantes era raro sacar 1 patch, agora ha jogos injogáveis sem os 1ºs patchs.
Como tal nem todos vão ser optimizados para dual core, e nos próximos 18 meses o Single deve ser de longe a melhor opção para jogos.

O cell n esta na mesma situação do k os dual core, já k ai todo o software vai ser optimizado e compilado para esse CPU especifico.
Agora quando vcs dizem k dual core = dobro da performace, bem descupem mas isso é ridículo! Ate nos 1º jogos optimizados.
Basta verem 1 caso diferente, em k tudo é muito mais fácil, o caso do SLI/AMR e a performance n é o dobro, alias esta muito longe de o ser.
Mas esperem ate o 1 jogo sair, e dps de ver os testes a uma resolução k n esteja limitado pelo GPU a gente fala.

 

[sapropel]

eu não li a thread toda, e tou aqui é para aprender qualquer coisa e não para mandar bocas pro ar. dito isto, digam-se só:

programar em 2+ cores mete-se o mm problema que programação multithreading? aquela insegurança, que não sabemos se a thread Y vai mudar a variavel X que vai dar chatices (depois de alterada) na thread Z se a coisa não for feita com cuidado?

o que não falta aí são APIs inseguras para programação multithreading, portanto a minha dúvida é essa.

Mas se o problema não é esse, então qual o problema?

obrigado.

 

[|Oc|CRASH_OVer]

zaron, foi dado o exemplo dos dual-core pois as aplicações optimizadas dobravam a performance nele. EMBORA isso não seja sinonimo que o mesmo aconteça em jogos de Pc por razões obvias (e que todos entendemos), temos de admitir que tal é possivel, ainda por cima se estivermos a falar de um cpu de caracteristicas multi-threaded para CONSOLAS (etc)
a PS2 funciona com 3 unidades de calculo + um Graphic synthesizer, embora nem todos os jogos tirem partido dos 2 vectores, os que tiram ficam bons, mt bons (Gow GT4 Tekken5 Vf4) etc...

se sai caro ou nao, isso ja esta fora do campo tecnologico e nao entra nas equações..

 

[Tafinho]

O problema e k vcs tão a confundir o k o GPU faz com o k o CPU faz.

Mas o k é k as gráficas têm a ver com o k o CPU faz?

Nada. Os gráficos aparecem por obra e graça do espírito santo.

Que é k 1 servidor dedicado tem a ver?
Tem k gerir os varios users? Ai sim os multicore brilham como em outras aplicações server.

Deves pensar que um servidor tem 1 processo dedicado por cada utilizador...

O CPU esta a fazer coisas como o gameplay, AI, fisica, etc.
Na parte dos GPU as historia é muito diferente mas isso não tem a ver com o DC.

Curiosamente (ou não) todas essas coisas são facilmente paralelisáveis...

O cell n esta na mesma situação do k os dual core, já k ai todo o software vai ser optimizado e compilado para esse CPU especifico.

A optimização é feita no compilador...
O código pode ser o mesmo, mas agora aparenta já ser paralelisável... curioso..

Agora quando vcs dizem k dual core = dobro da performace, bem descupem mas isso é ridículo! Ate nos 1º jogos optimizados.

Depende do caso concreto. É possível teres ganhos superiores a 100%.

 

[Tafinho]

programar em 2+ cores mete-se o mm problema que programação multithreading? aquela insegurança, que não sabemos se a thread Y vai mudar a variavel X que vai dar chatices (depois de alterada) na thread Z se a coisa não for feita com cuidado?

Depende se usares threads ou processos.

 

[|Oc|CRASH_OVer]

Na demo dos 48 videos mpeg2:

What's perhaps even more interesting is that they did this using software that allowed the programmers to code this without worrying what SPE does what - their software automatically split everything up for them (though this is perhaps easier to do with an application like this than in general).

uhmmm...

 

[Xpirit]

Transcrevendo algo que escrevi noutro fórum:

Cell, também conhecido por "o cpu que o Tafinho diz que não vale nada" vai ser discutido ao vivo já no próximo dia 6 de Junho em Barcelona. Certamente que não vão perder o vosso tempo.

The first European Power.org Community Conference will be hosted by the Barcelona Supercomputing Center at the Campus Nord of the Technical University of Catalonia in the City of Barcelona — site of the Mare Nostrum supercomputer, one of the top supercomputers in Europe based on the Top500 Supercomputer list — on June 9, 2005.

The agenda:

The Barcelona technical conference agenda includes a balanced mix of technologies (microprocessors and architectures including Cell) and business and technical challenges from a wide variety of applications fields (information technologies, life sciences, physics and engineering, telematics, media, and entertainment), bringing together the end users and the R&D staff that produce and maintain the technologies and solutions. The day will consist of exciting technical seminars in the areas of academic applications, scientific applications, and Power Architecture™ and Linux® solutions. Many of the topics were submitted via the power.org web site by fellow Power Architecture Community members. They will focus on innovative solutions, challenging problem solving, as well as, experiences, and lessons learned with Power Architecture technology.

http://www.power.org/events/barcelona.html

O comboio está em movimento.

 

[Nemesis11]

Por falar em comboio em movimento.....

IBM will unlock door to Cell

San Jose, Calif. — The three developers of the Cell processor are preparing to release full chip specifications and software libraries in an effort to rally the open-source community around the device that powers the Sony Playstation 3. With the outlook for the multicore chip's use beyond Sony's internal systems cloudy at best, the partners are hoping to spark its uptake in applications ranging from HDTVs to supercomputers.

http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=163106213



Pics e specs do "Cell Server" da IBM:

Cell(2.4GHz～2.8GHz)*2
XDR-RAM(512MBit*10)*2
South Bridge LSI*2
400Gflops(if 3.0GHz)
OS:Linux 2.6.11

http://techon.nikkeibp.co.jp/article/NEWS/20050524/105016/

 

[_zZz_]

bem..noticia excelente! isso significa que com os specs ca fora o people do open source vai poder fazer milagres com a consola

_zZz_

 

[Xpirit]

Transcrevendo algo que escrevi noutro fórum:

Cell, também conhecido por "o cpu que o Tafinho diz que não vale nada" vai ser discutido ao vivo já no próximo dia 6 de Junho em Barcelona. Certamente que não vão perder o vosso tempo.

The first European Power.org Community Conference will be hosted by the Barcelona Supercomputing Center at the Campus Nord of the Technical University of Catalonia in the City of Barcelona — site of the Mare Nostrum supercomputer, one of the top supercomputers in Europe based on the Top500 Supercomputer list — on June 9, 2005.

The agenda:

The Barcelona technical conference agenda includes a balanced mix of technologies (microprocessors and architectures including Cell) and business and technical challenges from a wide variety of applications fields (information technologies, life sciences, physics and engineering, telematics, media, and entertainment), bringing together the end users and the R&D staff that produce and maintain the technologies and solutions. The day will consist of exciting technical seminars in the areas of academic applications, scientific applications, and Power Architecture™ and Linux® solutions. Many of the topics were submitted via the power.org web site by fellow Power Architecture Community members. They will focus on innovative solutions, challenging problem solving, as well as, experiences, and lessons learned with Power Architecture technology.

http://www.power.org/events/barcelona.html

O comboio está em movimento.

É já amanhã...

We would like to remind you of theWe would like to remind you of the Web Broadcast for Power.org in Barcelona on the 9th June 2005.

To access the Web Broadcast on the 9th June 2005 please visit http://www.power.org/events/barcelona

To view the latest Agenda please visit http://www.power.org

If you have any questions you may contact the registration team at [email protected] or on +44 (0)208 334 6974


The Power.org Conference Registration Team

 

[chight]

Depende se usares threads ou processos.

Depende também se estás numa situação em que podes, ou não, usar processos.

Com tanta dependência, é complicado argumentar que um algo X que tem mais 3 vezes mais dependências que algo Y demore o mesmo tempo a computar. Não é pelo facto de terem lá as pipelines que torna tudo divisível. Existem operações atómicas que não podem ser divididas. Para que se dê uso correctamente de um processamento pipelined é preciso preparar bem os dados a processar e ter um bom motor predictivo. Logo, é trabalho extra. Logo tens que optimizar o código para que dês uso a essa funcionalidade, logo demora mais tempo.

Neste fórum o bom senso é coisa que raramente existe. Parece que a malta tem a tendência para contrariar tudo o que os outros dizem só para marcar uma posição. Por vezes penso que se a primeira pessoa a começar o tópico dissesse o contrário do que disse, as pessoas que o contrariavam, contrariam na mesma pois a sua opinião é a contrária a qualquer uma que venha, seja ela certa ou errada.

 

[Tafinho]

Depende também se estás numa situação em que podes, ou não, usar processos.

Neste fórum o bom senso é coisa que raramente existe. Parece que a malta tem a tendência para contrariar tudo o que os outros dizem só para marcar uma posição. Por vezes penso que se a primeira pessoa a começar o tópico dissesse o contrário do que disse, as pessoas que o contrariavam, contrariam na mesma pois a sua opinião é a contrária a qualquer uma que venha, seja ela certa ou errada.

Sempre que podes usar threads, podes usar processos.

A ti faltou-te bom senso para amanhar o contexto da discussão, e conhecimentos para saber distinguir processos de threads, e quais as vantagens e desvantagens de cada um deles. Posso-te dizer, que usar processos é SEMPRE mais seguro que usar threads, dá muito menos trabalho a sincronizar, mas pode ter desempenho ligeiramente mais baixo, especialmente quando só tens um processador.

Não existe discussão sobre se a paralelização é ou não o futuro. Isto já não tem discussão.
Claro que se quiseres "inovar" e não quiseres usar SMP ou SMT, então o Cell terá um desempenho semelhante a um K6.

 

[chight]

usar processos é SEMPRE mais seguro que usar threads, dá muito menos trabalho a sincronizar,

Concordo que é mais seguro porque um processo não pode corromper outro processo.

No entanto, não falei em segurança. Falei em termos de complexidade de código e tempo de desenvolvimento.

Nesse aspecto a comunicação inter-processo é mais dispendiosa pq tens que efectuar a mudança de contexto entre processos. Isto envolve entre dois processos A e B mudar o contexto de utilizador do processo A para o contexto do kernel e mudar este processo de novo para o contexto de utilizador do processo B. A comunicação inter-thread usa a memória partilhada do processo e não necessita de mudança de contexto. É menos segura, mas uma vez mais, eu não falei em segurança.

Sempre que podes usar threads, podes usar processos.

Sempre que posso ir de carro a um sítio, também posso ir a pé.
Resta saber o que é mais eficiente. É uma questão de bom senso.

Em relação à questão de eu ter ou não conhecimentos para distinguir o que são processos e threads e à tua opinião em relação a isso, resume-se mesmo a isso, a tua opinião.

 

[Tafinho]

Concordo que é mais seguro porque um processo não pode corromper outro processo.

No entanto, não falei em segurança. Falei em termos de complexidade de código e tempo de desenvolvimento.

A comunicação inter-thread usa a memória partilhada do processo e não necessita de mudança de contexto. É menos segura, mas uma vez mais, eu não falei em segurança.

Precisamente pelo facto de que 2 threads usam o mesmo espaço de memória gastas BASTANTE mais tempo de desenvolvimento para te certificares que não há problemas, porque senão de certeza que haverá problemas.
Já com processos, é tudo trabalho para o kernel, não para o programador.

Mas não te iludas, a perda de desempenho nos processos não é devido à sincronização, já que esta terá sempre que passar pelo kernel, e envolverá sempre um context switching, quer estejas com threads ou processos. O context switching é que é mais demorado.

Daqui a vantagem do software com threads em CPU's SMT, e dos processos em software SMP.

Sempre que posso ir de carro a um sítio, também posso ir a pé.
Resta saber o que é mais eficiente. É uma questão de bom senso.

Agora falta-te uma opinião informada para decidires qual é o mais eficiente. O bom senso não vem para aqui chamado.
Um software com threads perde bastante desempenho quando o sistema tem mais quem 1 processador.

 

[NeoToPower]

Estive aqui há momentos com um cliente que trazia consigo um palmpc e vei-me uma ideia maluca á cabeça.
ora, num palm temos o processador central, um gpu ( os mais recentes) e em alguns um chip dedicado ao som.
Ora tendo em conta que o cell tem á sua cabeça um costum PPC que se encarrega da parte general porpuse e várias unidades vectoriais que podem fazer desde processamento grafico até processamento de som ( lembrem-se que a PS3 ñ vai ter chip de som... vai ser tudo feito pelo cell), ñ seria possivel "capar" o cell ccom apenas 3 vectores ou mesmo 2 e ainda assim oferecer aceleração 3d e boa qualidade sonora num Palm PC? Seria de certo uma solução muito mais barata do que ter n chips.
Eu sei que parace assim uma ideia treloucada e tal, mas acho que têm a sua lógica