Stai parlando di quel thread nel quale ti e' stato detto dal sysop di non frammentare i messaggi in modo incivile e decontestualizzante e vi e' stato criticato il fatto che vi siate iscritti nuovi nuovi e freschi freschi per venire a far il casino che non ho assecondato in altri forum?? :D Beh, sì, mi sa proprio che tu stia parlando di quello.
Sì, ricordi bene: è proprio quello in cui tu sparlavi me e fek alle spalle (e anche DJLode, se non ricordo male). Ed è il motivo per cui ci siamo iscritti.
Non avete fatto una gran figura agli occhi di nessuno lì dentro, tanto e' vero che e' diventato cosi' una merda quel thread che e' stato giustamente cancellato.
E' diventato così perché gente come te non aveva gli attributi per dire le stesse cose in faccia, riportando anche menzogne (sei stato tu a offendere pesantemente me qui in quel thread nella sezione Processori, e raccontavi l'esatto opposto).

La figuraccia l'hai fatta tu perché sei stato letteramente devastato su tutto quello che dicevi, e infatti ti sei anche ben guardato da rispondere a tutti i miei messaggi (come al solito: ma ormai ci sono abituato), visto che non eri in grado di argomentare.
Cosa che non accade piu' da quando non intervenite (fortunatamente). :)
Finché non parli alle spalle non hai niente da temere. Infatti mi dicono che te ne stai buono buono, dopo quella batosta: continua così che non mi vedrai mai più là dentro.
Ma a te basta compiacerti di te stesso. In fin dei conti, per me, hai l'importanza che hai, dunque fai pure. :)
Non tornero' sull'argomento.
Non c'è problema. Tanto siamo stati in tanti a partecipare, sappiamo benissimo com'è andata (io posso ancora recuperare i tuoi messaggi e quelli dei tuoi amichetti), e ci siamo divertiti un mondo a smontarti pezzo per pezzo davanti agli occhi dei tuoi fedelissimi amichetti.

Sara' stato il tuo gatto a scrivere questo allora:

A te si devono fare i disegnini (cosi' poi li colori con il gatto :) ), non ho mai definito uno SPE CPU per come la intendete voi. Se poi in un post (che non nascondo perche' come vedi lo ho riportato anche senza il tuo prezioso aiuto) ho scritto CPU al posto di "processore" ed a qualcuno questo non sta bene.. beh, ciccia!! :) Per il resto dei post in tutto(/i) il thread lo chiamo processore. Fermo restando che la differenza e' tanto sottile quanto discutibile (non oltre per me).
Il Cell e' e resta un'architettura multi processore e non un multi-DPS, multi Cooprocessore, multi- Servettotroppostupido o quante altre fantasiose definizioni abbiate trovato nel tempo. :)

A te si devono fare i disegnini (cosi' poi li colori con il gatto :) ), non ho mai definito uno SPE CPU per come la intendete voi. Se poi in un post (che non nascondo perche' come vedi lo ho riportato anche senza il tuo prezioso aiuto) ho scritto CPU al posto di "processore" ed a qualcuno questo non sta bene.. beh, ciccia!! :) Per il resto dei post in tutto(/i) il thread lo chiamo processore. Fermo restando che la differenza e' tanto sottile quanto discutibile (non oltre per me).
Il Cell e' e resta un'architettura multi processore e non un multi-DPS, multi Cooprocessore, multi- Servettotroppostupido o quante altre fantasiose definizioni abbiate trovato nel tempo. :)

Si' si', fammi i disegnini del multi-dps o del cooprocessore comprato alla coop.

Per non dimenticare:

Prima della cura.

Gli SPE sono delle CPU con delle limitazioni se paragonate ad altre (e delle agevolazioni se paragonate ad altre ancora, mi riallaccio e prendo per buono l'esempio ci VPU vista come CPU che tu hai riportato), ma sempre CPU rimangono.

Dopo la cura.

Non ho mai sostenuto inoltre che uno SPE sia una CPU, non so se qualcuno qui dentro lo ha mai sostenuto,

Anche l'Amiga aveva 26 canali DMA altamente integrati nel sistema, estremamente efficienti, che fa parte della concezione stessa dell'hardware di questa piattaforma.

Sono due cose completamente differenti. Ficchi l'Amiga ovunque!! Gia' mi stava sulle balle al tempo, ma ora me la stai mandando proprio sul.. :D

Sono le prestazioni della memoria a essere notevoli: sull'efficienza del DMA è da vedere.

No, non sono da vedere, sono da leggere.

Finalmente ci sei arrivato:

E' quel che scrivo sin dall'inizio, se non sai leggere o eviti di farlo, sono solo problemi tuoi che purtroppo riversi nei forum.

non c'avrei scomesso un centesimo.

Rischiero' di sembrare scortese, ma direi: "E sti cazzi". :) Risparmiati certi commenti idioti, fa' la cortesia.

Purtroppo gli altri mi hanno tolto lo spasso di quotarti e riportarti quello che avevi scritto. Peccato.
Dovresti vergognarti per le menzogne che continui a dire, visto che stai pubblicamente sconfessando tutto quello che avevi sostenuto fino a stanotte.
Meriteresti il bannaggio soltanto per questo, visto che non hai fatto altro che fomentare flame e insultare la gente che non la pensava come te tentando malamente di farli apparire come eretici e coglionazzi insignificanti che hanno avuto la sfrontataggine di mettersi contro tutto il mondo.
Se hai un po' di dignità dovresti quanto meno chiedere scusa, se non anche esiliarti togliendo il disturbo per tutto quello che hai combinato.
In merito ho risposto poco sopra. Per il resto, se non ti vorgogni tu di dare dell'ignorante al mondo intero, io potrei non vergognarmi nemmeno di andare in giro con un cesso in testa. :)

Non c'e' nulla di errato in quest'affermazione. E' esattamente la stessa affermazione dei documenti di IBM sul Cell, riprovaci :)

L'importante e' capirla bene la documentazione, questo qualcuno puo' essere lo stesso SPE tramite il proprio DMA incorporato.

Allora le SPE sono CPU o no? :asd:
Punti di vista. :)

A te si devono fare i disegnini (cosi' poi li colori con il gatto :) ), non ho mai definito uno SPE CPU per come la intendete voi. Se poi in un post (che non nascondo perche' come vedi lo ho riportato anche senza il tuo prezioso aiuto) ho scritto CPU al posto di "processore" ed a qualcuno questo non sta bene.. beh, ciccia!! :) Per il resto dei post in tutto(/i) il thread lo chiamo processore.
come già detto da qualcuno a te berlusconi fa una pippa :D
26 pagine a spaccarci i maroni dicendo ke le SPE sono CPU e alla fine ammetti FINALMENTE ke NON sono CPU, ma ci vieni a dire ke tu non hai mai sostenuto una cosa del genere! :rotfl:
mai pensato di darti al cabaret????
saresti SICURAMENTE piu' bravo in quel campo! :sofico:
e meno male ke in questo forum i MODs non si mettono a cancellare le prove delle cavolate da te sparate ma tutti le possono vedere :D

A te si devono fare i disegnini (cosi' poi li colori con il gatto :) ), non ho mai definito uno SPE CPU per come la intendete voi.
Infatti per come la definisci tu ci rientra anche il Copper. :asd:

Poi quella definizione non ce la siamo inventata, ma è quella che viene usata nella letteratura informatica, e che Yossorian ha certo di ripeterti per ben 4 volte, anche dietro tua richiesta: non è servito a niente. :rotfl:
Se poi in un post (che non nascondo perche' come vedi lo ho riportato anche senza il tuo prezioso aiuto) ho scritto CPU al posto di "processore" ed a qualcuno questo non sta bene.. beh, ciccia!! :)
Infatti: è tutto grasso che cola. :p
Per il resto dei post in tutto(/i) il thread lo chiamo processore. Fermo restando che la differenza e' tanto sottile quanto discutibile (non oltre per me).
Discutibile solo per te, visto che hai dato una definizione tutta tua di CPU. :asd:
Il Cell e' e resta un'architettura multi processore e non un multi-DPS, multi Cooprocessore, multi- Servettotroppostupido o quante altre fantasiose definizioni abbiate trovato nel tempo. :)
Certo: e il Copper è una CPU. :asd:

Sono due cose completamente differenti. Ficchi l'Amiga ovunque!! Gia' mi stava sulle balle al tempo, ma ora me la stai mandando proprio sul.. :D
Certo, sono cose differenti: infatti è ben noto che l'Amiga non aveva i canali DMA, ma le marmotte che al posto di incartare la cioccolata trasportavano i dati verso la memoria. :asd: :rotfl:

Jay Miner si starà ribaltando nella tomba. :D
No, non sono da vedere, sono da leggere.
Se ci fai avere i dati, li leggeremo. ;)
E' quel che scrivo sin dall'inizio, se non sai leggere o eviti di farlo, sono solo problemi tuoi che purtroppo riversi nei forum.
Non ti preoccupare: leggo così bene che mi sto divertendo un mondo con te. :D
Rischiero' di sembrare scortese, ma direi: "E sti cazzi". :) Risparmiati certi commenti idioti, fa' la cortesia.
Toh, ma guarda un po': escono fuori gli insulti. Non l'avrei mai detto, eh!
In merito ho risposto poco sopra.
Anche io, fek e tanti altri.
Per il resto, se non ti vorgogni tu di dare dell'ignorante al mondo intero,
No, io l'ignorante lo do a chi lo è veramente, non al mondo intero, visto che il mondo intero non la pensa come te. ;)
io potrei non vergognarmi nemmeno di andare in giro con un cesso in testa. :)
Le tue squallide battutine a doppio senso falle ai dementi che ti sbavano dietro: con me non attaccano.

D'altra parte, visto che ti sei autosputtanato e l'hanno capito tutti qui, non t'è rimasto altro da fare.

L'importante e' capirla bene la documentazione, questo qualcuno puo' essere lo stesso SPE tramite il proprio DMA incorporato.
L'SPE senza essere a sua volta programmato se ne sta servilmente in attesa: almeno questo l'hai letto nella documentazione (sempre che tu l'abbia fatto: i dubbi sono forti)?
Punti di vista. :)
E risposta alla domanda assente. Come al solito. :mc:

tutto ha un'evoluzione, ma i principi di base restano immutati. Un sottosistema resta tale, indipendentemente dalla sua tipologia. Nel caso del cell, una SPE è un sottosistema a tutti gli effetti e la PPE è la CPU dell'intero "sistema" cell. Alla stregua di un sottosistema, la SPE, per sgravare di lavoro la CPU (PPE), può accedere direttamente alla ram tramite DMA. Il fatto che si tratti di un sistema integrato su un chip non sposta di una virgola il principio di base.

Questo dimostra che la SPE non è stata pensata come CPU e che non può essere assimilata ad una cpu neppure all'interno del "sistema cell", come ho detto qualche post fa (quindi, ribaltando l'assunto, non è il mancato accesso diretto alla ram a non farne una cpu, ma è il fatto che non è una cpu a non permetterle di accedere direttamente alla ram).

In quanto alle definizioni, si può non raggiungere un accordo se non si ha intenzione di farlo; a me sembra che il termine C.P.U. sia fin troppo esplicativo di ciò che una tale unità è deputata a fare.

In quanto ai DSP, mi sembra che la loro importanza sia stata fin troppo sminuita: ce ne sono di ben più complessi di una SPE del cell, in grado di fungere da cpu di un sistema (in questo caso altamente specializzato), a tutti gli effetti.. Questo tanto per sgombrare il campo ad ogni equivoco

Infatti ritengo assurdo sin dall'inizio dire "non sono CPU, ma DSP”. A parer mio, voi state dando un significato troppo ferreo alla parola CPU. Fermo restando che ho sempre definito gli SPE come processori indipendenti, salvo qualche post (se non uno solo) ove li ho definiti CPU.
Tuttavia anche questo e' sindacabile. Mi sembra anche il mio parere sia il piu' diffuso. Non mi stupisce che fek o cdi abbiano un parere tutto loro, perche' e' sempre cosi'. Il tuo e' molto piu' collimante con quanto si senta in giro. se non fosse per il tuo impuntarti sul concetto di CPU (a questo punto direi di poca importanza, visto quanto si e' detto).

Ti riassumo quanto ho riportato da tutte le recensioni che ho trovato.

http://www.pcstats.com/articleview.cfm?articleID=1727
'Synergistic Processing Elements' (SPEs), essentially eight more highly specialized mini-computers on the same die.
It's these SPEs that make the Cell architecture special, as you might guess. IBM describes the product as a 'System on a Chip”

http://www.blachford.info/computer/Cell/Cell1_v2.html
"An SPE is a self contained vector processor which acts as an independent processor"
According to IBM a single SPE(which is just 15 square millimetres and consumes less than 5 Watts at 4GHz) can perform as well as a top end (single core) desktop CPU given the right task”

http://www.realworldtech.com/page.c...RWT021005084318
"Each SPE is in essence a private system-on-chip (SoC)..
The PPE and SPE processing elements access system memory through the MIC..
The SPE is an in-order processor that can issue two instructions per cycle to seven execution units in two different pipelines..

http://www.anandtech.com/cpuchipset...aspx?i=2379&p=3
The Cell architecture debuted in a configuration of 9 independent cores..

Each SPE is a fully functioning independent microprocessor..

Che gli SPE possano lavorare autonomamente c'e' scritto chiaramente anche nella documentazione.

Dunque fek e cdi ridono perche' non riescono a spiegarmi il contrario di quello che sostiene il resto del mondo. :)
Che fosse tutto solo una questione di punti di vista sbagliati (ovviamente loro)?? Io credo di sì.
Alla fine io vi do anche ragione, in fin dei conti a me cosa cambia il come la pensiate voi?? Senza offesa Yoss, ma mi basta aver letto ovunque cio' che sostenevo.

Riguardo al discorso del DMA, non concordo, semplicemente perche' vedendola dall'altro lato.. il motore DMA incluso in ogni processore, rende lo stesso molto simile ad una CPU (fermo restando il fatto che non mi interessa minimamente discutere ulteriormente riguardo cosa possa o non possa essere definita CPU). Quel che sostenevo e sostengo e' che sono processori veri e propri indipendenti (ovviamente nei limiti di logica, visto nessun componente di un sistema informatico e' indipendente, nemmeno piu' gli alimentatori oramai :) ).

Quoto questo perla, perché sul discorso di CPU e GP ti sei ampiamente sputtanato da solo

Parere tuo, non richiesto e molto fastidioso.

(ma aggiungo qualche chicca sotto).
Continui a parlare di cooprocessori: il termine corretto è coprocessore, non cooprocessore. Un espertone di architetture di elaboratori quale pretende di spacciarti dovrebbe conoscere almeno la nomeclatura AMPIAMENTE UTILIZZATA in materia.
Tu, invece, hai scritto sempre cooprocessori: segno che la tua cultura in materia è fatta soltanto di voci riportate chissà dove e da veloci ricerchine.

Dunque siccome io per motivi che non sto qui a spiegarti ho sempre chiamato i coporcessori “cooprocessori”, tutto quello che ho detto ed avvalorato con decine di link (che tu non potrai mai portare, perche' dici minchiate), e' tutto sbagliato?? Ma sì, questi sono argomentoni. :)

Ma non eri tu che parlavi di "parametri convenzionali CPU"?

No, io parlo di quelli che VOI volete stabilire come tali.

Eppure ti sei guardato bene dal fornirlo. Addirittura vai a chiedere lumi a Yossorian, che è costretto, poveretto, a ripetere per ben 4 volte le stesse cose. :asd:

Ho chiesto il suo parere, dunque?? Pensi che il tuo sia cosi' perfetto ed assoluto da escludere automaticamente quello di tutti gli altri?? Patetico. :)

Ed ecco, invece, la tua "incontrovertibile" definizione di CPU:
"Ognuno puo' far girare le proprie applicazioni. Dunque sono delle CPU."
Ci rientra persino il Copper dell'Amiga, come ho detto. :asd:
E il bello è che hai da ridire sulla nostra definizione, che poi è quella usata ovunque nella letteratura informatica. :rotfl:

Sul Copper non girava nulla, non ha nulla che somigli alle capacita' di uno SPE e soprattutto i tempi cambiano, forse e' ora che lasci il posto ai giovani con mente piu' aperta.

Già. Anche perché vedere uno che parla di SPE affermando che rispetto alle PPE difettano di alcune cose (di poco conto, eh?), ma affermando poi che basta aggiungere istruzioni GP per farle diventare GP, è impagabile. :rotfl:

Non mi meraviglia vedere che non hai capito nulla di cio' che ho detto. Non ho mai detto cazzate simili che saltellano come conigli solo nella tua testa.
Ho solo detto che sono processori GP, poi voi volete misurarne le potenzialita', argomento riguardo il quale mi sono espresso chiaramente e con decisione sin dall'inizio, sin dal primo post in merito, sostenendone le scarse capacita'. Concetto che guarda caso ti e' sfuggito ogni volta e scommetto seguiterai a non leggere e parlare di vaccate in merito mai dette.

Ed ecco che la tua vera natura esce fuori: chi non la pensa come te, chi osa tocca il tuo oggetto del desiderio, non può che essere un poco di buono. Ma tu fai di meglio: offendi bellamente, che poi è l'unica cosa che hai dimostrato di saper fare (anche nel thread da cui sei fuggito hai fatto la stessa cosa con me).

Quello e' un elenco di puttanate fatte da qualcuno che avrebbe potuto compilare la lista della spesa.
Mi fa piacere vedere che tu sia d'accordo con quanto detto da quel pazzo. :) Non mi stupisce.

L'unica cosa su cui mi trovo totalmente d'accordo. :p

Forse perche' non hai capito nemmeno questa. :)

L'hai già fatto tu. :asd:
Il tuo punto di vista lascia il tempo che trova, come vedi mi hai detto di aver scritto cose che non ho mai nemmeno pensato, mi riferisco ovviamente alla tua allucinata visione del mio discorso relativo alle istruzioni GP degli SPE.

P.S. Frammenta un'altra volta un mio post in questo modo e risponditi direttamente da solo.

Infatti ritengo assurdo sin dall'inizio dire "non sono CPU, ma DSP”. A parer mio, voi state dando un significato troppo ferreo alla parola CPU. Fermo restando che ho sempre definito gli SPE come processori indipendenti, salvo qualche post (se non uno solo) ove li ho definiti CPU.
Tuttavia anche questo e' sindacabile. Mi sembra anche il mio parere sia il piu' diffuso. Non mi stupisce che fek o cdi abbiano un parere tutto loro, perche' e' sempre cosi'. Il tuo e' molto piu' collimante con quanto si senta in giro. se non fosse per il tuo impuntarti sul concetto di CPU (a questo punto direi di poca importanza, visto quanto si e' detto).
Ma infatti io, fek e Yossiaran abbiamo lo STESSO parere: t'è sfuggito anche questo?
Ti riassumo quanto ho riportato da tutte le recensioni che ho trovato.
Fuffa.
Che gli SPE possano lavorare autonomamente c'e' scritto chiaramente anche nella documentazione.
C'è anche scritto che se non gli viene assegnato un lavoro, non sono in grado di fare niente.
Dunque fek e cdi ridono perche' non riescono a spiegarmi il contrario di quello che sostiene il resto del mondo. :)
Ridiamo perché riesci a smentirti con le tue stesse parole, non perché trovi altri (e non il resto del mondo) che sbagliano come te.
Che fosse tutto solo una questione di punti di vista sbagliati (ovviamente loro)?? Io credo di sì.
Alla fine io vi do anche ragione, in fin dei conti a me cosa cambia il come la pensiate voi?? Senza offesa Yoss, ma mi basta aver letto ovunque cio' che sostenevo.
Tranne nei documenti di IBM: fa niente anche questo, vero?
Riguardo al discorso del DMA, non concordo, semplicemente perche' vedendola dall'altro lato.. il motore DMA incluso in ogni processore, rende lo stesso molto simile ad una CPU (fermo restando il fatto che non mi interessa minimamente discutere ulteriormente riguardo cosa possa o non possa essere definita CPU). Quel che sostenevo e sostengo e' che sono processori veri e propri indipendenti (ovviamente nei limiti di logica, visto nessun componente di un sistema informatico e' indipendente, nemmeno piu' gli alimentatori oramai :) ).
Sono talmente indipendenti che hanno bisogno della PPE per poter lavorare. Invece la PPE ci riesce benissimo (mi sto riferendo al fatto che funziona come CPU, chiaramente).

mi piacerebbe che nao intervenisse di più...in fondo è l' unico che qua adesso ci sta lavorando davvero su sto benedetto CELL...ma credo che comunque tra gli nda e il fatto che stia lavorando a Heavenly Sword gli lascino davvero poco tempo per rispondere... :cry:

Io SONO soffocato dal ridere. :p

Dì la verità: non avresti mai pensato che arrivasse addirittura a sbugiardarsi da solo, vero? In pochi sono in grado di servire la propria testa su un piatto d'argento con tanta disinvoltura... :asd: :asd: :asd:

Le tue capacita di comprensione sono ridotte all'osso, fai uso di droghe?? :)
Io non ho mai affermato cose differenti da quelle precedentemente da me affermate. Se ti appigli al discorso della CPU (definizione utilizzata una o poche volte), dai evidenti segni di non saper piu' che dire. :)

Ovviamente sono passato al termine di "processore", visto che non mi sembrava il caso di districarsi e perdersi nella definizione di CPU, (dato che quella di Processore, ci stava gia' portando via troppo tempo).
In fin dei conti sostenevate (e continuate!!) che non son processori indipendenti, vi ho fatto leggere ovunque che siete gli unici a pensarla cosi'.. che dire oltre?? :yeah: :tapiro: Bravi :D sono quasi onorato di stare qui a parlare con la conoscenza e la verita' assoluta in persona!! :D

Dunque si sbagliano tutti quei tipi incompetenti che hanno fatto recensioni in giro per il mondo?? :) Dunque voi due valete piu' di chiunque altri??

Parere tuo, non richiesto e molto fastidioso.
Il fatto che non ti sia gradito non me può fregar di meno.
Dunque siccome io per motivi che non sto qui a spiegarti ho sempre chiamato i coporcessori “cooprocessori”, tutto quello che ho detto ed avvalorato con decine di link (che tu non potrai mai portare, perche' dici minchiate), e' tutto sbagliato?? Ma sì, questi sono argomentoni. :)
Le minchiate le dici tu, visto che sei l'unico in grado di sostenere una tesi e l'esatto contrario. E i motivi per cui usavi cooprocessori anziché coprocessori è che non ti sei mai studiato nemmeno un testo in materia di architettura degli elaboratori, ma gironzoli per la rete a caccia di informazioni che può aver scritto chiunque.
No, io parlo di quelli che VOI volete stabilire come tali.
Veramente sei TU che parlavi di "parametri convenzionali" per una CPU: quali sarebbero? Diccelo chiaramente e anche il motivo per cui sono definiti "convenzionali".
Ho chiesto il suo parere, dunque?? Pensi che il tuo sia cosi' perfetto ed assoluto da escludere automaticamente quello di tutti gli altri??
No, visto che il mio guarda caso coincide con quello di tutti gli altri (a parte nAo), Yossorian incluso.
Patetico. :)
E' l'unica cosa che sai fare: offendere. Ma ti conosciamo già.
Sul Copper non girava nulla, non ha nulla che somigli alle capacita' di uno SPE e soprattutto i tempi cambiano, forse e' ora che lasci il posto ai giovani con mente piu' aperta.
Ma infatti è sei tu che hai una mente aperta da lasciare una definizione di CPU che alla perfezione con quella del Copper. E il copper fa girare le sue applicazioni, altro che "nulla".

Adesso devi dirmi se per te il Copper è una CPU oppure no: voglio una risposta secca, un sì o un no. Niente giri di parole come quelli che stai cercando di fare, tirando in ballo i tempi che cambiano e le capacità delle SPE: con me non attacca.

Ripeto ancora una volta: un sì o un no. La definizione l'hai data tu: sarai pur in grado di applicarla al Copper e tirare fuori una risposta, no?
Non mi meraviglia vedere che non hai capito nulla di cio' che ho detto. Non ho mai detto cazzate simili che saltellano come conigli solo nella tua testa.
Hai detto delle cazzate e basta infatti. E l'unica cosa che sai fare per difenderti è offendere ancora, visto che non sei in grado di argomentare e sei con le spalle al muro.
Ho solo detto che sono processori GP,
E non lo sono infatti. L'hai detto anche tu: dovresti cercare di tenere almeno un discorso coerente.
poi voi volete misurarne le potenzialita',
Mi sembra più che legittimo, visto che le CPU GP sono in grado di fare certe cose, e le SPE assolutamente no.
argomento riguardo il quale mi sono espresso chiaramente e con decisione sin dall'inizio, sin dal primo post in merito, sostenendone le scarse capacita'. Concetto che guarda caso ti e' sfuggito ogni volta e scommetto seguiterai a non leggere e parlare di vaccate in merito mai dette.
Le uniche vaccate di cui parlo sono quelle che riporti tu: le potenzialità sono scarse proprio perché le SPE NON SONO CPU.
Quello e' un elenco di puttanate fatte da qualcuno che avrebbe potuto compilare la lista della spesa.
Mi fa piacere vedere che tu sia d'accordo con quanto detto da quel pazzo. :) Non mi stupisce.
Mi fai vedere dov'è che l'avrei detto, cortesemente? Non mettermi in bocca parole che non ho mai detto.
Forse perche' non hai capito nemmeno questa. :)
Io riesco a capire benissimo: mi sembra che qui tutti abbiano potuto constatare che quello che non riesce a capire il documento di IBM, che è troppo complicato, e si rivolge invece a gùgul per avere la pappa pronta condita da chissà chi, sei tu.
Il tuo punto di vista lascia il tempo che trova, come vedi mi hai detto di aver scritto cose che non ho mai nemmeno pensato, mi riferisco ovviamente alla tua allucinata visione del mio discorso relativo alle istruzioni GP degli SPE.
Non ho fatto altro che quotare le tue stesse parole: le allucinazioni le avrai avute tu, togliendo cose alle SPE e mettendogliene altre, come fosse un patchwork.
P.S. Frammenta un'altra volta un mio post in questo modo e risponditi direttamente da solo.
E' inutile che lo scrivi: sai benissimo che continuerò a farlo. Potevi smettere di scrivere anche da prima: tanto ormai è evidente che vuoi mezza scusa per scappare via, come al solito, visto che sei stato messo con le spalle al muro e non hai via di scampo.

Torna pure nel forum in cui i tuoi amichetti ti leccano i piedi: qui la figura da cioccolataio l'hai già fatta alla grande, e ci c'hai fatto divertire tutti con le panzane che hai riportato.

Sì, ricordi bene: è proprio quello in cui tu sparlavi me e fek alle spalle (e anche DJLode, se non ricordo male). Ed è il motivo per cui ci siamo iscritti.

Non dire minchiate, io ho detto qualcosa riguardo fek sapendo che crash lo informava tempestivamente (come ha sempre fatto) per di piu' in un thread non certo nascosto che lui aveva gia' frequentato (anche poco tempo prima).
Di te ho solo detto che sei l'unico altro con il quale abbia avuto discussioni ed abbia comuqnue argomentato le mie motivazioni e risposte. Se poi mi hai devastato le palle ed assorbito troppo tempo per continuare ad allungare una discussione che comunque non mi avrebbe mai portato ragione, (visto che tu non sbagli mai, in nessuna discussione da quando ti ocnosco) ho lasciato perdere (per altro nemmeno sapevo che avessi replicato ulteriormente).

Sì, ricordi bene: è proprio quello in cui tu sparlavi me e fek alle spalle (e anche DJLode, se non ricordo male). Ed è il motivo per cui ci siamo iscritti.

Non dire minchiate, io ho detto qualcosa riguardo fek sapendo che crash lo informava tempestivamente (come ha sempre fatto e come infatti ha fatto) per di piu' in un thread non certo nascosto che lui aveva gia' frequentato (anche poco tempo prima).
Di te ho solo detto che sei l'unico altro con il quale abbia avuto discussioni ed abbia comunque argomentato le mie affermazioni (che poi tu non le abbia trovate corrette, poco mi interessa). Se poi mi hai devastato le palle ed assorbito troppo tempo per continuare ad allungare una discussione che comunque non mi avrebbe mai portato ragione, (visto che tu non sbagli mai, in nessuna discussione da quando ti conosco[ovviamente, perché sei un dio]) ho lasciato perdere, (per altro nemmeno sapevo che avessi replicato ulteriormente).

E' diventato così perché gente come te non aveva gli attributi per dire le stesse cose in faccia, riportando anche menzogne (sei stato tu a offendere pesantemente me qui in quel thread nella sezione Processori, e raccontavi l'esatto opposto).

Non ho offeso te piu' di quanto tu non abbia fatto con me. :) Perche' lamentarsi??

La figuraccia l'hai fatta tu perché sei stato letteramente devastato su tutto quello che dicevi, e infatti ti sei anche ben guardato da rispondere a tutti i miei messaggi (come al solito: ma ormai ci sono abituato), visto che non eri in grado di argomentare.

Ho risposto a tutto, tranne l'ultimo messaggio di quel thread, perche' e' stato chiuso. Mi pare di avertelo gia' detto 3 o 4 volte.
In quel tread ad esempio si parlava di R520 che sarebbe dovuto uscire ed io ne sostenevo la somiglianza con l'R500. Quanto sono stato deriso e sputtanato.. ma avevo ragione. :)

Finché non parli alle spalle non hai niente da temere. Infatti mi dicono che te ne stai buono buono, dopo quella batosta: continua così che non mi vedrai mai più là dentro.

Io non parlo alle spalle, infatti chi interessato ha replicato.

Non c'è problema. Tanto siamo stati in tanti a partecipare, sappiamo benissimo com'è andata (io posso ancora recuperare i tuoi messaggi e quelli dei tuoi amichetti), e ci siamo divertiti un mondo a smontarti pezzo per pezzo davanti agli occhi dei tuoi fedelissimi amichetti.

Che infatti mi hanno detto che siete dei poco di buono e dite un mare di minchiate. :) Ma a voi basta compiacervi tra voi. :) Contento tu, contenti tutti. :)

Certo, sono cose differenti: infatti è ben noto che l'Amiga non aveva i canali DMA, ma le marmotte che al posto di incartare la cioccolata trasportavano i dati verso la memoria. :asd: :rotfl:
Jay Miner si starà ribaltando nella tomba. :D
Se ci fai avere i dati, li leggeremo. ;)
Non ti preoccupare: leggo così bene che mi sto divertendo un mondo con te. :D
Toh, ma guarda un po': escono fuori gli insulti. Non l'avrei mai detto, eh!
Anche io, fek e tanti altri.
No, io l'ignorante lo do a chi lo è veramente, non al mondo intero, visto che il mondo intero non la pensa come te. ;)
Le tue squallide battutine a doppio senso falle ai dementi che ti sbavano dietro: con me non attaccano.
D'altra parte, visto che ti sei autosputtanato e l'hanno capito tutti qui, non t'è rimasto altro da fare.

Vedo che continui a parlare di te come se fosi tutti. :) Prova a consultare uno psicologo, puo' aiutarti.

Io ho postato dei link provenienti da tutto il mondo, tu?? :) ah ga'!! tu sei tutti!! :D Mi chiedo solo perche' ti stia ancora dando retta. :)

Le tue capacita di comprensione sono ridotte all'osso, fai uso di droghe?? :)
No, soltanto di endorfine: sono quelle sviluppate dal mio stesso cervello, che è letteralmente deliziato dalle cose che scrivi. :D

Comunque noto che la voglia di offendere non t'è ancora passata: non hai altro a cui appellarti per difendere il tuo io ripetutamente violato?
Io non ho mai affermato cose differenti da quelle precedentemente da me affermate. Se ti appigli al discorso della CPU (definizione utilizzata una o poche volte), dai evidenti segni di non saper piu' che dire. :)
Veramente sono stati in tanti a riportarti le tue stesse parole, dove prima affermi che le SPE sono delle CPU e poi l'esatto contrario. Quello che non sa più cosa dire sei tu.
Ovviamente sono passato al termine di "processore", visto che non mi sembrava il caso di districarsi e perdersi nella definizione di CPU, (dato che quella di Processore, ci stava gia' portando via troppo tempo).
In fin dei conti sostenevate (e continuate!!) che non son processori indipendenti, vi ho fatto leggere ovunque che siete gli unici a pensarla cosi'.. che dire oltre?? :yeah: :tapiro: Bravi :D sono quasi onorato di stare qui a parlare con la conoscenza e la verita' assoluta in persona!! :D
Noi un briciolo di conoscenza ce l'abbiamo: sei tu che ne sei completamente a digiuno. :asd:
Dunque si sbagliano tutti quei tipi incompetenti che hanno fatto recensioni in giro per il mondo?? :) Dunque voi due valete piu' di chiunque altri??
Si sbaglia chi continua a definire CPU le SPE: quindi tutti quelli che hai citato e che l'hanno fatto. E non siamo noi a valere di più di chiunque, ma i documenti di IBM e la definizione di CPU che si sposano perfettamente con quello che abbiamo detto. Checché ne dica tu e gli altri che la pensano come te.

Adesso vado a dormire: continuerò domani, perché tanto so che è più forte di te e, nonostante le tue intenzioni di cui sopra, continuerai a scrivermi, perché pensi di uscirtene fuori in qualche modo.
Non te ne darò la possibilità: è bene che te lo metti in testa una volta per tutte. E poi è un vero spasso: perché mai dovrei perdermelo? :D

mi piacerebbe che nao intervenisse di più...in fondo è l' unico che qua adesso ci sta lavorando davvero su sto benedetto CELL...ma credo che comunque tra gli nda e il fatto che stia lavorando a Heavenly Sword gli lascino davvero poco tempo per rispondere... :cry:
Ma che, leggi i suoi post, secondo loro nemmeno lui non ci capisce nulla.
Ha fatto bene a defilarsi, anzi che restare qui a perdere il proprio tempo con 'sti sapientoni.

No, soltanto di endorfine: sono quelle sviluppate dal mio stesso cervello, che è letteralmente deliziato dalle cose che scrivi. :D

Comunque noto che la voglia di offendere non t'è ancora passata: non hai altro a cui appellarti per difendere il tuo io ripetutamente violato?

Ti offendi facilmente.. io che dovrei dire??
Comunque no, non ho piu' molto da dire, mi basta aver letto come tutto il mondo scriva "fuffa" e tu le assolute verità. :)
Non penso che sprecando mille parole tu ammetterai mai un tuo errore, non credo che la madonnina di Civita Vecchia pianga perché non credo ai miracoli, né ritengo che un sasso possa sanguinare.

Veramente sono stati in tanti a riportarti le tue stesse parole, dove prima affermi che le SPE sono delle CPU e poi l'esatto contrario. Quello che non sa più cosa dire sei tu.

Ho gia' chiarito l'argomento, vedo che eviti di leggere. Pazienza.

Noi un briciolo di conoscenza ce l'abbiamo: sei tu che ne sei completamente a digiuno. :asd:

Tue illazioni senza il minimo basamento. Continua ad offendermi che tutto il mondo iniziera' a scrivere che gli SPE non sono processori e soprattutto non sono indipendenti. :)

Si sbaglia chi continua a definire CPU le SPE: quindi tutti quelli che hai citato e che l'hanno fatto. E non siamo noi a valere di più di chiunque, ma i documenti di IBM e la definizione di CPU che si sposano perfettamente con quello che abbiamo detto. Checché ne dica tu e gli altri che la pensano come te.

I documenti possono essere anche mal interpretati. Io se fossi in te mi butterei sull'oroscopo che "forse" lo capisci meglio. :) (tu hai diritto al tuo parere riguardo me, io ho diritto al mio riguardo te, nulla di piu' lecito).

Adesso vado a dormire: continuerò domani, perché tanto so che è più forte di te e, nonostante le tue intenzioni di cui sopra, continuerai a scrivermi, perché pensi di uscirtene fuori in qualche modo.
Non te ne darò la possibilità: è bene che te lo metti in testa una volta per tutte. E poi è un vero spasso: perché mai dovrei perdermelo? :D
Come gia' detto non penso tu possa capire o scendere dal tuo piedistallo immaginario. I sassi non sanguinano. :) Buonanotte. ;)

"Linux e' gratis per quelli il cui tempo non vale nulla"

Non ho mai letto parole più concilianti il mio pensiero in questi giorni :D

Sto preparando il sistema di test con quattro distribuzioni Linux su un HD e vi assicuro che non è esattamente la stessa cosa che installare quattro Windows XP sullo stesso HD :D

Attento a non confondere la banda del FlexIO con la banda verso la memoria centrale ;)

Però sul sito Rambus parlano fino a 100Gb/s per le Rambus XDR!!
Ora non ho capito se sono esattamente quelle montate sulla PS3, ma insomma in prospettiva dovrebbero andare con il Cell.
Siamo davvero un ordine di grandezza sopra le DDR2, forse anche più!

Veramente sono stati in tanti a riportarti le tue stesse parole, dove prima affermi che le SPE sono delle CPU e poi l'esatto contrario. Quello che non sa più cosa dire sei tu.

