Una nuova dimostrazione della tecnologia Cell

[Maury]

Originariamente inviato da fek

La verita'? Non e' ho la piu' pallida idea
A pelle sono piu' vicino alla soluzione dell'XBOX2, che mi sembra piu' flessibile e facile da programmare, ma la soluzione della PS3 dovrebbe essere in linea teorica piu' performante e complicata da programmare.
A questo stadio, senza aver mai scritto una riga di codice per nessuna delle due, non saprei davvero dire di piu'.

Grazie

Sbaglio se dico che la PS3 è più forte di Xenon nel lato CPU ma più deficitaria nel versante VPU ? Del resto si dice che la VPU nVidia sia una derivazione di base GF6800, quindi unità NON unificate, mentre Xenon potrebbe avere una gestione dei pixel/vertex molto più efficente.

[fek]

Originariamente inviato da Maury

Grazie

Sbaglio se dico che la PS3 è più forte di Xenon nel lato CPU ma più deficitaria nel versante VPU ? Del resto si dice che la VPU nVidia sia una derivazione di base GF6800, quindi unità NON unificate, mentre Xenon potrebbe avere una gestione dei pixel/vertex molto più efficente.

Ma potrebbe anche non averlo. Davvero, a questo stadio non sappiamo proprio nulla, anch'io non ho ancora visto i data sheet di nessuna delle due. Spero di mettere a breve le mani sui manuali dello Xenon.

[Maury]

Originariamente inviato da fek

Ma potrebbe anche non averlo. Davvero, a questo stadio non sappiamo proprio nulla, anch'io non ho ancora visto i data sheet di nessuna delle due. Spero di mettere a breve le mani sui manuali dello Xenon.

muoio dalla voglia di sapere cosa c'è dentro a ste scatole malefiche

[Criceto]

Originariamente inviato da fek

Un bonus che costa transistor che possono essere usati meglio in applicazioni che non richiedono le PPE (il 90%).

Un bonus che ti permette di fare in real-time quel 10% di cose che inchiodano gli altri computer...

[fek]

Originariamente inviato da Criceto

Un bonus che ti permette di fare in real-time quel 10% di cose che inchiodano gli altri computer...

Ma lo capisci che se a me interessa compilare un programma, non mi interessa che faccia l'encoding di 48 video in simultanea???
Ma lo cogli questo piccolissimo problema?
Voglio solo compilare, fosse per me puo' anche cacare fulmini e saette il Cell, ma se si inchioda a fare il 90% di quello che mi serve, se lo possono anche tenere.

E la compilazione e' solo un esempio, e vale anche per il restante 90% di cio' che di solito si fa con un PC.

[Coyote74]

@Fek
Per essere più precisi, visto che c'è anche gente, come me, che ne capisce poco di queste cose... Quali sono in soldoni le applicazioni comuni in ambito PC dove il Cell sarebbe deficitario e quali dove invece sarebbe una bomba. Mi piacerebbe avere una specie di lista tipo:
Word-processing: fa schifo
Compilazione: fa schifo
Streaming Video: è una bomba

Sai perchè te lo chiedo? Perchè non tutti gli utenti PC sono uguali, c'è chi predilige un applicativo ad un altro. Quindi magari per te il Cell è inutile, ma per uno che lavora in ambito grafico o audio-video potrebbe essere la famosa chimera.

Certo è che finalmente si stà facendo un po' di chiarezza su questa tecnologia, non avrei mai immaginato tante problematiche. Ma è naturale, penso, visto che miracoli non se ne possono fare ed è come una coperta troppo corta. Certo è che finalmente qualcuno (Sony, IBM & Co) ha avuto almeno il coraggio di intraprendere una nuova strada, chissà che non risulti, alla fine, essere quella vincente.

[fek]

Originariamente inviato da Coyote74

@Fek
Per essere più precisi, visto che c'è anche gente, come me, che ne capisce poco di queste cose... Quali sono in soldoni le applicazioni comuni in ambito PC dove il Cell sarebbe deficitario e quali dove invece sarebbe una bomba. Mi piacerebbe avere una specie di lista tipo:
Word-processing: fa schifo
Compilazione: fa schifo
Streaming Video: è una bomba

Hai gia' fatto tu l'elenco.
Posso aggiungere che in genere le applicazioni dove il Cell va molto bene sono quelle che richiedono molti calcoli relativamente semplici su un flusso di dati (il processing video e audio).

Va molto male in applicazioni che manipolano strutture dati complesse, come la compilazione, la gestione di database, fogli elettronici, l'IA dei giochi, la gestione delle scene 3d sempre nei giochi, anche se alcuni mettono queste applicazioni fra i punti di forza del Cell.