Noi un briciolo di conoscenza ce l'abbiamo: sei tu che ne sei completamente a digiuno. :asd:


Un bel corso di "Reti logiche" o almeno di "Calcolatori Elettronici" è quello che servirebbe a chi spara frasi a casaccio prese da google...

Cmq i processori fatti alla coop sono il massimo!!!

:rotfl: :rotfl: :rotfl: :rotfl:


E poi è un vero spasso: perché mai dovrei perdermelo? :D

CVD: quoto!! :rotfl:

Però sul sito Rambus parlano fino a 100Gb/s per le Rambus XDR!!
Ora non ho capito se sono esattamente quelle montate sulla PS3, ma insomma in prospettiva dovrebbero andare con il Cell.
Siamo davvero un ordine di grandezza sopra le DDR2, forse anche più!

appunto.. fino a. Così come il FlexIo consente fino a...
Anche se linko 8 Opteron ho 50 Gb/s di banda passante totale verso le memorie.. ma non è certo economico realizzare una soluzione del genere (e per linkarne di più esistono altri canali di interconnessione ad alta velocità).
Itanium ad esempio utilizza più di 2 canali di memoria DDR per avere una banda passante enorme (mi sembra anche 8-16 canali, se non erro), ma non sono soluzioni alla portata di tutti.
Nella PS3, ovviamente, per motivi di costo, non si avrà certo memoria con banda passante a 80 Gb/s ;)

EDIT: nelle prime presentazioni la banda passante verso la memoria XDR della PS3 veniva data nell'ordine di 25 Gb/s, il che significa una connessione XDR a 8 bit, 3.2 GHz. Nulla ci viene detto poi delle latenze.

Non dire minchiate, io ho detto qualcosa riguardo fek sapendo che crash lo informava tempestivamente (come ha sempre fatto) per di piu' in un thread non certo nascosto che lui aveva gia' frequentato (anche poco tempo prima).
Ricordo perfettamente che tu e luca lo prendevate in giro a presunte affermazioni che aveva fatto su Cell e GPU.
Di te ho solo detto che sei l'unico altro con il quale abbia avuto discussioni ed abbia comuqnue argomentato le mie motivazioni e risposte.
Ricordi male: hai affermato che io t'avrei offeso, quando è vero l'esatto contrario. Basta leggere il thread in questione nella sezione Processori: è tutto nero su bianco.
Se poi mi hai devastato le palle ed assorbito troppo tempo per continuare ad allungare una discussione che comunque non mi avrebbe mai portato ragione,
Per forza: sei l'unico a sostenere delle cose fuori da ogni logica, come la moltiplicazione dei canali PCM senza perdita di qualità e addirittura a costo zero per la CPU. Tanto per fare un esempio, ma di chicche come queste ne hai scritte decine.
(visto che tu non sbagli mai, in nessuna discussione da quando ti ocnosco)
Quando ho commesso degli errori l'ho detto pubblicamente e mi sono scusato; ultimamente l'ho fatto in un thread in cui si parlava dei SP di Windows XP, nella sezione delle news, ad esempio.

Io non ho problemi a riconoscere i miei errori e a chiedere scusa: mi sembra una cosa normale, visto che ho superato da tempo la maggiore età.
ho lasciato perdere (per altro nemmeno sapevo che avessi replicato ulteriormente).
Te l'ho anche scritto, ma continui a ignorare quel thread.
Non dire minchiate, io ho detto qualcosa riguardo fek sapendo che crash lo informava tempestivamente (come ha sempre fatto e come infatti ha fatto) per di piu' in un thread non certo nascosto che lui aveva gia' frequentato (anche poco tempo prima).
Di te ho solo detto che sei l'unico altro con il quale abbia avuto discussioni ed abbia comunque argomentato le mie affermazioni (che poi tu non le abbia trovate corrette, poco mi interessa). Se poi mi hai devastato le palle ed assorbito troppo tempo per continuare ad allungare una discussione che comunque non mi avrebbe mai portato ragione, (visto che tu non sbagli mai, in nessuna discussione da quando ti conosco[ovviamente, perché sei un dio]) ho lasciato perdere, (per altro nemmeno sapevo che avessi replicato ulteriormente).
Guarda che mi basta leggere una sola volta quello che scrivi: non ho ancora bisogno che mi si ripetano le stesse cose n volte.
Non ho offeso te piu' di quanto tu non abbia fatto con me. :) Perche' lamentarsi??
Perché è assolutamente falso quello che dici: infatti non ti ho mai offeso. Vogliamo riprendere quel thread? Così mi fai vedere dov'è che t'avrei offeso. Al contrario, io ho alcuna difficoltà a riportare le offese: l'ho già fatto anche in quel forum.

Ti puoi inventare quello che vuoi, ma se non porti fatti a testimonianza, quello che dici non vale niente.
Ho risposto a tutto, tranne l'ultimo messaggio di quel thread, perche' e' stato chiuso. Mi pare di avertelo gia' detto 3 o 4 volte.
Non cercare di ribaltare la frittata: hai risposto a tutti tranne che a me. Infatti a tutti gli altri rispondevi man mano che scrivevano, mentre hai sistematicamente evitato i miei messaggi.
In quel tread ad esempio si parlava di R520 che sarebbe dovuto uscire ed io ne sostenevo la somiglianza con l'R500. Quanto sono stato deriso e sputtanato.. ma avevo ragione. :)
Infatti è noto che R520 ha schader unificati e memoria embedded. :asd:
Io non parlo alle spalle, infatti chi interessato ha replicato.
L'hai fatto con me e fek invece: prima di sparlare qualcuno dovresti imparare la buona creanza di avvisarlo, per dargli la possibilità di controbattere.

Come ti ho già detto, io invece le cose non te le mando a dire, ma te le dico in faccia.
Che infatti mi hanno detto che siete dei poco di buono e dite un mare di minchiate. :) Ma a voi basta compiacervi tra voi. :) Contento tu, contenti tutti. :)
Del giudizio di quelle menti illuminate che frequenti non me ne può fregar di meno: i simili si riconoscono.

Anzi, come dissi all'epoca: dio li fa e cdimauro li accoppa. :asd:

Vedo che continui a parlare di te come se fosi tutti. :) Prova a consultare uno psicologo, puo' aiutarti.
Lo psicologo servirà a te per farti riprendere dalle botte che stai prendendo da tutte le parti. :asd:
Io ho postato dei link provenienti da tutto il mondo, tu?? :) ah ga'!! tu sei tutti!! :D
Specifica meglio: il TUO mondo.
Mi chiedo solo perche' ti stia ancora dando retta. :)
Secondo me è puro masochismo autolesionista: difficile spiegarlo altrimenti. :D

Ma che, leggi i suoi post, secondo loro nemmeno lui non ci capisce nulla.
Quando mai l'avremmo detto questo? Non mettere in bocca alla gente parole che non hanno mai detto. :rolleyes:
Ha fatto bene a defilarsi, anzi che restare qui a perdere il proprio tempo con 'sti sapientoni.
Ma almeno ti paga per fargli da avvocato pro tempore? :asd:

Lascia che sia lui a scrivere, se ha interesse a farlo: può difendersi da solo, visto che le competenze e le capacità non gli mancano. Con te potrebbe soltanto perderci... :asd:

comunque avrei una domanda da fare....

come mai il cell raggiunge nei test una frequenza di 4.6 Ghz quando avevo sentito che il limite per i processori odierni è di 4 GHz circa? :confused:

Ti offendi facilmente..
Vorrei ben vedere: non fai altro che offendere.
io che dovrei dire??
Semplicemente attenerti sul piano strettamente tecnico, evitando di fare battutine squalide che non fanno ridere nessuno.

Io, come ho già detto centinaia di volte, non ho alcuna difficoltà a mantenere una discussione sul piano puramente tecnico.
Ma di sicuro non sono una pecora disposta a subire supinamente: preferisco la parte del lupo, in questi casi. ;)
Comunque no, non ho piu' molto da dire, mi basta aver letto come tutto il mondo scriva "fuffa" e tu le assolute verità. :)
Sei duro, eh? E' il TUO mondo, e te lo puoi tenere bello stretto: a me basta ciò che scrive IBM e la letteratura informatica in materia.
Non penso che sprecando mille parole tu ammetterai mai un tuo errore, non credo che la madonnina di Civita Vecchia pianga perché non credo ai miracoli, né ritengo che un sasso possa sanguinare.
Infatti, come ho già detto, non ho mai avuto a difficoltà ad ammettere i miei errori pubblicamente e chiedere scusa, quando è capitato. ;)
Ho gia' chiarito l'argomento, vedo che eviti di leggere. Pazienza.
Infatti, è così chiaro che ti ho fatto una domanda in merito e continui a evitare di esprimere una risposta: per te il Copper è una CPU, sì o no? Mi basta una risposta secca. Sono due lettere da mettere in fila: non dirmi che non sei in grado di battere due tasti, dopo tutta la pappardella che hai scritto e continui a scrivere.
Tue illazioni senza il minimo basamento. Continua ad offendermi che tutto il mondo iniziera' a scrivere che gli SPE non sono processori e soprattutto non sono indipendenti. :)
L'offesa la vedi soltanto tu: ho soltanto detto che non hai cognizione in materia, e l'hai dimostrato ampiamente finora.

Hai dato una TUA personalissima definizione di CPU in cui il Copper dell'Amiga ci rientra alla perfezione: qualunque progettista di architetture degli elaboratori farebbe harakiri piuttosto che ammettere un'assurdità come questa.

Dulcis in fundo, punti il dito con la definizione di CPU che ci saremmo inventati, e che guarda caso è quella conclamata nella letteratura informatica e che ti hanno riportato anche gli altri, Yossorian compreso (a cui avevi chiesto lumi).

Cos'altro c'è da dire? Stai facendo ridere tutti coi tuoi spassosi tentativi di uscirtene con la faccia pulita, ma tanto è inutile: dovresti averlo capito da un pezzo che non finirà così.
I documenti possono essere anche mal interpretati.
Già: è quello che hai fatto sistematicamente tu. Infatti IBM ha fatto un elenco preciso di caratteristiche che mancano alle SPE, e che non permettono di classificarla come CPU: fattene una ragione.
Io se fossi in te mi butterei sull'oroscopo che "forse" lo capisci meglio. :)
Infatti non lo capisco affatto. L'oroscopo è appannaggio di gente che s'inventa le cose, quindi è un dominio che lascio tranquillamente a te. :D
(tu hai diritto al tuo parere riguardo me, io ho diritto al mio riguardo te, nulla di piu' lecito).
Indubbiamente: tu hai il diritto dire quello che vuoi, io quello di ribadire che stai dicendo delle eresie che non stanno né in cielo né in terra.
Come gia' detto non penso tu possa capire o scendere dal tuo piedistallo immaginario. I sassi non sanguinano. :) Buonanotte. ;)
Io capisco benissimo, grazie: infatti il documento di IBM mi è chiarissimo, al contrario di te che hai bisogno di cercare la pappetta pronta sul web.

comunque avrei una domanda da fare....

come mai il cell raggiunge nei test una frequenza di 4.6 Ghz quando avevo sentito che il limite per i processori odierni è di 4 GHz circa? :confused:
Quello di 4Ghz non è il limiti di tutti i processori: dipende dall'architettura e dal processo produttivo.

In laboratorio possono testare a frequenze superiori a quelle dei processori in commercio, perché hanno apparecchiature apposite per mantenere la temperatura bassa, ad esempio.

Quello di 4Ghz non è il limiti di tutti i processori: dipende dall'architettura e dal processo produttivo.

In laboratorio possono testare a frequenze superiori a quelle dei processori in commercio, perché hanno apparecchiature apposite per mantenere la temperatura bassa, ad esempio.


quindi praticamente hanno fatto test con cell overclockati??

ma che senso ha? :confused:

Le tue capacita di comprensione sono ridotte all'osso, fai uso di droghe?? :)

Vedo che continui a parlare di te come se fosi tutti. :) Prova a consultare uno psicologo, puo' aiutarti.

Ma sono insulti intollerabili. Ci piace invece ricordarlo cosi:

Gli SPE sono delle CPU con delle limitazioni se paragonate ad altre (e delle agevolazioni se paragonate ad altre ancora, mi riallaccio e prendo per buono l'esempio ci VPU vista come CPU che tu hai riportato), ma sempre CPU rimangono.

Non ho mai sostenuto inoltre che uno SPE sia una CPU, non so se qualcuno qui dentro lo ha mai sostenuto,


Punti di vista. :)

:asd:

in fondo è l' unico che qua adesso ci sta lavorando davvero su sto benedetto CELL...

Ehm... no :p

Ma infatti io, fek e Yossiaran abbiamo lo STESSO parere: t'è sfuggito anche questo?

Si', credo gli sia sfuggito visto che io, te, yoss, leone, cionci, e compagnia cantante (scusate se non vi nomino tutti, siete davvero tantissimi, ma vi amo tutti) diciamo esattamente le stesse cose :)

Lui e DinoXP (tutto il mondo) no. Pero' insiste, e la cosa piu' fastidiosa e' che insulta pure.

Tue illazioni senza il minimo basamento. Continua ad offendermi che tutto il mondo iniziera' a scrivere che gli SPE non sono processori e soprattutto non sono indipendenti. :)

Tutto il mondo e' DinoXP per te (perche' tutto il resto che hai linkato ti da' torto). A me basta che Yoss del quale ho fiducia totale dica che non sono CPU indipendenti e che lo dica IBM e sono felice. Mi accontento di poco.

Ehm... no :p


anche tu ci stai lavorando? per quale studio? :cool:

MadRat owned :D
io direi.. che mo una mail al moderatore per le offese gliela maderei guarda..
quasi quasi :p

anche tu ci stai lavorando? per quale studio? :cool:

Lionhead.

Lionhead.

e che gioco state sviluppando?

e che gioco state sviluppando?

Non posso rispondere, scusami :)

Le tue capacita di comprensione sono ridotte all'osso, fai uso di droghe?? :)
Ti avevo già detto di non cercare la rissa...per questa frase e per quella sui "commenti idioti" sei sospeso 5 gg...

nooooooo....è la morte di questo thread :D

e adesso come farà :muro:
si starà già disperando :p

tranquilli ke appena torna accuserà anke cionci di essere di parte .... :rolleyes:

Gli SPE sono delle CPU con delle limitazioni se paragonate ad altre (e delle agevolazioni se paragonate ad altre ancora, mi riallaccio e prendo per buono l'esempio ci VPU vista come CPU che tu hai riportato), ma sempre CPU rimangono.

Non ho mai sostenuto inoltre che uno SPE sia una CPU, non so se qualcuno qui dentro lo ha mai sostenuto,

:sbonk:

Non ho mai letto parole più concilianti il mio pensiero in questi giorni :D

Sto preparando il sistema di test con quattro distribuzioni Linux su un HD e vi assicuro che non è esattamente la stessa cosa che installare quattro Windows XP sullo stesso HD :D
si vede ke non sei capace (potresti addirittura avere installazioni differenti e condividere le home)! io ci ho messo una vita a installare XP xkè non c'è scritto da nessuna parte ke XP deve essere installato nella prima partizione dell'HD.. ovviamente io lì avevo messo linux! ke kasino! ho dovuto riformattare tutto!
comunque linux è gratis! e su questo non ci piove! infatti puoi scaricare distribuzioni gratuitamente da molti siti! se poi vuoi supporto tecnico e assistenza allora paghi! ma all'utente domestico non credo ke serva tutto ciò!

Raffaele, si vede che non sei capace. Ora diciamo a Paolo che le recensioni di HWUPG ce le fara' lui (magari gli fa scrivere gli articoli con le k :asd: ).

Raffaele, si vede che non sei capace. Ora diciamo a Paolo che le recensioni di HWUPG ce le fara' lui (magari gli fa scrivere gli articoli con le k :asd: ).
uno ke si limita a giudicare le persone dal numero di 'k' ke scrive non merita risposta! comunque se mio fratello usa linux e non ha più bisogno di windows (e di me) vuol dire ke tutti possono farlo (se qualkuno ti spiega come funziona all'inizio)! lui non è un "addetto ai lavori"! non capisco tutti questi problemi ke trovate su linux! sono semplicemente problemi diversi da quelli ke si trovano su windows.. ma non mi pare ke siano di meno o meno gravi di quelli ke trovi su win! sono daccordo comunque ke non sia ankora pronto al 100% x il desktop... ma ci è vicino

edit: ma non mi pare ke siano di più o più gravi di quelli ke trovi su win! si capiva no?

comunque x carità.. non intendevo dire incapace in generale (mi scuso xkè effettivamente non ho specificato)! intendevo con linux

uno ke si limita a giudicare le persone dal numero di 'k' ke scrive non merita risposta!

A quanto pare almeno una risposta l'ho meritata invece.

comunque avrei una domanda da fare....
come mai il cell raggiunge nei test una frequenza di 4.6 Ghz quando avevo sentito che il limite per i processori odierni è di 4 GHz circa? :confused:

Lo sviluppo del Cell è iniziato circa 5 anni fà, quando la corsa alla frequenze più elevate era massima. Quindi è stato pesantemente ottimizzato per scalare in frequenza con varie accortezze architetturali. Accortezze che di solito non si usano nello sviluppo di altri processori perchè richiedono la progettazione manuale di molti circuiti (mentre solitamente si utilizzano tools automatici) che richiedo tempi di sviluppo e risorse molto maggiori.
C'era un articolo di uno dei progettisti del Cell che spiegava in dettaglio la questione...

hey gente! non so se qualkuno ha provato a clikkare sul link di darkquasar... http://www.elivecd.org/gb/Download/0.3/
io ho avuto tempo di provare la live solo poco fa... giuro ke non credevo agli screenshot e invece è proprio vero! ecco un ottimo esempio per dire ke il server X non fa affatto skifo e non è affatto lento!! comunque con xorg ne vedrete delle belle! potete cominciare appunto scaricando questa live! poi kissà kde4, gnome3 oppure gorm (semisconosciuto) ke strada prenderanno! peccato ke non sono riuscito a regolare la risoluzione dello skermo (sarà tipo 800x600 di default e con il 19pollici... mmm)! ma si intravede il futuro di linux in quella live! a dire la verità E16 non è un grankè.. è E17 a essere stupendo anke xkè pur assomigliando molto a MacOS tenta anke qualkosina di originale...

ps. ki ha un briciolo di tempo e voglia è un MUST
pps. x la questione dei giochi meno performanti su linux... io ho giocato a DoomIII e posso dire ke la differenza non è molta, ma sospetto sia solo colpa dei drivers ATI (kissà con nVidia)

hey gente! non so se qualkuno ha provato a clikkare sul link di darkquasar... http://www.elivecd.org/gb/Download/0.3/
pps. x la questione dei giochi meno performanti su linux... io ho giocato a DoomIII e posso dire ke la differenza non è molta, ma sospetto sia solo colpa dei drivers ATI (kissà con nVidia)

Ho fatto partire doom 3 sulla Gentoo prendendo in prestito i file dalla partizione "c:" ;)... ed ho notato che gira meglio! ho la 6600GT cmq...

Addirittura le animazioni iniziali sono in perfetto synch col video, mentre su windows si vedono le ORRENDE "spezzate verticali"...

sarà che la gentoo fa meno testo, visto che è super-ottimizzante (e ci vogliono un paio di giorni per installare una decina di applicazioni "grosse")

Addirittura le animazioni iniziali sono in perfetto synch col video, mentre su windows si vedono le ORRENDE "spezzate verticali"...

Avviene perche' da una parte hai il vsync attivato dall'altra no.

Avviene perche' da una parte hai il vsync attivato dall'altra no.

invece no: è attivo anche su win, ma non sui filmati iniziali evidentemente.

si vede ke non sei capace (potresti addirittura avere installazioni differenti e condividere le home)! io ci ho messo una vita a installare XP xkè non c'è scritto da nessuna parte ke XP deve essere installato nella prima partizione dell'HD.. ovviamente io lì avevo messo linux! ke kasino! ho dovuto riformattare tutto!
comunque linux è gratis! e su questo non ci piove! infatti puoi scaricare distribuzioni gratuitamente da molti siti! se poi vuoi supporto tecnico e assistenza allora paghi! ma all'utente domestico non credo ke serva tutto ciò!

Si vede che la mia battuta è stata presa più seriamente del dovuto. In ogni caso, non sto qui a dire che l'utente che non è in grado di installare Linux, è invece in grado di installare Windows. Probabilmente questo genere di utenza non saprà mai fare questo genere di operazioni. Il discorso è un altro. Io ho installato letteralmente decine e decine di volte Windows XP su tantissimi computer e bene o male la procedura è semplice. Il massimo che l'utente deve conoscere è il concetto di "cartella", per scegliere dove installarlo anche se alla fine tutti lasciano C:\Windows e qualche altra cosa come la scelta della lingua per la tastiera e del GMT per l'ora legale.

Non posso assolutamente dire la stessa cosa di Linux. Ovviamente fare un discorso generico è sbagliato perché ci sono distribuzioni e distribuzioni, ma effettivamente la gamma di problematiche che possono sorgere durante l'installazione di Linux è decisamente più complessa. Qualche esempio:

-con Fedora l'installazione ha sbagliato a generare il fstab e al riavvio successivo all'installazione il sistema non partiva. Ho dovuto avviare il sistema in altro modo, intuire il problema dai messaggi di errore all'avvio e modificare il fstab a mano per risolvere il problema.

-con Arklinux, la peggiore distribuzione mai vista, l'installazione si bloccava all'avvio: dovevo forzarla ad andare a 16 colori per avviarla ed ho provato sia con schede ATi che NVIDIA. Ora non per essere polemici, ma che diavolo di chip grafici testano se nessun chip GeForce o Radeon PCI Express funziona? Solo il Rage XL integrato nei server? Maddai... Poi dopo l'eccezionale installazione grafica a 16 colori (che ogni tanto portava al riavvio improvvisto del sistema), all'avvio il sistema partiva e mandava un bel "kernel panic".

-ogni distribuzione che installavo a seguito dell'installazione delle altre (cioè dalla seconda distro in poi) mi sovrascriveva le impostazioni di grub senza darmi la possibilità di impedirlo e costringendomi a rimodificarlo ogni volta (anche se ne facevano il backup da sole)

-non parliamo poi di distribuzioni come Gentoo che sono letteralmente impossibili da installare senza una connessione a banda larga disponibile e che richiedono l'impostazione manuale di fstab, del make.conf (con i suoi use flags, ecc...), di settarsi il kernel, configurarsi a mano grub e xorg.

Insomma con Windows XP il massimo delle problematiche che si possono avere all'installazione di un sistema pulito quali sono? Che non si hanno i driver SATA? Beh sono sicuro che ci sono molte più persone in grado di premere F8 e inserire il dischetto con i driver SATA che non persone in grado di configurarsi a mano fstab, xorg, il make.conf ecc...

Per cortesia non tentiamo di affermare che l'installazione di Linux è più semplice di quella di Windows. Al più può avere pari difficoltà se si usano determinate distribuzioni, ma mediamente resta più difficile.

Un'ultima cosa: il fatto che Linux sia gratis non lo giustifica ad essere poco user-friendly. Personalmente non ritengo che Linux sia ancora pronto per entrare a far parte di un utilizzo domestico, specie considerando che tale utilizzo va normalmente conciliato con la necessità di fare ampio uso di applicazioni multimediali e, in particolare, di videogames, ma non solo, aspetto in cui Linux è decisamente (per non dire quasi totalmente) carente.

invece no: è attivo anche su win, ma non sui filmati iniziali evidentemente.

Invece si', se vedi il tearing e' perche' il vsync e' disabilitato (forzato da driver o dall'applicazione). Se i video iniziali disabilitano il vsync e i driver di Linux non onorano questa richiesta allora e' un bug dei driver.

Tra l'altro la cosa incredibile è che a un certo punto è arrivato il megamoderatore galattico che, su un nuovo thread che s'era aperto sullo stesso argomento, visto che si continuava sulla stessa scia, aveva scritto un messaggio in cui dichiarava che non dovevano assolutamente essere scritti altri messaggi, pena conseguenze.
--MEGACUT--
Ho tagliato il resto xché non voglio entrare nel merito della questione (cmq sono sostanzialmente d'accordo con quello che scrivi).
Solo mi domando: se un moderatore non vuole più che si scriva in un thread, non può semplicemente chiuderlo, che si fa prima? :D
c'é qualcosa che mi sfugge? Forse vBulletin non permette di chiudere i thread? :mbe:

"Linux e' gratis per quelli il cui tempo non vale nulla"


Effettivamente!!! :rotfl:

Invece si', se vedi il tearing e' perche' il vsync e' disabilitato (forzato da driver o dall'applicazione). Se i video iniziali disabilitano il vsync e i driver di Linux non onorano questa richiesta allora e' un bug dei driver.

Infatti LI' è disabilitato... io che ho detto? :) Io lo tengo abilitato (sul gioco e sui driver) ma il filmato iniziale dice "picche" su windows, mentre su linux no.

Il gioco vero e proprio infatti, non presenta questo problema, né su win né su linux.

bug dell'eseguibile?...

Insomma con Windows XP il massimo delle problematiche che si possono avere all'installazione di un sistema pulito quali sono? Che non si hanno i driver SATA? Beh sono sicuro che ci sono molte più persone in grado di premere F8 e inserire il dischetto con i driver SATA che non persone in grado di configurarsi a mano fstab, xorg, il make.conf ecc...


Quoto... anche se non in toto. :)

Su Linux ci sono problemi simili per driver nuovi o poco usati, mentre invece ormai su hardware più standard Linux si installa quasi come winXP. I problemi vengono dopo... :mc: :mc:

Per installare Linux su RAID0 SATA sono stato costretto a:

- Mettere la vetusta Suse 8.2
- Provare la RH9 che però si inchiodava
- Fare dei magheggi con la Debian inserendo al volo il floppy con dmraid durante l'installazione
- Installare la complicata Gentoo

...l'ultima è l'unica per cui qualcuno si sia degnato di fare un CD con supporto dmraid (utile anche in caso di problemi).

Inutile aggiungere che se non ti leggi la documentazione e non fai diversi "copia" + "incolla", non vai lontano nella fase di installazione... :D :D

La bellezza di Gentoo invece è che, anche in caso di problemi di dipendenze (la cosa peggiore dei pacchetti sparpagliati di linux IMHO), basta riprovare ad installare o seguire le istruzioni e tutto va a posto.

Se nn si installano programmi troppo "beta" questa cosa è cmq estremamente rara. :cool:

Non ho mai letto parole più concilianti il mio pensiero in questi giorni :D

Sto preparando il sistema di test con quattro distribuzioni Linux su un HD e vi assicuro che non è esattamente la stessa cosa che installare quattro Windows XP sullo stesso HD :D
Beh, se sono 4 distribuzioni diverse, lo credo bene che non é come installare 4 volte Windows XP.
Perché se installi 4 volte Wndows XP, installi 4 volte *LO STESSO* sistema operativo.
Se invece instali 4 distribuzioni linux diverse, installi 4 sistemi operativi *DIVERSI*.

Prova a installare 4 volte XP e poi a installare 4 volte Ubuntu sullo stesso PC.
Scommettiamo che ci metti meno con Ubuntu? :D

Beh, se sono 4 distribuzioni diverse, lo credo bene che non é come installare 4 volte Windows XP.
Perché se installi 4 volte Wndows XP, installi 4 volte *LO STESSO* sistema operativo.
Se invece instali 4 distribuzioni linux diverse, installi 4 sistemi operativi *DIVERSI*.

Prova a installare 4 volte XP e poi a installare 4 volte Ubuntu sullo stesso PC.
Scommettiamo che ci metti meno con Ubuntu? :D

Ma guarda, sono sicuro che se installo Windows 98, Windows 2000, Windows XP e Windows 2003 Server comunque l'operazione è più semplice di quattro diverse distribuzioni.

Quoto... anche se non in toto. :)

Su Linux ci sono problemi simili per driver nuovi o poco usati, mentre invece ormai su hardware più standard Linux si installa quasi come winXP. I problemi vengono dopo... :mc: :mc:

Per installare Linux su RAID0 SATA sono stato costretto a:

- Mettere la vetusta Suse 8.2
- Provare la RH9 che però si inchiodava
- Fare dei magheggi con la Debian inserendo al volo il floppy con dmraid durante l'installazione
- Installare la complicata Gentoo

...l'ultima è l'unica per cui qualcuno si sia degnato di fare un CD con supporto dmraid (utile anche in caso di problemi).

Inutile aggiungere che se non ti leggi la documentazione e non fai diversi "copia" + "incolla", non vai lontano nella fase di installazione... :D :D

La bellezza di Gentoo invece è che, anche in caso di problemi di dipendenze (la cosa peggiore dei pacchetti sparpagliati di linux IMHO), basta riprovare ad installare o seguire le istruzioni e tutto va a posto.

Se nn si installano programmi troppo "beta" questa cosa è cmq estremamente rara. :cool:

Attenzione, non sto dicendo che le distribuzioni che ho citato siano sistematicamente affette dai problemi che ho riportato. Gentoo non è la distribuzione più semplice da installare, ma probabilmente è quella che meglio si presta alla ottimizzazione estrema e questo è un pregio, benché non vada d'accordo con la facilità d'uso.

Non quoto tutto il resto perche' sono sostanzialmente d'accordo con quello che scrivi. Per applicazioni CPU-intensive, le prestazioni sono paragonabili fra WinXP ed una qualche distribuzione Linux. Non vedo per quali motivi dovrebbero essere diverse a parita' di hardware.
vero... :D


Su questo invece non sono d'accordo, o, meglio, ti direi... vedremo :)
ok vedremo... però io ho abbastanza fiducia nella mia previsione ;)


Beh, si', e' un dato di fatto, perche' lo e' per qualunque software. Qualunque software e' buggato :)
ok ok é inutile imbarcarsi nel solito flame MS buggosa sì, MS buggosa no... fermiamoci qui... (cmq secondo me i software MS son + buggati della media ;)

Così però stai spostando la discussione verso altri lidi. ;)
vero... però é anche vero che OpenOffice non l'ho introdotto io nella discussione...


Dipende quello che ci fai: Office è uno strumento completo, con un'interfaccia semplice e intuitiva (quando si decideranno a mettere uno strumento di zoom come quello suo in OpenOffice?!?), veloce e pieno zeppo di comode funzionalità. Vale tutti i soldi della sua licenza.
Vale tutti i soldi della sua licenza? Sì forse li vale SE lo sfrutti...
Per l'idea che mi sono fatto io vedendo qua e là come viene usato il computer negli uffici, secondo me + del 90% degli utenti che usano Office al lavoro, sfruttano solo una minima parte delle features... sfruttano features che c'erano già in Office 97 e forse anche prima.. quindi nella stragrande maggioranza dei casi IMHO OpenOffice basta e avanza...


E' chiaro, però, che se devi scrivere qualche letterina con Word o farti qualche banale calcolo, non vale la pena comprarlo. Infatti non a caso si chiama Office, no?
ecco esatto... hai centrato la questione... si chiama "Office", ma nella maggior parte degli uffici tutte quelle features rimangono inutilizzate, lo usano solo "per scrivere qualche letterina con word" come dici tu...


Basta lavorarci, come dicevo: ti sei mai accorto che se salvi un documento, quando finisce puoi vedere uno per uno ridisegnarsi i pulsanti della barra degli strumenti, e per giunta l'operazione viene ripetuta due volte?
O che con Calc se ti sposti a destra col cursore su un foglio che ha un po' di colonne, e poi verso sinistra, a un certo punto assisti a un impietoso scroll di una scattosità a dir poco scandalosa?
Per non parlare della quantità di memoria che occupa e dei tempi di partenza micidiali.
boh... a me quelle situazioni di scattosità non é son mai successe, forse dipende dalla complessità e dalla dimensione dei file salvati...
x quanto riguarda la velocità di avvio: a me non capita assolutamente, ma tu lo usi il QuickStart?


Mi fa venir voglia di tornare a OpenOffice 1.1.3. :(
'sagerato... :D


No, perché questo riguarda soltanto la fase di importazione ed esportazione (operazioni cominque MOLTO lente :(): una volta che hai il documento davanti, lavori con le strutture di OpenOffice (non hai mica n versioni di OpenOffice: una per ogni tipo di file supportato!).
quando dicevo "tipo di file" intendevo dire file complessi con + o - formule e/o di dimensioni + o - grandi eccetera, non mi riferivo al FORMATO in cui il file viene salvato... :D


Io lo uso in ufficio, appunto, e quando devo usarlo mi vengono le lacrime agli occhi. :cry:
beh.. mi spiace... :D


Non è una giustificazione: e la suite di Corel dove la mettiamo?
Ti riferisci a WordPerfect Office? Non mi risulta che sia multipiattaforma.. c'é solo per Windows...


Dai, lasciamo perdere OpenOffice, perché è veramente fatto coi piedi.
ok lasciamolo perdere... de gustibus non disputandum est... però io uso quello perchè una suite office mi serve e non voglio spendere 1 occhio della testa... e cmq secondo me non é poi così male... :D


Questo è frutto delle sue politiche, perché Office è scritto usando un framework comune, e l'unica cosa che cambia è il layer che s'interfaccia col s.o..
ehe... dici poco tu... l'interfaccia col SO... bisogna vedere fino a che strato arriva l'interfaccia col SO e fino a che strato arriva il framework comune...
comunque le release di Office x Win e x Mac sono diverse anche nell'interfaccia utente (quindi anche all'interno di ciò che sta nel framework comune)... uscendo sempre sfasata, la versione Mac ha sempre qualche feature in più della precedente versione Windows e qualcosa in meno della successiva...
Mi sembra qualcosa di molto diverso rispetto ad openoffice, che viene rilasciato contemporaneamente per tutte le piattaforme supportate.. e non supporta solo 2 piattaforme, ma ben 5: Windows, Linux, Mac, FreeBSD e Solaris.
E la versione Mac, la 2.0 gira col supporto X11 del Mac, ma se ti accontenti della release 1, allora c'é NeoOffice (http://neowiki.sixthcrusade.com/index.php/Main_Page), che usa l'interfaccia nativa del Mac e quindi risulta ben integrato. Purtroppo con 'sta versione sono 1 po' indietro, ma fa ben sperare... ;)


Anche la comunità open source può contare su diverse braccia. Non ci si lamenta della lentezza di MS nel correggere e rilasciare patch? Non è soltanto questione di metodologie di sviluppo diverse, ma per lavorare servono uomini che fanno lo sporco lavoro, e per quante risorse abbia, il personale di MS non è certo infinito; tutt'altro.
Si vabeh ma quelli della comunità Open Source per la maggior parte lavorano a gratis e quindi tendenzialmente solo nel tempo libero, e poi i software open source sono liberi e gratuiti, quindi tutto ciò che viene rilasciato va preso per come é: a caval donato non si guarda in bocca.
Invece i software commerciali si pagano profumatamente, quindi é giusto pretendere che facciano il loro dovere, che non abbiano troppi bug, e che se necessitano di patch queste vengano rilasciate in fretta.


Il s.o. può essere leggero quanto vuoi, ma fra server X e desktop come KDE, diventa particolarmente pesante.
mah... io non noto particolare pesantezza... la notavo quando KDE era uscito da poco, era molto meno raffinato e ottimizzato, e l'hardware disponibile all'epoca era molto meno potente... ma adesso direi che nell'uso quotidiano del PC, é bello fluido...


Anche Windows lo è.
XP e Server 2k3 sono sicuramente molto migliori dei predecessori sotto questo aspetto... ma rispetto a linux... comunque anche qui: portare PROVE su questo argomento é impossibile, quindi ognuno provi gli OS che vuole e tragga le sue conclusioni...
Cmq x quanto riguarda la versione per server di Windows, di cui l'ultima versione é Windows Server 2k3, la cosa che non sopporto proprio é l'essere obbligati ad installare un OS con la GUI sempre in esecuzione anche su un server su cui gira un'applicazione critical... se a me 'sta cappero di GUI sul server non mi serve a una cippa, perché mi obbligano ad installarla??? :D


Linux non è gratis: a lavoro abbiamo Red Hat Enterprise, e la nostra azienda ha sganciato fior di milioni (all'epoca).
Dunque: se il server é a scatola chiusa e lo vendono col sistema operativo preinstallato, il SO fa parte del pacchetto complessivo, quindi ha senso guardare solo il prezzo del pacchetto complessivo.
Se il server, al di là della "scatola chiusa" o meno, costa uno sproprosito di soldi, il prezzo pagato per l'OS diventa abbastanza ininfluente.
Ma se il server aveva un prezzo paragonabile a quello di un PC potente o poco più, chi ve l'ha fatto fare di installare Red Hat Enterprise?
Non potevate installare Debian (o un'altra distribuzione completamente free)?
Mancanza di personale preparato? Anche con Windows non se non c'é personale preparato é la stessa cosa...


Infatti: io ci lavoro, e so quello che dico, perché lo provo sulla mia pelle.

Ad esempio, con FC4 aprendo diverse applicazioni grafiche (Evolution, Opera, GaIM, a volte Calc o Write, Kate, 16 shell), il sistema dopo un po' di tempo estremamente pesante perché comincia a swappare come un dannato, e quando Linux swappa... No comment: con la freccetta del mouse puoi solo giocarci, perché finché non ha finito non risponde (al più, se è mosso a compassione, ti permette di minimizzare le finestre, ma se le espandi rimangono vuote).

Secondo me c'è qualche problema di memory leak da qualche parte sul server X, ma vai a capire dove.

Poi, vabbé: FC4 si sta rivelando una peggiore distro che abbia mai provato, ma d'altra parte Kubuntu 5.10 è rimasto sempre fermo alla partenza del server X con la freccetta che si muove e lo schermo pieno di pixel casuali. L'ultima mia speranza è OpenSuse 10: poi basta però, perché c'ho già perso fino troppo tempo. :muro:
'azz ma che computer hai.. ti capita DI TUTTO... :D


Entrambe le cose valgono anche per Windows.
mmmh... però windows ha 1 bel po' di cose che vanno disabilitate perché sembrano messe lì apposta x far casino...
e cmq linux se installi un nuovo pacchetto, a meno che non sia dal pool ufficiale della distro, ci metti pochi secondi, invece windows quando installi 1 roba tante volte é un cinema... più installi roba più il sistema diventa instabile... non hai un controllo su cosa i pacchetti installati facciano all'interno del registro e delle directory di Windows...


Questo non vuol dire niente: i s.o. si provano sul campo, non contemplando le specifiche.
si appunto: il campo mi suggerisce che di solito i sistemi operativi MS per girare bene hanno bisogno di hardware più pompato di quello descritto nei requisiti, quindi se i requisiti dichiarati per Vista sono così alti, figuriamoci quelli REALI... :D
Mi viene in mente la prima volta che installai Windows 95. Girava. Lui però, e basta!!! :D


E' tutto da vedere appunto.
ok, come dicevo a fek, vedremo... cmq io rimango fiducioso di questa "previsione" ;)


Idem come sopra: prima di parlare io aspetterei i fatti. ;)
vaaa bene... (idem come sopra rimango fiducioso ;) )

Se ti riferisci al SP2, non doveva nemmeno uscire secondo i piani di MS.
vuoi dire secondo i piani che avevano prima di pianificarne la sua uscita... :D
comunque non mi riferivo a quello in particolare...
ad ogni modo, i software di MS di solito o escono in ritardo, oppure escono seguendo le scadenze a costo di avere molti problemi irrisolti, com'era successo col lancio di Windows 95, per cui avevano fatto una campagna pubblicitaria sbalorditiva...


Saranno pieni di bug, ma mai quanto gli altro s.o. Unix-like: http://www.hwupgrade.it/news/sicurezza/16090.html

"Sul totale dei bug catalogati, 812 sono relativi all'ambiente Windows e 2328 sono invece relative all'ambiente *NIX (che include sistemi operativi Linux, Unix e Mac OS X)."
appunto...
- i sistemi unix sono PIU' sistemi operativi e si contano anche tutte le distribuzioni
- bisogna vedere i criteri usati perché le distro linux hanno milgiaia di pacchetti inclusi, ma di solito se ne installano una piccolissima parte, quindi se li contano tutti é 1 po' sbilanciata la cosa
- quello che conta é quanto i bug siano GRAVI... se ho un OS con un bug grave enorme è molto peggio che avere 300 bug marginali...
- é facile fare conteggi di bug che risultino favorevoli a 1 o all'altro o interpretarli così "alla carlona", però quello che conta é: quanti bug ci sono nell'installazione standard della release della distro inquestione, CONTANDO le patch già uscite? Perché quello che conta é per quanto tempo i bug che rimangono SCOPERTI E QUINDI SFRUTTABILI... e poi: quanto sono pericolosi i bug SFRUTTABILI?
Facendo un conteggio così come quello in quell'articolo di hwupgrade, IMHO si ha in mano un dato che non vuol dire nulla...


Stai sbagliando: Intel aveva deciso di buttare l'architettura del P3 e passare stabilmente a quella NetBurst del P4. Non era, quindi, un escamotage a breve termine, ma un progetto di lunga durata. Infatti erano previsti altri processori con l'evoluzione dell'architettura NetBurst, che sono stati poi cancellati per le difficoltà incontrate da Intel a tenere a bada i consumi salendo in frequenza e scendendo col processo produttivo.
salire di frequenza utilizzando un'architettura meno evoluta era l'unica carta che potevano giocare, visto che AMD aveva un'architettura migliore della loro, e una nuova architettura non si tira fuori dal cappello in pochi mesi.
Probabilmente avran detto: "facciamo che passiamo a 'sta NetBurst così saliamo coi MHz e la gente compra i P4, poi prevediamo tutto 'sto lungo piano di sviluppo, ma non stiamo lì a vautare bene se sia fattibile o no, tanto 'sta cosa la dobbiamo far partire per forza senò AMD ci affonda."
Il risultato é stato che sono riusciti a vendere i P4 però i piani di sviluppo a lungo termine si sono rivelati errati. Comunque non ci avranno pianto troppo sopra perché in quel momento quella mossa era per loro obbligata.
Prevedere un piano di sviluppo così lungo senza fare delle analisi approfondite per vedere se é tecnicamente fattibile, é un errore.
Ripeto: secondo me la spiegazione é che l'errore l'hanno fatto perché tanto gli conveniva percorrere quella strada comunque... però é un errore (o forse un "falso errore" perché loro sapevano che c'era una certa probabilità di cannare in pieno, ma non gliene fregava poi molto)...


Facile dire "hanno toppato" a funerale già avvenuto: nessuno poteva prevedere una cosa del genere. Hai forse letto dei commenti a proposito 5 anni fa?
i commenti gli esperti del settore mica possono farli sulle notizie rilasciate da Intel alla stampa... solo uno che ci lavora può fare commenti simili.. e magari li avranno fatti all'interno della stessa Intel, anche se noi non ne sappiamo niente...


Visto che le architetture RISC, che avrebbero dovuto dominare il mondo uccidendo i CISC, sono invece per lo più defunte, direi che Intel con le previsioni è in buona compagnia. ;)
ah certo, io non ho mica detto che Intel é il mostro cattivo e/o che sbaglia sempre... ;)


Ti ricordo che anche AMD ha gettato la spugna tempo addietro, abbandonando la sua famiglia RISC 29000.
sissì ripeto: mica dico che Intel é il mostro cattivo...


E' una previsione sbagliata. Punto. C'è poco da dire.
ooohhh! siam d'accordo allora!! :D


Ripeto: rileggi la tua frase e quella mia risposta. Le cose non stanno come pensi: so bene quello che ho detto. ;)
ok vabè... adesso sulle differenze tra Intel e AMD ci stiamo ampiamente discutendo... :D

Sbagli: gli Athlon hanno avuto prestazioni mediamente superiori ai P4 finché questi ultimi non sono arrivati ad avere il bus a 800Mhz e l'HT.

Ci sono un sacco di recensioni e test: anche qui su hwupgrade puoi vedere tu stesso. ;)
beh, quando sono usciti gli Athlon, i P4 non erano ancora sul mercato... c'erano ancora i P3... quindi tu stai dicendo che, nonostante l'uscita dei P4, questi ultimi non son riusciti a raggiungere gli Athlon fin quando non hanno avuto il bus a 800MHz e l'HT. In sostanza mi stai dando ancora più ragione! :D

"Linux e' gratis per quelli il cui tempo non vale nulla"
Condizioni di esistenza:
si assume che "quelli" siano tutta gente skillata su Windows e non skillata su Linux...

Altrimenti é vero il contrario...

:D

peccato ke non sono riuscito a regolare la risoluzione dello skermo (sarà tipo 800x600 di default e con il 19pollici... mmm)!
quando sei su E17, se vai nel menu delle impostazioni, quello che esce se clikki sul desktop col tasto sinistro, puoi attivare vari moduli di E17: non tutti sono attivati di default.
Se attivi il modulo per cambiare la risoluzione del monitor, poi puoi cambiarla al volo.
Se da quello che ho capito hai un monitor flat, di quelli nuovi, probabilmente fa fatica a rilevarne la risoluzione massima...

PS: comunue é vero, é molto bello, ma tu stai parlando come uno che ha visto la madonna!!
:D

Ma guarda, sono sicuro che se installo Windows 98, Windows 2000, Windows XP e Windows 2003 Server comunque l'operazione è più semplice di quattro diverse distribuzioni.
mmmh... sarebbe da provare... secondo me non é così scontato... :D
Cmq dipende anche da quanto conosci Windows e da quanto conosci le 4 distribuzioni...
E cmq fare quello che dici té é come provare a installare RedHat 5, RedHat 7, Fedora e RedHat Enterprise... che sono 4 versioni della stessa distribuzione.... non é proprio come installare 4 diverse distribuzioni...

quindi praticamente hanno fatto test con cell overclockati??

ma che senso ha? :confused:
Uno dei motivi penso che sia quello di testare il prodotto alle frequenze che ci si aspetta di raggiungere quando si utilizzerà un processo produttivo più avanzato.
Di Cell, se non ricordo male, è stato detto che a 65nm dovrebbe girare a 4,6Ghz e arrivare a toccare temperature di 85°C, ma questo nuovo processo produttivo sta arrivando soltanto adesso ad essere impiegato commercialmente.

Il tutto IMHO, chiaramente. ;)

ps. ki ha un briciolo di tempo e voglia è un MUST
No, non ne ho proprio tempo, e ne ho già perso abbastanza, grazie.

Ho tagliato il resto xché non voglio entrare nel merito della questione (cmq sono sostanzialmente d'accordo con quello che scrivi).
Solo mi domando: se un moderatore non vuole più che si scriva in un thread, non può semplicemente chiuderlo, che si fa prima? :D
c'é qualcosa che mi sfugge? Forse vBulletin non permette di chiudere i thread? :mbe:
Sì, infatti il thread in cui MadRat e compagno di merende sparlavano è stato chiuso dopo che è diventato un inferno.

Nel nuovo thread i moderatori (ce n'erano più di uno: poi è intervento anche il grande capo) non volevano che si scatenassero gli stessi flame del precedente, ma che si continuasse col topic. Giustamente, direi io.

Soltanto che il loro comportamento è stato a dir poco squallido: il thread, oltre che chiuso, è stato fatto sparire, inoltre in quello nuovo non è stato preso nessun provvedimento contro quell'utente che era andato nuovamente OT dopo la chiarissima minaccia di sanzioni del moderatore capo nei confronti di chi lo avrebbe fatto, e invece il messaggio in questione è stato fatto sparire.

Non credo che si possa e si debba amministrare così un forum.

ok ok é inutile imbarcarsi nel solito flame MS buggosa sì, MS buggosa no... fermiamoci qui... (cmq secondo me i software MS son + buggati della media ;)
Cosi secondo me non si va molto avanti, però. ;)

vero... però é anche vero che OpenOffice non l'ho introdotto io nella discussione...
Certamente, ma Windows e Office sono le applicazioni di MS più diffuse.
Vale tutti i soldi della sua licenza? Sì forse li vale SE lo sfrutti...
Per l'idea che mi sono fatto io vedendo qua e là come viene usato il computer negli uffici, secondo me + del 90% degli utenti che usano Office al lavoro, sfruttano solo una minima parte delle features... sfruttano features che c'erano già in Office 97 e forse anche prima.. quindi nella stragrande maggioranza dei casi IMHO OpenOffice basta e avanza...

ecco esatto... hai centrato la questione... si chiama "Office", ma nella maggior parte degli uffici tutte quelle features rimangono inutilizzate, lo usano solo "per scrivere qualche letterina con word" come dici tu...
Esattamente. Infatti, visto che Office si paga, comprarlo e usarne a malapena 1/10 delle potenzialità non ha molto senso. Sono cazzi delle aziende se decidono di buttare i loro soldi così.
boh... a me quelle situazioni di scattosità non é son mai successe, forse dipende dalla complessità e dalla dimensione dei file salvati...
x quanto riguarda la velocità di avvio: a me non capita assolutamente, ma tu lo usi il QuickStart?
Certo. Ma tanto è uguale: anche se provi a chiudere Calc o Write, per poi riaprirlo subito dopo, il tempo di caricamento è comunque consistente.
quando dicevo "tipo di file" intendevo dire file complessi con + o - formule e/o di dimensioni + o - grandi eccetera, non mi riferivo al FORMATO in cui il file viene salvato... :D
OK. Ma tanto è uguale: ho dei file di Excel da 600KB, e pur disabilitando anche le macro, i problemi restano. :muro:
Ti riferisci a WordPerfect Office? Non mi risulta che sia multipiattaforma.. c'é solo per Windows...
Hai ragione. Pensavo fosse questo pacchetto, ma ricordavo male. C'era un prodotto abbastanza famoso disponibile per Linux, ma a questo punto è evidente che non ricordo più quale. :(
ehe... dici poco tu... l'interfaccia col SO... bisogna vedere fino a che strato arriva l'interfaccia col SO e fino a che strato arriva il framework comune...
comunque le release di Office x Win e x Mac sono diverse anche nell'interfaccia utente (quindi anche all'interno di ciò che sta nel framework comune)... uscendo sempre sfasata, la versione Mac ha sempre qualche feature in più della precedente versione Windows e qualcosa in meno della successiva...
Guarda che il codice di Office rimane lo stesso: non è che, ad esempio, il find & replace lo riscrivono da capo per ogni piattaforma.

Idem per i prodotti Adobe e Macromedia.
Mi sembra qualcosa di molto diverso rispetto ad openoffice, che viene rilasciato contemporaneamente per tutte le piattaforme supportate.. e non supporta solo 2 piattaforme, ma ben 5: Windows, Linux, Mac, FreeBSD e Solaris.
E la versione Mac, la 2.0 gira col supporto X11 del Mac, ma se ti accontenti della release 1, allora c'é NeoOffice (http://neowiki.sixthcrusade.com/index.php/Main_Page), che usa l'interfaccia nativa del Mac e quindi risulta ben integrato. Purtroppo con 'sta versione sono 1 po' indietro, ma fa ben sperare... ;)
Certo, ma non c'è una versione per Aqua ancora: il porting del framework per Mac manca e usare OpenOffice come applicazione X non è certo la stessa cosa; tutt'altro. ;)
Si vabeh ma quelli della comunità Open Source per la maggior parte lavorano a gratis e quindi tendenzialmente solo nel tempo libero,
Già, ma ne perdono parecchio di tempo, e comunque la comunità è molto numerosa.
e poi i software open source sono liberi e gratuiti, quindi tutto ciò che viene rilasciato va preso per come é: a caval donato non si guarda in bocca.
Io invece lo faccio, perché per me il tempo è una variabile molto importante.
Invece i software commerciali si pagano profumatamente, quindi é giusto pretendere che facciano il loro dovere, che non abbiano troppi bug, e che se necessitano di patch queste vengano rilasciate in fretta.
I bug, ripeto, sono una componente intrinseca del software: non li puoi eliminare! E le patch, ripeto ancora una volta, richiedono tempo al personale, che è LIMITATO.
mah... io non noto particolare pesantezza... la notavo quando KDE era uscito da poco, era molto meno raffinato e ottimizzato, e l'hardware disponibile all'epoca era molto meno potente... ma adesso direi che nell'uso quotidiano del PC, é bello fluido...
Abbiamo impressioni diverse. Sarà che m'è rimasto "l'occhio clinico" del programmatore di videogiochi, e certe cose le colgo anche senza volerlo. :p
Cmq x quanto riguarda la versione per server di Windows, di cui l'ultima versione é Windows Server 2k3, la cosa che non sopporto proprio é l'essere obbligati ad installare un OS con la GUI sempre in esecuzione anche su un server su cui gira un'applicazione critical... se a me 'sta cappero di GUI sul server non mi serve a una cippa, perché mi obbligano ad installarla??? :D
Puoi sempre prendere il CD e fartene una versione custom con NLite, magari rimpiazzando l'eseguibile della shell di sistema con una che non fa niente (esistono già dei replacement, anche open source: basta realizzarne uno ad hoc). :D
Dunque: se il server é a scatola chiusa e lo vendono col sistema operativo preinstallato, il SO fa parte del pacchetto complessivo, quindi ha senso guardare solo il prezzo del pacchetto complessivo.
Se il server, al di là della "scatola chiusa" o meno, costa uno sproprosito di soldi, il prezzo pagato per l'OS diventa abbastanza ininfluente.
Ma se il server aveva un prezzo paragonabile a quello di un PC potente o poco più, chi ve l'ha fatto fare di installare Red Hat Enterprise?
Non potevate installare Debian (o un'altra distribuzione completamente free)?
Mancanza di personale preparato? Anche con Windows non se non c'é personale preparato é la stessa cosa...
No, abbiamo un amministratore di sistema che sa il fatto suo, ma un'azienda seria non può mettersi dietro a una distribuzione qualunque che non offre alcun supporto: se c'è un problema che dipende da Red Hat, noi alziamo la cornetta e chiamiamo, perché abbiamo pagato per questo.

Allo stesso modo, i server li compriamo da Dell perché se c'è un problema alziamo la cornetta e entro 4 ore abbiamo il tecnico alla server farm.

Il mondo del lavoro è qualcosa di MOLTO diverso da quello hobbystico. ;)
'azz ma che computer hai.. ti capita DI TUTTO... :D
Già. Non hai idea delle cose che mi sono capitate: perfino con le distro live non ho avuto fortuna (ilsensine si starà rotolando dalle risate :asd: ).
mmmh... però windows ha 1 bel po' di cose che vanno disabilitate perché sembrano messe lì apposta x far casino...
Sono dei servizi, non delle cose inutili: che poi troppi servizi sono attivi di default è vero. Infatti 2003 Server è un'altra cosa: parte con un sacco di servizi disabilitati, e gli altri li devi attivare tu (Linux-like).
e cmq linux se installi un nuovo pacchetto, a meno che non sia dal pool ufficiale della distro, ci metti pochi secondi, invece windows quando installi 1 roba tante volte é un cinema...
Veramente sono anni che faccio Setup, Avanti, Avanti, Fine e in poco tempo ho tutto funzionante, senza l'incubo delle dipendenze di pacchetti.
più installi roba più il sistema diventa instabile...
Esattamente come Linux: più servizi attivi, più il tempo di caricamento aumenta. Mi sembra anche logico.
non hai un controllo su cosa i pacchetti installati facciano all'interno del registro e delle directory di Windows...
Se usano installer che seguono le direttive standard di MS, sai perfettamente cosa fanno.

Comunque questo è un non-problema: anche su Linux se realizzo un installer mio, posso fargli infilare i file dove voglio, e cambiare i file di configurazione come mi pare e piace.
si appunto: il campo mi suggerisce che di solito i sistemi operativi MS per girare bene hanno bisogno di hardware più pompato di quello descritto nei requisiti, quindi se i requisiti dichiarati per Vista sono così alti, figuriamoci quelli REALI... :D
Non è solamente un problema di MS: il PC che ho a lavoro è più potente del muletto che ho a casa, ma a livello desktop è più pesante.
Mi viene in mente la prima volta che installai Windows 95. Girava. Lui però, e basta!!! :D
Ma che macchina avevi? Un 386 a 16Mhz? ;) Io ricordo che sulla stessa macchina su cui prima avevo il DOS, girava molto bene.

Cerchiamo di rimanere in topic :)

vuoi dire secondo i piani che avevano prima di pianificarne la sua uscita... :D
GRRR :)
comunque non mi riferivo a quello in particolare...
ad ogni modo, i software di MS di solito o escono in ritardo, oppure escono seguendo le scadenze a costo di avere molti problemi irrisolti, com'era successo col lancio di Windows 95, per cui avevano fatto una campagna pubblicitaria sbalorditiva...
Dei ritardi ne abbiamo già parlato: a parte Vista non mi sembra ce ne siano altri.

Sul fatto che escano con problemi irrisolti, mi sembra normale: i bug sono sempre dietro l'angolo.

Esempio. Per quanto mi riguarda, FC4 come distribuzione è ben peggio della 2: non doveva nemmeno uscire (ho ancora CUPS che non mi funziona, dopo 2,5GB di pacchetti scaricati).

E che dire di OS X Tiger, che è arrivato a ben 4 "SP" nel giro di 6 mesi?

Come vedi sono problemi comuni, quando si ha a che fare con software di questa portata, fatti da decine di milioni di righe di codice.
appunto...
- i sistemi unix sono PIU' sistemi operativi e si contano anche tutte le distribuzioni
- bisogna vedere i criteri usati perché le distro linux hanno milgiaia di pacchetti inclusi, ma di solito se ne installano una piccolissima parte, quindi se li contano tutti é 1 po' sbilanciata la cosa
- quello che conta é quanto i bug siano GRAVI... se ho un OS con un bug grave enorme è molto peggio che avere 300 bug marginali...
- é facile fare conteggi di bug che risultino favorevoli a 1 o all'altro o interpretarli così "alla carlona", però quello che conta é: quanti bug ci sono nell'installazione standard della release della distro inquestione, CONTANDO le patch già uscite? Perché quello che conta é per quanto tempo i bug che rimangono SCOPERTI E QUINDI SFRUTTABILI... e poi: quanto sono pericolosi i bug SFRUTTABILI?
Facendo un conteggio così come quello in quell'articolo di hwupgrade, IMHO si ha in mano un dato che non vuol dire nulla...
So benissimo che quelli sono dati da prendere con le pinze, ma anche riducendo di un ordine di grandezza il dato dei sistemi Unix-like per questo motivo, non è che ne esca fuori un quadro entusiasmante.

Voglio dire: se prendi i changelog relativi a una singola distribuzione, e ti metti a contare il numero di bug fix, le cifre ci sono e sono consistenti.

Questo perché, e lo ripeto ancora una volta, i bug sono una componente intrinseca del software, sia esso targato MS, Apple, Sun, IBM, FSF, o altro.
salire di frequenza utilizzando un'architettura meno evoluta era l'unica carta che potevano giocare, visto che AMD aveva un'architettura migliore della loro, e una nuova architettura non si tira fuori dal cappello in pochi mesi.
Ma infatti è proprio per questo che ti dico che NetBurst era la nuova architettura di Intel: non è che l'abbia tirata fuori subito dopo la presentazione di Athlon da parte di AMD.

Il P3 era già destinato a morire per Intel.
Probabilmente avran detto: "facciamo che passiamo a 'sta NetBurst così saliamo coi MHz e la gente compra i P4, poi prevediamo tutto 'sto lungo piano di sviluppo, ma non stiamo lì a vautare bene se sia fattibile o no, tanto 'sta cosa la dobbiamo far partire per forza senò AMD ci affonda."
Vedi sopra. E poi non si programmano piani DECENNALI per poi buttarli via a metà strada, se non ci sono delle gravi motivazioni alla base.
Il risultato é stato che sono riusciti a vendere i P4 però i piani di sviluppo a lungo termine si sono rivelati errati. Comunque non ci avranno pianto troppo sopra perché in quel momento quella mossa era per loro obbligata.
Ma infatti stanno piangendo un po' tutti: se ci fai caso la folle corsa ai Mhz s'è fermata. Intel col P4 (e IBM col G5) ne ha risentito di più, perché la sua era un'architettura pensata appositamente per scalare in frequenza.
Prevedere un piano di sviluppo così lungo senza fare delle analisi approfondite per vedere se é tecnicamente fattibile, é un errore.
Non è un errore: prevedere che la riduzione dei transistor a 90nm possa provocare problemi così grossi, quando si sta ancora usando il processo a 0.18u (o peggio a 0.25u), non è cosa facile per nessuno.

Il modello semplificato del funzionamento di un transistor è già abbastanza pesante: simulare il funzionamento in maniera più precisa, e per giunta non di uno ma di 50 milioni di transistor, è pura follia.

E' che ci si affida a delle stime, come è stato fatto.
Ripeto: secondo me la spiegazione é che l'errore l'hanno fatto perché tanto gli conveniva percorrere quella strada comunque... però é un errore (o forse un "falso errore" perché loro sapevano che c'era una certa probabilità di cannare in pieno, ma non gliene fregava poi molto)...
Vedi sopra: non credo proprio che fosse un errore. Era quella la strada che aveva pensato, e a cui si era affidata.
i commenti gli esperti del settore mica possono farli sulle notizie rilasciate da Intel alla stampa... solo uno che ci lavora può fare commenti simili.. e magari li avranno fatti all'interno della stessa Intel, anche se noi non ne sappiamo niente...
Vedi sopra: la situazione è la stessa per tutti i tecnici, c'è poco da fare. La sfera di cristallo non ce l'ha nessuno.
ooohhh! siam d'accordo allora!! :D
Ci mancherebbe, ma vedi sopra: non è che si può dire che Intel abbia fatto una cazzata colossale a cuor leggero. Le stime errate sono un problema comune a tutti.
ok vabè... adesso sulle differenze tra Intel e AMD ci stiamo ampiamente discutendo... :D
Sì, ma sono di tutt'altra natura, e nonostante tutto la situazione non è molto diversa. :p

Cerchiamo di rimanere in topic :)
L'ho letto soltanto ora. OK, allora non rispondo agli altri messaggi. :stordita:

Infatti LI' è disabilitato... io che ho detto? :) Io lo tengo abilitato (sul gioco e sui driver) ma il filmato iniziale dice "picche" su windows, mentre su linux no.

Il gioco vero e proprio infatti, non presenta questo problema, né su win né su linux.

bug dell'eseguibile?...

E' possibile. Dovrei sapere se il play del video si appoggia ad una libreria oppure no. Nel primo caso, e' possibile che su Linux la libreria attivi il vsync, su Windows non lo faccia, oppure si affidi alle impostazioni standard. E' un problema a livello di applicazione. Infatti se forzi manualmente il vsync off su Linux e on su Windows da driver, il tearing si scambiera'.

ok ok é inutile imbarcarsi nel solito flame MS buggosa sì, MS buggosa no... fermiamoci qui... (cmq secondo me i software MS son + buggati della media ;)

Portami delle statistiche :)

Secondo me no, conoscendo i loro processi di produzione e le politiche di testing. Ma non ho statistiche da portare perche' non esistono.

ok siamo OT ci dobbiam fermare, ma ci tengo a rispondere a questa cosa:
Ma che macchina avevi? Un 386 a 16Mhz? ;) Io ricordo che sulla stessa macchina su cui prima avevo il DOS, girava molto bene.
io facevo girare Windows 95 su un 486 DX2 a 66MHz con 32MB di ram (o 16 non ricordo, ma non cambia molto il succo della questione), e con scheda video SVGA.
i requisiti ufficiali erano:
- CPU: 386 DX a 20MHz
- RAM: 4MB minimo, 8MB consigliati
- scheda video: VGA minimo, SVGA consigliata

Quindi sul mio PC, non mi aspettavo che fosse un fulmine, ma almeno che andasse in maniera decente.
Invece ci metteva qualche minuto a bootare, e poi quando andava era talmente pesante, e l'accesso al disco era talmente elevato, che far partire qualsiasi applicazione era un calvario.
Dopo un po' mi son rotto le scatole e ho rimesso DOS+Win 3.11.
Se questo non é un esempio di requisiti hardware "ingannevoli", allora io sono il re d'inghilterra...

ps. ki ha un briciolo di tempo e voglia è un MUSTNo, non ne ho proprio tempo, e ne ho già perso abbastanza, grazie.
Ma lol... qui si sta parlando di un liveCD... non c'é niente da installare, va subito... se non ti va nemmeno quello, o il tuo computer é stregato, o é posseduto...
:rotfl:



@cionci: capisco siamo andati OT però é 1 peccato... dopo tutte quelle pagine di flame su una questione inutile, anche se era in-topic (cosa molto opinabile visto la genericità dell'articolo di hwupgrade in questione), adesso che si stava facendo una discussione tranquilla e piacevole viene stroncata così...
:cry:

"Se arbitro fischia, è rigore" - Boskov. :p

"Se arbitro fischia, è rigore" - Boskov. :p


era "rigore è quando arbitro fischia"

:D

Voglio la memoria con l'ECC! :p

Per iniziare vale la pena fare una nota molto sfiziosa e divertente.
Quotiamo colui che capisce tutti i significati anche nelle sfumature, ovviamente sto parlando di cdimauro che con gran superbia e maestria ci ha fatto notare che la P di SPE, giustamente stia ad indicare la parola PROCESSING e non PROCESSOR!! perché non tutti lo capiscono ma sono due cose ben differenti e dunque..

Infatti dimentichi che nella letteratura informatica i termini "CPU" e "Processore" sono usati indifferentemente per indicare la stessa cosa.
Questo non vuol dire che se la P di SPE sta per Processing, automaticamente diventa una CPU; anche e soprattutto perché fra Processor e Processing c'è una bella differenza.
Un conto sono le definizioni (come CPU <-> Processore), e tutt'altra cosa sono le parole usate nella lingua comune (come la P di SPE, che comunque sta per Processing e non per Processor).

Qui si nota come con la sua impeccabile cultura informatica ha spiegato a tutti come tra Processing e Processor ci sia una bella differenza!! Ed infatti poi continua giustamente a rimarcare il concetto facendo notare che la P di SPE sta per Processing, non processor!! (capito?? IMPARATE PLEBEI!!).

Come e' giusto che accada quando un maestro insegna qualcosa, ecco che arriva l'allievo (il più sveglio di tutti) che gli fa coro e ripete la lezione!!

per questo una SPU è un "Processor" nel senso di "Processing Unit" ovvero unità atta ad eseguire calcoli, unità di processamento, ma non nel senso comunemente usato in italiano di "[/]Processore[/b]", ovvero "Central Processing Unit" o "General Purpose Processor"

Dunque anche lui mi viene a spiegare cosa sia un processore. :) (menomale, avrei rischiato di rimanere ignorante..)

Se IBM continua a parlare di processing element per la SPE e non di processore, avrà pure i suoi buoni motivi.
Qui il dottore ci spiega ulteriormente come sia ovvio che se IBM in persona (mica cazzi) scelga il termine PROCESSING e non PROCESSOR, ci sarà un motivo!! (che prima o poi capirò anche io, almeno spero).

La sola presenza di "istruzioni GP" non fa di un Processing Element una CPU.

e qui con grande serietà specifica chiaramente ed ulteriormente il come si stia parlando di PROCESSING element. (eh beh.. giusto no?? quello sono :) ).
Andiamo ancora avanti e vediamo chi altri ha imparato dal grande capo. :)
Thread nuovo, adepti nuovi..

No, sta per "processing

Ecco il primo, anche se, a dire il vero, ha seguito abbondantemente questo concetto anche nell'altro thread.

Sta per Processing :)
GPU, Graphics Processing Unit, e' una CPU anche questa? Ci faccio girare un task scheduler sull'R500 e ci posso fare ricerche sui database e ci piloto altre periferiche. Se per te l'SPE e' una CPU, devi concludere che anche l'R500 e' una CPU, un'evidente contraddizione in termini.

Ed ecco il secondo!! Chiariamo bene, mi raccomando!! Criceto ascolta fek perché ora ti spiega la differenza tra Processor e Processing!! Va be' non hai detto CPU, hai detto Processor e lui ti contesta CPU, ma non importa, tu bada alla chiara differenza tra Processing e Processor, perché loro hanno capito tutto e possono illuminare il nostro buio cammino.
L'importante e' che sia oramai ben chiaro il concetto di Processore e di Processing. Il mio errore fino ad ora era solo dovuto al fatto che “stupidamente” ho sempre considerato Processore una Processing unit!! E' ovvio che che la mia ignoranza non mi consentiva di capire questo!! Dunque è 'sì ovvio come gli SPE non sono processori, ma unità di di elaborazione (processing) come all'inizio ci ha fatto notare il ferratissimo fek!! Tutto questo ci fa capire chiaramente che se gli SPE fossero chiamati Processor e non “Processing Element”, sarebbero come la PPE (che infatti, come ci fanno notare, possiede la “P” di “Processor”).
Chiedo venia a tutti, scusate veramente di cuore!! Anzi sai che faccio?? me ne vado al sito della IBM e reinizio a studiare daccapo!!

Dunque: Mumble mumble..

Documento di introduzione al MultiProcessore Cell (Introduction to the Cell multiprocessor)

Cavolo, però qui già c'è qualcosa di strano, se gli SPE non sono Processori, bensì Processing Unit (perché ci hanno abbondantemente spiegato come le due cose siano BEN DIFFERENTI, tanto da incentrarci tutto il tema) e solo la PPE è un Processore (o addirittura CPU se preferite), come fa ad essere un multiprocessore?? Eh già, come fa?? Seguito a leggere, lo capirò di certo perché loro hanno ragione!! :)

Ora facciamo un bel giochino, aprite questo documento:

http://researchweb.watson.ibm.com/journal/rd/494/kahle.html

Cercate nella pagina la parola “spes” e guardate stupefatti al primo risultato!!

The first-generation Cell processor combines a dual-threaded, dual-issue, 64-bit Power-Architecture-compliant Power processor element (PPE) with eight newly architected synergistic processor elements (SPEs)

:) Per TUTTO il documento (e la documentazione) vengono chiamati Synergistic processor elements!!

E tutte le lezioni?? tutto quel salire in cattedra?? Ora diranno che si tratta chiaramente di un errore!! (diffuso per tutta IBM, 'sti caproni!!) o chissà su quale specchio si arrampicheranno. Certo e' che la loro bellissima e meritata figura l'hanno fatta (come accade SEMPRE quando si parla senza cognizione di causa).
Ovviamente qualcuno si arrampicherà sullo specchio della differenza tra CPU e Processore, ma più avanti analizzeremo anche questo aspetto, sempre leggendo ciò che IBM dice.
Ferma e perentoria rimane comunque la serie ci cazzate dette a sproposito riguardo Processing/Processor.

------------------------------------------------------------------------

Leggendo qua e là (ma proprio a caso) ho trovato pareri altisonanti di fek riguardo la teorica comune decisione che il Cell non sia un multi-processore (come definito da IBM), ma semplicemente una PPE-CPU (come non definita da IBM) con .. aspetta com'è che le ha chiamate?? Ah sì!! "un certo numero di unita' vettoriali molto evolute” :) (molto evolute?? ma che cavolo significa?? bah, va be', andiamo avanti).

La fantasia non manca, non c'è che dire. Senza scendere nel dettaglio del fatto che un'unità vettoriale molto evoluta può tranquillamente essere un processore a tutti gli effetti ed anche una CPU, ma il nocciolo della questione (per ora) è un altro. Questa definizione fantasiosa non figura tra quelle scelte da IBM, né somiglia ad alcuna di quelle utilizzate.

Inizialmente dissi che gli 8 processori del Cell (perché il Cell E' UN MULTIPROCESSORE sin dal titolo) fossero CPU (una o poche volte, ma sono bastate a qualcuno privo di argomenti per incentrarci le proprie strambe ragioni), poi passai al termine sicuramente più consono di “Processori” per tre motivi:

Il primo è che la definizione di CPU mal si adatta ad un processore come il Cell, basato proprio sulla distribuzione dei compiti di lavoro (in un certo senso, non esiste un processore centrale in un sistema con più processori [centrali]).

Il secondo è, che risulta difficile indicare un significato esatto e “standard” per la parola CPU come già ampiamente (ed abbastanza) discusso. (tanto che non lo vedremo MAI nell'articolo citato).

Il terzo motivo vede in esame l'affermazione dell'IBM che definisce gli SPE come una via di mezzo tra Processori e DSP. Ponendo la definizione di Processore per ciascun unità del Cell(in base alla definizione di multiprocessor e le varie citazioni come “Processor Element”), IBM indica CHIARAMENTE l'identità e la natura degli SPE, dunque la similitudine con un DSP che viene indicata, si riferisce ovviamente solo ed esclusivamente al genere di calcoli che può compiere, vistane anche l'architettura molto vettoriale. Ferma restando la varietà di DSP esistenti, dunque tale affermazione, non può esser presa in altro modo che come un indicazione sommaria ed introduttiva.

Si deve notare come per tutti i documenti che ho portato e porterò in questo post, IBM (e non cdimauro o fek) non chiamerà MAI CPU né la PPE né gli SPE, saranno chiamati tutti sempre e solo “PROCESSOR ELEMENT” (con architetture differenti), né gli SPE verranno mai chiamati “unità vettoriali”, come invece fa più volte con (appunto) l'unita' vettoriale presente nella PPE. (inizierei già a chiedermi il perché).

A questo punto io proseguirei con l'articolo d'introduzione. Mi sembra un ottimo modo per comprendere come funzioni e per cosa sia stato pensato il Cell.

Design concept and architecture:

The Broadband Processor Architecture extends the 64-bit PowerArchitecture with cooperative offload processors (“synergistic processors”), with the direct memory access (DMA) and synchronization mechanisms to communicate with them (“memory flow control”), and with enhancements for real-time management.

Qui si nota chiaramente come il DMA non sia un ripiego, ma una precisa scelta. L'unico vero modo per rendere il Cell ciò che è, con le relative capacità e la propria ed unica flessibilità.

The first-generation Cell processor (Figure 1) combines a dual-threaded, dual-issue, 64-bit Power-Architecture-compliant Power processor element (PPE) with eight newly architected synergistic processor elements (SPEs) [11], an on-chip memory controller, and a controller for a configurable I/O interface. These units are interconnected with a coherent on-chip element interconnect bus (EIB). Extensive support for pervasive functions such as power-on, test, on-chip hardware debug, and performance-monitoring functions is also included.

--------------------

-Single-instruction, multiple-data (SIMD) architecture, supported by both the vector media extensions on the PPE and the instruction set of the SPEs, as one of the means to improve game/media and scientific performance at improved power efficiency.

Come detto poco fa e come si può leggere chiaramente qui sopra, l'unita' vettoriale interna alla PPE, e' chiamata vector media extension, fatto che non accade mai con gli SPE (dato che sono molto di più di questo).

Leggete con attenzione i seguenti passaggi.

-SPEs for coherent offload. SPEs have local memory, asynchronous coherent DMA, and a large unified register file to improve memory bandwidth and to provide a new level of combined power efficiency and performance. The SPEs are dynamically configurable to provide support for content protection and privacy.

The SPE implements a new instruction-set architecture optimized for power and performance on computing-intensive and media applications. The SPE operates on a local store memory (256 KB) that stores instructions and data. Data and instructions are transferred between this local memory and system memory by asynchronous coherent DMA commands, executed by the memory flow control unit included in each SPE. Each SPE supports up to 16 outstanding DMA commands. Because these coherent DMA commands use the same translation and protection governed by the page and segment tables of the Power Architecture as the PPE, addresses can be passed between the PPE and SPEs, and the operating system can share memory and manage all of the processing resources in the system in a consistent manner.

Alla faccia delle limitazioni. :)

The DMA unit can be programmed in one of three ways: 1) with instructions on the SPE that insert DMA commands in the queues; 2) by preparing (scatter-gather) lists of commands in the local store and issuing a single “DMA list” of commands; or 3) by inserting commands in the DMA queue from another processor in the system (with the appropriate privilege) by using store or DMA-write commands. For programming convenience, and to allow local-store-to-local-store DMA transactions, the local store is mapped into the memory map of the processor, but this memory (if cached) is not coherent in the system.
The local store organization introduces another level of memory hierarchy beyond the registers that provide local storage of data in most processor architectures. This is to provide a mechanism to combat the “memory wall,” since it allows for a large number of memory transactions to be in flight simultaneously without requiring the deep speculation that drives high degrees of inefficiency on other processors. With main memory latency approaching a thousand cycles, the few cycles it takes to set up a DMA command becomes acceptable overhead to access main memory. Obviously, this organization of the processor can provide good support for streaming, but because the local store is large enough to store more than a simple streaming kernel, a wide variety of programming models can be supported, as discussed later.