[Coyote74]

Scusa FeK, ma le scene 3d non sono vettorizzate? A quel punto dovrebbe andare benone, meglio di un processore tradizionale. Se invece intendi che a quel punto una GPU le gestisce meglio allora è un altro paio di maniche.

[Darkdragon]

vi dico subito che:
-mi sono avvicinato seriamente all informatica da 2 mesi
-anche se ho un sony non sono stato influenzato dal marketing
-fino a quando non ho le prove non grido al miracolo, ma questo processore e il futuro della multimedialita, a molte condizioni pero, la piu importante credo che sia quella di avere affianco un proc con architettura x86 e una gpu.
lo li metterei su un socket della MB affianco al proc con delle loro ram.
CPU, GPU e CELL che lavorano insieme credo possano dare grandi risultati se ho capito bene.
(vorrei aprire una parentesi su una cosa che molti non hanno capito: si chiama "cell" perche proprio come una cellula lavora "in simbiosi con altre cellule" come gli xeon e gli opteron, ma questo ovviamente dipendera dal costo)

[fek]

Originariamente inviato da Coyote74

Scusa FeK, ma le scene 3d non sono vettorizzate? A quel punto dovrebbe andare benone, meglio di un processore tradizionale. Se invece intendi che a quel punto una GPU le gestisce meglio allora è un altro paio di maniche.

Questo e' un errore comune

Una scena 3d non e' altro che un database ed e' gestito con algoritmi in parte simili.
Ci sono gli oggetti, gli oggetti sono organizzati in famiglie, un oggetto e' composto di sotto oggetti ai quali sono associati materiali e poligoni.

Disegnare una scena significa eliminare gli oggetti non visibili in un qualche modo, metterli in ordine secondo un qualche criterio, applicare alcune trasformazioni e poi spedire i poligoni che fanno parte degli oggetti visibili al resto della pipeline che li trasformera' e dividera' in pixel (quest'ultima parte e' appannaggio della GPU o chi per lei).

Tutta la fase di ordinamento e controllo della visibilita' non e' altro che maneggiare una struttura dati piu' o meno complicata, da tenere tendenzialmente sempre in memoria cache per velocizzare gli accessi. E' molto simile come ho detto a gestire un database. Queste non sono operazioni che un processore come il Cell gradisce enormemente.

[Coyote74]

Grazie Fek, sei stato esaustivo e gentilissimo.

[Fx]

fek: hai lasciato fuori la fisica dei giochi, mentre un pc può gestire poche decine di oggetti un pc con vpu, una ps 3 con cell o una xbox 360 (che dovrebbe macinare gflops su gflops pure lei) dovrebbe gestirne migliaia

[fek]

Originariamente inviato da Fx

fek: hai lasciato fuori la fisica dei giochi, mentre un pc può gestire poche decine di oggetti un pc con vpu, una ps 3 con cell o una xbox 360 (che dovrebbe macinare gflops su gflops pure lei) dovrebbe gestirne migliaia

Hai ragione, una simulazione fisica e' spesso facilmente parallelizzabile, un calcolo relativamente semplice da svolgere su uno "stream di oggetti".

[Fx]