Credo ci sia poco da commentare. Per il resto riguardo l'argomento, vi rimando all'articolo.

--------------

The first-generation Cell processor is a highly optimized full-custom high-frequency, low-power implementation of the architecture. Cell is a system on a chip; however, unlike most SoCs, Cell has been designed with a full-custom design methodology. Some aspects of the physical design stand out in comparison with previous full-custom efforts:

---------

Il passaggio che segue ci spiega chiaramente quali siano i fattori che più differenziano uno SPE da un “microporcessore convenzionale”. A questo punto già si può dedurre un qualcosa di moto molto semplice ed importante.
Siccome processore e' un termine molto generico ed indica una vastità di prodotti in silicio e metallo seconda forse solo al catalogo dell'Ikea, risulta ovvio che come con “microprocessore” IBM intenda CPU o comunque un processore come la PPE o un X86. Altrimenti quale e' il microprocessore (che nel secondo “motivo” chiameranno processore, come potete facilmente leggere qui sotto) convenzionale di paragone?? Dunque e' un microprocessore anch'esso che si differenzia per i seguenti motivi.

The second aspect of the design that affects the programming model is the SIMD nature of the dataflows. Programmers can ignore this aspect of the design, but in doing so they may often leave a significant amount of performance on the table. Still, it is important to note that as with PC processors that implement SIMD units and do not always use them, an SPE can be programmed as a conventional scalar processor for applications that are not easily SIMD-vectorized. The SIMD aspects of the SPE are handled by programmers and supported by compilers in much the same way as the SIMD units on PC processors, with much the same benefits, and we do not elaborate on this aspect of the design here.


No!! possono essere programmate come processori (scalari) convenzionali?? :o c'è un errore!!


The SPE differs from conventional microprocessors in a number of other ways, most significantly in the size of the register file (128 entries), the way branches are handled (and avoided), and some instructions that allow software to assist the arbitration on the local store and instruction issue. These aspects of the SPE can be effectively leveraged or handled by the compiler, and while a programmer who wants to obtain maximal performance can benefit from awareness of these mechanisms, it is almost never needed to program the SPE in assembly language.

A final aspect of the SPE that differentiates it from conventional processors is the fact that only a single program context is supported at any time. This context can be a thread in an application (problem state) or a thread in a privileged (supervisor) mode, extending the operating system.

....The Cell processor supports virtualization and allows multiple operating systems to run concurrently on top of virtualization software running in “hypervisor” state. The SPEs can even be used to support hypervisor functionality.
The fact that the SPE supports only one context we believe will generally be managed by the operating system; and just as most programmers of uniprocessors are only occasionally aware of the fact that the operating system will from time to time take execution time (and cache content) away from their application, most programmers may not realize that the SPEs are managed by an operating system running on a different processor.

Incorporating a Power-Architecture-compliant core as the control processor enables Cell to run existing 32-bit and 64-bit Power and PowerPC applications without modification. However, in order to obtain the performance and power efficiency advantages of Cell, utilization of the SPE is required. The rich set of processor–processor communication and data movement facilities incorporated in the Cell processor make a wide range of programming models feasible. For example, it is possible for existing applications to use the SPEs rather transparently by utilizing a function offload model, with the SPE code providing acceleration to specific performance-critical library functions.
As noted earlier, since the SPEs can support message passing to and from the PPE and other SPEs, it is very feasible to set up serial or parallel pipelines, with each SPE in the pipeline applying a particular computational kernel to the data that streams through it.

The PPE can act as a stream controller and the SPEs act as the stream data processors. When each SPE has to do an equivalent amount of work, this can be an efficient way to use the Cell processor, since data remains inside the processor as long as possible (remember that the on-chip memory bandwidth exceeds the off-chip bandwidth by an order of magnitude). In some cases it may be more efficient to move code to data within the SPEs instead of the more conventional movement of data to code.

Qui vale la pena soffermarci un istante in più. Sperando che con questo finisca l'era nella quale fek andava in giro a definire il Cell “streaming processor”. La PPE PUO' fungere da SC e le SPE da SDP. Questo perché il Cell è ANCHE un ottimo streaming processor, ma non solo. Le unita' possono lavorare in blocchi o da sole, in serie o in parallelo (cosi' come i Cell stessi tra di loro). Queste sono però proprio le basi del concetto Cell.

The Cell processor can be programmed as a shared-memory multiprocessor having processing units with two different instruction sets catering to applications in which a single instruction set is inefficient for the variety of required tasks. The SPE and PPE units can interoperate fully in a cache-coherent shared-memory programming model. With respect to the SPE units, all DMA operations are cache-coherent. Conventional shared-memory load instructions are replaced by the combination of a DMA operation from shared memory to local store, using an effective address in common with all PPE or SPE units assigned to this address space, and a load from local store to the register file. Conventional shared-memory store instructions are replaced by the combination of a store from the register file to the local store and a DMA operation from local store to shared memory, using an effective address in common with all PPE or SPE units assigned to this address space. Equivalents of the Power Architecture atomic update primitives (load with reservation and store conditional) are also provided on the SPE units by utilizing the DMA lock line commands.
It is also not difficult to contemplate a compiler or interpreter that would manage part of the local store as a local cache for instructions and data obtained from shared memory.

Un altro po' di chiarimenti riguardo il DMA e le comunicazioni/compiti/possibilità di PPE e SPE, chiarimenti che a questo punto si rendono necessari.

____________________

In this extension to a familiar runtime model, threads can be scheduled to run on either the PPE or the SPEs, and threads interact with one another as they do in a conventional SMP. This model provides an excellent foundation for many Cell programming models by extending the thread or lightweight task models of a modern operating system to include processing units having different instruction sets such as the PPE and SPE. Various scheduling policies can then be applied to both the PPE and SPE threads to optimize performance and utilization. While full preemptive task switching on SPEs is supported for debugging, it is costly in terms of performance and resources during runtime, and FIFO run-to-completion models or lightweight cooperative yielding models can be employed for efficient task scheduling.
The fact that the SPEs do not support multiple threads running simultaneously is hidden from the programmer. This runtime model is extremely flexible and can support all of the previously mentioned Cell programming models.

The fourth objective (schedule) was met jointly by constructing the Cell processor by using the Power Architecture as its core. Thus, IBM experience in designing and verifying symmetric multiprocessors could be leveraged.
Even though the SPEs operate on local memory, the DMA operations are coherent in the system, and Cell is a ten-way SMP from a coherence perspective. Also, by building on Power technology, existing operating systems and applications can run without modification, and the extra effort the programmer makes is needed only to unleash the power of the SPEs. Ease of programming was also the primary motivation for including the Power Architecture SIMD extensions on the PPE. This allows for a staged approach, where code is developed and then SIMD-vectorized in a familiar environment, before performance is enhanced by using the synergistic processors.

Bene con questo penso sia tutto molto più chiaro.

Concluderei rivolgendomi prima a cdimauro riguardo post precedenti (ai quali non ho potuto rispondere per cause di forza maggiore, ma che comunque ritengo inutili per la maggior parte), ricordandogli che anche se lui non lo capisce, l'R520/580, hanno molto più in comune con l'architettura dell'R500 a shader unificati che con quella dell'R4x0. Per ulteriori informazioni, chiedi direttamente a Yoss, almeno con lui non discuti e soprattutto non lo offendi.
Altra cosa da far notare più che a te, direi a chi legge, è che; non siamo solo io e Dino a dire che gli SPE sono Processori a tutti gli effetti, ma anche tutti i link di tutte le recensioni sparse per il mondo, che tendi stranamente a ricordare, ma io che sono così premuroso, te le ricorderò anche ora per l'ennesima volta.
http://www.pcstats.com/articleview.cfm?articleID=1727
'Synergistic Processing Elements' (SPEs), essentially eight more highly specialized mini-computers on the same die.
It's these SPEs that make the Cell architecture special, as you might guess. IBM describes the product as a 'System on a Chip”

http://www.blachford.info/computer/Cell/Cell1_v2.html
"An SPE is a self contained vector processor which acts as an independent processor"
According to IBM a single SPE(which is just 15 square millimetres and consumes less than 5 Watts at 4GHz) can perform as well as a top end (single core) desktop CPU given the right task”

http://www.realworldtech.com/page.c...RWT021005084318
"Each SPE is in essence a private system-on-chip (SoC)..
The PPE and SPE processing elements access system memory through the MIC..
The SPE is an in-order processor that can issue two instructions per cycle to seven execution units in two different pipelines..

http://www.anandtech.com/cpuchipset...aspx?i=2379&p=3
The Cell architecture debuted in a configuration of 9 independent cores..

Each SPE is a fully functioning independent microprocessor..



A questi oggi aggiungo quest'altro

http://www-128.ibm.com/developerworks/power/library/pa-cbea.html

In questa sezione del sito IBM si può leggere che le SPE ovviamente non sono ottimizzate per un OS (ma chi lo ha mai detto..anzi) e si può leggere anche questo:

The SPEs are independent processors, each running its own individual application programs . Each SPE has full access to coherent shared memory, including the memory-mapped I/O space. The designation synergistic for this processor was chosen carefully -- there is a mutual dependence between the PPE and the SPEs.

Anche IBM dice che sono PROCESSORI INDIPENDENTI e che non sono gli SPE ad essere dipendenti dalla PPE, bensì la dipendenza è reciproca (per un efficiente e corretto funzionamento).

Miei cari professoroni e grandi professionisti.. non ci avete capito un °&$% e sfottete pure chi non vi da retta. Capisco sempre di più il perché questo forum scarseggi di professionisti.


Dunque per il mondo intero sono processori indipendenti. Qualunque altra cosa, dopo tutto quanto qui sopra e dopo la dimostrazione palese della confusione riguardo il concetto di processore (processing) e le vostre inopportune ed immeritate scalate alla cattedra, direi che non ci sia più altro da aggiungere.

________________________________


Chiuderei con un sentitissimo ringraziamento al correttidssimo e democraticissimo cionci, che sostiene (in PVT) che saremmo stati da sospendere entrambi (io e cdi, quest'ultimo, guarda caso, non e' però mai stato nemmeno ripreso), tuttavia, ad un certo punto senza avvertimento, ha deciso che il primo che avesse usato termini non di suo gradimento (per altro non ho offeso, ho solo fatto una domanda che scaturiva da un mio lecito dubbio), sarebbe stato la vittima!!
Beh, che dire, molto giusto no?? come è giusto che non siano stati sospesi (né mai nemmeno “redarguiti”) taluni idioti che piazzavano post solo palesemente per sfottere (dimmi cionci, questo lo consente il regolamento??) senza aver la più pallida cognizione dell'argomento trattato, solo per simpatia.
Qualora per il futuro non farai mantenere l'ordine e non userai lo stesso peso per TUTTI, sposterò l'argomento su forum più democratici, senza aspettare che terminino cinque giorni (5 mi sembrano il minimo per ciò che ho detto rispondendo ai toni di tutti gli altri [se solo avessi saputo che loro possono ed io no!! però dillo no?? o non sei corretto nemmeno in questo??]).

A voi la fantasiosa risposta. :) Tanto so che ne inventerete una.

MadRat II: la vendetta :D :D

E' tornato e continua a confondere Processor, Processing e CPU :rotfl:
E continua a quotare roba che gli da' torto.

Gli SPE sono delle CPU con delle limitazioni se paragonate ad altre (e delle agevolazioni se paragonate ad altre ancora, mi riallaccio e prendo per buono l'esempio ci VPU vista come CPU che tu hai riportato), ma sempre CPU rimangono.

Non ho mai sostenuto inoltre che uno SPE sia una CPU, non so se qualcuno qui dentro lo ha mai sostenuto,


Punti di vista. :)

:asd:

E poi continua ad offendere, magari lo sospendono di nuovo.

MadRat: ti ripeto che tu avevi chiamato le SPE CPU General Purpose...non processori... Ovviamente general purpose è sbagliato...come tiportato anche dalla documentazione che hai incollato sopra dove li chiamano Vector Processor...quindi di fatto Special Purpose...

Chiuderei con un sentitissimo ringraziamento al correttidssimo e democraticissimo cionci, che sostiene (in PVT) che saremmo stati da sospendere entrambi (io e cdi, quest'ultimo, guarda caso, non e' però mai stato nemmeno ripreso), tuttavia, ad un certo punto senza avvertimento, ha deciso che il primo che avesse usato termini non di suo gradimento (per altro non ho offeso, ho solo fatto una domanda che scaturiva da un mio lecito dubbio), sarebbe stato la vittima!!

Gli avvertimenti li ho fatti e sono ben evidenti nel thread... Chiedere se uno si droga è un domanda lecita ? Dare dell'idiota è lecito ? Poi tra l'altro me ne era sfuggita anche un'altra che ora non ricordo...
Se poi pensi che io difenda cdiamuro allora sei nel torto...forse non hai mai visto lo sfogo che ho avuto verso di lui qualche mese fa :)
Beh, che dire, molto giusto no?? come è giusto che non siano stati sospesi (né mai nemmeno “redarguiti”) taluni idioti che piazzavano post solo palesemente per sfottere (dimmi cionci, questo lo consente il regolamento??) senza aver la più pallida cognizione dell'argomento trattato, solo per simpatia.
Vedi che non ci siamo capiti ? Se tu li chiami idioti vai automaticamente nel torto... Gli sfottò fanno parte del gioco, ovviamente entro certi limiti...
Il fatto è che ti sei intestardito su una cosa convinto di poterla dimostra, ma che ancora non hai fatto... La gente un po' si diverte a vedere questa cosa...ed è chiaro che qualche sfottò parta ;) Ovviamente se fosse stato superato qualche limite l'utente sarebbe stato sospeso...c'è anche il tasto segnala...
Qualora per il futuro non farai mantenere l'ordine e non userai lo stesso peso per TUTTI, sposterò l'argomento su forum più democratici, senza aspettare che terminino cinque giorni (5 mi sembrano il minimo per ciò che ho detto rispondendo ai toni di tutti gli altri [se solo avessi saputo che loro possono ed io no!! però dillo no?? o non sei corretto nemmeno in questo??]).

Ti ho avvertito ben due volte di smetterla con quei toni...e l'avvertimento era anche per gli altri... Gli altri hanno smesso mentre tu no...quindi sei stato sospeso...

Ah...ultima cosa guardati il punto 1.3b del regolamento...

Design concept and architecture:

The Broadband Processor Architecture extends the 64-bit PowerArchitecture with cooperative offload processors (“synergistic processors”), with the direct memory access (DMA) and synchronization mechanisms to communicate with them (“memory flow control”), and with enhancements for real-time management.

Qui si nota chiaramente come il DMA non sia un ripiego, ma una precisa scelta. L'unico vero modo per rendere il Cell ciò che è, con le relative capacità e la propria ed unica flessibilità.

The first-generation Cell processor (Figure 1) combines a dual-threaded, dual-issue, 64-bit Power-Architecture-compliant Power processor element (PPE) with eight newly architected synergistic processor elements (SPEs) [11], an on-chip memory controller, and a controller for a configurable I/O interface. These units are interconnected with a coherent on-chip element interconnect bus (EIB). Extensive support for pervasive functions such as power-on, test, on-chip hardware debug, and performance-monitoring functions is also included.



scusa Mad, se ti quoto solo questo, ma il fatto è che tutto ruota attorno ad un enorme equivoco.
Che il DMA sia una scelta precisa è assodato. L'alternativa sarebbe stata accedere alla ram di sistema attraverso la PPE. Ormai sono tantissimi i sottosistemi interni ad un pc che fanno uso di DMA (una scheda video, una scheda audio, un disk drive controller, tanto per fare alcuni esempi). E lo fanno tutti per libera scelta progettuale (l'alternativa sarebbe quella di caricare di ulteriore lavoro la cpu).
Quindi, l'alternativa all'utilizzo dell DMA non è un accesso di "tipo cpu" (a cui si è preferito il primo), ma un accesso attraverso la "cpu" del sistema, che è la PPE.

Infine torno un attimo sulle definizioni. "Processore" è un termine molto generico che comprende una vasta tipologia di dispositivi. "CPU", invece, è molto specifico; una cpu è un processore, ma un processore non è necessariamente una cpu. Questo credo sia chiaro

MadRat: ti ripeto che tu avevi chiamato le SPE CPU General Purpose...non processori... Ovviamente general purpose è sbagliato...come tiportato anche dalla documentazione che hai incollato sopra dove li chiamano Vector Processor...quindi di fatto Special Purpose...

Forse no hai letto bene tutto il post. Io sin dall'inizio ho comunque sempre detto che gli SPE non sono ottimi per far girare un OS tradizionale!!
Per quanto riguarda il disgroso GP, beh, c'e' scritto abbastanza sul mio post, non credo si debba aggiungere altro.

Forse no hai letto bene tutto il post. Io sin dall'inizio ho comunque sempre detto che gli SPE non sono ottimi per far girare un OS tradizionale!!
Per quanto riguarda il disgroso GP, beh, c'e' scritto abbastanza sul mio post, non credo si debba aggiungere altro.
Se non è ottimo per far girare un SO non è un processore General Purpose !!! :D
E mi sembra che Yossarian abbia chiarito sul discorso CPU...

Forse no hai letto bene tutto il post. Io sin dall'inizio ho comunque sempre detto che gli SPE non sono ottimi per far girare un OS tradizionale!!
Per quanto riguarda il disgroso GP, beh, c'e' scritto abbastanza sul mio post, non credo si debba aggiungere altro.

C'e' bisogno di aggiungere questo:

Gli SPE sono delle CPU con delle limitazioni se paragonate ad altre (e delle agevolazioni se paragonate ad altre ancora, mi riallaccio e prendo per buono l'esempio ci VPU vista come CPU che tu hai riportato), ma sempre CPU rimangono.

Non ho mai sostenuto inoltre che uno SPE sia una CPU, non so se qualcuno qui dentro lo ha mai sostenuto,

:asd:

Cmq ormai sto thread è un incubo...
Quindi visto che entrambe le parti hanno finito con un "non credo ci sia da aggiungere altro", esaurito il discorso Play 3, parliamo di Vista? :fagiano:

scusa Mad, se ti quoto solo questo, ma il fatto è che tutto ruota attorno ad un enorme equivoco.
Che il DMA sia una scelta precisa è assodato. L'alternativa sarebbe stata accedere alla ram di sistema attraverso la PPE. Ormai sono tantissimi i sottosistemi interni ad un pc che fanno uso di DMA (una scheda video, una scheda audio, un disk drive controller, tanto per fare alcuni esempi). E lo fanno tutti per libera scelta progettuale (l'alternativa sarebbe quella di caricare di ulteriore lavoro la cpu).
Quindi, l'alternativa all'utilizzo dell DMA non è un accesso di "tipo cpu" (a cui si è preferito il primo), ma un accesso attraverso la "cpu" del sistema, che è la PPE.

Infine torno un attimo sulle definizioni. "Processore" è un termine molto generico che comprende una vasta tipologia di dispositivi. "CPU", invece, è molto specifico; una cpu è un processore, ma un processore non è necessariamente una cpu. Questo credo sia chiaro

Mi sembra chiara la posizione di IBM, no?? Loro non parlano di CPU, perche' secondo me non ha proprio senso fare una simile distinzione oramai.
Come gia' detto nel post, e' lungo forse ti e' sfuggito o e' passato inosservato il passo, loro dichiarano che uno SPE ha delle differenze rispetto ad un processore convenzionale, dunque e' un processore un po' differente da quelli convenzionali, questo che ti fa pensare??
Un DSP e' un processore, una VPU e' un processore, un microcontroller e' un processore, tutto e' un processore!! allora la loro frase che vuol dire?? O non vuol dir nulla o la chiave di lettura e' sbagliata. :) Come processore, loro intendono ovviamente CPU, visto anche il parallelo continuo con la PPE e nessun'altra interpretazione possibile e plausibile.

Tutti i discorsi riguardo processing/processor, sono stupidagini vere e proprie.

Per quanto riguarda il DMA anche qui ho affrontato abbondantemente l'argomento, IBM ha scelto un complesso DMA per una vastita' di motivi e perché è l'unico modo per rendere il Cell così flessibile e modulare. Mi sembrano chiari, dicono che gli SPE possono far tutto quello che fanno le CPU convenzionali (ma tramite DMA). Come diceva nAo (ed io) non c'e' differenza alcuna se si usa il DMA (anzi..).

mi scuso con tutti se n leggo gli arretrati, ma volevo capire una cosa...

il fulcro della diatriba è se è corretto meno definire gli SPE dei processori?
( intendendo per processore, una CPU x destinata a fare compiti x? Insomma general purpose, come potrebbe essere un P4, un XP ecc...?)

Se non è ottimo per far girare un SO non è un processore General Purpose !!! :D
E mi sembra che Yossarian abbia chiarito sul discorso CPU...

attenzione. Sul link postato da madrat c'è scritto che le spe non sono ottimizzate per farci girare un o.s. non che non è possibile farlo ;)

Cmq ormai sto thread è un incubo...
Quindi visto che entrambe le parti hanno finito con un "non credo ci sia da aggiungere altro", esaurito il discorso Play 3, parliamo di Vista? :fagiano:

ennò dai io mi sn perso qlc pezzo, aspettate un attimo prima di chiudere :D

C'e' bisogno di aggiungere questo:

:asd:

Tu ridi per non piangere mio caro. :) Credo di aver chiarito abbastanza il perche' anche io tenda a discostarmi dal concetto di CPU e preferisca parlare di processori, concetto che non ribadirò ora per l'ennesima volta.
Ora non attaccarti alle cavolate, ci si potrebbe mandare lo shuttle su plutone con tutte quelle che avete detto. :)

mi scuso con tutti se n leggo gli arretrati, ma volevo capire una cosa...

il fulcro della diatriba è se è corretto meno definire gli SPE dei processori?
( intendendo per processore, una CPU x destinata a fare compiti x? Insomma general purpose, come potrebbe essere un P4, un XP ecc...?)

Piu' o meno si', da 20 pagine sta cercando affannosamente di dimostrare che le SPE sono CPU, con scarsi risultati, ma con grasse risate da parte di tutti gl'altri :)

Se non è ottimo per far girare un SO non è un processore General Purpose !!! :D
E mi sembra che Yossarian abbia chiarito sul discorso CPU...
Alla IBM si parla anche di streaming Kernel, ma il fatto che non sia ottimizzato per, non vuol dire che non possa farlo all'occorrenza. Un SO studiato appositamente per essi, potrebbe funzionare degnamente.

Tu ridi per non piangere mio caro. :) Credo di aver chiarito abbastanza il perche' anche io tenda a discostarmi dal concetto di CPU e preferisca parlare di processori, concetto che non ribadirò ora per l'ennesima volta.
Ora non attaccarti alle cavolate, ci si potrebbe mandare lo shuttle su plutone con tutte quelle che avete detto. :)

L'unica cosa che hai chiarito e' che stai rosicando come poche volte ho visto tanto da postare una valanga di roba che ti da' torto per l'ennesima volta :)

E c'e' solo piu' il povero yoss che prova a farti ragionare. Gli altri si limitano a ridere.

L'unico a dire cavolate e non sapere di che parla sei tu:
Gli SPE sono delle CPU con delle limitazioni se paragonate ad altre (e delle agevolazioni se paragonate ad altre ancora, mi riallaccio e prendo per buono l'esempio ci VPU vista come CPU che tu hai riportato), ma sempre CPU rimangono.
Non ho mai sostenuto inoltre che uno SPE sia una CPU, non so se qualcuno qui dentro lo ha mai sostenuto,

:asd:

ennò dai io mi sn perso qlc pezzo, aspettate un attimo prima di chiudere :D

Bhè chiudere no, è un thread di Articoli e non si fa :nonsifa:
Poi però tu con calma ti puoi leggere tutti gli arretrati :read:

Alla IBM si parla anche di streaming Kernel, ma il fatto che non sia ottimizzato per, non vuol dire che non possa farlo all'occorrenza. Un SO studiato appositamente per essi, potrebbe funzionare degnamente.
Ripeto se non è pensato ANCHE per far girare un SO allora non è un processore General Purpose... Puoi darmi torto in qualcosa in questa affermazione ?
Se non sbaglio non ha nemmeno i livelli di privilegio...

Piu' o meno si', da 20 pagine sta cercando affannosamente di dimostrare che le SPE sono CPU, con scarsi risultati, ma con grasse risate da parte di tutti gl'altri :)

diciamo che anche la vostra parte qualche errore l' ha commesso ;)..anche voi a definirle synergistic PROCESSING elements quando sui documenti IBM (almeno quelli che hapostato mad) è synergistic PROCESSOR elements.. :)

diciamo che anche la vostra parte qualche errore l' ha commesso ;)..anche voi a definirle synergistic PROCESSING elements quando sui documenti IBM (almeno quelli che hapostato mad) è synergistic PROCESSOR elements.. :)

Sono corrette entrambe le diciture :)

http://www-128.ibm.com/developerworks/power/library/pa-cell/?ca=dgr-lnxw02SpufsCell

The Synergistic Processing Elements (SPEs) are the most interesting feature of the Cell processor, as they are the source of its overwhelming processing power. A single chip contains eight SPEs, each with an SPU, a Memory Flow Controller (MFC), and 256KB of SRAM that are used as local store memory.

diciamo che anche la vostra parte qualche errore l' ha commesso ;)..anche voi a definirle synergistic PROCESSING elements quando sui documenti IBM (almeno quelli che hapostato mad) è synergistic PROCESSOR elements.. :)
In questo anche IBM stessa ha qualche difficoltà :D
http://www-128.ibm.com/developerworks/library/pa-celldmas/

Piu' o meno si', da 20 pagine sta cercando affannosamente di dimostrare che le SPE sono CPU, con scarsi risultati, ma con grasse risate da parte di tutti gl'altri :)

Non credo che tu possa capire, forutunatamente il problema e' tuo. :)



Tecnicamente comunque le 8 SPE integrate nel core sono dei processori a sè stanti (penso che ti riferisci a questo con molto evolute) progettati però per eseguire velocemente solo i calcoli vettoriali. Alla fine sono dei processori studiati per funzionare da unità vettoriali, mantenendo però le funzioni di base di un processore (branching, gestione della memoria, calcoli sugli interi ecc...)
No, guarda, ti prego non ricominciamo, non sono dei processori a se' stanti (se per processori intendi delle CPU). C'e' un'amplissima discussione proprio su questo argomento nella sezione Articoli, condita da qualche perla gustosissima per altro :)

Sono delle unita' vettoriali molto evolute e flessibili, con una memoria locale, e accesso ad un DMA per i trasferimenti, ma non possono funzionare indipendentemente da un controllore, che nel caso del Cell e' costituito dalle PPE.

DA IBM:

The SPEs are independent processors, each running its own individual application programs . Each SPE has full access to coherent shared memory, including the memory-mapped I/O space.

Credo che dopo questo, non meriti altre risposte. :)

Ripeto se non è pensato ANCHE per far girare un SO allora non è un processore General Purpose... Puoi darmi torto in qualcosa in questa affermazione ?
Se non sbaglio non ha nemmeno i livelli di privilegio...

Se ci fossero dei Kernel con i quali questi si trovassero a proprio agio?? :) Poi GP non vuol dire "far girare un SO", mi sembra un po' riduttivo.

Non credo che tu possa capire, forutunatamente il problema e' tuo. :)


Calmati che poi ti sospendono di nuovo :)


DA IBM:

The SPEs are independent processors, each running its own individual application programs . Each SPE has full access to coherent shared memory, including the memory-mapped I/O space.

Credo che dopo questo, non meriti altre risposte. :)

Continui a quotare roba che ti da' torto, non c'e' scritto CPU, infatti non lo sono e non c'e' scritto che possono funzionare indipendentemente dalle PPE infatti non possono come piu' volte dimostrato :)

diciamo che anche la vostra parte qualche errore l' ha commesso ;)..anche voi a definirle synergistic PROCESSING elements quando sui documenti IBM (almeno quelli che hapostato mad) è synergistic PROCESSOR elements.. :)

La P sta per processing, non avevano torto, il torto marcio lo hanno nel voler insegnare a me (e a chi si permette di contraddirli) che processing e processor, sono due cose differenti!! spiegarci pure i motivi per i quali IBM avrebbe scelto denominazioni differenti ed incentrarci nu simile delirio informatico!! :D mentre IBM non fa alcuna (ovviamente, non serve un espertone informatico per saperlo) distinzione tra le due cose.

Continui a quotare roba che ti da' torto, non c'e' scritto CPU, infatti non lo sono e non c'e' scritto che possono funzionare indipendentemente dalle PPE infatti non possono come piu' volte dimostrato :)

I sassi non sanguineranno mai.

In questo anche IBM stessa ha qualche difficoltà :D
http://www-128.ibm.com/developerworks/library/pa-celldmas/

Se ti interessa, nel sito trovi già i primi bench stra SSE (P4) e SPE, ma nulla di molto concreto.

La P sta per processing, non avevano torto, il torto marcio lo hanno nel voler insegnare a me (e a chi si permette di contraddirli) che processing e processor, sono due cose differenti!! spiegarci pure i motivi per i quali IBM avrebbe scelto denominazioni differenti ed incentrarci nu simile delirio informatico!! :D mentre IBM non fa alcuna (ovviamente, non serve un espertone informatico per saperlo) distinzione tra le due cose.

Processing e' un verbo, Processor e' un sostantivo. Pure la grammatica :)
Non sai piu' a che cosa attaccarti.

Ti stiamo insegnando che le SPE non sono CPU, come pensavi. E poi ti stiamo insegnando un po' di educazione che non guasta mai.

Se ci fossero dei Kernel con i quali questi si trovassero a proprio agio?? :) Poi GP non vuol dire "far girare un SO", mi sembra un po' riduttivo.
No appunto..ma una CPU GP non deve essere stata pensata per un determinato compito, altrimenti è Special Purpose... Il Cell è stato pensato come SIMD unit o Vector Processor che dir si voglia e quindi è un processore Special Purpose...

I sassi non sanguineranno mai.

Mi stai dando del sasso? :)

Mi sembra chiara la posizione di IBM, no?? Loro non parlano di CPU, perche' secondo me non ha proprio senso fare una simile distinzione oramai.
Come gia' detto nel post, e' lungo forse ti e' sfuggito o e' passato inosservato il passo, loro dichiarano che uno SPE ha delle differenze rispetto ad un processore convenzionale, dunque e' un processore un po' differente da quelli convenzionali, questo che ti fa pensare??
Un DSP e' un processore, una VPU e' un processore, un microcontroller e' un processore, tutto e' un processore!! allora la loro frase che vuol dire?? O non vuol dir nulla o la chiave di lettura e' sbagliata. :) Come processore, loro intendono ovviamente CPU, visto anche il parallelo continuo con la PPE e nessun'altra interpretazione possibile e plausibile.

Tutti i discorsi riguardo processing/processor, sono stupidagini vere e proprie.

Per quanto riguarda il DMA anche qui ho affrontato abbondantemente l'argomento, IBM ha scelto un complesso DMA per una vastita' di motivi e perché è l'unico modo per rendere il Cell così flessibile e modulare. Mi sembrano chiari, dicono che gli SPE possono far tutto quello che fanno le CPU convenzionali (ma tramite DMA). Come diceva nAo (ed io) non c'e' differenza alcuna se si usa il DMA (anzi..).

con tutto il rispetto per quanto hai riportato, il termine "processore di tipo non convenzionale" non ha alcun senso. Si può classificare come processore qualunque dispositivo in grado di svolgere determinati task (e uno spe rientra nella categoria, senza perdita di generalità; quindi, da questo punto di vista, è un processore tradizionale come un dsp o una gpu).
Interpretare liberamente non ha molto senso e non è costruttivo. IBM parla di processore, non di cpu, quando si riferisce allo spe, mentre per il cell, ad esempio, è utilizzato il termine cpu.
La differenza tra l'uso del dma e in accesso di "tipo cpu" c'è, eccome. Sta nei tempi di accesso alla ram; una cpu accede più velocemente di quanto non possa fare un qualunque dispositivo che faccia uso di dma. In molti casi, persino l'accesso, da parte di un dispositivo periferico, tramite cpu, è più veloce di quello ottenibile attraverso dma. Il problema è che quando sono tanti i dispositivi a dover accedere in maniera veloce alla ram di sistema, farli passare tutti tramite cpu significherebbe utilizzare gran parte delle risorse di quest'ultima per gestire gli accessi alla ram dei diversi sottosistemi. Per questo motivo, si ricorre all'espediente del dma che, per quanto spesso sia più lento (come tempi d'accesosde l singolo dispositivo alla ram), evite un rallentamento dell'interno sistema dovuto al sovraccarico da parte della cpu.
Anche in questo, il cell non ha niente di innovativo (molti chipset di schede madri, dai tempi del PII, se non prima, permettevano l'utilizzo di dma da parte dei disk drive controller, tanto per fare un esempio).
Il cell, in maniera forse semplicistica, può essere schematizzato nel modo seguente: un controller che gestisce una serie di unità di calcolo. La differenza rispetto ad un sistema tradizionale di questo tipo è che parte della complessità circuitale è stata spostata dal controller alle unità di calcolo; queste ultime sono processori ma non cpu. Quindi, se è corretta la definizione "sistema multiprocessore" non lo è quella di "sistema multi-cpu".

Che en dite se chiudiamo qui la feccenda e non la riapriamo più ? Tanto ognuno di noi ha detto quello che doveva dire...stare qui a fare a testate e a continuare a ripetere le stesse cose è inutile ;)

Che en dite se chiudiamo qui la feccenda e non la riapriamo più ? Tanto ognuno di noi ha detto quello che doveva dire...stare qui a fare a testate e a continuare a ripetere le stesse cose è inutile ;)

no dai, alla fine anche se i toni si accendono un pò questo thread è davvero pieno di cose interessanti! :)

No appunto..ma una CPU GP non deve essere stata pensata per un determinato compito, altrimenti è Special Purpose... Il Cell è stato pensato come SIMD unit o Vector Processor che dir si voglia e quindi è un processore Special Purpose...

Leggi tutto il post e tutto l'articolo, ci sono le risposte che cerchi. A me oramai sembrano molto piu' che chiare.

Che en dite se chiudiamo qui la feccenda e non la riapriamo più ? Tanto ognuno di noi ha detto quello che doveva dire...stare qui a fare a testate e a continuare a ripetere le stesse cose è inutile ;)

Ci sto. Gli lascio l'ultima parola che sembra ci tenga cosi' tanto da tornare anche dopo la sospensione :)

no dai, alla fine anche se i toni si accendono un pò questo thread è davvero pieno di cose interessanti! :)
Certo fino a quando non ci mettiamo a ripetere le stesse cose...me compreso ;)
Abbiamo già esposto le nostre tesi...ora si tratta solo di dare ragione a l'uno o l'altro...ma tanto è impossibile, quindi tanto vale chiudere questa diatriba...

con tutto il rispetto per quanto hai riportato, il termine "processore di tipo non convenzionale" non ha alcun senso. Si può classificare come processore qualunque dispositivo in grado di svolgere determinati task (e uno spe rientra nella categoria, senza perdita di generalità; quindi, da questo punto di vista, è un processore tradizionale come un dsp o una gpu).
Interpretare liberamente non ha molto senso e non è costruttivo. IBM parla di processore, non di cpu, quando si riferisce allo spe, mentre per il cell, ad esempio, è utilizzato il termine cpu.
La differenza tra l'uso del dma e in accesso di "tipo cpu" c'è, eccome. Sta nei tempi di accesso alla ram; una cpu accede più velocemente di quanto non possa fare un qualunque dispositivo che faccia uso di dma. In molti casi, persino l'accesso, da parte di un dispositivo periferico, tramite cpu, è più veloce di quello ottenibile attraverso dma. Il problema è che quando sono tanti i dispositivi a dover accedere in maniera veloce alla ram di sistema, farli passare tutti tramite cpu significherebbe utilizzare gran parte delle risorse di quest'ultima per gestire gli accessi alla ram dei diversi sottosistemi. Per questo motivo, si ricorre all'espediente del dma che, per quanto spesso sia più lento (come tempi d'accesosde l singolo dispositivo alla ram), evite un rallentamento dell'interno sistema dovuto al sovraccarico da parte della cpu.
Anche in questo, il cell non ha niente di innovativo (molti chipset di schede madri, dai tempi del PII, se non prima, permettevano l'utilizzo di dma da parte dei disk drive controller, tanto per fare un esempio)

Se e' per questo si puo' risalire anche ai computer 6800 based. :)

Se giri un po' per il sito IBM vedrai i tempi ed i cicli necessari e ti accorgerai che non sono poi cosi' male. In fine ti invito a trovare la definizione "CPU" all'interno di tutto quel documento. Ti aiuto, non la trovi. :)

Se e' per questo si puo' risalire anche ai computer 6800 based. :)

Se giri un po' per il sito IBM vedrai i tempi ed i cicli necessari e ti accorgerai che non sono poi cosi' male. In fine ti invito a trovare la definizione "CPU" all'interno di tutto quel documento. Ti aiuto, non la trovi. :)

di quello no, di altri si ;)

leggiti questa intervista (presa da Tom's)

http://www.tomshw.it/business.php?guide=20051223

Che en dite se chiudiamo qui la feccenda e non la riapriamo più ? Tanto ognuno di noi ha detto quello che doveva dire...stare qui a fare a testate e a continuare a ripetere le stesse cose è inutile ;)

Direi che alcuni non dovrebbero piu' andare in giro a replicare a chi giustamente dice che gli SPE sono processori indipendenti, appligliandosi ancora ad concetto di CPU che IBM non tratta affatto.

di quello no, di altri si ;)
Ne fa solo un piccolo accenno in alcuni schemi sulal documentazione riferendosi alla cache, ma credo siano solo abbreviazioni per necessita' di schema, visto che non ne accenna mai altrove (almeno non ricordo).
Comuqnue in quel documento parla del Cell in todo, spiega architetture e concetti base, se non parla di CPU, avrà le prprie ragioni. :)

In fin dei conti, nessuno processore e' CENTRALE nel Cell, c'e' una mutua dipendenza e molti compiti possono essere delegati tranquillamente agli SPE (che volendo possono essere completamente indipendenti e programmati come processori scalari convenzionali).
Questo non solo secondo me, ma secondo quanto letto.

Direi che alcuni non dovrebbero piu' andare in giro a replicare a chi giustamente dice che gli SPE sono processori indipendenti, appligliandosi ancora ad concetto di CPU che IBM non tratta affatto.

Se per processori indipendenti intende CPU come pensavi tu, che non sai di che parli, e' giusto che gli si faccia notare l'errore.

Gli SPE sono delle CPU con delle limitazioni se paragonate ad altre (e delle agevolazioni se paragonate ad altre ancora, mi riallaccio e prendo per buono l'esempio ci VPU vista come CPU che tu hai riportato), ma sempre CPU rimangono.
Non ho mai sostenuto inoltre che uno SPE sia una CPU, non so se qualcuno qui dentro lo ha mai sostenuto,

Lo so, sono un debole, non ho resistito, ora gliela lascio sul serio :asd:

di quello no, di altri si ;)

leggiti questa intervista (presa da Tom's)

http://www.tomshw.it/business.php?guide=20051223

Conosco quell'intervista, scusa se ho postato qualcosa di unpo' più concreto e dettagliato. :)

"possono essere intesi come ecc.." E' una delle possibilità che ho inserito nel mio post, se non erro. ;)

Se per processori indipendenti intende CPU come pensavi tu, che non sai di che parli, e' giusto che gli si faccia notare l'errore.

Lo so, sono un debole, non ho resistito, ora gliela lascio sul serio :asd:

Non fai che quotare sempre due cose decontestualizzate, non hai piu' nulla da dire (e ti credo). :)

di quello no, di altri si ;)

leggiti questa intervista (presa da Tom's)

http://www.tomshw.it/business.php?guide=20051223

i tratta di unità SPE, Synergistic Broadband Engine. Queste unità possono essere intese come dei processori specializzati che si occupano di elaborare frammenti di codice (audio, video, etc), coordinati dall'unità centrale che poi elabora il prodotto finito, comunicando tramite un bus centrale.

Ma che ignorante che e', li chiama processori specializzati e non CPU, la prossima volta dovrebbero intervistare MadRat che gli spiega a tutti... :asd:

Non fai che quotare sempre due cose decontestualizzate, non hai piu' nulla da dire (e ti credo). :)

Si' si', decontestualizzate:

Gli SPE sono delle CPU con delle limitazioni se paragonate ad altre (e delle agevolazioni se paragonate ad altre ancora, mi riallaccio e prendo per buono l'esempio ci VPU vista come CPU che tu hai riportato), ma sempre CPU rimangono.
Non ho mai sostenuto inoltre che uno SPE sia una CPU, non so se qualcuno qui dentro lo ha mai sostenuto,


Dopo la frutta sei passato al dolce :asd:

Ne fa solo un piccolo accenno in alcuni schemi sulal documentazione riferendosi alla cache, ma credo siano solo abbreviazioni per necessita' di schema, visto che non ne accenna mai altrove (almeno non ricordo).
Comuqnue in quel documento parla del Cell in todo, spiega architetture e concetti base, se non parla di CPU, avrà le prprie ragioni. :)

In fin dei conti, nessuno processore e' CENTRALE nel Cell, c'e' una mutua dipendenza e molti compiti possono essere delegati tranquillamente agli SPE (che volendo possono essere completamente indipendenti e programmati come processori scalari convenzionali).
Questo non solo secondo me, ma secondo quanto letto.

non è vero; la ppe può svolgere tutti i compiti tipici di una cpu; magari non sarà un fulmine nell'eseguire i calcoli e, in questo si avvantaggia della presenza delle spe (era persino prevista, a livello di brevetti, la possibilità di avere cell cpn ppe senza unità di calcolo interne, che si servivano, per questi, di una delle spe). Lo stesso discorso non è valido per le spe. L'intervista aparsa su Tom's, epr quanto la si possa definire generica, è fatta ad un esponente di IBM (non si tratta di opinioni di chi scrive).

non è vero; la ppe può svolgere tutti i compiti tipici di una cpu; magari non sarà un fulmine nell'eseguire i calcoli e, in questo si avvantaggia della presenza delle spe (era persino prevista, a livello di brevetti, la possibilità di avere cell cpn ppe senza unità di calcolo interne, che si servivano, per questi, di una delle spe). Lo stesso discorso non è valido per le spe. L'intervista aparsa su Tom's, epr quanto la si possa definire generica, è fatta ad un esponente di IBM (non si tratta di opinioni di chi scrive).

Potevi metterlo in dubbio fin quando si trattava solo di una mia affermazione, ma ora no.

"The designation synergistic for this processor was chosen carefully -- there is a mutual dependence between the PPE and the SPEs"

Anche gli SPE sono indipendenti, ma non sono un fulmine in determinati (altri) campi. :)

Me sembra una posizione di parità.

L'esponente di IBM potrebbe essere pure un PR un portavoce, un manager.
Quello che ho scritto e quotato io, mi sembra molto, ma molto piu' completo ed attendibile.

Potevi metterlo in dubbio fin quando si trattava solo di una mia affermazione, ma ora no.

"The designation synergistic for this processor was chosen carefully -- there is a mutual dependence between the PPE and the SPEs"

Anche gli SPE sono indipendenti, ma non sono un fulmine in determinati (altri) campi. :)

Me sembra una posizione di parità.

L'esponente di IBM potrebbe essere pure un PR un portavoce, un manager.
Quello che ho scritto e quotato io, mi sembra molto, ma molto piu' completo ed attendibile.

l'esponente IBM non ha fatto altro che ripetere quello che si trova anche sui brevetti relativi al cell. Non c'è alcun rapporto paritario tra ppe e spe (neanche un pr può spacciare qualcosa per ciò che non è; al massimo può ingigantire i pregi e minimizzare i difetti).
Ti ripeto la domanda fatta qualche pagina fa (a cui non mi pare che qualcuno abbia ancora risposto). Se le spe non hanno bisogno della ppe, per quale motivo il cell non è stato progettato con 10 spe (una ppe occupa, grosso modo, lo spazio di due spe)? Ne avrebbero guadagnato in potenza di calcolo. Oppure, perchè non utilizzare 9 spe (risparmiando 21 mln di transistor)?

Piu' o meno si', da 20 pagine sta cercando affannosamente di dimostrare che le SPE sono CPU, con scarsi risultati, ma con grasse risate da parte di tutti gl'altri :)

quindi almeno il tema conduttore l'avevo colto :D

posso dire la mia o mi sbranate? :p

Bhè chiudere no, è un thread di Articoli e non si fa :nonsifa:

sìsì lo sò, intendevo dire di n smettere di scrivere lasciandomi solo proprio ora che posto :D


Poi però tu con calma ti puoi leggere tutti gli arretrati :read:

me le pagate voi le ferie che mi occorrono per leggere tutto sto ambaradan? :asd:



Rispondo a macchie...


Alla IBM si parla anche di streaming Kernel, ma il fatto che non sia ottimizzato per, non vuol dire che non possa farlo all'occorrenza. Un SO studiato appositamente per essi, potrebbe funzionare degnamente.

il fatto che possa essere utilizzato, possa eseguire...è tutto un discorso in potenza che non nobilita o cambia la tipologia di unità di calcolo.

Faccio un paragone automobilistico...

Posso in teoria prendere una macchina da Formula 1 ( = SO) e farla correre in una corsa di Rally, posso adattare un motore da Formula 1 e montarlo ( implementarlo...= kernel) in una macchina da Rally ma questo n fà della macchina da Formula 1 una macchina General Purpose, adatta per il Rally, adatta per la città...
E' una macchina particolare, con un motore particolare pensata per un tipo di corsa particolare.
Gli altri tentativi possono essere esercizi di stile, esperimenti magari interessanti ( o folli a seconda dei pdv :D), ma nella pratica, non varrebbe la candela.
Nel nostro caso, il costo computazionale di far eseguire al Cell ed alle SPE un flusso dati che non si adatta alla sua architettura, rende il Cell stesso svantaggioso per un certo tipo di compiti ( e su questo tanto è stato scritto anche su HWUp) e per questo non è assimilabile ad una CPU ( il Cell) General Purpose.

Per quanto ne sò, ad es., esistono tentativi di far girare dei veri e propri kernel su moderne GPU, soprattutto in campi dove si studia e si necessita di elaborazioni real-time ( anche la mia università mi pare stia facendo qlc), questo non fà però della GPU una CPU.
Non sò se sn stato chiaro :)




http://www.anandtech.com/cpuchipset...aspx?i=2379&p=3
The Cell architecture debuted in a configuration of 9 independent cores..

per quanto riguarda l'indipendenza, ho detto la mia poco + sotto in questo post. Il fatto che poi Anandtech scriva core, beh è corretto perchè il Cell è composto da + core...ma un core non è una CPU :)

Tanto per fare un esempio, si parla ( rumoreggia + che altro :D...yoss magari ne sà qlc di + :p) di un'evoluzione delle GPU verso il multicore, per gli stessi motivi per cui è stato adottato con le CPU ( avvicinamento al limite fisico del silicio ecc. ecc.).
Ma il multicore applicato alle GPU non farà della GPU una CPU :)


Each SPE is a fully functioning independent microprocessor..


Indipendente perchè una SPE non dipende l'una dell'altra e dovrebbe essere agnostica rispetto ai taks eseguiti dalle altre ( non ci giurerei ma è la PPE a coordinarli quindi potrebbe bastare che sia essa stessa ad occuparsi di quest'aspetto).

Per quanto riguarda il termine microprocessore, nella letteratura soprattutto tradotta c'è una sovrapposizione di termine processore con microprocessore con CPU.
Ma un microprocessore è anche una unità vettoriale di calcolo ( VPU) o un'unità di elaborazione grafica ( GPU)...e nè VPU nè GPU sn delle CPU General Purpose....



DA IBM:

The SPEs are independent processors, each running its own individual application programs . Each SPE has full access to coherent shared memory, including the memory-mapped I/O space.

Credo che dopo questo, non meriti altre risposte. :)

indipendenti in questo caso significa che tra di loro le SPE sn indipendenti ed ognuna si occupa di una certa applicazione, o per meglio dire ( dato che il CELL è pensato per utilizzi multithread), si occupa di un thread di una stessa applicazione/processo ( che poi potrebbe essere la gestione di un particolare flusso multimediale), ma dipendono necessariamente dall'unità centrale che è la PPE.

Per fare un parallelo è come dire che i tentacoli di una piovra sn indipendenti tra loro, ma dipendono dalla testa ( che ne coordina i movimenti) e il corpo.
Un tentacolo da solo n farebbe e n servirebbe a niente.

E proprio perchè le SPE senza testa non potrebbero funzionare, non possono essere assimilate a delle CPU ( ma restano cmq dei "processori")

Nel nostro caso, il costo computazionale di far eseguire al Cell ed alle SPE un flusso dati che non si adatta alla sua architettura, rende il Cell stesso svantaggioso per un certo tipo di compiti ( e su questo tanto è stato scritto anche su HWUp) e per questo non è assimilabile ad una CPU ( il Cell) General Purpose.

su questo non sono daccordo! basta guardare le cose da un altro punto di vista... allora le altre CPU visto che sono svantaggiose (rispetto al cell) nel calcolo vettoriale non sono GP?
no credo che il Cell è una CPU GP nel senso che è adatta a applicazioni diverse rispetto alle altre CPU, ma è pur sempre un grande range di applicazioni! il Cell non è un'architettura specifica per la Play3 per intenderci...

su questo non sono daccordo! basta guardare le cose da un altro punto di vista... allora le altre CPU visto che sono svantaggiose (rispetto al cell) nel calcolo vettoriale non sono GP?
no credo che il Cell è una CPU GP nel senso che è adatta a applicazioni diverse rispetto alle altre CPU, ma è pur sempre un grande range di applicazioni! il Cell non è un'architettura specifica per la Play3 per intenderci...
sì ma guarda che dire "non é GP" non é come dire "fa schifo".
Se io dico che un freezer non é un frigo, non vuol dire che fa schifo, vuol dire che serve per congelare le bistecche invece che per conservare il provolone...

e cmq: le CPU GP hanno prestazioni di buon livello in tutti i tipi di applicazione, calcolo vettoriale incluso.
il Cell eccelle nel calcolo vettoriale mentre decade paurosamente in altri tipi di utilizzo, quindi non é GP. Punto.
Poi puoi avere tutti i punti di vista che vuoi con anche le lenti deformabili e il grandangolo con la visuale a spioncino, ma la sostanza é sempre quella... :D

allora le altre CPU visto che sono svantaggiose (rispetto al cell) nel calcolo vettoriale non sono GP?


No, perchè il calcolo vettoriale è uno dei possibili campi applicativi di quel microprocessore e di quella macchina.

General Purpose non significa che debba fare tutto e lo debba fare bene, è ovvio che un processore dedicato per fare una certa cosa la faccia ( si spera almeno :D) meglio di uno General Purpose, altrimenti non avrebbe senso che esistessero i processori Special Purpose.

Un GPP ( General Purpose Processor) è costruito in maniera tale da essere estremamente flessibile ( e qui ci si richiama alle scelte architetturali, le modalità di funzionamento per esempio, le istruzioni utilizzate, i meccanismi di protezione della memoria ecc.).
E per flessibile non si intende solo riuscire a comportarsi sufficientemente bene in svariate situazioni, ma soprattutto adattarsi in futuro ad i cambiamenti HW e SW dell'intera macchina.
Ti faccio un esempio...

Fino a qlc tempo fà, prima che uscissero svariati formati vantaggiosi dal punto di vista del rapporto qualità ( o perdita di informazione se la vogliamo leggere dall'altro lato)/ Memoria secondaria allocata, nessuno si metteva col proprio pc ad encodare film, a rippare i propri cd audio, a fare del videoediting con i filmati catturati da varie sorgenti.
Le CPU fondamentalmente sn rimaste le stesse ( certo, sn aumentate le istruzioni, sn aumentate le pipeline e via avanti...); sempre X86 sono.
Oppure...nessuno si sarebbe sognato che per le simulazioni ad alto livello, nel supercomputing si sarebbero utilizzati processori che utilizza la casalinga per guardare il sito della propria banca da casa.
Eppure da qlc anno si usano e con successo, all'interno di cluster ovviamente, ma di quei processori stiamo parlando.


Non sn convinto che per il Cell si possano fare gli stessi discorsi ( naturalmente vedremo perchè IBM sta tentando di infilarli un pò ovunque :D)...anche perchè IBM stessa parla di Stream Processor...

no credo che il Cell è una CPU GP nel senso che è adatta a applicazioni diverse rispetto alle altre CPU, ma è pur sempre un grande range di applicazioni! il Cell non è un'architettura specifica per la Play3 per intenderci...

ma è un range ristretto ad una GPP è questo il "problema".
In applicazioni dove il calcolo vettoriale sia massiccio, le elaborazioni che sfruttano l'FPU andrà benissimo ( ecco le simulazioni scientifiche), ma per es. in applicazioni che dialogano frequentemente con dispositivi esterni ( quindi in I/O) io la vedo fortemente penalizzata.
così come in applicazioni web-oriented non avrà senso utilizzarlo, per gestire moli di dati come nei nei database e nei file-server nemmeno ( dato che si utilizzano praticamente solo gli interi)...

l'esponente IBM non ha fatto altro che ripetere quello che si trova anche sui brevetti relativi al cell. Non c'è alcun rapporto paritario tra ppe e spe (neanche un pr può spacciare qualcosa per ciò che non è; al massimo può ingigantire i pregi e minimizzare i difetti).
Ti ripeto la domanda fatta qualche pagina fa (a cui non mi pare che qualcuno abbia ancora risposto). Se le spe non hanno bisogno della ppe, per quale motivo il cell non è stato progettato con 10 spe (una ppe occupa, grosso modo, lo spazio di due spe)? Ne avrebbero guadagnato in potenza di calcolo. Oppure, perchè non utilizzare 9 spe (risparmiando 21 mln di transistor)?

Semplicemente perche' gli SPE non sono stati creati per lavorare senza PPE, duqnue sono processori indipendenti, con "serie" carenze da alcuni punti di vista che non comportano alcun problema perche', appunto, non devono lavorar da sole. Qualora si creasse un Cell senza SPE, questo sarebbe una CPU come tante altre (tipo quella del 360). La potenza del Cell e' sita negli SPE.

http://www.research.ibm.com/journal/sj/451/damor6.gif

Che a quanto pare differiscono discretamente dalla VMX in termini di risultati.

il fatto che possa essere utilizzato, possa eseguire...è tutto un discorso in potenza che non nobilita o cambia la tipologia di unità di calcolo.

Faccio un paragone automobilistico...

Posso in teoria prendere una macchina da Formula 1 ( = SO) e farla correre in una corsa di Rally, posso adattare un motore da Formula 1 e montarlo ( implementarlo...= kernel) in una macchina da Rally ma questo n fà della macchina da Formula 1 una macchina General Purpose, adatta per il Rally, adatta per la città...
E' una macchina particolare, con un motore particolare pensata per un tipo di corsa particolare.
Gli altri tentativi possono essere esercizi di stile, esperimenti magari interessanti ( o folli a seconda dei pdv :D), ma nella pratica, non varrebbe la candela.
Nel nostro caso, il costo computazionale di far eseguire al Cell ed alle SPE un flusso dati che non si adatta alla sua architettura, rende il Cell stesso svantaggioso per un certo tipo di compiti ( e su questo tanto è stato scritto anche su HWUp) e per questo non è assimilabile ad una CPU ( il Cell) General Purpose.

Per quanto ne sò, ad es., esistono tentativi di far girare dei veri e propri kernel su moderne GPU, soprattutto in campi dove si studia e si necessita di elaborazioni real-time ( anche la mia università mi pare stia facendo qlc), questo non fà però della GPU una CPU.
Non sò se sn stato chiaro :)

Con i motori fila, ma questi sono processori. Il Cell e' stato ideato per un ampio utilizzo, anzi, ampissimo!! Sicuramente molto piu' di quando non lo sia un X86. Dunque, almeno a logica, e' piu' GP. :)
Che un Kernel tradizionale non giri ottimamente su una SPE (ma su 8??) è solo un limite che potrebbe essere superato con SO studiati appositamente. Questo lo vedremo tutti, piu' avanti.



per quanto riguarda l'indipendenza, ho detto la mia poco + sotto in questo post. Il fatto che poi Anandtech scriva core, beh è corretto perchè il Cell è composto da + core...ma un core non è una CPU :)

Tanto per fare un esempio, si parla ( rumoreggia + che altro :D...yoss magari ne sà qlc di + :p) di un'evoluzione delle GPU verso il multicore, per gli stessi motivi per cui è stato adottato con le CPU ( avvicinamento al limite fisico del silicio ecc. ecc.).
Ma il multicore applicato alle GPU non farà della GPU una CPU :)

Indipendente perchè una SPE non dipende l'una dell'altra e dovrebbe essere agnostica rispetto ai taks eseguiti dalle altre ( non ci giurerei ma è la PPE a coordinarli quindi potrebbe bastare che sia essa stessa ad occuparsi di quest'aspetto).

Per quanto riguarda il termine microprocessore, nella letteratura soprattutto tradotta c'è una sovrapposizione di termine processore con microprocessore con CPU.
Ma un microprocessore è anche una unità vettoriale di calcolo ( VPU) o un'unità di elaborazione grafica ( GPU)...e nè VPU nè GPU sn delle CPU General Purpose....


indipendenti in questo caso significa che tra di loro le SPE sn indipendenti ed ognuna si occupa di una certa applicazione, o per meglio dire ( dato che il CELL è pensato per utilizzi multithread), si occupa di un thread di una stessa applicazione/processo ( che poi potrebbe essere la gestione di un particolare flusso multimediale), ma dipendono necessariamente dall'unità centrale che è la PPE.

Per fare un parallelo è come dire che i tentacoli di una piovra sn indipendenti tra loro, ma dipendono dalla testa ( che ne coordina i movimenti) e il corpo.
Un tentacolo da solo n farebbe e n servirebbe a niente.

E proprio perchè le SPE senza testa non potrebbero funzionare, non possono essere assimilate a delle CPU ( ma restano cmq dei "processori")

Aspetta, qui mi devi trovare dove IBM dichiari la dipendenza vincolante degli SPE rispetto alla PPE. Non esiste. Sono microprocessori indipendenti con tutte le caratteristiche del caso (quelle che hai quotato poco fa ed altre..). Indipendenti in nessuna lingua vuol dire "indipendenti, ma fino ad un certo punto :D".
Se poi vuoi dirmi che per lavorare bene necessitino della PPE, beh, questo sono mesi che lo sostengo anche io, cosi'come la PPE per lavorare bene necessita degli SPE.

Come ci ha detto nAo che ci lavora, possono (volendo, ma perche' volerlo??) essre totalmente indipendenti.
Anzi, ti diro' di piu', lavorando in streaming possono rivelarsi anche PPE limited (per ora, con codici non ottimizzati ed in taluni casi), dunque e' ovvio pensare che la loro possibilita' di lavorare indipendentemente sia e rarà discretamente utilizzata (come già accade infatti).

Quanto al concetto di CPU, non fatemi scrivere mille volte le stesse cose. Un microprocessore e' una vastità di cose che non puo' essere definito in alcun modo "convenzionale", dunque se IBM parla di processore (o microprocessore) con differenze da uno convenzionale, intende chiaramente riferirsi ad una CPU standard.

su questo non sono daccordo! basta guardare le cose da un altro punto di vista... allora le altre CPU visto che sono svantaggiose (rispetto al cell) nel calcolo vettoriale non sono GP?
no credo che il Cell è una CPU GP nel senso che è adatta a applicazioni diverse rispetto alle altre CPU, ma è pur sempre un grande range di applicazioni! il Cell non è un'architettura specifica per la Play3 per intenderci...

Bingo!! Finalmente ci si arriva.

sì ma guarda che dire "non é GP" non é come dire "fa schifo".
Se io dico che un freezer non é un frigo, non vuol dire che fa schifo, vuol dire che serve per congelare le bistecche invece che per conservare il provolone...

e cmq: le CPU GP hanno prestazioni di buon livello in tutti i tipi di applicazione, calcolo vettoriale incluso.
il Cell eccelle nel calcolo vettoriale mentre decade paurosamente in altri tipi di utilizzo, quindi non é GP. Punto.
Poi puoi avere tutti i punti di vista che vuoi con anche le lenti deformabili e il grandangolo con la visuale a spioncino, ma la sostanza é sempre quella... :D

Ma hai dei benchmark sotto mano che io non ho ancora vito?? :-/

Semplicemente perche' gli SPE non sono stati creati per lavorare senza PPE, duqnue sono processori indipendenti, con "serie" carenze da alcuni punti di vista che non comportano alcun problema perche', appunto, non devono lavorar da sole. Qualora si creasse un Cell senza SPE, questo sarebbe una CPU come tante altre (tipo quella del 360). La potenza del Cell e' sita negli SPE.

http://www.research.ibm.com/journal/sj/451/damor6.gif

Che a quanto pare differiscono discretamente dalla VMX in termini di risultati.

ti sei risposto da solo; se non devono (e non possono) star da sole, allora non sono cpu (ma semplicemente processori). Questo no perchè debbano lavorare in sinergia per avere la sufficiente potenza di calcolo, ma perchè non hanno la possibilità di lavorare da sole. Non vedrai mai una spe utilizzata come cpu (mentre questo non è vero per i dsp, ad esempio).
Una PPE o ciascuno dei 3 core dello xenon possono lavorare da soli. Un spe no.

Conosco quei bench, ma non è che dicano molto; quelle della PPE non sono molto indicative come prestazioni di un'architettura altivec (ti ricordo che la ppe è di "derivazione" PPC).
Tra l'altro, ti faccio notare come, all'aumentare del numero di spe impiegati, le prestazioni tendano ad appiattirsi (già a partire, praticamente, da 3 spe in poi).

Poi, per carità, il mondo è bello perchè è vario; prendo mio nonno, gli consento un accesso alla memoria che tenga conto dell'arteriosclerosi, customizzo un SO in base al tasso di colesterolo e al diabete, e lo faccio funzionare come cpu del "sistema Casa". :D

No, perchè il calcolo vettoriale è uno dei possibili campi applicativi di quel microprocessore e di quella macchina.

........

Non sn convinto che per il Cell si possano fare gli stessi discorsi ( naturalmente vedremo perchè IBM sta tentando di infilarli un pò ovunque :D)...anche perchè IBM stessa parla di Stream Processor...


Il Cell e' anche un ottimo streaming processor, probabilmente il migliore della sua classe.

IBM lo definisce Cell, nel nome c'è la sua natura. Ogni processore (inteso come Cell intero o come elemento interno), puo' essere una cella o appartenere ad una. Duqnue e' seriale o parallelo a seconda di come si decide.

ma è un range ristretto ad una GPP è questo il "problema".
In applicazioni dove il calcolo vettoriale sia massiccio, le elaborazioni che sfruttano l'FPU andrà benissimo ( ecco le simulazioni scientifiche), ma per es. in applicazioni che dialogano frequentemente con dispositivi esterni ( quindi in I/O) io la vedo fortemente penalizzata.
così come in applicazioni web-oriented non avrà senso utilizzarlo, per gestire moli di dati come nei nei database e nei file-server nemmeno ( dato che si utilizzano praticamente solo gli interi)...

Vedremo irisultati dei bench, potrebbero riservare sorprese. Non mi aspetto nulla di che, ma ho l'impressione che lo sottovalutiate un po' troppo.

ti sei risposto da solo; se non devono (e non possono) star da sole, allora non sono cpu (ma semplicemente processori). Questo no perchè debbano lavorare in sinergia per avere la sufficiente potenza di calcolo, ma perchè non hanno la possibilità di lavorare da sole. Non vedrai mai una spe utilizzata come cpu (mentre questo non è vero per i dsp, ad esempio).
Una PPE o ciascuno dei 3 core dello xenon possono lavorare da soli. Un spe no.

Conosco quei bench, ma non è che dicano molto; quelle della PPE non sono molto indicative come prestazioni di un'architettura altivec (ti ricordo che la ppe è di "derivazione" PPC).
Tra l'altro, ti faccio notare come, all'aumentare del numero di spe impiegati, le prestazioni tendano ad appiattirsi (già a partire, praticamente, da 3 spe in poi).


Qui sbagli, volendo possono essere indipendenti (parola di IBM). Comunque non farmi difendere un qualcosa che poco sostengo, io li chiamo TUTTI processori, esattamente come fa IBM. La definizione di CPU a mio avviso, scemerà con il tempo.

Come puoi leggere nei post successivi, ho detto anche che si puo' incappare in fenomeni di "PPE-limited", dunque l'ho notato eccome. ;)
Il fatto della VMX, l'ho detto solo perche' nell'atro thread, qualcuno paragonava gli SPE a delle VMX rivisitate. E chiaramente non e' esattamente la definizione piu' appropriata.
Comunque sì, per ora 'sti bench vogliono dire poco.

"The PowerPC core present in the system is a general-purpose 64-bit PowerPC processor that handles the Cell BE's general-purpose workload (or, the operating system) and manages special-purpose workloads for the SPEs."

http://www-128.ibm.com/developerworks/library/pa-celldmas/

Le SPE non potranno essere mai indipendenti dalla PPE, almeno per come sono ora, in quanto il recupero delle eccezioni avvenute nelle SPE è demandato alla PPE... Sono indipendenti fra loro, ma non dalla PPE...

Qui sbagli, volendo possono essere indipendenti (parola di IBM). Comunque non farmi difendere un qualcosa che poco sostengo, io li chiamo TUTTI processori, esattamente come fa IBM. La definizione di CPU a mio avviso, scemerà con il tempo.


dipende cosa si intende per indipendenti; sfido chiunque, IBM compresa, a mettere su un sistema che abbia un senso (che sia tale da farsi preferire ad altri che svolgono lo stesso lavoro), che abbia uno o più spe come cpu.
In quanto alla definizione "cpu", non vedo perchè debba perdersi. I sistemi multiprocessore non sono una novità, anzi, per essere pignoli, non lo sono neppure quelli multi-cpu. Ora, il fatto che si abbiano più processori sullo stesso die, non sposta di una virgola la cosa.
Il cell non è destinato a rivoluzionare la terminologia informatica (e a detta di Mark Rein, l'evoluzione non va neppure in direzione degli stream processor).
CPU ha un significato ben preciso, non applicabile ad un spe.


Come puoi leggere nei post successivi, ho detto anche che si puo' incappare in fenomeni di "PPE-limited", dunque l'ho notato eccome. ;)
Il fatto della VMX, l'ho detto solo perche' nell'atro thread, qualcuno paragonava gli SPE a delle VMX rivisitate. E chiaramente non e' esattamente la definizione piu' appropriata.
Comunque sì, per ora 'sti bench vogliono dire poco.

dal punto di vista dell'architettura della pipeline, la differenza tra un spe e un'unità altivec non è abissale. Nel cell, però, parte della complessità di un sistema di tipo "controller+unità di calcolo", è stato spostato su queste ultime che quindi non sono delle semplici unità vettoriali (ma neppure delle cpu).

Secondo me questo 3d non finirà mai! :D
Giungerà il successore del cell :sofico: ma sarete ancora quì a discutere di questa cosa :D ne sono certo!

Con i motori fila, ma questi sono processori.

a mio parere se fila per i motori, fila anche per i processori...


Il Cell e' stato ideato per un ampio utilizzo, anzi, ampissimo!! Sicuramente molto piu' di quando non lo sia un X86. Dunque, almeno a logica, e' piu' GP. :)

a logica...ma è la tua logica, non una logica assodata ed universale, perchè parti dall'ipotesi ( per te certa) che i Cell siano stati progettati per una serie di scopi/calcoli addirittura superiore agli X86.

Ed essere ideati per un qlc significa aspettarsi prestazioni decenti nel momento in cui il processore elabora quel tipo di dati.
Come ho detto prima, la 500 su una pista di F1 ci và solo che ci mette n volte il tempo di una macchina da F1 e quindi si può dire senza problemi che NON è pensata per quel tipo di corse ( e nessun tipo di corse :D).


Faccio presente inoltre un'altra questione, forse puntigliosa ma IMHo significativa.
Un prodotto può essere realizzato per un certo scopo, per un certo target, questo non significa poi che all'atto della commercializzazione e delle prove su strada si riveli efficiente/adatto a soddisfare le idee di partenza.

Faccio un parallelo con un processore che ha, secondo me + di qlc in comune con il Cell.
L'Itanium ( di cui tutti sanno la storia) nasce con l'intento di rivoluzionare il mondo dell'informatica, dal pdv dell'HW, dal pdv delle prestazioni ma dal pdv mi verrebbe da dire quasi filosofico, perchè l'obiettivo era in principio quello di costruire la CPU universale, adatta a qls scopo e per qls macchina.

Gli obiettivi prefissati da Intel sn falliti miseramente e l'IA64 si è rivelata un'architettura molto performante per certi compiti, molto poco per tanti altri ( sui desktop n si è mai vista praticamente, nel calcolo degli interi è quanto mai debole così come lo è il Cell ed è stato surclassato dagli X86...è estremamente presente nei grossi cluster che eseguono simulazioni per es. metereologiche o cmq che si sobbarcano notevoli quantità di calcoli in floating point).
Se vai a scartabellare i vari documenti tra white papers, drafts dell'Intel troverai svariati nomi o terminologie utilizzate per identificare l'itanium e l'IA64; sta di fatto che la pratica ha dimostrato che non è una CPU utilizzabile in un range elevato di campi se si vuole avere un rapporto costo/efficienza vantaggioso.


Che un Kernel tradizionale non giri ottimamente su una SPE (ma su 8??) è solo un limite che potrebbe essere superato con SO studiati appositamente. Questo lo vedremo tutti, piu' avanti.


io francamente continuo a dubitare assai che vedremo SO "ad hoc" in gran quantità sul Cell e figuriamoci su una singola SPE, per il semplice fatto che un applicativo di questo tipo non beneficerebbe anzi al contrario sarebbe inficiato da una simile architettura.
Su un'architettura penalizzata dall'esecuzione out-of-order e da accessi frequenti di tipo I/O, men che meno, non ha senso progettare programmi complessi e universali ( nel senso che fanno e permettono di svolgere n tipi di task differenti) come un SO.
Sarebbe troppo costoso dal pdv della progettazione ( mi riferisco al lato SW) e non appagante in termini di prestazioni, tale da far perdere all'SO le caratteristiche intrinseche per es. di reattività o modularità...

Se poi per kernel si intende il "subdivisional" kernel sviluppato per la GPU che sgrava la CPU in alcune fasi di elaborazione ( come la computazione di alcuni algoritmi e la parallellizzazione nel rendering delle varie mesh) ok è un kernel anche quello.
Ma n credo lo vedrai mai utilizzato per farci girare un SO ;)


Aspetta, qui mi devi trovare dove IBM dichiari la dipendenza vincolante degli SPE rispetto alla PPE. Non esiste. Sono microprocessori indipendenti con tutte le caratteristiche del caso (quelle che hai quotato poco fa ed altre..).

ok domani dò un'occhiata ;)


Indipendenti in nessuna lingua vuol dire "indipendenti, ma fino ad un certo punto :D".
Se poi vuoi dirmi che per lavorare bene necessitino della PPE, beh, questo sono mesi che lo sostengo anche io, cosi'come la PPE per lavorare bene necessita degli SPE.