a tal proposito, sono molto curioso di vedere un gioco che sfrutta queste nuove tecnologie (siano esse cell, le unità vettoriali dell'xbox 360 o physx)... dev'essere un salto epocale

[Maury]

Originariamente inviato da Fx

fek: hai lasciato fuori la fisica dei giochi, mentre un pc può gestire poche decine di oggetti un pc con vpu, una ps 3 con cell o una xbox 360 (che dovrebbe macinare gflops su gflops pure lei) dovrebbe gestirne migliaia

Sembra proprio che XBox 360 integra la PPU Ageia per la gestione della fisica, le CPU non devono fare manco questo

[cdimauro]

Originariamente inviato da Criceto

Oh, ma ti dimentichi la "SPE" da 4.6 ghz dual-threaded!

Le hai scambiate: questa è la PPE (che comunque dovrebbe essere a 4Ghz, anche se inizialmente si pensava potesse raggiungere i 4,6Ghz in produzione).

Comunque è vero che può lavorare su due thread, ma è in grado di eseguire al più due istruzioni "in ordine". Paragonato a un G5 che riesce a estrarre e spedire in esecuzione fino a 5 istruzioni fuori ordine, la PPE è un cesso...

Anche scordandoci degli altri 8 cores, io credo che sarebbe sempre meglio dei G4/G5 attualmente montati su tutti i Mac ad esclusione dei PowerMac!

Vedi sopra: meglio un G4 a 1,5Ghz che una PPE a 4Ghz...

Le PPE vedile come "bonus"...

Vedi sopra: sono le SPE. E sono queste ad essere rilevanti, certamente non il PPE. Tant'è che i 250GFlops sono calcolati contando la potenza di calcolo delle SPE: il PPE non l'hanno cacato neppure di striscio...

Altro che "bonus"!

[cdimauro]

Originariamente inviato da Fx

io sapevo che hanno numero di registri, capacità di calcolo e numero di operazioni inferiori ad altivec...

Il numero di registri nell'architettura x86 (a 32 bit) è di 8, mentre in quella x86-64 è di 16. Comunque buona parte dei problemi "parallelizzabili" non usa molti registri: considera che già un solo registro è in grado di contenere 4 dati in virgola mobile a 32 bit (e addirittura 16 interi a 8 bit, 8 interi a 16 bit, ecc.).

Le capacità di calcolo sono simili: SSE (ma anche le "vecchie" 3DNow! di AMD) e Altivec sono in grado di effettuare 4 operazioni sui 4 dati per ciclo di clock. Altivec è più efficiente perché permette di usare 4 registri per ogni operazione, di cui uno con una maschera da applicare. Comunque l'uso di queste caratteristiche dipende strettamente dall'algoritmo da implementare.

Il numero di operazioni, invece, è superiore nel caso delle SSE: ne conta più di 200, se non erro. Ma non è la quantità di operazioni a fare la differenza fra due implementazioni SIMD, quanto piuttosto cosa fanno, e da questo punto di vista fanno più o meno le stesse cose. In più le SSE hanno anche un set di istruzioni scalari, che permette di fare a meno di passare dall'uso delle SIMD a quello dell'FPU x87 quando i calcoli si devono effettuare su un solo dato alla volta; cosa inutile per i G4 e G5, in quanto già dotati di un'ottima FPU (comunque gl Athlon, e in particolare gli Athlon64, sono molto efficienti anche sul codice x87).

[cdimauro]

Originariamente inviato da Criceto

Beh i Power5 sono di un'altra lega (e costo), ma Microprocessor Report è di un altro avviso in un confronto con gli attuali "G5":

"The performance of only the 4GHz Power core without the SPEs is harder to compare with the slower 2.5GHz G5 processor, because of the Cell core’s simpler microarchitecture. The higher clock speed of the Cell processor can still process many math operations faster than the G5 can, so we would give the performance edge to the Cell processor."

Sì, può fare tante operazioni più velocemente... Ma QUANTE ne riesce a fare in un ciclo di clock? Poche, visto che ne può fare AL PIU' due IN ORDINE. E' questo che devi capire.

[Criceto]

Originariamente inviato da cdimauro

Sì, può fare tante operazioni più velocemente... Ma QUANTE ne riesce a fare in un ciclo di clock? Poche, visto che ne può fare AL PIU' due IN ORDINE. E' questo che devi capire.

2 operazioni per ciclo di clock non fanno schifo. Quante ne può fare teoricamente il G5, 3? E considera che possono essere due istruzioni di 2 thread differenti, cosa che il G5 non può fare, quindi sono più facilmente utilizzabili.

Inoltre il bus e la memoria del Cell è estremamente più veloce, così come pure la frequenza. Sono architetture molto differenti, è difficile dire sulla carta quale delle 2 è più veloce, ma una cosa è certa: non ci sarà un abisso prestazionale tra un G5 attuale e una PPE del Cell. Potrà essere un po' più veloce una o l'altra, a seconda dei casi e dei compilatori. Ma all'atto pratico saranno SIMILI. E quindi dire che il Cell è da escludere per un utilizzo general purpose perchè per il codice scalare fà schifo è sbagliato.

Inoltre i compiti della PPE saranno limitati rispetto ad un processore attuale, in quando per il lavoro pesante ci sono sempre altri gli altri 8 cores SPE.
Infine i Cell sono progettati per lavorare insieme ad altri Cell, quindi fare macchine con più di 1-2 processori dovrebbe essere molto più facile che con i processori attuali e quindi si possono adattare bene anche per compiti che possono essere divisi in molti thread ma non sono vettorializzabili come la compilazione, che diceva Fek, o i database relazionali.

[leoneazzurro]

Originariamente inviato da Criceto

2 operazioni per ciclo di clock non fanno schifo. Quante ne può fare teoricamente il G5, 3? E considera che possono essere due istruzioni di 2 thread differenti, cosa che il G5 non può fare, quindi sono più facilmente utilizzabili.

Il G5 ha un limite teorico di più di 3 Comunque un'architettura OOO ha dei decisi vantaggi prestazionali.