per essere proprio precisi dal pdv semantico, indipendenti vuol dire non dipendere da nessuno, poi però se si contestualizza l'aggettivo il significato può ( anzi deve, spesso, almeno parzialmente) essere rivisto.
Gli Stati sn indipendenti ma poi nei fatti _dipendono_ da organizzazioni sovranazionali da cui n possono staccarsi per la sopravvivenza (economica) dello Stato stesso.


Come ci ha detto nAo che ci lavora, possono (volendo, ma perche' volerlo??) essre totalmente indipendenti.
Anzi, ti diro' di piu', lavorando in streaming possono rivelarsi anche PPE limited (per ora, con codici non ottimizzati ed in taluni casi), dunque e' ovvio pensare che la loro possibilita' di lavorare indipendentemente sia e rarà discretamente utilizzata (come già accade infatti).

infatti sn e saranno utilizzati per lavorare indipendentemente l'uno dall'altro, ciascuno si occuperà per es. di un thread ma ciò non significa che ciascuno delle SPE potrà far girare per es. un sistema operativo.
Ed in ogni caso l'indipendenza delle SPE è garantita dalla PPE.

Per quanto riguarda limited o non limited io non ho ancora visto una riga di codice fatta girare su un Cell, quindi n saprei dire esattamente quando lo è, in che misura e in che tipo di elaborazioni...forse tu sì e quindi ne sai di + :)


Quanto al concetto di CPU, non fatemi scrivere mille volte le stesse cose. Un microprocessore e' una vastità di cose che non puo' essere definito in alcun modo "convenzionale", dunque se IBM parla di processore (o microprocessore) con differenze da uno convenzionale, intende chiaramente riferirsi ad una CPU standard.

Scusa ma per microprocessore si intende un'ampia varietà di "pezzi di silicio".
Per CPU no, deve avere delle caratteristiche intrinseche che non sn imprescindibili, rivoluzione o meno che si ricerchi.
ALU, MMU, protezione della memoria, set di istruzioni e via avanti...

Quando IBM parla di SPE, dal nome stesso indica un'unità di elaborazione dedicata a compiti particolare, che non è quindi una CPU "standard" o "convenzionale" o "General Purpose" o come la vuoi chiamare.
Non è una CPU.

altrimenti l'avrebbero chiamate GPP non SPE.

"The PowerPC core present in the system is a general-purpose 64-bit PowerPC processor that handles the Cell BE's general-purpose workload (or, the operating system) and manages special-purpose workloads for the SPEs."

http://www-128.ibm.com/developerworks/library/pa-celldmas/

Le SPE non potranno essere mai indipendenti dalla PPE, almeno per come sono ora, in quanto il recupero delle eccezioni avvenute nelle SPE è demandato alla PPE... Sono indipendenti fra loro, ma non dalla PPE...

QQueste sono tue speculazioni, io ve l'ho fatto leggere dal sito IBM, sono tutti indipendenti e specializzati a modo loro. C'e' una mutua dipendenza per un corretto e buon funzionamento. E' ovvio che la PPE nel 90% dei casi (forse piu') gestira' i pacchetti di lavoro degli SPE, ma questo non fa degli SPE processori dipendenti dalla PPE.

dipende cosa si intende per indipendenti; sfido chiunque, IBM compresa, a mettere su un sistema che abbia un senso (che sia tale da farsi preferire ad altri che svolgono lo stesso lavoro), che abbia uno o più spe come cpu.
In quanto alla definizione "cpu", non vedo perchè debba perdersi. I sistemi multiprocessore non sono una novità, anzi, per essere pignoli, non lo sono neppure quelli multi-cpu. Ora, il fatto che si abbiano più processori sullo stesso die, non sposta di una virgola la cosa.
Il cell non è destinato a rivoluzionare la terminologia informatica (e a detta di Mark Rein, l'evoluzione non va neppure in direzione degli stream processor).
CPU ha un significato ben preciso, non applicabile ad un spe.

Allora diciamo cosi', IBM utilizza gli stessi sotantivi per SPE e PPE. Poi fai tu. ;)
In ogni caso, se il futuro no e' streaming processor, bene, il Cell si chiama cosi' perche' funziona a celle, non lavorera' in streaming e via. :)


dal punto di vista dell'architettura della pipeline, la differenza tra un spe e un'unità altivec non è abissale. Nel cell, però, parte della complessità di un sistema di tipo "controller+unità di calcolo", è stato spostato su queste ultime che quindi non sono delle semplici unità vettoriali (ma neppure delle cpu).

Non sono nulla. :)

Secondo me questo 3d non finirà mai! :D
Giungerà il successore del cell :sofico: ma sarete ancora quì a discutere di questa cosa :D ne sono certo!

Sai che mi chiedo come sara' il successore del Cell?? (sempre che che venga fatto!!)

a mio parere se fila per i motori, fila anche per i processori...
a logica...ma è la tua logica, non una logica assodata ed universale, perchè parti dall'ipotesi ( per te certa) che i Cell siano stati progettati per una serie di scopi/calcoli addirittura superiore agli X86.
Ed essere ideati per un qlc significa aspettarsi prestazioni decenti nel momento in cui il processore elabora quel tipo di dati.
Come ho detto prima, la 500 su una pista di F1 ci và solo che ci mette n volte il tempo di una macchina da F1 e quindi si può dire senza problemi che NON è pensata per quel tipo di corse ( e nessun tipo di corse :D).
Faccio presente inoltre un'altra questione, forse puntigliosa ma IMHo significativa.
Un prodotto può essere realizzato per un certo scopo, per un certo target, questo non significa poi che all'atto della commercializzazione e delle prove su strada si riveli efficiente/adatto a soddisfare le idee di partenza.

..o una F1 usata in città. :)

Faccio un parallelo con un processore che ha, secondo me + di qlc in comune con il Cell.
L'Itanium ( di cui tutti sanno la storia) nasce con l'intento di rivoluzionare il mondo dell'informatica, dal pdv dell'HW, dal pdv delle prestazioni ma dal pdv mi verrebbe da dire quasi filosofico, perchè l'obiettivo era in principio quello di costruire la CPU universale, adatta a qls scopo e per qls macchina.
Gli obiettivi prefissati da Intel sn falliti miseramente e l'IA64 si è rivelata un'architettura molto performante per certi compiti, molto poco per tanti altri ( sui desktop n si è mai vista praticamente, nel calcolo degli interi è quanto mai debole così come lo è il Cell ed è stato surclassato dagli X86...è estremamente presente nei grossi cluster che eseguono simulazioni per es. metereologiche o cmq che si sobbarcano notevoli quantità di calcoli in floating point).
Se vai a scartabellare i vari documenti tra white papers, drafts dell'Intel troverai svariati nomi o terminologie utilizzate per identificare l'itanium e l'IA64; sta di fatto che la pratica ha dimostrato che non è una CPU utilizzabile in un range elevato di campi se si vuole avere un rapporto costo/efficienza vantaggioso.

Scusami, ma l'itaniom ha poco a che spartire con un Cell, vedremo se IBM sa fare le cose meglio di Intel, sinceramente io ho pochi dubbi al riguardo. :)


io francamente continuo a dubitare assai che vedremo SO "ad hoc" in gran quantità sul Cell e figuriamoci su una singola SPE, per il semplice fatto che un applicativo di questo tipo non beneficerebbe anzi al contrario sarebbe inficiato da una simile architettura.
Su un'architettura penalizzata dall'esecuzione out-of-order e da accessi frequenti di tipo I/O, men che meno, non ha senso progettare programmi complessi e universali ( nel senso che fanno e permettono di svolgere n tipi di task differenti) come un SO.
Sarebbe troppo costoso dal pdv della progettazione ( mi riferisco al lato SW) e non appagante in termini di prestazioni, tale da far perdere all'SO le caratteristiche intrinseche per es. di reattività o modularità...

Se poi per kernel si intende il "subdivisional" kernel sviluppato per la GPU che sgrava la CPU in alcune fasi di elaborazione ( come la computazione di alcuni algoritmi e la parallellizzazione nel rendering delle varie mesh) ok è un kernel anche quello.
Ma n credo lo vedrai mai utilizzato per farci girare un SO ;)

Non credo nemmeno io vedremo SO su SPE, non l'ho nemmeno mai ritenuto probabile, nè utile (poi si vedra'). Si puo' fare, non ho detto come, anzi ho sempre scherzosamente detto "io non lo consiglierei". :)
In ogni caso, io aspetterei (aspetto) i risultati concreti prima di parlare.
La differenza tra me e te (e chi la pensa come te), sta nel mio non dare per assodate determinate questioni che potranno solo essere valutate con dei bench approfonditi. Quanto ad impressioni, beh, siamo tutti d'accordo, uno SPE non e' certamente il massimo per far girare Windows (uno a caso :D).


per essere proprio precisi dal pdv semantico, indipendenti vuol dire non dipendere da nessuno, poi però se si contestualizza l'aggettivo il significato può ( anzi deve, spesso, almeno parzialmente) essere rivisto.
Gli Stati sn indipendenti ma poi nei fatti _dipendono_ da organizzazioni sovranazionali da cui n possono staccarsi per la sopravvivenza (economica) dello Stato stesso.
infatti sn e saranno utilizzati per lavorare indipendentemente l'uno dall'altro, ciascuno si occuperà per es. di un thread ma ciò non significa che ciascuno delle SPE potrà far girare per es. un sistema operativo.
Ed in ogni caso l'indipendenza delle SPE è garantita dalla PPE.

Ad essere precisi, indipendente vuol dire indipendente. :) :mc: :p


Per quanto riguarda limited o non limited io non ho ancora visto una riga di codice fatta girare su un Cell, quindi n saprei dire esattamente quando lo è, in che misura e in che tipo di elaborazioni...forse tu sì e quindi ne sai di + :)

Ci sono dei bench, ma nulla di concreto.

Scusa ma per microprocessore si intende un'ampia varietà di "pezzi di silicio".
Per CPU no, deve avere delle caratteristiche intrinseche che non sn imprescindibili, rivoluzione o meno che si ricerchi.
ALU, MMU, protezione della memoria, set di istruzioni e via avanti...

Quando IBM parla di SPE, dal nome stesso indica un'unità di elaborazione dedicata a compiti particolare, che non è quindi una CPU "standard" o "convenzionale" o "General Purpose" o come la vuoi chiamare.
Non è una CPU.
altrimenti l'avrebbero chiamate GPP non SPE.

Allora la PPE si chiama GPE o GPP?? :)

Ma tralasciamo questo dettaglio, andiamo al sodo.. "CPu vuol dire ..ecc. ha certi requisiti.. ecc.. non ha un vasto numero di significati come "microprocessore".. ariecc.." Dunque?? Aiutami tu a capire. :)
Loro hanno detto che differisce da un microprocessore tradizionale per taluni fatti, dunque cosa e' un microprocessore "tradizionale"?? :) Non venirmi a dire un DSP, una VPU o simili, perché sai bene che non sta né incielo né in terra. Sono architetture ben differenti che non possono essere prese come puto di riferimento.
Per tanto se quella frase non vuol dire ""Uno SPE, si differenzia da una CPU (o da un processore come PPE X86 ecc) convenzionale per le seguenti ragioni.. ecc." che altro puo' voler dire??
Non credo proprio vi siano altri significati. :)

P.S. Cerca di non frammentare troppo i post!! Grazie. :)

Questo da arstechnica.com:

http://arstechnica.com/articles/paedia/cpu/cell-1.ars/2

The actual architecture of the Cell SPE is a dual-issue, statically scheduled SIMD processor with a large local storage (LS) area. In this respect, the individual SPUs are like very simple, PowerPC 601-era processors.


The SPE's ISA, which is not VMX/Altivec-derivative (more on this below), includes instructions for using the DMA controller to move data between main memory and local storage. The end result is that each SPE is like a very small vector computer, with its own "CPU" and RAM.

http://arstechnica.com/articles/paedia/cpu/cell-2.ars

The basic architecture of the Cell is described by IBM as a "system on a chip" (SoC) design. This is a perfectly good characterization, but I'd take it even further and call Cell a "network on a chip." As I described yesterday, the Cell's eight SPUs are essentially full-blown vector "computers," insofar as they are fairly simple CPUs with their own local storage.

:) Mi sento sempre meno visionario. :p


Ci sono anche delle considerazioni riguardo il discorso del GP, lo consigilo a chi e' interessato all'argomento.

Se non dovesse bastarvi nemmeno questo, che dirvi.. Mi arrendo!! Ma felice di essere in buona compagnia con il resto del mondo. :)

QQueste sono tue speculazioni, io ve l'ho fatto leggere dal sito IBM, sono tutti indipendenti e specializzati a modo loro. C'e' una mutua dipendenza per un corretto e buon funzionamento. E' ovvio che la PPE nel 90% dei casi (forse piu') gestira' i pacchetti di lavoro degli SPE, ma questo non fa degli SPE processori dipendenti dalla PPE.
No...veramente la questione delle eccezioni era presentata nella documentazione postata da cdimauro dall'ISA del Cell...che forse a questo punto non hai letto...

Sinceramente quello che dicono altri siti non mi interessa...anche perchè credo che il livello di preparazione delle persone che ti hanno risposto in queste pagine sia veramente alto (e bada non solo uno ti ha dato ragione)...e di fatto le risposte sono autorevoli almeno quanto quello di un review di arstechnica (che per altro di castronerie ne ha scritte)...

Comunque riguardo al primo quote da Arstechnica:

The actual architecture of the Cell SPE is a dual-issue, statically scheduled SIMD processor with a large local storage (LS) area. In this respect, the individual SPUs are like very simple, PowerPC 601-era processors.

Le SPE sono "simili a molto semplici" PowerPC 601...però ovviamente ci sono differenze notevoli: le SPE sono ottimizzate per il calcolo vettoriale e non sono processori indipendenti (tant'è che nei testi IBM vengono presentate come SIMD unit, Vector processor, ma mai come CPU)...

The SPE's ISA, which is not VMX/Altivec-derivative (more on this below), includes instructions for using the DMA controller to move data between main memory and local storage. The end result is that each SPE is like a very small vector computer, with its own "CPU" and RAM.

Che non fa che confermare la mia tesi...se le chiamano Vector Computer di fatto la definiscono una unità Special Purpose... Riguardo a "its own "CPU" and RAM": a parte che CPU è fra apici e già questo può far pensare "chiamo la SPU CPU, ma non sono CPU", ma il discorso che vogliono tirare fuori è che l'SPU svolge nelle SPE il ruolo che la CPU svolge all'interno di un computer... In pratica vendendo la SPE come un computer a sè stante (ma non lo è, ma come visione di insieme ci può stare) la SPU è pragonabile al ruolo centrale della CPU, e la Ram locale a quello della ram di sistema... Quindi niente a suffragare la tua tesi che le SPE siano CPU...visto che al massimo CPU possono essere definite le SPU, ma solo rispetto al sistema SPE... SPU che comunque non sono indipendenti dalla PPE...
Stesso discorso per il secondo quote...il discorso è lo stesso che hanno tentato di fare sopra...

Ferma e perentoria rimane comunque la serie ci cazzate dette a sproposito riguardo Processing/Processor.

Miei cari professoroni e grandi professionisti.. non ci avete capito un °&$% e sfottete pure chi non vi da retta. Capisco sempre di più il perché questo forum scarseggi di professionisti.

Chiuderei con un sentitissimo ringraziamento al correttidssimo e democraticissimo cionci, che sostiene (in PVT) che saremmo stati da sospendere entrambi (io e cdi, quest'ultimo, guarda caso, non e' però mai stato nemmeno ripreso), tuttavia, ad un certo punto senza avvertimento, ha deciso che il primo che avesse usato termini non di suo gradimento (per altro non ho offeso, ho solo fatto una domanda che scaturiva da un mio lecito dubbio), sarebbe stato la vittima!!
Beh, che dire, molto giusto no?? come è giusto che non siano stati sospesi (né mai nemmeno “redarguiti”) taluni idioti che piazzavano post solo palesemente per sfottere (dimmi cionci, questo lo consente il regolamento??) senza aver la più pallida cognizione dell'argomento trattato, solo per simpatia.
Qualora per il futuro non farai mantenere l'ordine e non userai lo stesso peso per TUTTI, sposterò l'argomento su forum più democratici, senza aspettare che terminino cinque giorni (5 mi sembrano il minimo per ciò che ho detto rispondendo ai toni di tutti gli altri [se solo avessi saputo che loro possono ed io no!! però dillo no?? o non sei corretto nemmeno in questo??]).

A voi la fantasiosa risposta. :) Tanto so che ne inventerete una.
Sì, dico soltanto che cionci lo devi ringraziare per averti dato soltanto 5 giorni, ma soprattutto per averti graziato visto appena sei tornato hai ripreso immediatamente a insulatare la gente di questo forum (vedi parti evidenziate). Come se non ti fossero bastati tutti i precedenti insulti:
Dove sta scritto che e' una CPU?? hum.. :bimbo:

Ho capito il tuo errore carissimo fek, anziché metterti a fare fastidiosissime (ed alquanto offensive) tratuzioni con annessa errata interpretazione, vai un po' a studiare perche' la tua ignoranza e' seconda solo alla tua arroganza.

un errore da nubbino, che capita a chi non ha mai aperto quel manuale in vita sua se non per fare ora il saputello.

Studia va, che poi ti interrogo.

@cdimauro, tranquillo, ti rispondo, anche se non so a questo punto quanto sia necessario, ti sei risposto da solo e non ti sei nemmeno capito.

-Non qui, su un altro forum, dunque?? devo pure farti un disegnino??

Non mi piace perdere tempo con chi parla senza ascoltare, nè ha voce in capitolo e fa il saputello.

Uè, forse e' meglio che tu vada a dormire come hai detto e facciamo finta che tu non abbia mai detto una simile fregnaccia.

Se te lo vai a cercare, sotto troverai la spiegazione del perche' quanto hai detto sia una grandissima cavolata.

A te si devono fare i disegnini (cosi' poi li colori con il gatto )

se non sai leggere o eviti di farlo, sono solo problemi tuoi

Risparmiati certi commenti idioti, fa' la cortesia.

Per il resto, se non ti vorgogni tu di dare dell'ignorante al mondo intero, io potrei non vergognarmi nemmeno di andare in giro con un cesso in testa.

tutto quello che ho detto ed avvalorato con decine di link (che tu non potrai mai portare, perche' dici minchiate), e' tutto sbagliato??

Pensi che il tuo sia cosi' perfetto ed assoluto da escludere automaticamente quello di tutti gli altri?? Patetico.

forse e' ora che lasci il posto ai giovani con mente piu' aperta.

Non mi meraviglia vedere che non hai capito nulla di cio' che ho detto. Non ho mai detto cazzate simili che saltellano come conigli solo nella tua testa.

Quello e' un elenco di puttanate fatte da qualcuno che avrebbe potuto compilare la lista della spesa.
Mi fa piacere vedere che tu sia d'accordo con quanto detto da quel pazzo. Non mi stupisce.

Forse perche' non hai capito nemmeno questa.

Le tue capacita di comprensione sono ridotte all'osso, fai uso di droghe??

Non dire minchiate

Prova a consultare uno psicologo, puo' aiutarti.

Io se fossi in te mi butterei sull'oroscopo che "forse" lo capisci meglio.

Come gia' detto non penso tu possa capire o scendere dal tuo piedistallo immaginario.
Cionci sa come la penso, e per questo abbiamo avuto non poche discussioni "pepate": è troppo buono e 5 giorni di sospensione dopo tutto quello che hai combinato in un solo thread per me sono anche pochi (la sfilza di cui sopra è stata pesantemente sfoltita: ho messo soltanto le offese e gli insulti più pesanti).

Comunque visto che la sospensione non t'è servita a molto e che continui a insultare e offendere la gente, la prossima volta chiederò una punizione esemplare nei tuoi confronti. Così magari tornerai a frequentare soltanto i tuoi "democraticissimi" forum coi tuoi amici moderatori che fanno il bello e il cattivo tempo, in barba ai regolamenti e alle stesse cose che scrivono.

Forse no hai letto bene tutto il post. Io sin dall'inizio ho comunque sempre detto che gli SPE non sono ottimi per far girare un OS tradizionale!!
Diciamo che NON possono farlo funzionare.
Per quanto riguarda il disgroso GP, beh, c'e' scritto abbastanza sul mio post, non credo si debba aggiungere altro.
Oltre al fatto che hai detto che le SPE sono CPU, salvo poi dire l'esatto contrario, ti faccio notare che sempre in questo thread hai definito le SPE contemporaneamente CPU GP (general purpose) e CPU SP (special purpose).

La Storia Infinita :D

Mi sembrano chiari, dicono che gli SPE possono far tutto quello che fanno le CPU convenzionali (ma tramite DMA). Come diceva nAo (ed io) non c'e' differenza alcuna se si usa il DMA (anzi..).
Falso. Infatti dal documento che hai riportato, IBM dice questo questo:

"The SPEs are independent processors, each running its own individual application programs. Each SPE has full access to coherent shared memory, including the memory-mapped I/O space. The designation synergistic for this processor was chosen carefully -- there is a mutual dependence between the PPE and the SPEs."

Quindi le SPE possono eseguire programmi applicativi: in sostanza, delle normale applicazioni. NON dei s.o.. Tant'è nei documenti di IBM quando si parla di sistema operativo, non si fa mensione al fatto che possa girare su una SPE, ma al contrario, viene presentanto come qualcosa "al di fuori" delle SPE.

A ciò aggiungiamo anche questo:

"The SPUs are less complex computational units than PPEs, in that they do not perform any system management function.

subject to any access properties set up by a PPE

The IIC component manages the priority of the interrupts presented to the PPEs.

Any SPU that encounters an illegal instruction immediately halts program execution, records the event in its status register, and requests an external interrupt. The illegal-instruction interrupt should be enabled and routed to a PPE.

The exceptions also cause an exception interrupt to be generated and sent to a PPE.

The SPU has the following restrictions:
• No direct access to main storage (access to main storage using MFC facilities only)
• No distinction between user mode and privileged state
• No access to critical system control such as page-table entries (this restriction should be enforced by
PPE privileged software).
• No synchronization facilities for shared local storage access

If the translation is not found in the hardware-accessed page table because of a page or mapping fault, a data storage interrupt (DSI) for the PPE or an interrupt for the SPE is posted to the PPE.

Each SPE has a set of interrupt registers for masking the interrupting condition, holding the status of the interrupting conditions, and routing the interrupt to a PPE or other device in the system.

an SPE interrupt condition causes an interrupt to be routed to a PPE or other device"

Quindi le SPE non sono affatto indipendenti, checché tu ne dica: senza PPE non vanno da nessuna parte.

Certo fino a quando non ci mettiamo a ripetere le stesse cose...me compreso ;)
Abbiamo già esposto le nostre tesi...ora si tratta solo di dare ragione a l'uno o l'altro...ma tanto è impossibile, quindi tanto vale chiudere questa diatriba...
Non vedo come possa pretendere di avere ragione, se è lui stesso che si smentisce con le stesse cose che riporta.

Diciamo che vuole avere l'ultima parola a tutti i costi e basta, anche di fronte al fatto che IBM stessa gli dà torto.

Sono le tue ad essere favolette: il DMA è un componente che introduce una certa LATENZA, visto che dev'essere programmato, avviato, e aspettare il completamento dell'operazione (per accedere ai dati, nel caso di richiesta di lettura; per poter riusare il buffer in memoria locale in caso di scrittura).

scusami cdmauro se riprendo un tuo vecchio intervento, ma vorrei capire questa cosa del dma.

Insomma sui documenti IBM c'è scritto che il DMA è stato inserito proprio per ovviare a delle latenze di migliaia di cicli per l' accesso alla memoria come riportato qui:

The result is that application performance is often limited by memory latency rather than peak compute capability or peak bandwidth. When a sequential program on a conventional architecture performs a load instruction that misses in the caches, program execution now comes to a halt for several hundred cycles. Compared with this penalty, the few cycles it takes to set up a DMA transfer for an SPE is quite small. Even with deep and costly speculation, conventional processors manage to get at best a handful of independent memory accesses in flight. The result can be compared to a bucket brigade in which a hundred people are required to cover the distance to the water needed to put the fire out, but only a few buckets are available.

e qui:

The local store organization introduces another level of memory hierarchy beyond the registers that provide local storage of data in most processor architectures. This is to provide a mechanism to combat the “memory wall,” since it allows for a large number of memory transactions to be in flight simultaneously without requiring the deep speculation that drives high degrees of inefficiency on other processors. With main memory latency approaching a thousand cycles, the few cycles it takes to set up a DMA command becomes acceptable overhead to access main memory

Ora tu sostieni invece che l' accesso diretto alla memoria è più veloce di quello del DMA. Ora io non ne capisco molto ma....

Chi ha ragione? :confused:

Se e' per questo si puo' risalire anche ai computer 6800 based. :)
Solo che un 6800 è tranquillamente in grado di far girare un s.o., ma una SPE (da sola) no.
Se giri un po' per il sito IBM vedrai i tempi ed i cicli necessari e ti accorgerai che non sono poi cosi' male. In fine ti invito a trovare la definizione "CPU" all'interno di tutto quel documento. Ti aiuto, non la trovi. :)
Per quella definizione non c'è problema, visto che l'hai fornita tu:

"Ognuno puo' far girare le proprie applicazioni. Dunque sono delle CPU."

Solo che, come ti ho già detto, con questa definizione anche il Copper diventa magicamente una CPU.

A proposito: me lo vuoi dire sì o no, se per te il Copper è una CPU? Una risposta chiara e senza giri di parole, cortesemente.

Semplicemente perche' gli SPE non sono stati creati per lavorare senza PPE,
Quindi DIPENDONO dalla PPE.
duqnue sono processori indipendenti,
No, dunque sono processori DIPENDENTI (dalla PPE).
con "serie" carenze da alcuni punti di vista che non comportano alcun problema perche', appunto, non devono lavorar da sole.
Quindi sono processori DIPENDENTI (dalla PPE).

Con i motori fila, ma questi sono processori. Il Cell e' stato ideato per un ampio utilizzo, anzi, ampissimo!! Sicuramente molto piu' di quando non lo sia un X86. Dunque, almeno a logica, e' piu' GP. :)
Un processore GP è un processore che presenta delle buone prestazioni davanti a tutti i tipi di codice che si trova a macinare.

Cell, invece, è un processore sbilanciato: ha delle scarse prestazioni in generale, ma eccelle nei calcoli di tipo streaming. Quindi è una CPU specializzata.
Che un Kernel tradizionale non giri ottimamente su una SPE (ma su 8??) è solo un limite che potrebbe essere superato con SO studiati appositamente. Questo lo vedremo tutti, piu' avanti.
C'è poco da vedere: non conosco s.o. che non gestiscano eccezioni. LE SPE NON SONO IN GRADO DI GESTIRE DELLE ECCEZIONI. Quindi NON POSSONO far girare un s.o.
Aspetta, qui mi devi trovare dove IBM dichiari la dipendenza vincolante degli SPE rispetto alla PPE. Non esiste.
Te l'ho già scritta nell'altro messaggio.
Sono microprocessori indipendenti con tutte le caratteristiche del caso (quelle che hai quotato poco fa ed altre..). Indipendenti in nessuna lingua vuol dire "indipendenti, ma fino ad un certo punto :D".
Infatti dai documenti di IBM è scritto chiaramente che le SPE dipendono dalla PPE. Quindi non sono indipendenti, ma dipendenti.
Se poi vuoi dirmi che per lavorare bene necessitino della PPE, beh, questo sono mesi che lo sostengo anche io, cosi'come la PPE per lavorare bene necessita degli SPE.
No, perché non è questione di lavorare bene o male: le SPE PER LAVORARE hanno bisogno della PPE. Senza PPE non potrebbero lavorare né bene né male.
Come ci ha detto nAo che ci lavora, possono (volendo, ma perche' volerlo??) essre totalmente indipendenti.
I documenti di IBM affermano l'esatto contrario, invece.
Anzi, ti diro' di piu', lavorando in streaming possono rivelarsi anche PPE limited (per ora, con codici non ottimizzati ed in taluni casi), dunque e' ovvio pensare che la loro possibilita' di lavorare indipendentemente sia e rarà discretamente utilizzata (come già accade infatti).
Infatti NON esiste questa possibilità di lavorare indipendentemente: senza PPE non vanno da nessuna parte.
Quanto al concetto di CPU, non fatemi scrivere mille volte le stesse cose.
Infatti l'hai scritto una sola volta, e ci rientra perfettamente il Copper. Solo che definire il Copper una CPU è una bestemmia.
Un microprocessore e' una vastità di cose che non puo' essere definito in alcun modo "convenzionale", dunque se IBM parla di processore (o microprocessore) con differenze da uno convenzionale, intende chiaramente riferirsi ad una CPU standard.
E le SPE non ci rientrano, appunto.

La Storia Infinita :D
Per forza: continua sempre con sola solfa, quando IBM stessa lo smentisce.

Tra un po' chiederà all'Accademia della Crusca di cambiare anche il significato di "indipendente" pur di farsi ragione.

Ora tu sostieni invece che l' accesso diretto alla memoria è più veloce di quello del DMA. Ora io non ne capisco molto ma....

Chi ha ragione? :confused:
Dipende dalle situazioni normali di utilizzo...un accesso tramite DMA ha una latenza inziale nettamente maggiore (setup del controller DMA)...ed è l'ideale quando si lavora a blocchi (vettori), quindi le SPE pagano una latenza iniziale molto alta, ma quando hanno i dati nella memoria embedded vanno molto forte... Al contrario un accesso per locazione in vector processor avrebbe poco senso...in quanto le latenze, seppur più basse di quella iniziale per il DMA, si sommerebbero ad ogni locazione richiesta...

Inoltre un accesso diretto alla memoria da parte delle unità SPE avrebbe creato non pochi problemi...prima di tutto di concorrenza... E' più facile gestire l'accesso alla memoria di 8 master che trasferiscono a blocchi, rispetto ad 8 master che accedono alla memoria "a locazione"...in quanto ci sono un numero nettamente più basso di richieste/sec...

Il problema di latenza nell'accesso alla ram di sistema delle CPU comunque è stato risolto ormai da anni con i vari livelli di cache...con cui c'è un buona possibilità di avere un dato pronto in un ciclo di clock... Se il dato non c'è anche in questo caso il recupero dalla ram di sistema (e l'eventuale scrittura) avviene a blocchi...

scusami cdmauro se riprendo un tuo vecchio intervento, ma vorrei capire questa cosa del dma.

Insomma sui documenti IBM c'è scritto che il DMA è stato inserito proprio per ovviare a delle latenze di migliaia di cicli per l' accesso alla memoria come riportato qui:

e qui:

Ora tu sostieni invece che l' accesso diretto alla memoria è più veloce di quello del DMA. Ora io non ne capisco molto ma....

Chi ha ragione? :confused:
La questione è molto semplice: non IBM parla di accesso diretto alla memoria in quel contesto, ma di accesso alla memoria (quindi generale), e in questo parla di ciò che normalmente avviene, ossia del fatto che quando si deve effettuare un accesso alla memoria, prima di ottenere il dato è necessario attendere diversi cicli di clock (per il processore).

Che l'accesso diretto alla memoria sia più veloce di quello tramite DMA è ovvio, e semplice da dimostrare.
Nel caso del Cell, se la PPE deve accedere alla memoria, lo fa direttamente senza programmare nessun canale DMA.
Le SPE invece devono programmare il DMA per fare la stessa cosa. Programmare il DMA significa impiegare un certo numero di cicli di clock per riempire i suoi registri e far partire infine l'operazione vera e propria.
E' chiaro che la PPE si trova in vantaggio, perché non perde cicli di clock per quest'operazione.

EDIT: cionci è stat ancora più chiaro. :p

Ora tu sostieni invece che l' accesso diretto alla memoria è più veloce di quello del DMA. Ora io non ne capisco molto ma....

Chi ha ragione? :confused:

Hanno ragione entrambi.

L'idea molto furba delle SPE e' quella di fornire al compilatore un modello di latenze uniforme, per aiutarlo nello schedulare le istruzioni, in quanto ogni SPU e' un'unita' di esecuzione in-order.

Facciamo un esempio in pseudo-assembly. Immagina di avere la sequenza di istruzioni:

1) load x, [addr]
2) y = x + 1
3) z = 0

E' una sequenza molto semplice. Quanto dura in termini di colpi di clock ogni istruzione? In un modello classico dove l'istruzione load causa un accesso alla memoria mediato da una cache la risposta e' non si sa, dipende. Se la cella all'indirizzo addr e' in cache interna dura pochi colpi di clock, se e' nella cache esterna dura di piu', se e' in memoria centrale puo' durare un centinaio e piu' colpi di clock, se e' stata parcheggiata su hard disk puo' durare milioni di colpi di clock. Un compilatore non puo' saperlo. Infatti l'unita' out-of-order cerca di riordinare le istruzioni di modo da eseguire qualcos'altro mentre la load finisce.

L'SPU e' un'unita' in-order, non per costrizione, ma per scelta progettuale: vuole essere semplice e risparmiare i transistor per mettere piu' unita' di esecuzione e velocizzare algoritmi fortemente paralleli. Ma allo stesso tempo non vuole incorrere nel problema di doversi fermare sulla load per un tempo indefinito prima di poter eseguire un'altra istruzione (tralascio il fatto che puo' eseguire due thread contemporaneamente in questo momento). L'SPU non ha e non vuole avere la logica che capisce che 3) e' indipendente da 1) quindi puo' essere eseguita subito dopo senza attendere che finisca la load nel registro x.

Allora l'idea furba: l'SPU puo' solo accedere alla memoria locale, la quale garantisce che ogni accesso alla memoria locale terminera' dopo un determinato numero di colpi di clock (mi sembra tre nel Cell sulla PS3 ma cito a memoria). Il compilatore conosce questo numero e quando compila l'esempio di cui sopra sa che dopo 1) il valore di x sara' valido dopo 3 colpi di clock, sempre e comunque. Allora il compilatore sa che puo' spostare l'istruzione 3) fra 1) e 2), perche' e' indipendente dalle altre istruzioni, e presenta all'SPU la seguente sequenza di istruzioni:

1) load x, [addr]
3) z = 0
2) y = x + 1

Questa sequenza e' piu' veloce della prima perche' 3) viene eseguita mentre 1) sta aspettando che la memoria locale restituisca il valore richiesto. Nota come in questo caso la logica per capire che l'istruzione seguente non dipende dalla load e' banale, mentre sarebbe molto complesso dover analizzare il flusso di istruzioni ancora da eseguire per andare a cercare tutte quelle istruzioni che non sono dipendenti e poi riordinare i risultati alla fine (classica architettura out-of-order).

Ecco che grazie al fatto che l'SPU non puo' accedere alla memoria centrale, il compilatore e' ora in grado di prevedere le latenze e schedulare le istruzioni di modo da velocizzare l'esecuzione, l'SPU rimane in-order, risparmia transistor, e se ne possono avere un numero maggiore, le prestazioni rimangono alte perche' la logica di riordino delle istruzioni e' spostata in software sul compilatore piuttosto che in hardware nelle SPU.

La memoria locale e' caricata e scaricata via DMA da memoria centrale.

Svantaggi? Questa architettura non e' adatta ad algoritmi che lavorano su un ampio working set con accessi random oppure non facilmente parallelizzabili (classici algoritmi GP), perche' si ritroverebbe a spendere piu' tempo a programmare il DMA per caricare la memoria locale con dati sparsi che ad eseguire calcoli. E' un missile sui tipici algoritmi in campo multimediale, dove i dati su cui eseguire i calcoli arrivano in streaming ed escono in streaming.

Ho cercato di semplificare il discorso e sono stato un po' impreciso qua e la', ma spero che il concetto sia chiaro.

Hanno ragione entrambi.

L'idea molto furba delle SPE e' quella di fornire al compilatore un modello di latenze uniforme, per aiutarlo nello schedulare le istruzioni, in quanto ogni SPU e' un'unita' di esecuzione in-order.

Facciamo un esempio in pseudo-assembly. Immagina di avere la sequenza di istruzioni:

1) load x, [addr]
2) y = x + 1
3) z = 0

E' una sequenza molto semplice. Quanto dura in termini di colpi di clock ogni istruzione? In un modello classico dove l'istruzione load causa un accesso alla memoria mediato da una cache la risposta e' non si sa, dipende. Se la cella all'indirizzo addr e' in cache interna dura pochi colpi di clock, se e' nella cache esterna dura di piu', se e' in memoria centrale puo' durare un centinaio e piu' colpi di clock, se e' stata parcheggiata su hard disk puo' durare milioni di colpi di clock. Un compilatore non puo' saperlo. Infatti l'unita' out-of-order cerca di riordinare le istruzioni di modo da eseguire qualcos'altro mentre la load finisce.

L'SPU e' un'unita' in-order, non per costrizione, ma per scelta progettuale: vuole essere semplice e risparmiare i transistor per mettere piu' unita' di esecuzione e velocizzare algoritmi fortemente paralleli. Ma allo stesso tempo non vuole incorrere nel problema di doversi fermare sulla load per un tempo indefinito prima di poter eseguire un'altra istruzione (tralascio il fatto che puo' eseguire due thread contemporaneamente in questo momento). L'SPU non ha e non vuole avere la logica che capisce che 3) e' indipendente da 1) quindi puo' essere eseguita subito dopo senza attendere che finisca la load nel registro x.

Allora l'idea furba: l'SPU puo' solo accedere alla memoria locale, la quale garantisce che ogni accesso alla memoria locale terminera' dopo un determinato numero di colpi di clock (mi sembra tre nel Cell sulla PS3 ma cito a memoria). Il compilatore conosce questo numero e quando compila l'esempio di cui sopra sa che dopo 1) il valore di x sara' valido dopo 3 colpi di clock, sempre e comunque. Allora il compilatore sa che puo' spostare l'istruzione 3) fra 1) e 2), perche' e' indipendente dalle altre istruzioni, e presenta all'SPU la seguente sequenza di istruzioni:

1) load x, [addr]
3) z = 0
2) y = x + 1

Questa sequenza e' piu' veloce della prima perche' 3) viene eseguita mentre 1) sta aspettando che la memoria locale restituisca il valore richiesto. Ecco che grazie al fatto che l'SPU non puo' accedere alla memoria centrale, il compilatore e' ora in grado di prevedere le latenze e schedulare le istruzioni di modo da velocizzare l'esecuzione, l'SPU rimane in-order, risparmia transistor, e se ne possono avere un numero maggiore, le prestazioni rimangono alte perche' la logica di riordino delle istruzioni e' spostata in software sul compilatore piuttosto che in hardware nelle SPU.

La memoria locale e' caricata e scaricata via DMA da memoria centrale.

Svantaggi? Questa architettura non e' adatta ad algoritmi che lavorano su un ampio working set con accessi random oppure non facilmente parallelizzabili (classici algoritmi GP), perche' si ritroverebbe a spendere piu' tempo a programmare il DMA per caricare la memoria locale con dati sparsi che ad eseguire calcoli. E' un missile sui tipici algoritmi in campo multimediale, dove i dati su cui eseguire i calcoli arrivano in streaming ed escono in streaming.

Ho cercato di semplificare il discorso e sono stato un po' impreciso qua e la', ma spero che il concetto sia chiaro.


ok grazie mille, ho capito

grazie comunque anche a cdmauro e cionci! :)

ps Fek ho un' altra domanda:
con campo multimediale intendi anche qualche cosa inerente la grafica nei videogiochi?

ok grazie mille, ho capito

grazie comunque anche a cdmauro e cionci! :)

Di nulla :)

Per queste cose il Cell e' adorabile da programmare: immagina di avere un flusso di vertici da trasformare prima di mandarli alla GPU per il rendering. Puoi programmare un SPE per prendere una rappresentazione parametrica della geometria (tipo NURBS), carichi in memoria locale la rappresentazione e sputi fuori vertici che scarichi in DMA sulla memoria locale dell'SPE successiva. L'SPE successiva prende i vertici, prende magari una displacement map, sposta i vertici calcolati dalla SPE precedente e li passa in DMA all'SPE ancora successiva che magari li proietta e li passa gia' proiettati alla GPU che li renderizza. Magari la displacement map arriva da una simulazione di fluidodinamica calcolata su una o piu' altre SPE.

Mentre un SPE processa un gruppo di vertici, passa via DMA il gruppo precedente giu' per la catena di montaggio. E' un esempio, in questo caso ogni SPE avrebbe abbastanza banda per eseguire tutti i calcoli in loco, ma rende l'idea di quello che ci si puo' fare :D

(E rende l'idea di quello che ci sto facendo :P).

Di nulla :)

Per queste cose il Cell e' adorabile da programmare: immagina di avere un flusso di vertici da trasformare prima di mandarli alla GPU per il rendering. Puoi programmare un SPE per prendere una rappresentazione parametrica della geometria (tipo NURBS), carichi in memoria locale la rappresentazione e sputi fuori vertici che scarichi in DMA sulla memoria locale dell'SPE successiva. L'SPE successiva prende i vertici, prende magari una displacement map, sposta i vertici calcolati dalla SPE precedente e li passa in DMA all'SPE ancora successiva che magari li proietta e li passa gia' proiettati alla GPU che li renderizza. Magari la displacement map arriva da una simulazione di fluidodinamica calcolata su una o piu' altre SPE.

Mentre un SPE processa un gruppo di vertici, passa via DMA il gruppo precedente giu' per la catena di montaggio. E' un esempio, in questo caso ogni SPE avrebbe abbastanza banda per eseguire tutti i calcoli in loco, ma rende l'idea di quello che ci si puo' fare :D

(E rende l'idea di quello che ci sto facendo :P).


:eek:
oh cappero :D

Ma come difficoltà di programmazione cosa mi puoi dire?

:eek:
oh cappero :D

Ma come difficoltà di programmazione cosa mi puoi dire?

Non e' una passeggiata al parco.

Non e' una passeggiata al parco.


Potresti quantificare il vantaggio che ha il cell, come supporto alla GPU, rispetto alla XeCPU?
E nella simulazione fisica?

Potresti quantificare il vantaggio che ha il cell, come supporto alla GPU, rispetto alla XeCPU?
E nella simulazione fisica?

A questo stadio dare numeri sarebbe davvero fuori luogo. Risposta diplomatica piuttosto che dire che non ne ho la piu' pallida idea.

A questo stadio dare numeri sarebbe davvero fuori luogo. Risposta diplomatica piuttosto che dire che non ne ho la piu' pallida idea.


Dicevo approssimativamente.. :p

C'è perlomeno qualcosa che ti piace della XeCPU oppure la consideri proprio una chiavica? Prendendo a paragone le più veloci cpu per pc con cui hai lavorato, ad esempio.

Dicevo approssimativamente.. :p

C'è perlomeno qualcosa che ti piace della XeCPU oppure la consideri proprio una chiavica? Prendendo a paragone le più veloci cpu per pc con cui hai lavorato, ad esempio.

Al momento propendo verso la 'chiavica'.

Al momento propendo verso la 'chiavica'.

Bella cpu allora! :sofico:

Sicuramente il Cell ha una marcia in più per quanto riguarda la fisica e i calcoli geometrici, Xenon avrà sì tre core dual threaded, ma in quanto a potenza vettoriale è sicuramente inferiore al concorrente. Ma immagino che dove non arriverà la CPU, subentrerà la GPU che è a quanto pare un gioiellino mica male (e credo che non a caso ATI si sia interessata al calcolo fisico su GPU).
quello che mi preoccupa è invece la gestione di tutto ciò che non è possibile mandare in streaming, come l'AI, ecc. Se già Xenos tende verso la "chiavica" (ma ha 3 core, anche se in order, con 1 mega di cache condivisa, ecc., un minimo di parallelismo potrà essere sfruttabile) immagino che la singola PPE di Cell tenderà verso la "chiavica^2" :D pur avendo un pò più di cache a disposizione per il singolo core, ma dovendo essere occupata a smistare anche il lavoro alle SPE.
Non a caso, penso, Nintendo per il Revolution ha scelto di privilegiare una CPU meno esasperata in termini di parallelismo ma con prestazioni un pò più elevate della concorrenza in termini di calcoli sul singolo thread.

Hanno ragione entrambi.

L'idea molto furba delle SPE e' quella di fornire al compilatore un modello di latenze uniforme, per aiutarlo nello schedulare le istruzioni, in quanto ogni SPU e' un'unita' di esecuzione in-order.

Facciamo un esempio in pseudo-assembly. Immagina di avere la sequenza di istruzioni:

1) load x, [addr]
2) y = x + 1
3) z = 0

E' una sequenza molto semplice. Quanto dura in termini di colpi di clock ogni istruzione? In un modello classico dove l'istruzione load causa un accesso alla memoria mediato da una cache la risposta e' non si sa, dipende. Se la cella all'indirizzo addr e' in cache interna dura pochi colpi di clock, se e' nella cache esterna dura di piu', se e' in memoria centrale puo' durare un centinaio e piu' colpi di clock, se e' stata parcheggiata su hard disk puo' durare milioni di colpi di clock. Un compilatore non puo' saperlo. Infatti l'unita' out-of-order cerca di riordinare le istruzioni di modo da eseguire qualcos'altro mentre la load finisce.

L'SPU e' un'unita' in-order, non per costrizione, ma per scelta progettuale: vuole essere semplice e risparmiare i transistor per mettere piu' unita' di esecuzione e velocizzare algoritmi fortemente paralleli. Ma allo stesso tempo non vuole incorrere nel problema di doversi fermare sulla load per un tempo indefinito prima di poter eseguire un'altra istruzione (tralascio il fatto che puo' eseguire due thread contemporaneamente in questo momento). L'SPU non ha e non vuole avere la logica che capisce che 3) e' indipendente da 1) quindi puo' essere eseguita subito dopo senza attendere che finisca la load nel registro x.

Allora l'idea furba: l'SPU puo' solo accedere alla memoria locale, la quale garantisce che ogni accesso alla memoria locale terminera' dopo un determinato numero di colpi di clock (mi sembra tre nel Cell sulla PS3 ma cito a memoria). Il compilatore conosce questo numero e quando compila l'esempio di cui sopra sa che dopo 1) il valore di x sara' valido dopo 3 colpi di clock, sempre e comunque. Allora il compilatore sa che puo' spostare l'istruzione 3) fra 1) e 2), perche' e' indipendente dalle altre istruzioni, e presenta all'SPU la seguente sequenza di istruzioni:

1) load x, [addr]
3) z = 0
2) y = x + 1

Questa sequenza e' piu' veloce della prima perche' 3) viene eseguita mentre 1) sta aspettando che la memoria locale restituisca il valore richiesto. Nota come in questo caso la logica per capire che l'istruzione seguente non dipende dalla load e' banale, mentre sarebbe molto complesso dover analizzare il flusso di istruzioni ancora da eseguire per andare a cercare tutte quelle istruzioni che non sono dipendenti e poi riordinare i risultati alla fine (classica architettura out-of-order).

Ecco che grazie al fatto che l'SPU non puo' accedere alla memoria centrale, il compilatore e' ora in grado di prevedere le latenze e schedulare le istruzioni di modo da velocizzare l'esecuzione, l'SPU rimane in-order, risparmia transistor, e se ne possono avere un numero maggiore, le prestazioni rimangono alte perche' la logica di riordino delle istruzioni e' spostata in software sul compilatore piuttosto che in hardware nelle SPU.

La memoria locale e' caricata e scaricata via DMA da memoria centrale.

Svantaggi? Questa architettura non e' adatta ad algoritmi che lavorano su un ampio working set con accessi random oppure non facilmente parallelizzabili (classici algoritmi GP), perche' si ritroverebbe a spendere piu' tempo a programmare il DMA per caricare la memoria locale con dati sparsi che ad eseguire calcoli. E' un missile sui tipici algoritmi in campo multimediale, dove i dati su cui eseguire i calcoli arrivano in streaming ed escono in streaming.

Ho cercato di semplificare il discorso e sono stato un po' impreciso qua e la', ma spero che il concetto sia chiaro.

aggiungo solo qualcosa su DMA e dintorni.
Quando si fa accesso tramite DMA, si invia una richiesta d'accesso ad un controller (che in molti sistemi è integrato sulla cpu). Il controller valuta la coda di richieste e stabilisce le priorità di accesso, quindi invia le autorizzazioni. A questo punto, la periferica o il sottosistema può accedere alla ram per effettuare le operazioni per cui è stato autorizzato. L'alternativa è aspettare che la cpu prelevi i dati dalla ram e li invii al sottosistema destinatario.
Nel cell, un spe può attivare autonomamente un dma, ossia una richiesta di invio dati, ma la stessa è valutata da un controller (posto all'esterno sia degli spe che della ppe), che fornisce le relative autorizzazioni d'accesso. Solo dopo aver ricevuto l'autorizzazione, il spe può accedere alla ram.
Ho fatto questa precisazione perchè ho avuto la sensazione, magari sbagliata, che qualcuno abbia interpretato il dma come una modalità d'accesso assimilabile a quella di una cpu (ad esempio di tipo x86).
Con questo approccio, il problema delle latenze difficili da quantificare si sposta a livello di invio delle richieste, accessi e ricezione dati. Una volta che si ha accesso, però, è possibile riempire la cache locale e lavorare con latenze note (inoltre l'MFC lavora in maniera indipendente dalla spu, una volta che sono state riempite le code delle richieste di accesso)
Infine, la gestione degli accessi in ram avviene in modalità OoO

Fino a qlc tempo fà, prima che uscissero svariati formati vantaggiosi dal punto di vista del rapporto qualità ( o perdita di informazione se la vogliamo leggere dall'altro lato)/ Memoria secondaria allocata, nessuno si metteva col proprio pc ad encodare film, a rippare i propri cd audio, a fare del videoediting con i filmati catturati da varie sorgenti.
Le CPU fondamentalmente sn rimaste le stesse ( certo, sn aumentate le istruzioni, sn aumentate le pipeline e via avanti...); sempre X86 sono.
Oppure...nessuno si sarebbe sognato che per le simulazioni ad alto livello, nel supercomputing si sarebbero utilizzati processori che utilizza la casalinga per guardare il sito della propria banca da casa.
Eppure da qlc anno si usano e con successo, all'interno di cluster ovviamente, ma di quei processori stiamo parlando.


Non sn convinto che per il Cell si possano fare gli stessi discorsi ( naturalmente vedremo perchè IBM sta tentando di infilarli un pò ovunque :D)...anche perchè IBM stessa parla di Stream Processor...
concordo con quasi tutto quello che hai scritto, ma le cose secondo me sono destinate a evolversi.. allo stato attuale hai pienamente ragione, ma io credo che ci sarà un'evoluzione come ci è stata per l'x86! si tratta di ripensare le applicazioni in modo che possano essere efficienti sull'architettura del Cell... vabbè è un pò presto per dirlo, ma penso che sia uno scenario possibile! poi di sicuro ci saranno campi di applicazioni critici in cui non eccellerà (come ci sono anche per l'x86), ma questo si compenserà nel tempo con la crescita della potenza di calcolo (come ha fatto l'x86 nei suoi settori critici)! non so, magari mi sbaglio clamorosamente :D!

Ma hai dei benchmark sotto mano che io non ho ancora vito?? :-/
secondo me, una moto da MotoGP se la usi per fare il motocross ottieni delle prestazioni scandalose...
però purtroppo non ho i benchmark per dimostrarlo, che sfiga, eh?
;)

No...veramente la questione delle eccezioni era presentata nella documentazione postata da cdimauro dall'ISA del Cell...che forse a questo punto non hai letto...

Sinceramente quello che dicono altri siti non mi interessa...anche perchè credo che il livello di preparazione delle persone che ti hanno risposto in queste pagine sia veramente alto (e bada non solo uno ti ha dato ragione)...e di fatto le risposte sono autorevoli almeno quanto quello di un review di arstechnica (che per altro di castronerie ne ha scritte)...

Comunque riguardo al primo quote da Arstechnica:

The actual architecture of the Cell SPE is a dual-issue, statically scheduled SIMD processor with a large local storage (LS) area. In this respect, the individual SPUs are like very simple, PowerPC 601-era processors.

Le SPE sono "simili a molto semplici" PowerPC 601...però ovviamente ci sono differenze notevoli: le SPE sono ottimizzate per il calcolo vettoriale e non sono processori indipendenti (tant'è che nei testi IBM vengono presentate come SIMD unit, Vector processor, ma mai come CPU)...

The SPE's ISA, which is not VMX/Altivec-derivative (more on this below), includes instructions for using the DMA controller to move data between main memory and local storage. The end result is that each SPE is like a very small vector computer, with its own "CPU" and RAM.

Che non fa che confermare la mia tesi...se le chiamano Vector Computer di fatto la definiscono una unità Special Purpose... Riguardo a "its own "CPU" and RAM": a parte che CPU è fra apici e già questo può far pensare "chiamo la SPU CPU, ma non sono CPU", ma il discorso che vogliono tirare fuori è che l'SPU svolge nelle SPE il ruolo che la CPU svolge all'interno di un computer... In pratica vendendo la SPE come un computer a sè stante (ma non lo è, ma come visione di insieme ci può stare) la SPU è pragonabile al ruolo centrale della CPU, e la Ram locale a quello della ram di sistema... Quindi niente a suffragare la tua tesi che le SPE siano CPU...visto che al massimo CPU possono essere definite le SPU, ma solo rispetto al sistema SPE... SPU che comunque non sono indipendenti dalla PPE...
Stesso discorso per il secondo quote...il discorso è lo stesso che hanno tentato di fare sopra...

Per quanto riguarda le rispste varie, passo direttamente, sono presenti nel mio lungo post a pagina 30.

Ora invece ricapitolerei!!
Dunque, prima di tutto, dobbiamo segnalare ad IBM che si e' sbagliata a dire che gli SPE sono processori indipendenti, ci pensate voi?? :) Interessante la vostra teoria.

Alla fine nesusno e' ancora riuscito a spiegarmi cosa intenda IBM dicendo "The SPE differs from conventional microprocessors in a number of other ways".
Dunque che tipo di processore convenzionale è?? :)

Comuqnue ricapitolando:
Quelli di pcstats, dicono cazzate, quelli di blachford, dicono cazzate come quelli di realworldtech e di anandtech!! Aggiungiamoci dinox me e nAo ed in fine anche asetechnica. :) Ovviamente non scordiamo IBM che li definisce processori indipendenti e System on Chip.
In fine aggiungiamo questo:

DA

The Cell Processor
- A short Introduction -
Torsten Hoefler
[email protected]
28th November 2005

2.3 The Synergistic Processing Element The SPE is essentially a full blown vector CPU with own RAM. Its ISA is not compatible to VMX and has a fixed length of 32 Bit. Current SPEs have about 21 Million Transistors where 2/3 of them are dedicated to the SRAM (memory). The processor has no branch prediction or scheduling logic, and relies on the programmer/compiler to find parallelism in the code. As the PPE, it uses two independent.

Dunque se proprio non volete chiamare CPU uno SPE, come minimo lo e' una SPU (che addirittura non comprende nemmeno la MMU e l'MFC per comunicare con la MM :D ) e lo SPE ne comprende una.

Tutti a dire stupidagini. Oh, che dirvi.. buon per voi che capite la differenza tra processing e processor. :)

____

Per chi fosse interessato al discorso GP, ci sono diverse cose in merito nella documentazione.

The SPU architecture defines a set of 128 general-purpose registers (GPRs), each of which contains 128 data bits. Registers are used to hold fixed-point and floating-point data. Instructions operate on the full width of the register, treating it as multiple operands of the same format.

P.S. Sono la MMU e l'MFC a gestire la comunicazione con le memorie (tutte) ed a gestirne le code.

P.P.S. Poi se mi volete tornare a spiegare che i task sono ripartiti dalla PPE, lasciate perdere, so bene come funziona un Cell.

Per quanto riguarda le rispste varie, passo direttamente, sono presenti nel mio lungo post a pagina 30.
Solo che il tuo post è stato ampiamente smentito dalla stessa IBM.
Ora invece ricapitolerei!!
Dunque, prima di tutto, dobbiamo segnalare ad IBM che si e' sbagliata a dire che gli SPE sono processori indipendenti, ci pensate voi?? :) Interessante la vostra teoria.
No, IBM non s'è sbagliata e infatti gli SPE sono dei processori indipendenti... una volta che sono state programmate per lavorare autonomamente.

C'è qualcuno che passa il tempo dicendo agli altri di non decontestualizzare, ma questo qualcuno STRANAMENTE non si fa scrupoli a tirare fuori una frase isolata tralasciando TUTTO il resto.

I documenti di IBM sono chiari: le SPE per poter lavorare autonamente DIPENDONDO COMUNQUE DALLA PPE.
Alla fine nesusno e' ancora riuscito a spiegarmi cosa intenda IBM dicendo "The SPE differs from conventional microprocessors in a number of other ways".
Dunque che tipo di processore convenzionale è?? :)
Infatti NON sono processori convenzionali: basta leggere la frase.

E il perché lo puoi vedere dal messaggio in cui ho riassunto le caratteristiche per cui una SPE NON è in grado di far girare un s.o..

La prossima volta invece di ignorare i messaggi degli altri, dovresti leggerli e rispondere. Se sei in grado di farlo, ovviamente.
Comuqnue ricapitolando:
Quelli di pcstats, dicono cazzate,
Dicono delle cose inesatte se paragonano le SPE a delle CPU.
quelli di blachford,
Veramente è un solo tizio, che ha sparato tante di quelle cazzate da esser stato deriso da tutto il web.

Ma che ci possiamo fare: per te è più credibile lui che la stessa IBM.
dicono cazzate come quelli di realworldtech e di anandtech!! Aggiungiamoci dinox me e nAo ed in fine anche asetechnica. :)
Idem come sopra: le SPE non si possono paragonare alle CPU perché DIFETTANO DI ALCUNE FUNZIONALITA' CHE LE RENDANO TALI.

Come tu stesso hai detto, tra l'altro: vuoi per caso smentirti?
Ovviamente non scordiamo IBM che li definisce processori indipendenti
Sì, ma in quale contesto? Se prendi una frase e la decontestualizzi da TUTTO il discorso che fa IBM, arrivi ad affermare delle cose che non hanno senso.
e System on Chip.
Questo è un termine generico.
In fine aggiungiamo questo:

DA

The Cell Processor
- A short Introduction -
Torsten Hoefler
[email protected]
28th November 2005

2.3 The Synergistic Processing Element The SPE is essentially a full blown vector CPU with own RAM. Its ISA is not compatible to VMX and has a fixed length of 32 Bit. Current SPEs have about 21 Million Transistors where 2/3 of them are dedicated to the SRAM (memory). The processor has no branch prediction or scheduling logic, and relies on the programmer/compiler to find parallelism in the code. As the PPE, it uses two independent.

Dunque se proprio non volete chiamare CPU uno SPE, come minimo lo e' una SPU (che addirittura non comprende nemmeno la MMU e l'MFC per comunicare con la MM :D ) e lo SPE ne comprende una.
Per questo link vale la stessa cosa di quanto detto sopra. Infatti né la SPE né tanto meno la SPU possono essere definite CPU.

Certo, a meno che non applichiamo la TUA definizione di CPU, e allora ci rientra anche il Copper. A proposito: ma per te il Copper è una CPU, sì o no? Non hai ancora risposto...
Tutti a dire stupidagini.
Già. Definire CPU una SPE o addirittura una SPU, è una grande stupidaggine. Fortunatamente tu sei tornato sui tuoi passi, e hai detto che non lo sono: bravo!
Oh, che dirvi.. buon per voi che capite la differenza tra processing e processor. :)
Già. Si tratta soltanto di imparare a leggere l'inglese (tecnico).
____

Per chi fosse interessato al discorso GP, ci sono diverse cose in merito nella documentazione.

The SPU architecture defines a set of 128 general-purpose registers (GPRs), each of which contains 128 data bits. Registers are used to hold fixed-point and floating-point data. Instructions operate on the full width of the register, treating it as multiple operands of the same format.
:eek: Quindi se un dispositivo è dotato di un set di registri "general purpose" tu automaticamente lo definisci "general purpose". :rotfl: :rotfl: :rotfl:

Vabbé, fa niente: tanto tu stesso hai affermato che le SPE sono contemporaneamente CPU GP e CPU SP. Il che è tutto dire...
P.S. Sono la MMU e l'MFC a gestire la comunicazione con le memorie (tutte) ed a gestirne le code.
Per curiosità: mi sai dire chi è che imposta i descrittori di pagina usati da MMU e MFC?
P.P.S. Poi se mi volete tornare a spiegare che i task sono ripartiti dalla PPE,
Infatti lo sono.
lasciate perdere, so bene come funziona un Cell.
Se lo sai, allora com'è che continui ad affermare che le SPE sono "processori indipendenti"?

P.S. Secondo te il Copper è una CPU?

P.P.S. Ma secondo te il Copper è una CPU?

P.P.P.S. Stavo quasi per dimenticarmene: il Copper non sarà una mica una CPU, per come l'hai definita tu?

:eek: Quindi se un dispositivo è dotato di un set di registri "general purpose" tu automaticamente lo definisci "general purpose". :rotfl: :rotfl: :rotfl:

Vabbé, fa niente: tanto tu stesso hai affermato che le SPE sono contemporaneamente CPU GP e CPU SP. Il che è tutto dire...

Dritto dritto dall'API dell'R500:

SetShaderGPRAllocation();

Alloca i GPR fra vertex e pixel shader. Allora anche l'R500 e' una CPU General Purpose come il Copper! :rotfl:


P.P.S. Poi se mi volete tornare a spiegare che i task sono ripartiti dalla PPE, lasciate perdere, so bene come funziona un Cell.

Ne dubitiamo molto fortemente :)

dal seguente documento IBM

http://www-128.ibm.com/developerworks/power/library/pa-cellperf/

The approach taken by the Cell BE design was to focus on improving performance/area and performance/power ratios (see Introduction to the Cell Multiprocessor, listed in Resources. These goals are largely achieved by using powerful, yet simple cores that use area more efficiently with less power dissipation. Supported by an interconnect with high data bandwidth, these cores could work both independently and cooperatively. By supporting a large number of simultaneous memory accesses from the cores, the memory bandwidth can be used more efficiently as well. The design philosophy is somewhat similar to the recent trend of having multiple general-purpose cores in the same chip; in the Cell BE, all cores are just much simpler, yet still powerful.

somewhat, ovvero, "in qualche modo" (la cosa è specificata più avanti).

The PPE consists of a POWER Processing Unit (PPU) connected to a 512KB L2 cache. The PPE is the main processor of the Cell BE, and is responsible for running the operating system and coordinating the SPEs. The key design goals of the PPE are to maximize the performance/power ratio as well as the performance/area ratio. The PPU is a dual-issue, in-order processor with dual-thread support. A pipeline timing diagram, as detailed in Introduction to the Cell Multiprocessor (see Resources for a link), is shown in Figure 2.

The PPE core can fetch four instructions at a time, and issue two. In order to improve performance from its in-order pipeline, the PPE utilizes delayed-execution pipelines and allows limited out-of-order execution of load instructions. This allows the PPE to get some of the advantages of out-of-order execution without any significant increase in complexity. We do not focus on the PPE in this paper since most of the algorithms presented here do not utilize the PPE.



Quindi i 9 chip non sono considerati tutti alla stessa stregua (la cosa è evidente) e il PPE è processore principale (che può essere assimilato ad una cpu, fa girare il SO e coordina gli SPE).

The SPE is a modular design consisting of a Synergistic Processing Unit (SPU) and a Memory Flow Controller (MFC). An SPU is a compute engine with SIMD support and 256KB of dedicated local storage. The MFC contains a DMA controller with an associated MMU, as well as an Atomic Unit to handle synchronization operations with other SPUs and the PPU.

An SPU is a dual-issue, in-order machine with a large 128-entry, 128-bit register file used for both floating-point and integer operations. The SPU operates directly on instructions and data from its dedicated local store, and relies on a channel interface to access the main memory and other local stores. The channel interface, which is in the MFC, runs independently of the SPU and is capable of translating addresses and doing DMA transfers while the SPU continues with the program execution.

Qui la SPU è definita semplicemente some "motore di calcolo", altro che cpu!


Per quanto riguarda il dma ho spiegato nel post precedente come funziona. Il MFC attiva la richiesta (autonomamente), ma il consenso al trasferimento dati e la priorità sono fissati dal MIC che è un dispositivo esterno agli SPE e che funge da controller. In maniera simile a quanto avviene con il MC di R5x0, in cui lo stesso si occupa solo di ricevere le richieste di trasferimento dati e di indirizzarle verso l'area di ram interessata, mentre il trasferimento dati avviene senza l'ausilio del MC, ma utilizzando le sottostazioni denominate ring-stop (al contrario di un'architettura crossbar tradizionale, in cui il MC si occupa di gestire tutte le fasi di trasferimento dati).

Insomma, come logica vuole, esiste almeno un controller (in realtà ce n'è più di uno, mi pare evidente), che coordina il lavoro degli SPE; qualsiasi architettura o sottosistema che lavori in streaming o in parallelo o adottando entrambe le modalità, non può prescindere dalla presenza di almeno un arbiter (spesso più di uno). L'alternativa sarebbe quella di avere, facendo un paragone calcistico, una partita di calcetto, senza arbitro e allenatori, con 10 giocatori, ognuno dei quali gioca per proprio conto e senza regola alcuna. :D

Yoss, secondo te perche' l'R500 non e' in grado di allocarsi dinamicamente i GPR e devo specificarli io a mano per ogni batch? Non e' un problema da poco, perche' sbagliare l'allocazione mi ha significato anche un drop del 50% sulle prestazioni della singola batch. Hanno voluto risparmiare transistor oppure secondo te c'e' un problema piu' basilare?

Un'altra cosa molto curiosa dell'R500: i texture fetch in un vertex shader non filtrano la texture. Ora, vertex e fragment shader usano per ovvi motivi le stesse unita' di esecuzione e adesso perche' mi devo filtrare la texture a mano?

MA LOOOL non mi avevate avverito che è tornato con le sue fantasiose teorie! :rotfl:

Come e' giusto che accada quando un maestro insegna qualcosa, ecco che arriva l'allievo (il più sveglio di tutti) che gli fa coro e ripete la lezione!!


per questo una SPU è un "Processor" nel senso di "Processing Unit" ovvero unità atta ad eseguire calcoli, unità di processamento, ma non nel senso comunemente usato in italiano di "Processore", ovvero "Central Processing Unit" o "General Purpose Processor"


Dunque anche lui mi viene a spiegare cosa sia un processore. :) (menomale, avrei rischiato di rimanere ignorante..)

è normale... quando dici kose come queste:

Gli SPE sono delle CPU con delle limitazioni se paragonate ad altre (e delle agevolazioni se paragonate ad altre ancora, mi riallaccio e prendo per buono l'esempio ci VPU vista come CPU che tu hai riportato), ma sempre CPU rimangono.


Non ho mai sostenuto inoltre che uno SPE sia una CPU, non so se qualcuno qui dentro lo ha mai sostenuto,

si capisce tutta la tua confusione, e per questo mi sono sentito IN DOVERE di kiarificarti le idee! :O
ah... e già ke ci sei quotami dove ho chiamato l'SPE Synergistic Processing Element visto ke sei così bravo :asd:
Ed evito ovviamente di commentare il resto del post dato che sono cose già dette, ridette, dimostrate e stradimostrate....
se vuoi continuare il tuo :mc: fai pure.
in questo sei tu il maestro indiscusso!:ave:

:asd:

attenzione. Sul link postato da madrat c'è scritto che le spe non sono ottimizzate per farci girare un o.s. non che non è possibile farlo ;)
senza la PPE ke controlla tutto la SPE non fa una mazza...
è un semplice elemento passivo...
devo ancora fare l'esempio dell'interruttore che attiva una CPU???
quindi anche quello sarebbe una CPU secondo te dato che grazie alla sua attivazione escono fuori dei calcoli???:asd:

diciamo che anche la vostra parte qualche errore l' ha commesso ;)..anche voi a definirle synergistic PROCESSING elements quando sui documenti IBM (almeno quelli che hapostato mad) è synergistic PROCESSOR elements.. :)
sempre chiamato prcessor io fin dal primo psot...
al max mi potrebbe essere sfuggito una volta... non ricordo...
se proprio ci tieni rileggiti tutto e trova dove ho scritto processing :asd:

In questo anche IBM stessa ha qualche difficoltà :D
http://www-128.ibm.com/developerworks/library/pa-celldmas/
ok allora è pure inutile rileggere tutti i miei post! :sofico:

Se ci fossero dei Kernel con i quali questi si trovassero a proprio agio?? :) Poi GP non vuol dire "far girare un SO", mi sembra un po' riduttivo.
ancora sto aspettando che mi spieghi come fare girare anche "Hello world" o quello ke vuoi su una SPE SENZA PPE :asd:

con tutto il rispetto per quanto hai riportato, il termine "processore di tipo non convenzionale" non ha alcun senso. Si può classificare come processore qualunque dispositivo in grado di svolgere determinati task
anke il processore che funzionava con un trenino elettrico e dei binari che ho riportato prima era un CPU a tutti gli effetti secondo MadRat :O
:asd:

Fine pausa... a stasera :D

Yoss, secondo te perche' l'R500 non e' in grado di allocarsi dinamicamente i GPR e devo specificarli io a mano per ogni batch? Non e' un problema da poco, perche' sbagliare l'allocazione mi ha significato anche un drop del 50% sulle prestazioni della singola batch. Hanno voluto risparmiare transistor oppure secondo te c'e' un problema piu' basilare?



così, a occhio, direi che un circuito di allocazione dei GPR avrebbe complicato ulteriormente il chip; tieni conto anche delle scelte fatte sulle granularità dei dati in input (64 pixel), che vanno nella direzione del risparmio dei transistor in un chip la cui circuiteria di controllo è già piuttosto complessa.


Un'altra cosa molto curiosa dell'R500: i texture fetch in un vertex shader non filtrano la texture. Ora, vertex e fragment shader usano per ovvi motivi le stesse unita' di esecuzione e adesso perche' mi devo filtrare la texture a mano?

questo è piuttosto strano; non applicano nessun filtro? Neppure point sampling?

senza la PPE ke controlla tutto la SPE non fa una mazza...
è un semplice elemento passivo...
devo ancora fare l'esempio dell'interruttore che attiva una CPU???
quindi anche quello sarebbe una CPU secondo te dato che grazie alla sua attivazione escono fuori dei calcoli???:asd:

io ho solo fatto una precisazione, non attacca con me, puoi fare l'esperto quanto vuoi tanto io di sti argomenti non nè so niente, ho solo interpretato quello che c'è scritto sui documenti IBM.

ciao! :)

questo è piuttosto strano; non applicano nessun filtro? Neppure point sampling?

Semplice point sampling. Nessun filtro bilineare. Ma sara' strano eh?

sempre chiamato prcessor io fin dal primo psot...
al max mi potrebbe essere sfuggito una volta... non ricordo...
se proprio ci tieni rileggiti tutto e trova dove ho scritto processing :asd:

stavo parlando in generale, se ti sei sentito tirato in causa mi dispiace!

ciao!

Semplice point sampling. Nessun filtro bilineare. Ma sara' strano eh?

faccio una premessa. R500 ha alu unificate, ma i thread e i dati relativi a vertici e pixel sono tenuti separati all'interno del chip. Quindi gli unici "punti" di contatto sono gli arbiter presenti tra i vari gruppi di code di comandi e le alu.

Detto ciò, mi vengono in mente due spiegazioni:

1) l'arbiter che si occupa di ricevere le istruzioni dalle code relative a vertici e pixel e inviare comandi alle code relative ad alu e texture unit è stato programmato per ignorare le richieste di filtraggio, quando i comandi arrivano dalla coda relativa ai vertici (scelta, all'occorrenza, reversibile).
2) le unità che fanno texture fetch, quando il comando è relativo a istruzioni sui vertici, non sono le stesse che si occupano di fare texture fetch per i pixel (ossia si avrebbero 16 unità che fanno texture fetch+filtraggio per i pixel e 16 che fanno solo texture fetch e point sampling per i vertici, come avviene, attualmente, per le 8 tmu dei vs di G70).

A occhio direi la soluzione 1). Se io imposto il sampler per farmi il bilinear filtering di un texture fetch nel vertex shader mi e' bellamente ignorato, non riporta alcun errore. Altrimenti quale ragione ci sarebbe per duplicare le texture unit? Non c'e' traccia di questo nella documentazione.

A occhio direi la soluzione 1). Se io imposto il sampler per farmi il bilinear filtering di un texture fetch nel vertex shader mi e' bellamente ignorato, non riporta alcun errore. Altrimenti quale ragione ci sarebbe per duplicare le texture unit? Non c'e' traccia di questo nella documentazione.

anche io propendo per la prima (anche se prima non ho dato le percentuali :D ).

anche io propendo per la prima (anche se prima non ho dato le percentuali :D ).

Pero' adesso mi devi spiegare il senso di questa eventuale decisione :D

io ho solo fatto una precisazione, non attacca con me, puoi fare l'esperto quanto vuoi tanto io di sti argomenti non nè so niente, ho solo interpretato quello che c'è scritto sui documenti IBM.

ciao! :)
era una dovuta precisazione...
scusa x le risate ma me le ha tirate l'andazzo generale del thread ke ormai è andato a "belle donne" :D

MA LOOOL non mi avevate avverito che è tornato con le sue fantasiose teorie! :rotfl:
è normale... quando dici kose come queste:
si capisce tutta la tua confusione, e per questo mi sono sentito IN DOVERE di kiarificarti le idee! :O
ah... e già ke ci sei quotami dove ho chiamato l'SPE Synergistic Processing Element visto ke sei così bravo :asd:
Ed evito ovviamente di commentare il resto del post dato che sono cose già dette, ridette, dimostrate e stradimostrate....
se vuoi continuare il tuo :mc: fai pure.
in questo sei tu il maestro indiscusso!:ave:

Dopo la figura che avete fatto con tutta la pappa riguardo la differenza tra processing e processor, per spiegare a me e ad altri la differenza tra SPE e processore, come minimo dovreste seppellirvi. :)
Ma non credo lo capiate, ne stiamo ridendo ancora su tre forum (non ti dico da quando state cercando di spiegare che indipendente non vuol dire indipendente!!). :D

@Yoss:
Ovvio che ci sia un organo apposito allo smistamento, non puo' non esserci, ma si deve tenere anche in considerazione l'efficenza di questo e la trasparenza del suo operato.
So perfettamente la dipendenza che c'e' tra SPE ed PPE.
IBM dice chiaramente in molti passaggiche la PPE dipende dagli SPE quando questi dipendono dalla PPE (ovviamente per ragioni differenti, ognuno e' favorito in determinate situazioni come e' logico che sia), ma questo non fa automaticamente dellla PPE un elemento non indipendente.
Penso che dopo avervi fatto leggere dalla IBM setssa che :
"The Synergistic Processing Element The SPE is essentially a full blown vector CPU with own RAM".."The processor has no branch prediction or scheduling logic, and relies on the programmer/compiler to find parallelism in the code. As the PPE, it uses two independent", dopo che vi ho fatto leggere che sono INDIPENDENTI, che la sezione DMA assolve agli stessi compiti di colloquio con la memoria che svolge una CPU tradizionale (a proposito, ancora non mi e' stato spiegato cosa intende IBM per CPU tradizionale), che possono essere programmati come comuni processori ecc. Non penso di dover aggiungere altro.
Quello che secondo voi non lo rende processore (o a questo punto "essenzialmente una CPU vettoriale") indipendente, evidentemente non vale per IBM e per tutti i siti che hanno recensito questo processore. Che dirvi, tanto di cappello per la vostra superioprita'. :)

Oggi aggiungo un'altra nutirta serie di ignorantoni che m copiano!! :)

http://www.gamepower.com.au/?aid=2386

Cell has one conventional Power PC-based core processor that essentially acts as a controller, serving tasks to the SPEs. The SPEs are not co-processors: each SPE is a completely independent vector CPU

Come vedete le cose possono andare di pari passo, non e' difficile da comprendere.

Sì, sì, lo so, chi ha mai sentito gamepaower.. ecc..


http://lowendmac.com/musings/05/0309.html

In fact, the heart of the Cell is distributed processing. Each Cell processor has a dual-threaded core processing unit and eight single-threaded attached processing units (APUs), and the Playstation 3 is expected to incorporate four Cell processors.

APUs are independent vector processors, and their work is distributed and coordinated by the core processing unit. Each APU has 256 KB of dedicated memory, 128 128-bit registers, four FPUs, and four integer units.

And it gets better. The APUs can be configured to stream a process, which means that when one APU has completed its calculations, it hands off the data to the next APU to perform the next step in the process. These steps can also be distributed to two or more APUs.

Anche loro non sono nessuno, lo so, ma capiscono che anche quando (praticamente sempre) coordinate da una PPE, possono essere comunque CPU indipendenti.

Guardate che scrivono questi dementi qui!! (ma tanto sono ignoranti..)

http://www.blachford.info/computer/Cell/Cell3_v2.html

"In this scenario job assignment is controlled by the PPE but other schemes have the SPEs running a tiny OS which allows it to assign itself jobs"

"SPEs can multitask like normal CPUs and have running tasks switch in and out but this is not an entirely good idea as the context switch time is likely to be pretty horrendous - the entire state of the SPE needs to be saved, this includes not just the contents of the registers but also the entire local store"

Poi..

http://everythingapple.blogspot.com/2005/02/cell-and-apple.html

"In essence, this Cell chip is a new and lean PowerPC chip with Altivec support, and a bunch of non-Altivec vector CPUs tacked onto it (each with its own local memory), all connected by a very fast bus"

Chiarito anche che non sono delle VMX evolute come fek va in giro a dire per altri thread (una gran boiata), a poveri utenti che giustamente definiscono il gli SPE come vuole IBM, ovvero "processori indipendenti (o vector CPU)", inventando terminologie astruse che IBM nemmeno si e' mai sognata di scrivere.

Che altro dire.. :)

Buona fortuna, avete da correggere il mondo. :)

P.S. Sì, fek, l'R500 per alcuni versi e' assimilabile ad una CPU, ovviamente non come uno SPE.

Buona fortuna, avete da correggere il mondo. :)

No, solo te che quoti roba che ti da' torto e non te ne accorgi :D

Powered by Gugul (c)


P.S. Sì, fek, l'R500 per alcuni versi e' assimilabile ad una CPU, ovviamente non come uno SPE.

:rotfl:

No, solo te che quoti roba che ti da' torto e non te ne accorgi :D

Powered by Gugul (c)



:rotfl:


fek, tralasciando le polemiche, dici che nel link che ha riportato madrat questo pezzo se lo siano inventato di sana pianta?

One method described by Sony uses the SPEs to do programmer defined Jobs [Jobs] . Each job is put into a queue, when an SPE becomes free the next job in line is assigned to that SPE for execution. In this scenario job assignment is controlled by the PPE but other schemes have the SPEs running a tiny OS which allows it to assign itself jobs. The SPEs are then completely autonomous and operate with no guidance from the PPE at all. The PPE just puts jobs into the job queue. Jobs are self contained mini-programs, the SPE loads up the data, DMAs in the data and gets computing.

Non voglio assolutamente fare polemica, chiedo solo per comprendere meglio la cosa :)

Non voglio assolutamente fare polemica, chiedo solo per comprendere meglio la cosa :)

E' molto simile all'esempio che feci qualche pagina fa sull'R500 sul quale posso scrivere un pixel shader che fa da scheduler per schedulare altri pixel shader sfruttando il memexport. Questo lo rende una CPU? Ovviamente no, perche' ha sempre e comunque bisogno di qualcuno che dia la partenza, come le SPE: una volta fatte partire dalla PPE e' possibile scrivere del codice che si auto-schedula il lavoro, ma, ad esempio, in caso si verificasse un'eccezione tornerebbe il controlla alla PPE (ovvero la CPU).

E' molto simile all'esempio che feci qualche pagina fa sull'R500 sul quale posso scrivere un pixel shader che fa da scheduler per schedulare altri pixel shader sfruttando il memexport. Questo lo rende una CPU? Ovviamente no, perche' ha sempre e comunque bisogno di qualcuno che dia la partenza, come le SPE: una volta fatte partire dalla PPE e' possibile scrivere del codice che si auto-schedula il lavoro, ma, ad esempio, in caso si verificasse un'eccezione tornerebbe il controlla alla PPE (ovvero la CPU).

si però in quel paragrafo c'è scritto che lo spe può far girare un minuscolo os che gli permette di assegnarsi il lavoro da solo (quindi credo senza l' ausilio della ppe). E' la stessa cosa? :confused:

Questo thread è ridicolo.

Le SPE SONO processori a tutti gli effetti, ottimizzati per il calcolo vettoriali, ma affatto limitate a quello. Hanno praticamente tutto di un processore. Non sono "unità" di calcolo come VMX, sono COMPLETI.

Certo particolari, soprattutto nella gestione della memoria, ma perfino Fek inizia a comprendere i vantaggi di quell'approccio...
Vantaggi sicuramente non applicabili in tutti gli ambiti, e per certe cose i processori tradizionali sicuramente restano superiori, ma d'altra parte i processori tradizionali sono troppo complessi per farcene entrare 8 in un chip e quindi restano pesantemente inferiori in molti altri.

L'unico vero "limite" (ma che limite non è visto che c'è la PPE per quello) è che non sono pensate per far girare OS moderni, quindi mancano di alcune features che non ne precludono però altri compiti, perfino quello di far girare degli OS semplificati per scopi specifici a quanto si apprende dagli ultimi documenti riportati.

si però in quel paragrafo c'è scritto che lo spe può far girare un minuscolo os che gli permette di assegnarsi il lavoro da solo (quindi credo senza l' ausilio della ppe). E' la stessa cosa? :confused:

E' esattamente equivalente :)
Quel paragrafo per mini-os intende proprio lo scheduler in grado di assegnarsi il lavoro. Ti ricordi l'esempio che ho fatto sulla generazione di vertici che poi sono passati all'SPE successiva per applicare una disp map?


Le SPE SONO processori a tutti gli effetti, ottimizzati per il calcolo vettoriali, ma affatto limitate a quello. Hanno praticamente tutto di un processore. Non sono "unità" di calcolo come VMX, sono COMPLETI.


No, non lo sono. Come ampiamente dimostrato (e testimoniato dai documenti IBM), sono unita vettoriali molto evolute, ma non sono CPU.


Certo particolari, soprattutto nella gestione della memoria, ma perfino Fek inizia a comprendere i vantaggi di quell'approccio...

Forse ti sfugge che fek con questi aggeggi ci lavora da un po' e gia' da un po' ha una buona idea di che cosa ci si puo' fare.

E' esattamente equivalente :)
Quel paragrafo per mini-os intende proprio lo scheduler in grado di assegnarsi il lavoro. Ti ricordi l'esempio che ho fatto sulla generazione di vertici che poi sono passati all'SPE successiva per applicare una disp map?




ah ok, ho capito...

grazie tante della spiegazione! :)

Pero' adesso mi devi spiegare il senso di questa eventuale decisione :D


questo dovresti spiegarlo tu a me :D

Nel senso che sei tu che devi dirmi quanto sono frequenti le richieste di texture fetch+filtering con i vs. Se sono poco frequenti la risposta può essere: "è stata una scelta per non sovraccaricare le tmu (visto che ciascuna alu può lavorare switchando di continuo tra pixel e vertici).
Se sono comuni, allora la risposta potrebbe essere: "si sono sbagliati nel programmare l'arbiter" :D

mi limito a quotare nuovamente questo

The PPE is the main processor of the Cell BE, and is responsible for running the operating system and coordinating the SPEs

main ha un significato piuttosto preciso, evidentemente non applicabile ad un spe. Se volete, potete non chiamare cpu il PPE, però se c'è un'unità (o processore) che ha un ruolo centrale (a livello di coordinamento e gestione) all'interno del cell, questo è il PPE. Il fatto che il controller che arbitra le richieste di accesso alla ram sia esterno al ppe, ne sminuisce, in parte, il ruolo centrale, ma non per questo conferisce autonomia agli spe, né tanto meno li rende assimilabili a delle cpu. Sono dei processori (termine quanto mai generico) che, per il loro funzionamento dipendono dal ppe e dal mic.

Non è un caso che IBM, in nessun documento, paragoni un spe ad una cpu o lo consideri il processore principale del cell.

questo dovresti spiegarlo tu a me :D

Nel senso che sei tu che devi dirmni quanto sono frequenti le richieste di texture fetch+filtering con i vs. Se sono poco frequenti la risposta può essere: "è stata una scelta per non sovraccaricare le tmu (visto che ciascuna alu può lavorare switchando di continuo tra pixel e vertici).
Se sono comuni, allora la risposta potrebbe essere: "si sono sbagliati nel programmare l'arbiter" :D

Relativamente infrequenti. Per buttare giu' qualche numero, l'esempio sul quale lavoro ora ha 128x128 texture fetch in una patch che occupa circa il 30% dei frammenti a 1280x720. A occhio c'e' un rapporto di 20 frammenti per ogni vertice.

Relativamente infrequenti. Per buttare giu' qualche numero, l'esempio sul quale lavoro ora ha 128x128 texture fetch in una patch che occupa circa il 30% dei frammenti a 1280x720. A occhio c'e' un rapporto di 20 frammenti per ogni vertice.


come pensavo; allora è verosimile che l'arbiter che riceve i comandi dalle "sottostazioni" riservate a pixel e vertici e invia istruzioni ad alu e tmu, in caso di chiamate relative ai soli vertivi non attivi il canale di comunicazione con le tmu ma trasferisca i comandi solo alle alu.
Se così è, all'occorrenza può essere riprogrammato per funzionare diversamente.
Dagli schemi a blocchi non mi pare che ci siano limitazioni di tipo hw alla possibilità di effettuare filtraggi anche sulle chiamate relative ai vertici

come pensavo; allora è verosimile che l'arbiter che riceve i comandi dalle "sottostazioni" riservate a pixel e vertici e invia istruzioni ad alu e tmu, in caso di chiamate relative ai soli vertivi non attivi il canale di comunicazione con le tmu ma trasferisca i comandi solo alle alu.
Se così è, all'occorrenza può essere riprogrammato per funzionare diversamente.
Dagli schemi a blocchi non mi pare che ci siano limitazioni di tipo hw alla possibilità di effettuare filtraggi anche sulle chiamate relative ai vertici

Interessante. Girero' la domanda a Microsoft e vedo che mi dicono, magari se espongono il filtering in una prossima release dell'SDK. Giusto ieri ero in conference call con loro e si parlava proprio di ottimizzazioni: avrei potuto domandarglielo, sara' per la prossima.

Scusa, yossarian, ma per fare il point sampling di una texture non serve la TMU, ma solo le Alu perchè devo solo calcolare la posizione del Texel da prelevare, è giusto? Invece negli altri casi devo prelevare N campioni e filtrarli, giusto?

Non è un caso che IBM, in nessun documento, paragoni un spe ad una cpu o lo consideri il processore principale del cell.
ok, ma il fatto che una spe non sia centrale nel Cell non vuol dire molto..
avrei una domanda (se qualcuno di voi può rispondere), e cioè: "è possibile creare l'architettura di una CPU in cui un SPE svolge un ruolo centrale? e se no, per quale motivo?" ovviamente in questo caso si tratterebbe di una CPU SP, e ovviamente sarebbe sconvenientissimo (non a caso IBM ci ha piazzato un PPE)! ma voglio solo sapere se è possibile..

poi per il fatto che il CELL secondo voi è SP.. http://www-128.ibm.com/developerworks/power/library/pa-expert4/
dW: It has been said that Cell is supposed to scale to -- everything from very tiny devices, up to huge supercomputers. What about right in the middle? Is there any point at all in having a desktop Cell machine?
Bergmann: For the regular desktop user, I think there will not be much difference, because you get all the benefits only if you write your applications specifically for the Cell processor. That's usually done either if you have just a very limited number of applications on the machine, like you have on embedded systems, [where you want] for instance to have MPEG encoding/decoding right there -- or in the supercomputer world, where you write your applications to run on the computer once.
dW: So all of the people who are hoping for a Cell computer at home are probably going to be disappointed.
Bergmann: Well, if they are programmers, they could of course write their own applications. And we might see some applications that are optimized for Cell. For example, you could have video editing software that's optimized for Cell, or some image manipulation. If you just want to run standard applications, it probably will not help you a lot.
dW: Well, but it wouldn't harm you either, would it? To run workaday applications like e-mail or Web browsing -- there wouldn't be any performance penalty, would there be?
Bergmann: No -- you'd just spend much more money for the processor itself, I guess.

penso quindi che il CELL sia una CPU GP con prestazioni particolarmente elevate in particolari settori (dove entrano in gioco gli SPE)! infatti è il PPE a garantire il GP a quanto ho letto! il problema è che se lo usi solo per il GP praticamente sprechi gli SPE (che non faranno quasi mai nulla) e quindi hai speso un sacco di soldi in più senza ottenere risultati in più (ma neanke in meno)!

ps. bergmann è "The Linux kernel maintainer for Cell"

avrei una domanda (se qualcuno di voi può rispondere), e cioè: "è possibile creare l'architettura di una CPU in cui un SPE svolge un ruolo centrale? e se no, per quale motivo?" ovviamente in questo caso si tratterebbe di una CPU SP, e ovviamente sarebbe sconvenientissimo (non a caso IBM ci ha piazzato un PPE)! ma voglio solo sapere se è possibile..
No, almeno per come sono ora strutturate... Bisogna programmare le SPE per farle "partire"...e comunque in caso di eccezione dipendono dalla PPE...

Chiaramente la definizione di SP e GP è molto traballante... Un CPU ottimizzata solo per un determinato ambito appplicativo è GP ? Anche un DSP riesce a far girare Linux, ma rimane sempre una CPU SP... Comunque secondo me puoi definirla sia GP che SP è indifferente, perchè dal punto di vista dell'istruction set è pari a quello di una CPU GP, ma trattarla come un PowerPC metterebbe in evidenza i notevoli problemi in un ambito GP...primo fra tutti il fatto che sia in-order...

ma secondo te fek, ora che puoi valutare la potenza di ps3, è possibile che si possa raggiungere la grafica del filmato di killzone 2? :)

Scusa, yossarian, ma per fare il point sampling di una texture non serve la TMU, ma solo le Alu perchè devo solo calcolare la posizione del Texel da prelevare, è giusto? Invece negli altri casi devo prelevare N campioni e filtrarli, giusto?

si tratta di una semplice operazione di campionamento, ma sono sempre le tmu ad occuparsene.

ok, ma il fatto che una spe non sia centrale nel Cell non vuol dire molto..


vuol dire, semplicemente, che non è una cpu, non è stata concepita per funzionare come cpu, non può essere assimilata ad una cpu (neppure all'interno del cell)

vuol dire, semplicemente, che non è una cpu, non è stata concepita per funzionare come cpu, non può essere assimilata ad una cpu (neppure all'interno del cell)
no, il fatto che un SPE non sia centrale nel Cell non significa che non sia possibile renderlo centrale in un'altra architettura! è solo una scelta progettuale, e con ogni probabilità la più conveniente, ma non è detto che sia l'unica possibile! infatti ringrazio cionci per la risposta :D !
No, almeno per come sono ora strutturate... Bisogna programmare le SPE per farle "partire"...e comunque in caso di eccezione dipendono dalla PPE...
ma per farle partire e farle risollevare da un'eccezione è necessaria tutta una CPU? non si potrebbe creare un circuitino che fa solo quello? (questa prometto che è l'ultima domanda scema :D )

Chiaramente la definizione di SP e GP è molto traballante... Un CPU ottimizzata solo per un determinato ambito appplicativo è GP ? Anche un DSP riesce a far girare Linux, ma rimane sempre una CPU SP... Comunque secondo me puoi definirla sia GP che SP è indifferente, perchè dal punto di vista dell'istruction set è pari a quello di una CPU GP, ma trattarla come un PowerPC metterebbe in evidenza i notevoli problemi in un ambito GP...primo fra tutti il fatto che sia in-order...
si effettivamente sembra la definizione più adatta.. infatti IBM stessa diceva che il Cell riempie il gap tra GP e SP.. l'anello mancante insomma!

no, il fatto che un SPE non sia centrale nel Cell non significa che non sia possibile renderlo centrale in un'altra architettura! è solo una scelta progettuale, e con ogni probabilità la più conveniente, ma non è detto che sia l'unica possibile! infatti ringrazio cionci per la risposta :D !

ma per farle partire e farle risollevare da un'eccezione è necessaria tutta una CPU? non si potrebbe creare un circuitino che fa solo quello? (questa prometto che è l'ultima domanda scema :D )

ti faccio la stessa domanda a cui non ha ancora risposto nessuno (e sono 3 volte):

se fosse stato possibile, perchè IBM non l'ha fatto, semplificando di molto l'architettura del cell e utilizzando un spe (con annesso il circuitino di cui parli) come unità centrale e risparmiando "qualche" transistor?

Visto che nessuno risponde (almeno nessuno dei sostenitori della tesi spe=cpu), la risposta la do io: perchè si sarebbe dovuto progettare un nuovo chip che non fosse semplicemente un spe (mentre se ne aveva già uno più o meno pronto).
Senza contare che il risultato finale sarebbe un chip forse lontano parente di un spe

ma secondo te fek, ora che puoi valutare la potenza di ps3, è possibile che si possa raggiungere la grafica del filmato di killzone 2? :)

Secondo me si', il video di KZ2 non e' nulla di eccezionale.

ma per farle partire e farle risollevare da un'eccezione è necessaria tutta una CPU? non si potrebbe creare un circuitino che fa solo quello? (questa prometto che è l'ultima domanda scema :D )
Chiamalo circuitino ;) E' un circuitino che deve "sorvegliare" lo stato della SPE ed in tal caso caricare un "vettore di interruzioni" dalla memoria centrale a quella locale della SPE e mandarla ad eseguire il codice corrispondente...
Insomma una CPU che non si sa recuperare da una eccezione mi sembra un po' limitante :) Senza contare l'accesso alla memoria....

ti faccio la stessa domanda a cui non ha ancora risposto nessuno (e sono 3 volte):

se fosse stato possibile, perchè IBM non l'ha fatto, semplificando di molto l'architettura del cell e utilizzando un spe (con annesso il circuitino di cui parli) come unità centrale e risparmiando "qualche" transistor?
forse sarebbe possibile ma non sarebbe affatto conveniente! un kernel sugli SPE girerebbe da schifo (ma girerebbe)! quindi la scelta del PPE è ovvia! il problema è stabilire se è possibile un'architettura senza PPE (anche se peggiore), perchè questo significherebbe che gli SPE potrebbero essere considerate in un qualche modo assimilabili a CPU in quel caso... non so se mi sono spiegato..

Secondo me si', il video di KZ2 non e' nulla di eccezionale.


non è nulla di eccezionale?

bhe allora ti auguro vivamente di tirare fuori un gioco eccezionale dalla ps3 :p

ciao!

Chiamalo circuitino ;) E' un circuitino che deve "sorvegliare" lo stato della SPE ed in tal caso caricare un "vettore di interruzioni" dalla memoria centrale a quella locale della SPE e mandarla ad eseguire il codice corrispondente...
Insomma una CPU che non si sa recuperare da una eccezione mi sembra un po' limitante :) Senza contare l'accesso alla memoria....
ok adesso è abbastanza convincente! gli SPE non sono abbastanza per essere considerate CPU (almeno allo stato attuale)!

Secondo me si', il video di KZ2 non e' nulla di eccezionale.


:eek: :eek: :eek:

Stai scherzando suppongo... :D

Se quello che dici è vero, i pc attuali con schede video equivalenti a quelle console (o simili cmq) sono esageratamente sottosfruttati!!! :sofico:

Questo thread è ridicolo.

Le SPE SONO processori a tutti gli effetti, ottimizzati per il calcolo vettoriali, ma affatto limitate a quello. Hanno praticamente tutto di un processore. Non sono "unità" di calcolo come VMX, sono COMPLETI.

Certo particolari, soprattutto nella gestione della memoria, ma perfino Fek inizia a comprendere i vantaggi di quell'approccio...
Vantaggi sicuramente non applicabili in tutti gli ambiti, e per certe cose i processori tradizionali sicuramente restano superiori, ma d'altra parte i processori tradizionali sono troppo complessi per farcene entrare 8 in un chip e quindi restano pesantemente inferiori in molti altri.

L'unico vero "limite" (ma che limite non è visto che c'è la PPE per quello) è che non sono pensate per far girare OS moderni, quindi mancano di alcune features che non ne precludono però altri compiti, perfino quello di far girare degli OS semplificati per scopi specifici a quanto si apprende dagli ultimi documenti riportati.

Perfetto.. come non quotare..

penso quindi che il CELL sia una CPU GP con prestazioni particolarmente elevate in particolari settori (dove entrano in gioco gli SPE)! infatti è il PPE a garantire il GP a quanto ho letto! il problema è che se lo usi solo per il GP praticamente sprechi gli SPE (che non faranno quasi mai nulla) e quindi hai speso un sacco di soldi in più senza ottenere risultati in più (ma neanke in meno)!

ps. bergmann è "The Linux kernel maintainer for Cell"

Un sacco di soldi magari no, non costa molto. Comunque IBM parla di streaming kernel ed ancora non ho visto bench relativi, in ogni caso resta la PPE che e' pur sempre un 64bit dual thread a 4Ghz, insomma per quanto IO (dipende molto dal SW dunque), rimane un buon pezzo di silicio.



Non è un caso che IBM, in nessun documento, paragoni un spe ad una cpu o lo consideri il processore principale del cell.

Non e' vero, io ho postato dove lo fa!! le chiama "Vector CPU".
Comuqnue son contento di andare d'accordo con il resto del mondo.. e criceto!! :D

ti faccio la stessa domanda a cui non ha ancora risposto nessuno (e sono 3 volte):

se fosse stato possibile, perchè IBM non l'ha fatto, semplificando di molto l'architettura del cell e utilizzando un spe (con annesso il circuitino di cui parli) come unità centrale e risparmiando "qualche" transistor?

Visto che nessuno risponde (almeno nessuno dei sostenitori della tesi spe=cpu), la risposta la do io: perchè si sarebbe dovuto progettare un nuovo chip che non fosse semplicemente un spe (mentre se ne aveva già uno più o meno pronto).
Senza contare che il risultato finale sarebbe un chip forse lontano parente di un spe

Semplice la risposta, perche' le prestazioni in alcuni ambiti, relativamente ai giorni d'oggi sarebbero troppo scarse. :) Non si puo' affermare che oramai un 6502 non sia piu' una CPU perche' non puo' fare moltissime cose che altre attuali fanno.

Secondo me si', il video di KZ2 non e' nulla di eccezionale.

Nulla di eccezionale?? :o Va be'. :) A me sembrano tonnellate di poligoni e particolato a sfare (per non parlare della qualita' delle texture e dell'effetto pellicola che ha l'immagine totale. Sicuramente si farà, ma temo che sotto taluni punti di vista, perdera' qualcosa (ad esempio non mi sembra so veda il minomo aliasing, anche se non ricordo bene), sperem!!


:eek: :eek: :eek:

Stai scherzando suppongo... :D

Se quello che dici è vero, i pc attuali con schede video equivalenti a quelle console (o simili cmq) sono esageratamente sottosfruttati!!! :sofico:


Che novità. :)

Semplice la risposta, perche' le prestazioni in alcuni ambiti, relativamente ai giorni d'oggi sarebbero troppo scarse. :)

ma anche no; in quali ambiti sarebbero troppo scarse (così, tanto per la cronaca)? Sempre per la cronaca, ti faccio notare che il cell è un processore dei giorni nostri, progettato oggi per applicazioni future. Oppure devo pensare che il spe sia stato progettato negli anni '70 (magari in contemporanea con il 6502)? :D

Non si puo' affermare che oramai un 6502 non sia piu' una CPU perche' non puo' fare moltissime cose che altre attuali fanno.


visto che lo tirate continuamente in ballo, ad esempio cosa poteva o non poteva fare, in particolare, il 6502 rispetto ad una cpu dell'epoca (ricordo che si parla del 1975)?

p.s. la spiegazione del perchè non l'hanno fatto è nel post successivo.......... :D

Non e' vero, io ho postato dove lo fa!! le chiama "Vector CPU".
Comuqnue son contento di andare d'accordo con il resto del mondo.. e criceto!! :D

se l'hanno fatto una volta, evidentemente si sono sbagliati, visto che centinaia di altre volte hanno affermato l'esatto contrario. E questa è una di quelle

Unlike existing SMP systems or multicore implementations of other processors, on the Cell, only the general purpose PowerPC core is able to run a generic operating system, while the SPUs are specialized to run computational tasks. Porting Linux™ to run on Cell's PowerPC core is a relatively easy task because of the similarities to existing platforms like IBM pSeries® or Apple Power Macintosh, but this does not give access to the enormous computing power of the SPUs.

e questo è il link al documento completo

http://www-128.ibm.com/developerworks/power/library/pa-cell/


Mi pare che si specifichi chiaramente che solo il ppe è in grado (capace o come vuoi tradurlo) di far girare un SO generico, mentre gli spe sono unità specializzate nell'effettuare calcoli.
Non mi risulta dica qualcosa del tipo: "un spe è una cpu gp ma poichè in molti ambiti sarebbe poco prestazionale, usiamo come cpu il ppe".
Inoltre, si sottolinea anche un "a differenza degli altri sistemi multicore" che fa chiaramente intendere che se un dual core è un dual cpu (ogni core è in grado di lavorare anche da solo, replicando esattamente le stesse funzionalità dell'altro), nel caso del cell questo non avviene; quindi, un spe non potrà mai sostituire il ppe che, ricordo, secondo IBM è il processore centrale del cell (processore centrale -> cpu). Infine, a maggior ragione, esclude nel modo più assoluto l'utilizzo di un spe come cpu gp (non mi pare neppure che dica:"però con un SO generico fortemente customizzato la cosa potrebbe funzionare"; semplicemente non se ne preoccupano e basta, perchè il spe non è stato ideato per funzionare come cpu e, tanto meno, come cpu gp).

......ecco spiegato il motivo del perchè IBM non utilizza un spe come cpu (la risposta non era poi così difficile) :D

Dopo la figura che avete fatto con tutta la pappa riguardo la differenza tra processing e processor, per spiegare a me e ad altri la differenza tra SPE e processore, come minimo dovreste seppellirvi. :)
Ma non credo lo capiate, ne stiamo ridendo ancora su tre forum (non ti dico da quando state cercando di spiegare che indipendente non vuol dire indipendente!!). :D
Ma non sei stanco di essere umiliato pubblicamente? Addirittura frequenti altre 3 forum (quindi ne hai di tempo da perdere, SE VUOI).
Spero che avrai avuto la buona educazione di non sparlare dei presenti. ;)

Comunque posta pure i link dei 3 forum, che veniamo a farti una visitina. :D :D :D

Per il resto, è inutile commentare: l'ultimo post di Yossorian mi sembra piuttosto eloquente (più chiaro di così, si muore).
Certo, proviene da IBM e non dai siti che ami tirare in ballo, primo su tutti quel saltimbanco di Blachford che ti piace tanto. :asd: :asd: :asd:

Ah, dimenticavo: ma il Copper è o non è una CPU? Mi spieghi perché ti ostini a non voler rispondere? Eppure quella definizione di CPU l'hai tirata fuori tu. ;)

Questo thread è ridicolo.

Le SPE SONO processori a tutti gli effetti, ottimizzati per il calcolo vettoriali, ma affatto limitate a quello. Hanno praticamente tutto di un processore. Non sono "unità" di calcolo come VMX, sono COMPLETI.

L'unico vero "limite" (ma che limite non è visto che c'è la PPE per quello) è che non sono pensate per far girare OS moderni, quindi mancano di alcune features che non ne precludono però altri compiti, perfino quello di far girare degli OS semplificati per scopi specifici a quanto si apprende dagli ultimi documenti riportati.
Non confondere il termine "s.o." con quello di "applicazione": le SPE sono in grado di far girare soltanto queste ultime, proprio perché mancano loro alcuni elementi per poterlo fare (e di questo ne abbiamo già ampiamente parlato).

Chiamalo circuitino ;) E' un circuitino che deve "sorvegliare" lo stato della SPE ed in tal caso caricare un "vettore di interruzioni" dalla memoria centrale a quella locale della SPE e mandarla ad eseguire il codice corrispondente...
Insomma una CPU che non si sa recuperare da una eccezione mi sembra un po' limitante :) Senza contare l'accesso alla memoria....
E senza contare che una SPE non è nemmeno in grado di caricare una page table. :p

ok adesso è abbastanza convincente! gli SPE non sono abbastanza per essere considerate CPU (almeno allo stato attuale)!
Ma nemmeno in futuro, perché dovrebbero stravolgerne l'architettura.
Le SPE sono nate per dei compiti ben precisi, e non vedo perché dovrebbe essere necessario cambiarle soltanto per farle diventare delle CPU: non c'è affatto questo bisogno! Fanno benissimo il loro lavoro, come pure la PPE per il suo. ;)

in ogni caso resta la PPE che e' pur sempre un 64bit dual thread a 4Ghz,
A 3,2Ghz (e doveva essere a 4,6Ghz). Nei server Blade di IBM addirittura è a "soli" 2,4Ghz.
insomma per quanto IO (dipende molto dal SW dunque), rimane un buon pezzo di silicio.
Per gli scopi per cui è stata progettata, sicuramente. Se poi vogliamo fargli fare qualcos'altro, una CPU in-order non è che sia il massimo prestazionalmente parlando (emulatori, compilatori, server database, ecc. girano MOLTO meglio su una CPU out of order "tradizionale").
Non e' vero, io ho postato dove lo fa!! le chiama "Vector CPU".
Se è per questo per la "P" di SPE ha usato indifferentemente "Processor" e "Processing". Solo che, e l'ultimo post di Yossorian è chiarissimo, non sono affatto delle CPU: fattene una ragione.

Altrimenti mi fai vedere come realizzare un piccolissimo s.o. ridotto all'osso che giri facendo ESCLUSIVAMENTE uso di una SPE? La PPE è perfettamente in grado di farlo.
Comuqnue son contento di andare d'accordo con il resto del mondo.. e criceto!! :D
Io sono contento di andare d'accordo con IBM e col resto del mondo...tecnico/professionale. ;)

A 3,2Ghz (e doveva essere a 4,6Ghz). Nei server Blade di IBM addirittura è a "soli" 2,4Ghz.

Io sono contento di andare d'accordo con IBM e col resto del mondo...tecnico/professionale. ;)

Stra-quoto. :Prrr:

Una domanda: un emulatore con un JIT altamente ottimizzato (che quindi convertisse le istruzioni in modo da tenere le pipeline il più possibile "calde" :)) perderebbe comunque molto? Immagino che sulla PS3 ci sarà qualcosa del genere per i titoli PS2/PS1... senza contare che poi le SPE potrebbero emulare gli altri processori in parallelo, ricalcando + da vicino il comportamento della macchina emulata.

Immagino che su un emulatore "normale" si ricorra ai thread per emulare "contemporaneamente" più coprocessori (non quelli della standa :rotfl: :rotfl: ), che però sempre seriali rimangono senza CPU dual-core.

EDIT: altra idea x gli emulatori, le SPE fanno la traduzione JIT in catena, mentre la PPE fischiettando passa e macina il codice trovato... magari è parzialmente applicabile anche ai compilatori??

Se allora anche per fare il point sampling è necessaria una TMU, perchè dici che nel caso dei vertex shader l'arbiter instrada i dati solo alle ALU e non alle TMU ? Come lo fanno allora il point sampling i vertex shader ?

per finire in bellezza, vediamo cosa ne pensa tale H. Peter Hofstee a proposito di spe e ppe

Riporto, testualmente, il suo breve commento

PPE handles operating systems and control tasks
SPE provides computational performance

Detta così, sembrerebbe quasi che il PPE si occupi di far girare sistemi operativi e controllare i task delle altre unità del cell (come farebbe una cpu di un qualunque sistema) e che gli SPE si occupino "solo" di eseguire gli incarichi che vengono loro assegnati. Addirittura, su un altro lucido, osa definirli coprocessori (ma non erano cpu a tutti gli effetti?)

Ma questo tizio va anche oltre, parlando di SPE e VMX (personalmente preferisco parlare di altivec, visto che la paternità sarebbe da attribuire a Motorola), dicendo che tra gli SPE highlights (c'è scritto proprio così, visto che si tratta di una breve presentazione), figurerebbe un

VMX-like SIMD dataflow (testuali parole). Ma come, un SPE non è tutt'altra cosa rispetto alle architetture altivec e questo parla di flusso di dati di tipo VMX?

Ovvio che il signore in questione non conosca affatto il cell e, in particolare i SPE :D

Se allora anche per fare il point sampling è necessaria una TMU, perchè dici che nel caso dei vertex shader l'arbiter instrada i dati solo alle ALU e non alle TMU ? Come lo fanno allora il point sampling i vertex shader ?

in effetti mi sono espresso male; il campionamento viene fatto, quella che viene ignorata è la richiesta di interpolazione necessaria per le operazioni di filtraggio più evoluto (dal bilinear in su)

ok, sono cattivo e vi rovino la festa: H. Peter Hofstee è quello che di fatto ha concepito e progettato i SPE :D

ok, sono cattivo e vi rovino la festa: H. Peter Hofstee è quello che di fatto ha concepito e progettato gli SPE :D

Che ignorante questo Hofstee!! Si vede che non conosce dinoXpc... :rotfl: :rotfl: :rotfl: :rotfl: :rotfl: :rotfl: :rotfl: :rotfl: :rotfl: :rotfl:

Stai scherzando suppongo... :D


Pronto ad essere smentito da Fek visto che è lui quello che ha di fatto detto che non è nulla di eccezionale.
Anche a me aveva fatto effetto sia il video che le affermazioni di Fek. Credo che lui parli da "tecnico" (passami la parola, non è affatto usata come parola "sminuente"), quindi io rimango lì, impressionato lo ammetto, nel guardare le immagini eccetera eccetera. E tutto si può dire tranne che il filmato non sia impressionante. Solo che ad un'analisi più attenta Fek aveva segnalato errori nelle ombre (vado a memoria), perdita di dettagli in lontananza eccetera eccetera (scusa se non sono preciso ma non mi ricordo per filo e per segno cosa era stato detto a suo tempo). Quindi il "non è nulla di eccezionale" forse è riferito a questo. Ovviamente se uscisse un gioco con quella grafica ora, ci sarebbe di che godere.

x yossarian...

Denghiu'... Allora avevo capito bene... :D

ok, sono cattivo e vi rovino la festa: H. Peter Hofstee è quello che di fatto ha concepito e progettato i SPE :D

E' un ignorantone che non sa neppure l'inglese, avrebbero dovuto farlo progettare a MadRat che ci sta insegnando a tutti :rotfl: