Link alla notizia: http://news.hwupgrade.it/13287.html

Il produttore americano annuncia alcuni dettagli ufficiali sulle prossime generazioni di cpu Opteron: ben 205 milioni di transistor integrati nel Die, grazie al processo a 0.09 micron

Click sul link per visualizzare la notizia.

"We don't see it as a race," Intel spokesman Otto Pijpker said.

AMD wasn't as restrained. "I think it's easy to say it's not a race if you're second," said Barry Crume, director of AMD's server and workstation business unit.

:)

Paolo pensi che a 1,6GHz la dissipazione resterà sotto il centinaio di watt?

solo fra il 30 il 50%?

non so fino a che punto possa convenire, un dual opteron a 1600 mhz non è certo un mostro prestazionale e se mancassero i programmi adatti un core resterebbe comunque inutilizzato dovendo sciegliere preferirei un fx 55

"incrementi prestazionali tra il 30 e il 55% rispetto a sistemi identici, ma basati su processori Single Core."

Rispetto a SISTEMI IDENTICI perchè ovviamente solo se al raddoppio dei core raddoppiassero quantitativamente o qualitativamente anche tutte le altre caratteristiche del sistema (bus,frequenza e capacità delle memorie,due hard disc in dual channel o un hard disc che garantisca banda passante doppia,due schede video o una che sia potente il doppio) ,fra le quali soprattutto la banda passante nel Bus di sistema,allora le prestazioni sì che sarebbero migliori anche del 100% IN TUTTE LE APPLICAZIONI.

"incrementi prestazionali tra il 30 e il 55% rispetto a sistemi identici, ma basati su processori Single Core."

Rispetto a SISTEMI IDENTICI perchè ovviamente solo se al raddoppio dei core raddoppiassero quantitativamente o qualitativamente anche tutte le altre caratteristiche del sistema (bus,frequenza e capacità delle memorie,due hard disc in dual channel o un hard disc che garantisca banda passante doppia,due schede video o una che sia potente il doppio), fra le quali soprattutto la banda passante nel Bus di sistema, allora le prestazioni sì che sarebbero migliori anche del 100% IN TUTTE LE APPLICAZIONI.

Mi si è sdoppiato senza motivo scusate....

Comunque del 100% in tutte le applicazioni che supportano efficientemente il doppio core naturalmente.

x Perfectdavid:
aspetta a parlare, bisogna vedere che frequenze usciranno e con quali Opteron single core loro hanno fatto il confronto, nonche' la scalabilita' in frequenza di queste nuove cpu.

Aspettare prima di parlare...

Secondo me non andranno così piano.
Il problema è molto commerciale:
se presentassero una cpu dual-core a bassa frequenza che andasse quasi come le migliori single-core, non ci sarebbe motivo (da parte degli eventuali acquirenti) per fare un upgrade, a meno che non costasse di meno della single... cosa impossibile.
Allora per attirare acquirenti, dovrebbe necessariamente essere MOLTO più potente della single-core più potente, in questo modo si avrebbero le basi (dual-core e potenza esagerata) per posizionarla in una fascia di prezzo a se (cioè una cifra!) e comunque attirare acquirenti.
Se la compatibilità di tali cpu sarà garantita con gli attuali sistemi (cioè veramente la stessa motherboard, chipset e operating sys) una cpu dual, anche costasse 2,5 una single, sarebbe certamente un vantaggio rispetto alla costruzione da zero di una macchina dual cpu.
Il che significa che un ipotetico Dual FX55 potrebbe costare anche 2000€ e comunque avrebbe valore commerciale :)
Secondo me poi, alla AMD non sono così stupidi da tenersi ancora per molto delle architetture che abbastanza chiaramente non vedranno i 3ghz.
Con tutta la fatica che stanno facendo per guadagnare quote di mercato, non ha senso. Sicuramente hanno qualcosa in cantiere.
Del resto AMD e Intel sono diametralmente opposte: se almeno una delle due, imparasse dall'altra... Avremmo cpu veramente veloci :eek: :D

Originariamente inviato da JOHNNYMETA
Comunque del 100% in tutte le applicazioni che supportano efficientemente il doppio core naturalmente.
Non è assolutamente vero...perchè lo sarebbe solo in caso l'applicazione processi dati distinti con ogni CPU... Ad esempio lanciando due client Seti...uno per ogni CPU...

La dipendenza dei dati c'è più o meno sempre...e non è mai possibile raggiungere il 100% se non con dati paralleli...

La mia domanda è questa. COSA VE NE IMPORTA?Se ho un processore da 1 ghz che da della fuffa a tutto il resto cosa può importarci di quanti ghz viaggia... e tra l'altro consuma anche di meno...

allora le prestazioni sì che sarebbero migliori anche del 100% IN TUTTE LE APPLICAZIONI.
Massè questa è utopia
solo fra il 30 il 50%?
anche meno...
Allora per attirare acquirenti, dovrebbe necessariamente essere MOLTO più potente della single-core
No affatto non devono ESSERLO, devono solo CONVINCERE il pubblico che lo sono :)

Imo i primi dual core non avranno prestazioni di molto superiori agli attuali single...poi probabilmente a distanza di mesi affineranno il processo produttivo, chipset etc ed allora si avrà un'idea chiara dei prossimi sistemi

Originariamente inviato da JOHNNYMETA
SE al raddoppio dei core raddoppiassero ....
bisogna vedere che frequenze usciranno e con quali Opteron single core loro hanno fatto il confronto, nonche' la scalabilita' in frequenza di queste nuove cpu.
Originariamente inviato da ErminioF
Imo i primi dual core non avranno prestazioni di molto superiori agli attuali single...poi probabilmente a distanza di mesi affineranno il processo produttivo, chipset etc ed allora si avrà un'idea chiara dei prossimi sistemi

ora io mi domando... perchè stare adesso a fare congetture su congetture sulle prestazioni future dei sistemi dual core ?

... se si presuppone che le prossime cpu dual core siano basate sull' architettura netburst , non basterebbe vedere le prestazioni di sistemi attuali dual Xeon?
nel caso di amd, sistemi multiprocessore opteron mi pare esistano da tempo, non dovrebbero dare l' idea delle prestazioni ottenibili dai chip multi core dell' anno prossimo?

dubito che una cpu dual core sarà il frutto di chissà quale alchimia tecnologica, secondo me i motivi per cui non sono ancora in commercio sono essenzialmente: redesign delle MB, dissipazione (nel senso che bisogna finire di progettare una forma per i dissipatori ) e soprattutto marketing
piuttosto direi, nè più nè meno che due processori in un unico die di silicio e unico package, e quindi le prestazioni saranno quelle di sistemi odierni con una coppia di cpu con quell' architettura...
idem per il campo di applicazione, per le tipologie di SW che se ne avvantaggeranno...

dal momento che le macchine multiprocessore non sono nate ieri, da parecchio tempo si insiste sulla programmazione multithread...
ora, il problema non è SE i programmi avranno un supporto multi thread (i campi in cui ci si può avvantaggiare dell' esecuzione concorrente mi pare siano stati abbondanetemente esplorati ... in caso di calcoli scientifici, rendering, DB si hanno dei vantaggi... per le normali applicazioni da ufficio direi molto meno, già il processore è tipicamente in idle tra la pressione di un tasto e la seguente)
ma quanto sono/saranno stabili ...

Originariamente inviato da magilvia
Massè questa è utopia


Non è utopia è un caso pratico in cui si verificano le condizioni descritte nel messaggio sopra,il caso pratico di un sistema totalmente sdoppiato e parallelo,non solo nel processore.

Originariamente inviato da cionci
Non è assolutamente vero...perchè lo sarebbe solo in caso l'applicazione processi dati distinti con ogni CPU... Ad esempio lanciando due client Seti...uno per ogni CPU...

La dipendenza dei dati c'è più o meno sempre...e non è mai possibile raggiungere il 100% se non con dati paralleli...

Appunto con dati paralleli e di cosa credevi che parlassi dicendo
"applicazioni che supportano efficientemente il doppio core" e parlando di dual channel,dual HD,dual core,dual videoboard......

Originariamente inviato da magilvia
No affatto non devono ESSERLO, devono solo CONVINCERE il pubblico che lo sono :)


Hum....
Sai quella gente che compra centinaia di macchine per fare i cluster?
Tipo non so... la Pixar Entertainment Studios?
O tutti coloro che utilizzano stazioni silicon graphics et similia?
Bhè tu ce li vedi a farsi abbindolare da AMD o Intel?
Io no :)

Originariamente inviato da jappilas
ora io mi domando... perchè stare adesso a fare congetture su congetture sulle prestazioni future dei sistemi dual core ?

Perchè questo è un sito di notizie sull'hardware?


nel caso di amd, sistemi multiprocessore opteron mi pare esistano da tempo, non dovrebbero dare l' idea delle prestazioni ottenibili dai chip multi core dell' anno prossimo?
dubito che una cpu dual core sarà il frutto di chissà quale alchimia tecnologica, nè più nè meno che due processori in un unico die di silicio e unico package, e secondo me i motivi per cui non sono ancora in commercio sono essenzialmente: redesign delle MB, dissipazione (nel senso che bisogna finire di progettare una forma per i dissipatori ) e soprattutto marketing

Non la farei così semplice...
Altrimenti li avremmo fin dai tempi dell'8086 :)
Disegnare qualcosa a transistor, dove un transistor è più piccolo di una cellula... Bhè non mi sembra una cosa da poco ;)
Tra l'altro per quanto le cpu amd consumino meno delle intel, una cpu che dissipa su 190mmq 180w...
Dovrebbe reggere una temperatura di funzionamento continuo di 140°C?
Ma ndo le sogni?
Non puoi pensare che basti metterle insieme, e disegnare un dissi nuovo...


e poi, il Sw... dal momento che le macchine multiprocessore non sono nate ieri, da parecchio tempo si insiste sulla programmazione multithread...
ora, il problema non è SE i programmi avranno un supporto multi thread ma quanto sono/saranno stabili ...

E questa da dove esce???
Se la cpu viene vista come cpu singola (come è) ma con due unità di esecuzione (come è), allora eventuali problemi di stabilità da cosa nascerebbero?

Cmq visto che eri riluttante a parlare di cose che non esistono, potevi anche non scrivere :asd:

Originariamente inviato da jappilas
ora io mi domando... perchè stare adesso a fare congetture su congetture sulle prestazioni future dei sistemi dual core ?


La mia non era una congettura su prestazioni future ma una risposta ad una questione pratica basata su sistemi dual che esistevano nel passato ed esistono nel presente. :read:

Originariamente inviato da erupter
Perchè questo è un sito di notizie sull'hardware?

sì è un sito di notizie sull' HW dove però a volte sembra che ci aspetti che lo stesso HW si comporti in modo imprevedibile e quasi "magico" ...mentre a me (abituato ad ing informatica v.o.) l' informatica stessa è sempre apparsa come scienza esatta (anche se complicata) ;)

Non la farei così semplice...
Altrimenti li avremmo fin dai tempi dell'8086 :)
Disegnare qualcosa a transistor, dove un transistor è più piccolo di una cellula... Bhè non mi sembra una cosa da poco ;)
Tra l'altro per quanto le cpu amd consumino meno delle intel, una cpu che dissipa su 190mmq 180w...
Dovrebbe reggere una temperatura di funzionamento continuo di 140°C?

guarda che i "tecnici" che disegnano a mano i transistor sui fotochemi (anche detti maschere) non ci sono più da tempo :rolleyes:
la progettazione di una cpu, come pure di un qualsiasi altro componente digitale vien fatta tramite supercomputer e strumenti SW... e le macchine per la fotoincisione hanno precisione estremamente elevata, appunto dell' ordine dei nanomentri
cmq da quando ho visto questo (http://www.lostcircuits.com/cpu/hp_pa8800/) , e cose analoghe riguardanti chip ibm e Sun, e leggevo che intel e amd avrebbero applicato la stessa tecnica nel settore mainstream...
al che, se si vanno a notare i tdp dei chip in questione, mi sono convinto che intel se lo avesse voluto, non avrebbe avuto molti più problemi a mettere due Xeon in uno di quanti ne ha avuti IBM ad affiancare quattro Chip Power in un unico package :rolleyes:
per questo non mi aspetto nulla di trascendentale nè dal punto di vista HW, nè tantomeno rivoluzioni applicative in ambito Sw...

certo, aumentano i watt dissipati, aumenta la superficie del die attraverso cui devono passare: accennavo al dissipatore , è ovvio che non sarà lo stesso usato per un singolo Xeon (/Opteron) ma qualcosa di nuovo
infatti occorrerà una superficie radiante doppia per mantenere gli stessi coefficienti di "efficienza di aletta" e di "resistenza termica" e forse un ingombro doppio sulla MB (a meno di usare layout più compatti, sviluppati in altezza o che so io...) in modo tale da mantenere la temperatura operativa nel solito "range" accettabile (che è quello in cui le giunzioni al silicio operano le transizioni 0-1 in modo attendibile e resistono senza fondere il materiale e/o innescare processi dannosi elettrici o eletromagnetici...almeno una volta valeva che a 70 gradi si innescano comportamenti imprevedibili alle giunzioni, fonte di erraticità nei calcoli, a 80 elettromigrazione, sopra i 100 effetto valanga con fusione del componente)
Ma ndo le sogni?
Non puoi pensare che basti metterle insieme, e disegnare un dissi nuovo...
vorrei che mi spiegassi perchè no... a parte i problemi che comprendo pure io di avere dei chip molto più ampi, con rese produttive inferiori in modo anche non proporzionale... ;)
E questa da dove esce???
Se la cpu viene vista come cpu singola (come è) ma con due unità di esecuzione (come è), allora eventuali problemi di stabilità da cosa nascerebbero?

allora: intanto la cpu resterebbe unica solo dal punto di vista estetico, da un punto di vista sia logico sia fisico sarebbero effettivamente 2 , diversamente dall' Hyper Threading che ha solo:
un duplice set dei registri logici (rimappati tramite la RAT sui 128 fisici del p4), una coppia di program counter e un bit in più sugli stadi di pipeline (per permettere alle alu di separare le istruzioni appartenenti ai due thread diversi) ...
e fammi il favore di non confondere "core"o CPU, con "unità di esecuzione" che restano le ALU, le AGU e le Branch Unit DENTRO una cpu, od ognuno dei "core"
e poi: se si vuole sfruttare un sistema MP, o gli si danno in esecuzione più processi diversi, oppure una singola applicazione con i famigerati thread multipli , che però condividono lo spazio di indirizzamento: a questo punto il problema base è che questi accedono a delle strutture dati che sono condivise, in modo concorrente, sia nel senso di "in parallelo", sia nel senso di "contesa"
tale concorrenza da una parte sconvolge il flusso di esecuzione del programma che non è più lo stesso del caso a thread singolo, dal' altro pone il problema di mantenere la consistenza dei dati qualora vi siano accessi multipli in scrittura o misti lettura/scrittura:
si dice che un programma è "thread safe" quando il suo codice è "rientrante" (fatto in modo che una singola copia delle sue istruzioni può essere riusato da più processi separati, il che implica che in tale copia comune non ci sia nulla che venga alterato dai processi separati, e le variabili individuali restino in zone di memoria diverse) o quando viene cmq implementata una forma di controllo e protezione sull' atomicità delle transazioni, di solito mutua esclusione (serializzazione), semafori, spinlocks, sezioni critiche ecc ecc...
solo che semaforizzare e debuggare correttamente del codice richiede un po' di impegno...
se un programma non era pensato per il multithread vuol dire che non implementava accorgimenti in questo senso e va almeno in parte riscritto, questo non è il caso in cui basta una ricompilata e via... :rolleyes:
Cmq visto che eri riluttante a parlare di cose che non esistono, potevi anche non scrivere :asd:
ridi ridi... :rolleyes:
a parte che per questa frase il messaggio non meritava risposta,

ma anche se a volte non riesco a essere sintetico oppure preciso, riluttante a dire quel che penso/so è proprio quello che non sono MAI... :rolleyes:

PS: se una cosa non la conosci , non vol dire che non esista... ;)

con un upgrade da singolo a dual core si potrebbero avere dei vantaggi anche su applicazioni non proggettate per essere eseguite per il dual, in quanto una processa l'applicazione, e una tutto il resto, senza interruzioni.
mentre su macchine nuove, la praticita' di avere a dsposizione due processori per ogni singolo socket non e' certo da trascurare: una scheda a 4 processori diventerebbe subito ad 8, raddoppiando di conseguenza la scalabilita'!
certo, c'e da dire che sicuramente non si avra' il raddoppio delle prestazioni, in quanto la banda per CPU verso le ram verrebbe dimezzata..
sarebbe interessante sapere se la prima CPU ha il controllo dei due canali ram, e la seconda si appogga sulla prima tramite un bus HT, o se ogniCPU ha a disposizione in modo esclusivo 1 bus ram, e sempre tramite HT fanno ponte tra' una e l'altra..
credo che sia piu' probabile la seconda configurazione, il che porta a dire che si limiterebbe in okmdo consistente la banda sulle ram, e percio' si avranno una maggiorazione delle prestazioni non in rapporto a due CPU tipo opteron, ma in rapporto a 2 CPU tipo 754, che sono quelle che si avvicinano di piu'..
..e comunque un guadagno sempre inferiore al 50% ( rispetto al singolo processore) nelle migliori condizioni ipotizzabili.

è un caso pratico in cui si verificano le condizioni descritte nel messaggio sopra,il caso pratico di un sistema totalmente sdoppiato e parallelo,non solo nel processore.
il quale caso è come dicevo utopia :asd:
Sai quella gente che compra centinaia di macchine per fare i cluster?
Tipo non so... la Pixar Entertainment Studios?
O tutti coloro che utilizzano stazioni silicon graphics et similia?
Bhè tu ce li vedi a farsi abbindolare da AMD o Intel?
Io no
Checcentra qui si parla di sistemi desktop e sono gli utenti che si faranno abbindolare. Quando le cpu saranno disponibili ci saranno i benchmark di questa o di quella applicazione che andranno al DOPPIO di velocità salvo poi accorgersi dopo l'acquisto che il proprio programma preferito va più piano di prima a causa del moltiplicatore più basso...

Mah... personalmente la stima fatta nella news sulla base della semplice affermazione che "un sistema dual core dovrebbe essere il 55% più efficiente (in media)" non mi sembra abbia molto senso.

Originariamente inviato da JOHNNYMETA
Non è utopia è un caso pratico in cui si verificano le condizioni descritte nel messaggio sopra,il caso pratico di un sistema totalmente sdoppiato e parallelo,non solo nel processore.

Appunto con dati paralleli e di cosa credevi che parlassi dicendo
"applicazioni che supportano efficientemente il doppio core" e parlando di dual channel,dual HD,dual core,dual videoboard......
Il fatto è che questo non può verificarsi con una "applicazione che supporta efficientemente il doppio core"... L'unico caso possibile è appunto iil far girare due programmi distinti che lavorano su dati distinti...

Un programma "che supporta efficientemente il doppio core" è un programma multithreaded che suddivide i calcoli da fare fra due o più thread cercando di mantenere la maggiore indipendenza possibile dei dati fra i dati elaborati dai due flussi... Ma l'elaborazione concorrente necessita in praticamente ogni caso pratico di mantenere una sincronizzazione fra i dati elaborati... Questa sincronizzazione è apunto i motivo per cui le prestazione non potranno mai raddoppiare se non elaborando dati diversi di due applicazioni distinte...

L'unico punto da determiare con queste CPU dual core sarà il campo di utilizzo...
Nel campo server installando due CPU dual core su una sistema che prima aveva due CPU single core si avranno sicuri vantaggi, anche con frequenze nettamente minori...
Mi lascia perplesso l'utilizzo desktop... Mettiamo il caso di avere una CPU single core da 3 Ghz...e supponiamo di sostituirla con una CPU dual core da 2 Ghz per core...
Il risultato sarà che il gioco che prima facevamo girare andrà sicuramente più piano...e questo avverrà per TUTTI i programmi non multithreaded presi singolarmente...
altro discorso se si faranno girare più programmi pesanti contemporaneamente...ad esempio: un client Seti e un codifica MPEG... In tutti i casi del genere si avrà un aumento notevole delle prestazioni rispetto alla stessa situazione (sempre con i soliti due programmi contemporaneamente) con una CPU single core a frequenza maggiore...

Originariamente inviato da cionci
snip

Mi lascia perplesso l'utilizzo desktop... Mettiamo il caso di avere una CPU single core da 3 Ghz...e supponiamo di sostituirla con una CPU dual core da 2 Ghz per core...
Il risultato sarà che il gioco che prima facevamo girare andrà sicuramente più piano...e questo avverrà per TUTTI i programmi non multithreaded presi singolarmente...
altro discorso se si faranno girare più programmi pesanti contemporaneamente...ad esempio: un client Seti e un codifica MPEG... In tutti i casi del genere si avrà un aumento notevole delle prestazioni rispetto alla stessa situazione (sempre con i soliti due programmi contemporaneamente) con una CPU single core a frequenza maggiore...

uhm, in certi giochi ci si potrebbe anche avvantaggiare della programmazione multithread, in quanto un gioco non è solo il suo engine 3D...
ma anche la parte che si occupa del suono, dell' IA dei personaggi , dell' input da tastiera/mouse/pad, dell' eventuale feedback vibrazionale o di forza...
ovvero le routine che effettuano chiamate a librerie diverse (direct input, directsound, direct3d... ) dovrebbero poter essere implementate in thread concorrenti
ora, magari la parte di simulazione fisica stresserebbe abbastanza la cpu su cui girerebbe, ma se si riservasse un core da 2 ghz per il solo "input loop" e l'audio, sarebbe, come direbbero in english... "overkill" ...
e può darsi che la differenza col fare girare il gioco su una sola cpu, risulti minima come pure consistente, valevole la complessità di sviluppo aggiunta che comporta lo sviluppo thread safe, complessità che si aggiunge a quella tipica dei videogiochi, della creazione di ambienti, personaggi, artwork, script , ecc ecc

Originariamente inviato da jappilas
uhm, in certi giochi ci si potrebbe anche avvantaggiare della programmazione multithread, in quanto un gioco non è solo il suo engine 3D...
Chiaramente intendevo un gioco di quelli attuali ;)

Un 30-55% rispetto al 2.4 mi pare sufficiente a giustificare un prezzo superiore. L'incremento si avrà con applicazioni adatte, ma gli Opteron sono pensati per il mercato server, sono usati per applicazioni fortemente parallele.

I dual core infatti non sono una novità in quella fascia di mercato. Ci sono già i Dual G5 e i Power5, e non mi pare abbiano prestazioni scarse...

Jappilas ha spiegato benissimo come mai l'architettura dual core è stata rimandata per così tanto tempo sui desktop... troppo complicato scrivere applicazioni che la sfruttino in maniera efficiente.

Nei giochi il dual core potrebbe servire, ma solo se programmati a dovere :p
Un motore fisico si avvanteggerebbe non poco di due processori, ma ho i miei dubbi che i programmatori si sbattano a farlo multithread per ottimizzare i calcoli quando il 99% dell'hardware che lo farà girare per ora è single core.

mine is longer than your

Originariamente inviato da magilvia
il quale caso è come dicevo utopia :asd:



Se è un caso PRATICO E CONCRETO non è utopia,non confondere questa con ciò che è reale dal momento che questo sistema parallelo non è mica una mia invenzione e come ho detto già prima:

"La mia non era una congettura su prestazioni future (o utopie) ma una risposta ad una questione pratica basata su sistemi dual che esistevano nel passato ed esistono nel presente."

E' chiaro? Sistemi o cluster completamente paralleli dual o multiprocessore esistono ormai da decine d'anni e tu mi cadi dalle nuvole parlando di sogni e utopie?????? :ahahah::what: :old: :read: :nono:

Ma, secondo me sia intel che amd la fanno un po' troppo facile, a mio parere pensare di accoppiare semplicemente due cpu per fare un dual core efficente e' troppo riduttivo.
Secondo me' come capita sempre con le novita' si troveranno difronte a molte problematiche che con una singola cpu non avevano, uno su' tutte la frequenza.
Mi pare di vedere come si parla di alzare e abbassare la frequenza cosi' come si vuole o in base alla dissipazione, ma a casa mia la frequenza di funzionamento non e' assolutamente un parametro cosi' flessibile, ma strettamente legata all'architettura del processore.Esempio lampate la lunghezza delle pipeline, se prendessimo per esempio un prescott a 3 ghz che ha 30 stadi di pipeline e lo facessimo andare a 1.5 ghz, non avremmo assolutamente il 50% delle prestazioni, ma MOOLTO meno.
Un altro esempio, un processore prodotto a 0.9 necessita di un certo voltaggio per funzionare a 3.0 ghz, provate a farlo andare a 1.5 ghz,se gia' adesso hanno avuto problemi di correnti vaganti e hanno dovuto sovralimentarli che necessitano un basso voltaggio, figuriamo quando il voltaggio necessario sara' ancora meno.
Parliamo di Amd, il controller interno della memoria rende cosi' tanto, proprio perche' la comunizazione tra cpu e controller gira alla stessa frequenza del processore, proviamo a dimezzare la frequenza, rendera' uguale rispetto ad un controller esterno?
Secondo me se prendono le cose alla leggera, come mi pare stiano facendo verranno fuori delle cpu dul core che sicuramente convinceranno tutti a comprarli ma avranno tanti di quei colli di bottiglia e latenze inutili che un sistema multiprocessore vecchio stampo gli dara' la biada per molto tempo.

Originariamente inviato da cionci
Il fatto è che questo non può verificarsi con una "applicazione che supporta efficientemente il doppio core"... L'unico caso possibile è appunto iil far girare due programmi distinti che lavorano su dati distinti...

Un programma "che supporta efficientemente il doppio core" è un programma multithreaded che suddivide i calcoli da fare fra due o più thread cercando di mantenere la maggiore indipendenza possibile dei dati fra i dati elaborati dai due flussi... Ma l'elaborazione concorrente necessita in praticamente ogni caso pratico di mantenere una sincronizzazione fra i dati elaborati... Questa sincronizzazione è apunto i motivo per cui le prestazione non potranno mai raddoppiare se non elaborando dati diversi di due applicazioni distinte...

L'unico punto da determiare con queste CPU dual core sarà il campo di utilizzo...
Nel campo server installando due CPU dual core su una sistema che prima aveva due CPU single core si avranno sicuri vantaggi, anche con frequenze nettamente minori...
Mi lascia perplesso l'utilizzo desktop... Mettiamo il caso di avere una CPU single core da 3 Ghz...e supponiamo di sostituirla con una CPU dual core da 2 Ghz per core...
Il risultato sarà che il gioco che prima facevamo girare andrà sicuramente più piano...e questo avverrà per TUTTI i programmi non multithreaded presi singolarmente...
altro discorso se si faranno girare più programmi pesanti contemporaneamente...ad esempio: un client Seti e un codifica MPEG... In tutti i casi del genere si avrà un aumento notevole delle prestazioni rispetto alla stessa situazione (sempre con i soliti due programmi contemporaneamente) con una CPU single core a frequenza maggiore...

E' molto chiaro quello che hai detto e concordo perfettamente su tutto.
Penso che a questo punto sia evidente per tutti il motivo di un aumento di prestazioni,nei sistemi domestici sostituendo il processore single con il dual, compreso fra il 30 e il 55% e mai del 95%-100% anche a causa della sincronizzazione fra dati elaborati.

Un ultima nota, nell'articolo si parla di un aumento di prestazioni del 30-55%, ora se giriamo la cosa vuole dire che il 45%-70% del secondo core e' inutile.

Forse sarebbe stato opportuno dire che tecnologicamente parlando, il dual core come lo stanno proponendo e' un sistema con un efficenza disastrosa, visto che come diceva qualcuno tempo fa' il vero progresso tecnologico e' un sistema che necessita meno risorse e energia per la costruzione ed il funzionamento ed ha prestazioni superiori.
Ci siamo lamentati per mesi del consumo dei pc e adesso arriva il dual core che e' in relata' la stessa minestra cucinata diversamente.

Originariamente inviato da jappilas
...mentre a me (abituato ad ing informatica v.o.) l' informatica stessa è sempre apparsa come scienza esatta (anche se complicata) ;)

Teoricamente esatta: vammi a spiegare perchè 1 volta l'anno becco una schermata blu :sofico:


Scherzo ;)


guarda che i "tecnici" che disegnano a mano i transistor sui fotochemi (anche detti maschere) non ci sono più da tempo :rolleyes:

Ma va :muro:
Però vista la tua erudizone, concorderai con me che progettare un circuitello per fare le luci "supercar" con tecnologia CMOS, e realizzare una cpu con processi produttivi minuscoli, oltre la complessità, propongono anche problemi nettamente diversi.
Con una complessità infinitamente superiore nel caso del secondo progetto.
Eddai: abbiamo a che fare con transistor quasi monomolecolari tra un po'! (non dubito che da qualche parte già li abbiano provati)
Con tutti i super computer, clusters, super-software, macchine elio-foto-lito-cippo-lippo-grafiche i problemi da risolvere sono sempre più grossi, non più piccoli.
No?

al che, se si vanno a notare i tdp dei chip in questione, mi sono convinto che intel se lo avesse voluto, non avrebbe avuto molti più problemi a mettere due Xeon in uno di quanti ne ha avuti IBM ad affiancare quattro Chip Power in un unico package :rolleyes:

Bhè è ovvio che se lo volessero potrebbero fare tutto in due giorni.
Se avessero voluto avremmo avuto il P4 3,4ghz 4 anni fa.
Ma nessuno l'ha voluto per allora.
Così come per ora nessuno vuole un dual-core 3+3ghz a 100€.

per questo non mi aspetto nulla di trascendentale nè dal punto di vista HW, nè tantomeno rivoluzioni applicative in ambito Sw...

Bhè la disponibilità a "basso" prezzo di tale potenza di calcolo, è qualcosa che secondo me avrà un impatto rilevabile sulla diffusione tecnologica o comunque sulla disponibilità di applicazioni sempre più avanzate (e parlo di RL, come applicazioni biomediche).


infatti occorrerà una superficie radiante doppia per mantenere gli stessi coefficienti di "efficienza di aletta" e di "resistenza termica" e forse un ingombro doppio sulla MB (a meno di usare layout più compatti, sviluppati in altezza o che so io...) in modo tale da mantenere la temperatura operativa nel solito "range" accettabile

Non mi pareva i sistemi termici fossero lineari, però posso anche ricordare male non mi piaceva molto Fisica Tecnica :p
Cmq effettivamente non credo "basti" raddoppiare la superfice radiante.
Il problema è che due core messi accanto, dissipano 1/4 di energia (diciamo, non è detto) dallo stesso lato.
In pratica una parte sola (quella la centro) si ritrova con metà della dissipazione di un intero core.
Ciò non significa soltanto una maggiore efficenza necessaria nel dissipatore, ma anche un riscaldamento delle parti vicine dei core, che a loro volta portano ad alzare i consumi, al degrado delle giunzioni ecc.
Insomma non è na passeggiata, anche coi supercomputer ;)

vorrei che mi spiegassi perchè no... a parte i problemi che comprendo pure io di avere dei chip molto più ampi, con rese produttive inferiori in modo anche non proporzionale... ;)

Problema che non avevo minimamente affrontato, ma che avranno affrontato ovviamente in fabbrica :)


allora: intanto la cpu resterebbe unica solo dal punto di vista estetico, da un punto di vista sia logico sia fisico sarebbero effettivamente 2 , diversamente dall' Hyper Threading che ha solo:[...]e fammi il favore di non confondere "core"o CPU, con "unità di esecuzione" che restano le ALU, le AGU e le Branch Unit DENTRO una cpu, od ognuno dei "core"

Concordo su tutto quello che dici, anche sulla "unità di calcolo", ma permettimi una licenza "poetica": so cosa sono le alu, le fpu, le agu, eccc
Il problema è far arrivare il discorso.
Per quanto concerne il supporto è verissimo che "effettivamente" le cpu sono due.
Ma il fatto che condividano un unico bus sia per il sistema che per la memoria, fa sì che in linea teorica il sistema potrebbe comportarsi come se ne vedesse una sola.
In pratica potrebbe essere la cpu a smistarsi il lavoro da sola (come fanno le Gf 6800 in SLI).
Questo per dire che mettere due core su una cpu, non è lo stesso che mettere due cpu.
Non so ora esattamente come verrà implementata sta cosa a livello software, ma ritengo che sia molto più facile che non gestire un sistema MP.

e poi: se si vuole sfruttare un sistema MP, o gli si danno in esecuzione più processi diversi, oppure una singola applicazione con i famigerati thread multipli , che però condividono lo spazio di indirizzamento: a questo punto il problema base è che questi accedono a delle strutture dati che sono condivise, in modo concorrente, sia nel senso di "in parallelo", sia nel senso di "contesa"
[cut...]
questo non è il caso in cui basta una ricompilata e via... :rolleyes:

A meno che non implementino un controllo automatico tipo lo SLI.
Non so se e quanto sia fattibile.
Però data la potenza di una GF 6800, mi sembra che più o meno la situazione sia simile.

a parte che per questa frase il messaggio non meritava risposta,

Permaloso.
La buttavo a ridere su!


PS: se una cosa non la conosci , non vol dire che non esista... ;)

Assolutamente vero T'Pol! :D

Originariamente inviato da erupter
In pratica potrebbe essere la cpu a smistarsi il lavoro da sola

Non credo proprio, almeno non accoppiancando due core esistenti. Per fare una cosa del genere bisognerebbe riprogettare tutto, e sarebbe comunque troppo complicato, a meno di sapere esattamente che tipo di dati saranno elaborati e come. E poi, se si deve comportare una sola cpu, tanto vale fare un solo core con il doppio dei registri, delle alu... (ma servirebbe comunque il supporto sw). Ma anche in questo caso, servirebbe almeno raddoppiare il bus dati (in termini di bit usati, e tutto si complicherebbe ulteriormente), perchè con le dimensioni attuali ti ritrovi al massimo un certo numero di istruzioni eseguibili in parallelo, un raddoppio delle risorse interne risulterebbe uno spreco, a meno di aspettare che arrivino dati/istruzioni sufficienti per riempire le pipe parallele. Inoltre non è detto che tali istruzioni siano parallelizzabili, per cui srebbe necessario comunque un adeguato supporto sw (multithreading), oppure gran parte delle risorse interne resterebbero inutilizzate. Se poi vogliamo far girare più processi contemporaneamente, bisogna riconoscere due cpu (e serve anche qui un supporto adeguato).

Ha più "senso" (sempre partendo da zero) studiare un sistema di condivisione del memory controller (per le cpu che lo integrano) ad hoc (staccando il controller dai core), e un sistema più sofisticato per la comunicazione dei core e la condivisione della cache. Ma in ogni caso, serve sempre sw ad hoc per sfruttare pienamente le risorse.

SLI è il sistema che consente di accoppiare due schede video in modo che ciascuna renderizzi una parte dello schermo, giusto? Non credo proprio che si possa fare per le cpu: una scheda video è un hw altamente specializzato, che fa sempre e solo determinate operazioni, l'esatto contrario di una cpu general purpouse. I sistemi out of order tentano un riordino (con buoni risultati) delle istruzioni prima di eseguirle, ma non possono certo fare miracolo. Se un problema non è parallelizzato all'origine, o se non è parallelizzabile, c'è poco da fare.

Ciao

Originariamente inviato da erupter
Bhè la disponibilità a "basso" prezzo di tale potenza di calcolo, è qualcosa che secondo me avrà un impatto rilevabile sulla diffusione tecnologica o comunque sulla disponibilità di applicazioni sempre più avanzate (e parlo di RL, come applicazioni biomediche).

l' abbassamento in ambito informatico dei prezzi è qualcosa che si verifica da molto tempo e spero continui anche in futuro, permettendo così di acquistare le macchine attualmente al top a prezzi da entry level ... quello è pacifico, la ridotta rivoluzione a cui mi riferivo è essenzialmente quella dell' ordine di grandezza delle prestazioni ottenibili, non troppo dissimili imho da quelle ottenibili con macchine attualmente esistenti ...;)

Non mi pareva i sistemi termici fossero lineari, però posso anche ricordare male non mi piaceva molto Fisica Tecnica :p
Cmq effettivamente non credo "basti" raddoppiare la superfice radiante.
Il problema è che due core messi accanto, dissipano 1/4 di energia (diciamo, non è detto) dallo stesso lato.
In pratica una parte sola (quella la centro) si ritrova con metà della dissipazione di un intero core.
Ciò non significa soltanto una maggiore efficenza necessaria nel dissipatore, ma anche un riscaldamento delle parti vicine dei core, che a loro volta portano ad alzare i consumi, al degrado delle giunzioni ecc.

ok, forse prima ho semplificato e banalizzato un po' il problema del layout dei componenti sul silicio per ottenere la miglior distribuzione termica/elettrica ... però dubito sia qualcosa di altrettanto serio dello sviluppare un' architettura radicalmente nuova da zero.. :rolleyes:


Per quanto concerne il supporto è verissimo che "effettivamente" le cpu sono due.
Ma il fatto che condividano un unico bus sia per il sistema che per la memoria, fa sì che in linea teorica il sistema potrebbe comportarsi come se ne vedesse una sola.
In pratica potrebbe essere la cpu a smistarsi il lavoro da sola (come fanno le Gf 6800 in SLI).

l' integrazione porterebbe probabilmente ad accorpare anche la logica di arbitraggio, quella di coerenza, gli APIC di due processori, in un unico guscio da chiamare sempre "cpu" (più o meno come quando si integrò per la prima volta la cache L2, prima sempre stata esterna nel processore)
quindi sembrerebbe che "la CPU fa tutto da sola" anche se le stesse funzioni verrebbero eseguite dalle stesse unità logiche, "separate in casa" dai "core" che continuerebbero a implementare l' execution loop tanto quanto prima..
però c' è da tenere presente una cosa: se non erro, sul bus delle cpu viaggiano dati istruzioni e comandi, con delle "tag", sia per identificare la sequenza di risposta (viene effettuato il pipelining e un certo livello di "out of order" sulle richieste alla RAM), sia per distinguere quali istruzioni appartengono al contesto di quale processore, mi pare venga aggiunto un paio di bit in più
ora, se l' obiettivo è mantenere una compatibilità a livello di socket /chipset con qualcosa di attuale, non si dovrebbe alterare il funzionamento e i protocolli delle interfacce northbridge-cpu, al limite spostare dei pezzi , inglobando qualcosa dentro qualcos' altro ...


Questo per dire che mettere due core su una cpu, non è lo stesso che mettere due cpu.
Non so ora esattamente come verrà implementata sta cosa a livello software, ma ritengo che sia molto più facile che non gestire un sistema MP.

forse sarà più facile per gli assemblatori di sistemi e gli upgrade per l' aspetto "esteriore", per come si presenterà il componente col suo package e i soi 775 piuttosto che 940, pin ...
ma secondo me per gli sviluppatori di bios e applicazioni sarà proprio lo stesso che lavorare con 2 cpu, per intel e amd che quei componenti stanno finendo di mettere a punto, quasi lo stesso

in informatica ci si basa sul criterio "poco di nuovo sotto il sole": cose che adesso ci paiono rivoluzionarie sono solo accorgimenti adottati anni fa in ambiti più ristretti o di ricerca, che intel e mad implementano per il mercato di massa: HT è l' implementazione del Simmetric Multi Threading, venuto alla ribalta alla fine degli anni 90... i memory controller integrati, erano stati implementati prima che da amd , dagli Alpha EV7 , sempre la piattaforma Alpha ha sperimentato prima di altre le soluzioni multicore (proprio come possibile implementazione esaustiva SMT), nonchè le interconnessioni punto-punto ... la possibile tecnologia futura che permetterà di far girare concorrentemente più "OS personalities", ha origine nella ricerca sugli exokernel e le VM ...

e poi, le specifiche intel SMP sono quelle, ignorarle vorrebbe dire creare un ulteriore modello di sviluppo, e non poter sfruttare i SW già esistenti , magari specifici per applicazioni serie/scientifiche e già in grado di avvantaggiarsi di CPU multiple sui sitemi di fascia alta, così come sono

A meno che non implementino un controllo automatico tipo lo SLI.

sì ma... un controllo a che livello? O_o
se anche un programma facesse un controllo per decidere se "abilitare" qualcosa, dovrebbe in pratica creare in automatico più thread...mi sa che non si esce dal discorso sui thread
quello che volevo dire prima è che il threading non è così "trasparente" come sembra: deve essere previsto, e il codice deve seguire determinati criteri di design per essere improntato alla thread safety...
se si scrive un programma proteggendo gli accessi concorrenti o mantenendo separate le variabili locali di ogni thread, allora si dovrebbe poter mettere la funzione "controlla se ci sono 2 cpu-> crea un thread per ciascuna"

Permaloso.
La buttavo a ridere su!

chiedo scusa se ho frainteso...però la frase suonava un tantino sarcastica... :O

Mi lascia perplesso l'utilizzo desktop... Mettiamo il caso di avere una CPU single core da 3 Ghz...e supponiamo di sostituirla con una CPU dual core da 2 Ghz per core...
Il risultato sarà che il gioco che prima facevamo girare andrà sicuramente più piano...e questo avverrà per TUTTI i programmi non multithreaded presi singolarmente...
altro discorso se si faranno girare più programmi pesanti contemporaneamente...ad esempio: un client Seti e un codifica MPEG... In tutti i casi del genere si avrà un aumento notevole delle prestazioni rispetto alla stessa situazione (sempre con i soliti due programmi contemporaneamente) con una CPU single core a frequenza maggiore...

Infatti proprio per questo motivo secondo me la frequenza a cui usciranno i primi processori dual core desktop non potrà essere troppo inferiore a quella dei processori single core disponibili in quel momento.
Come farà Intel altrimenti a giustificare un ipotetico PIV 970 dual core con prestazioni inferiori ad un 740, oppure AMD un ipotetico Athlon 5000+ dual core con prestazioni inferiori ad un 3500+, almeno nella maggior parte delle applicazioni standard eseguite singolarmente?
Ah ho sparato dei numeri a caso come model number sia chiaro...

Che pizza questo dual core! Si sbrigassero a farlo, ci stanno illudendo da mesi.

Originariamente inviato da Joe.Bagheera
Infatti proprio per questo motivo secondo me la frequenza a cui usciranno i primi processori dual core desktop non potrà essere troppo inferiore a quella dei processori single core disponibili in quel momento.
Come farà Intel altrimenti a giustificare un ipotetico PIV 970 dual core con prestazioni inferiori ad un 740, oppure AMD un ipotetico Athlon 5000+ dual core con prestazioni inferiori ad un 3500+, almeno nella maggior parte delle applicazioni standard eseguite singolarmente?
Ah ho sparato dei numeri a caso come model number sia chiaro...

soluzione "alla jappilas" : non sparare model number e processor altissimi, ma variare quelli attuali, applicati alle cpu standard, aggiungendo lettere in fondo (intel imho sarebbe stata facilitata se acesse continuato a denotare le cpu con la frequenza) al MN relativo al core singolo...ad esempio

3200+D dove la D indicherebbe appunto il dual ...
oppure pentium 540 ^2 (ad esponente)

secondo me sarebbe una denominazione chiara e concisa per tutti.. ;)

Originariamente inviato da kuru
Che pizza questo dual core! Si sbrigassero a farlo, ci stanno illudendo da mesi.

non è che fare un processore dual core è come preparare il pane, lo fai di notte, lo cuoci e alla mattina presto è già pronto...


E cmq si sbrigassero a che pro?
Ora come ora, gli applicativi che ne trarrebbero un vantaggio considerevole tale da giustificare la spesa sono pochissimi...

x PacManZ :
ti spiace se me la metto in firma?
risp in pvt!

Gli incrementi prestazionali di un software su di un sistema a doppio core non dipendono solo da mono o multi thread. Un software puo' essere multi threading ma con 9 Thread che lavorano al minimo ed 1 che fa il 95% del lavoro totale.
La maggior parte del software per PC di oggi non è scritto per avvantaggiarsi dell'utilizzo di 2 core ed in generale per fare questo il software o quantomeno l'engine vanoo RIPROGETTATI.

Quindi ogni speculazione OGGI è assolutamente non veritiera.
Come esempio basterebbe vedere le prestazioni di software che è stato "portato" su piattaforma Itanium ( Architettura assolutamente parallela) su cui il software non ha enormi vantaggi, a meno che non venga "RIPROGETTATO" appositamente per il MultiProcessing.

E credo che prima che avvenga questo di tempo ne passerà visto che un software progettato per il MultiProcessing ha prestazioni inferiori su di una macchina MonoProcessore ( la totalità dell'esitente oggi ) per via dei frequentissimi e pesanti thread switch necessari a far girare 2 Thread paralleli.

In realtà il thread switch è veramente molto leggero, basta salvare una manciata di registri e basta...

Originariamente inviato da lamp76
Gli incrementi prestazionali di un software su di un sistema a doppio core non dipendono solo da mono o multi thread. Un software puo' essere multi threading ma con 9 Thread che lavorano al minimo ed 1 che fa il 95% del lavoro totale.
qui non ci piove ... d' altra parte posso anche avere 2 applicazioni in contemporanea , di cui uno sia un word processor e l' altra sia UT: ok che si ripartiscono (lo scheduler dell' OS dovrebbe assegnare) una a ciascuna cpu, però uno dei due processori sarà pressochè in "idle"... :rolleyes:
se la distribuzione del carico di lavoro tra più thread fosse sbilanciata potrebbe voler dire o che l' applicazione è scritta male ( e allora si può ovviare, ma non è riprogettazione, è tuning) ... oppure, se l' algoritmo implementato è quello che risolve al meglio il problema, allora c'è poco da fare, l' applicazione avrebbe QUEL modo di funzionare ... a occhio sarebbe quasi meglio non ripartire neppure più thread su 2 cpu diverse, ma lasciare tutti i thread sulla stessa, in tal modo si risparmia dell' inutile context switch sulla seconda
La maggior parte del software per PC di oggi non è scritto per avvantaggiarsi dell'utilizzo di 2 core ed in generale per fare questo il software o quantomeno l'engine vanoo RIPROGETTATI.

mah... bisogna vedere SE si possono riprogettare ... :rolleyes:
Quindi ogni speculazione OGGI è assolutamente non veritiera.
Come esempio basterebbe vedere le prestazioni di software che è stato "portato" su piattaforma Itanium ( Architettura assolutamente parallela) su cui il software non ha enormi vantaggi, a meno che non venga "RIPROGETTATO" appositamente per il MultiProcessing.
itanium pone altri problemi in sede di sviluppo...
se vuoi approfondire, suggerirei la lettura di due splendidi thread, soffermandoti sugli interventi della sorprendente repne scasb e del dott. di Mauro... divertiti ;)
http://forum.hwupgrade.it/showthread.php?s=&threadid=761742
http://forum.hwupgrade.it/showthread.php?s=&threadid=722776
E credo che prima che avvenga questo di tempo ne passerà visto che un software progettato per il MultiProcessing ha prestazioni inferiori su di una macchina MonoProcessore ( la totalità dell'esitente oggi ) per via dei frequentissimi e pesanti thread switch necessari a far girare 2 Thread paralleli.
uhm, io sapevo che, dal momento che i thread appartengono allo spazio di indirizzamanto di uno stesso processo, in realtà non ci sarebbe un cambiamento nel contesto della cpu al passaggio dall' uno all' altro ..:rolleyes:

Originariamente inviato da jappilas
uhm, io sapevo che, dal momento che i thread appartengono allo spazio di indirizzamanto di uno stesso processo, in realtà non ci sarebbe un cambiamento nel contesto della cpu al passaggio dall' uno all' altro ..:rolleyes:

Infatti, il principale vantaggio dei thread rispetto ai processi tradizionali è la maggiore "leggerezza" e velocità nel passaggio da uno all'altro, tanto che tecnicamente vengono definiti "lightweight", contrariamente ai processi "heavyweight". Non vedo perchè il multithreading dovrebbe risultare così lento su macchina monoprocessore

Esempio lampate la lunghezza delle pipeline, se prendessimo per esempio un prescott a 3 ghz che ha 30 stadi di pipeline e lo facessimo andare a 1.5 ghz, non avremmo assolutamente il 50% delle prestazioni, ma MOOLTO meno

Piccola precisazione
Non è vero, primo perchè le prestazioni non aumentano in maniera lineare con l'aumento di frequenza, secondo, anche approssimando ad un andamento lineare non non sono legate da una funzione del tipo y=x (ovvero, se raddoppio la frequenza x del P4, non raddoppio le prestazioni y). Ergo dimezzando la frequenza non otterrò metà delle prestazioni, ma qualcosa in più.

Originariamente inviato da lamp76
Gli incrementi prestazionali di un software su di un sistema a doppio core non dipendono solo da mono o multi thread. Un software puo' essere multi threading ma con 9 Thread che lavorano al minimo ed 1 che fa il 95% del lavoro totale.
La maggior parte del software per PC di oggi non è scritto per avvantaggiarsi dell'utilizzo di 2 core ed in generale per fare questo il software o quantomeno l'engine vanoo RIPROGETTATI.

Quindi ogni speculazione OGGI è assolutamente non veritiera.
Come esempio basterebbe vedere le prestazioni di software che è stato "portato" su piattaforma Itanium ( Architettura assolutamente parallela) su cui il software non ha enormi vantaggi, a meno che non venga "RIPROGETTATO" appositamente per il MultiProcessing.

E credo che prima che avvenga questo di tempo ne passerà visto che un software progettato per il MultiProcessing ha prestazioni inferiori su di una macchina MonoProcessore ( la totalità dell'esitente oggi ) per via dei frequentissimi e pesanti thread switch necessari a far girare 2 Thread paralleli.

si, effettivamente per un'applicazione scientifica, un sistema multprocesore dovrebbe far girare un software effettivamente proggettato per il multitread parallelo, ma, in un sistema "casalingo", i software potrebbero essere riassemblati, senza essere riproggettati.
un sistema "casalingo" effettivamente fa' girare diverse decine di software indipendentemente, quindi si potrebbero instradare sulle diverse CPU;
in piu' un software potrebbe essere proggettato per far girare codice "scollegato" sulle due diverse unita' di calcolo, o meglio ancora, lo stesso software usa le due unita'' di calcolo per la stessa elaborazione che necessita si' di tread consequenziali, ma che possono essere divisi ed elaboratiin diverse parti, tipo gli stream multimediali..
ad esempio un encoder MPEG4 potrebbe lavorare su 2 diverse parti dello streaming di un file, in quanto comunque ci sarebbero dei key frame da dove un ipotetico monocore ricomincerebbe a rilocalizzare i frame successivi, percio' e' indifferente qualnti o quali core eseguano il calcolo, ma e' solo necessario che l'applicazione riassembli poi il tutto in un unico stream (io separo il primo tempo dal secondo su due macchine, perche' non farlo con una e poi ricucire il tutto?)..
insomma, il vantaggio di avere due untita' logiche separate c'e', solo che verranno sfruttate in un modo non efficentissimo in tutte le situazioni; nel caso sopracitato si avrebbe il raddoppio della velocita' del singolo core, in altri casi una unita' di calcolo elabora con un applicazione normale, e l'altra elaborera' per il monitoraggio delle funzioni e tutti i programmini in background che ci sono su un desktop "usato", fermorestando che consumera' sempre poco, grazie al cool'n quiet sulla singola unita' di calcolo (essendo uguale ad un singlecore odierno, anche le features dovrebbero esssere le stesse)..

Originariamente inviato da lamp76
Quindi ogni speculazione OGGI è assolutamente non veritiera.
Come esempio basterebbe vedere le prestazioni di software che è stato "portato" su piattaforma Itanium ( Architettura assolutamente parallela) su cui il software non ha enormi vantaggi, a meno che non venga "RIPROGETTATO" appositamente per il MultiProcessing.

Le prestazioni di un ipotetico dual core dovrebbero essere simili a quelle di un un sistema con due processori a stessa frequenza. Non dovrebbe essere difficile stimare le prestazioni. Al punto che si può cercare di indovinare la frequenza del dual core a partire dall'incremento prestazionale.
Itanium è un'architettura completamente diversa, la EPIC (Explicit Parallel Instruction Computing) è molto più simile all'HT, al punto che richiede codice compilato opportunamente.

E credo che prima che avvenga questo di tempo ne passerà visto che un software progettato per il MultiProcessing ha prestazioni inferiori su di una macchina MonoProcessore ( la totalità dell'esitente oggi ) per via dei frequentissimi e pesanti thread switch necessari a far girare 2 Thread paralleli.
Tutte le applicazioni che sfruttano CPU (calcoli scientifici, 3d, database) sono da anni pronte per il MultiProcessing. Per l'uso quotidiano è più importante che lo sia il sistema operativo (che si mangia la maggior parte della CPU). Windows XP ha già il supporto multi (anche la Home riesce a riconoscerne fino a due), quindi non c'è problema. E' più difficile passare a 64 bit da questo punto di vista.
Poi ci saranno applicazioni non multithread. Ma non credo che porti vantaggio riscrivere notepad per il dual core :p

Originariamente inviato da Banus
Itanium è un'architettura completamente diversa, la EPIC (Explicit Parallel Instruction Computing) è molto più simile all'HT, al punto che richiede codice compilato opportunamente.
Vorrei anche vedere... Ha un altro istruction set...
Inoltre non vedo cosa abbia di simile l'HT con l'EPIC...sono tecnologie completamente diverse... Su EPIC il parallelismo è impostato a livello di codice dalle varie istruzioni... Sono le istruzioni dello stesso thread che vengono predisposte per essere eseguite parallelamente...
Il parallelismo dell'HT è ottenuto su due thread...ed è quindi la CPU a determinare come le istruzioni dei due thread possano essere edeguite parallelamente...

La somiglianza sta nel fatto che in entrambi i casi si ha l'esecuzione parallela di alcune istruzioni pur non avendo due core distinti. Poi come hai giustamente precisato l'Itanium si basa su un paradigma completamente diverso (la sigla EPIC non è scelta a caso ;) ).

Intendevo mostrare che non si può prendere come metro di confronto per le prestazioni di un dual core un processore come l'Itanium che ha un modo di operare molto diverso...

Il paragone non regge: anche P4 e Athlon eseguono istruzioni in parallelo, come Itanium. L'HT, invece, è tutt'altra cosa, come ha detto cionci...

Originariamente inviato da cdimauro
Il paragone non regge: anche P4 e Athlon eseguono istruzioni in parallelo, come Itanium. L'HT, invece, è tutt'altra cosa, come ha detto cionci...
Infatti...

Che HT è l'istruction level parallelism abbiano lo stesso scopo non lo metto in dubbio...cioè aumentare la % di tempo di allocazione di ogni unità di alaborazione... Ma dire che si assomiglino...è dura ;)

L'aumento dell'ILP non porta sempre benefici, comunque: possiamo ottenere un aumento dell'IPC a livello "globale" (dell'intera macchina), mentre a livello "locale" (per i singoli thread) rimane lo stesso o addirittura peggiora (caso abbastanza comune, visto il contendersi delle risorse della CPU dei due thread).
Questo nel caso di P4 o soluzione CMT, mentre nel caso dell'Itanium trovo difficile pensare a dei netti miglioramenti rispetto a quel che già avviene con i processori x86 da un po' di anni a questa parte, e in generale a quelli che implementano out-of-order execution e speculative execution...

massimo 55% poichè nonostante i due processori, tutto ciò che sta oltre il processore è medesimo nel single core!

Ma io dico: a sQuola ci sei stato? Eventualmente, hai passato il tempo a scaldare il banco? Perché non si capisce una mazza di quello che scrivi!!! :rolleyes: :muro:

Originariamente inviato da cionci
Il risultato sarà che il gioco che prima facevamo girare andrà sicuramente più piano...e questo avverrà per TUTTI i programmi non multithreaded presi singolarmente...

Non e' detto, nel senso che e' quasi sicuramento vero per tutti i giochi fino ad oggi, ma sara' il contrario per i giochi futuri. Si sta iniziando a sviluppare i giochi per le console di nuova generazione che prevedono uso massiccio di piu' core/cpu e le architetture si stanno muovendo in quella direzione.
In futuro ci saranno piu' giochi che faranno automaticamente uso di piu' core se disponibili.

Originariamente inviato da jappilas
uhm, in certi giochi ci si potrebbe anche avvantaggiare della programmazione multithread, in quanto un gioco non è solo il suo engine 3D...
ma anche la parte che si occupa del suono, dell' IA dei personaggi , dell' input da tastiera/mouse/pad, dell' eventuale feedback vibrazionale o di forza...
ovvero le routine che effettuano chiamate a librerie diverse (direct input, directsound, direct3d... ) dovrebbero poter essere implementate in thread concorrenti
ora, magari la parte di simulazione fisica stresserebbe abbastanza la cpu su cui girerebbe, ma se si riservasse un core da 2 ghz per il solo "input loop" e l'audio, sarebbe, come direbbero in english... "overkill" ...
e può darsi che la differenza col fare girare il gioco su una sola cpu, risulti minima come pure consistente, valevole la complessità di sviluppo aggiunta che comporta lo sviluppo thread safe, complessità che si aggiunge a quella tipica dei videogiochi, della creazione di ambienti, personaggi, artwork, script , ecc ecc

Qui ci sono due scuole di pensiero o due diverse architetture.

La prima architettura prevede che ogni sottosistema viaggi nel suo thread e, possibilmente, sul suo processore se presente, quindi l'AI avra' il suo thread, la fisica il suo thread, il motore 3d il suo thread. E' la soluzione piu' semplice da implementare, ma non quella che fa miglior uso delle risorse.
Che accade se il motore 3d e' molto meno pesante dell'IA e della fisica e passasse la maggior parte del tempo ad aspettare, tenendo occupato la sua cpu? Il sistema sarebbe sottoutilizzato. Si puo' ovviare parzialmente a questo problema mandando in sleep i thread in attesa e con accorto uso di primitive di sincronizzazione, ma c'e' un'altra soluzione...

La seconda architettura prevede un sistema che sia in grado di eseguire dei "lavori" (job) ed ogni sottosistema sottopone i lavori in una coda d'elaborazione. Il sistema di scheduling si occupa di allocare le cpu a disposizione ai lavori (job) da eseguire di modo da usare al massimo il numero di unita' di elaborazione disponibili. Questa architettura e' decisamente piu' complicata da implementare della prima.

Originariamente inviato da fek
La seconda architettura prevede un sistema che sia in grado di eseguire dei "lavori" (job) ed ogni sottosistema sottopone i lavori in una coda d'elaborazione[...]

Ti riferisci a schedulazioni tipo shortest job first et similia? Non danno qualche problema per la schedulazione a breve termine e sistemi interattivi rispetto ai task suddivisi in thread? Oppure alla schedulazione a code multilivello (controreazione?), con "schedulatori" diversi in base alla priorità e coda (insieme di code) unica per tutti i processori presenti? Se le code associate a ciascun processore (sottosistema) sono distinte c'è comunque il rischio che alcuni processori vadano in idle mentre altri sono oberati di lavoro... :wtf:

Forse una soluzione potrebbe essere quella di sfruttare i processori simulando la pipeline delle CPU:
1) una o più CPU si occupano di effettuare tutti i calcoli dell'A.I. e della fisica, sistemando i risultati in un buffer.
2) una o più CPU leggono questo buffer si occupano di effettuare il ricalcolo della scena, della spedizione dei dati alla GPU, e il calcolo dell'audio
Supponendo di avere 2 buffer per i dati, che chiamiamo A e B, quando 1) lavora sul buffer A, 2) usa il buffer B; al successivo "ciclo di pipeline", 1) lavora su B e 2) su A, e così via.
In questo modo le CPU di ogni "stadio" della pipeline lavorano a pieno regime senza badare a ciò che fanno le CPU dell'altro "stadio".

Forse una soluzione potrebbe essere quella di sfruttare i processori simulando la pipeline delle CPU

piu processori, piu lavori in parallelo se c'e indipendenza dei dati di origine;
pipeline, computazione in sequenza, dipendenza dei dati dal risultato precendete, nessun parallelismo possibile(parlo di pipeline classica, non so come funziona ht, anche se ho un idea di come potrebbe essere che mi sembra coerente, cio non toglie che la pipeline sia una catena di montaggio, quindi sequenziale, non parallelizzabile).

concordo che ogni thread potrebbe avere un buffer su cui fare switching per non lasciare processori in attesa del thread piu pesante che finisca la sua computazione

io rimango del idea di spezzare in thread e sfruttare primitve di locking per il codice tipicamente sequenziale, scriversi un proprio gestore delle unita atomiche di esecuzione e uno sbattimento quando dovrebbe essere il so a gestire i thread con le loro priorita spezzandoli su piu cpu,il guadagno di scriversi il proprio non penso porti a vantaggi consistenti.

Originariamente inviato da Mason
io rimango del idea di spezzare in thread e sfruttare primitve di locking per il codice tipicamente sequenziale, scriversi un proprio gestore delle unita atomiche di esecuzione e uno sbattimento quando dovrebbe essere il so a gestire i thread con le loro priorita spezzandoli su piu cpu,il guadagno di scriversi il proprio non penso porti a vantaggi consistenti.
Magari valutando bene il "peso" dei vari lavori sarebbe possibile accorpare vari lavori che potrebbero anche essere svolti parallelamente in un unico thread creando in questo modo due soli thread di "peso" più o meno simile...

Sicuramente questa soluzione funzionerebbe bene in un sistema dual processor, ma non in un sistema quad...magari con una semplice rilevazione di numero e tipo di CPU si potrebbe scegliere la configurazione migliore...

Originariamente inviato da cdimauro
Forse una soluzione potrebbe essere quella di sfruttare i processori simulando la pipeline delle CPU:
1) una o più CPU si occupano di effettuare tutti i calcoli dell'A.I. e della fisica, sistemando i risultati in un buffer.
2) una o più CPU leggono questo buffer si occupano di effettuare il ricalcolo della scena, della spedizione dei dati alla GPU, e il calcolo dell'audio
Supponendo di avere 2 buffer per i dati, che chiamiamo A e B, quando 1) lavora sul buffer A, 2) usa il buffer B; al successivo "ciclo di pipeline", 1) lavora su B e 2) su A, e così via.
In questo modo le CPU di ogni "stadio" della pipeline lavorano a pieno regime senza badare a ciò che fanno le CPU dell'altro "stadio".

Così, a prima vista, sembra un po' uno schema doppio produttore-consumatore, in cui ogni sottosistema si comporta come produttore e consumatore. Forse si potrebbe fare qualcosa di simile con un buffer unico trattato logicamente come due di dimensioni variabili, mediante un sistema di indici che consenta:
a) di "bloccare" una quantità di dati congrua al problema (interdipendenti) e
b) poter "saltare" il blocco in fase di elaborazione da parte dell'altro thread e accedere a parti non ancora elaborate da nessuno dei due.
In ogni caso, sia che i buffer siano distinti fisicamente, sia che lo siano logicamente, si dovrebbe evitare che vengano elaborati dati non completamente processati dall'altro "stadio", per evitare incoerenze, salvo prevedere un meccanismo di validazione del risultato simile a quello che, mi dicevi, presenta itanium.

Una cosa però non ho capito sullo schema a buffer distinti: durante l'elaborazione ciascun buffer serve da imput per uno stadio e output per l'altro, oppure ciascuno è usato in modo "esclusivo" in ciascuna fase? Cioè 1 legge da A e produce in B mentre 2 consuma i dati già prodotti in B e scrive su aree non in fase di elaborazione in A, e in tal caso non serve lo switch tra i buffer, oppure a regime 1 elabora e modifica i dati in A, mentre 2 fa altrettanto in B, quindi avviene lo switch? Ma in questo caso uno stadio non deve attendere che il primo a cominciare completi la prima elaborazione di tutto un buffer prima di entrare in esecuzione? oppure all'inizio si segue il primo meccanismo? C'è anche la possibilità che sia necessaria una prima elaborazione da un solo "stadio" su tutti i dati iniziali, però cominciare il prima possibile anche il secondo non guasterebbe. In ogni caso, non c'è sempre la possibilità che uno stadio termini prima e debba aspettare che anche l'altro termini e possa cominciare una nuova fase? Però, sui dati pronti, ogni stadio si comporterebbe in effetti in maniera indipendente, attendendo poi l'arrivo di dati "freschi".

Originariamente inviato da cionci
Magari valutando bene il "peso" dei vari lavori sarebbe possibile accorpare vari lavori che potrebbero anche essere svolti parallelamente in un unico thread creando in questo modo due soli thread di "peso" più o meno simile...

Forse non è necessario: sincronizzi i thread in modo che liberino la cpu appena terminano (o devono aspettare il risultato di altre elaborazioni) e lo notifichino agli altri, così, se le cpu sono due, mentre una è impegnata col thread più pesante, l’altra elabora sequenzialmente i thread più leggeri che erano stati pensati per un’esecuzione parallela.

Sicuramente questa soluzione funzionerebbe bene in un sistema dual processor, ma non in un sistema quad...magari con una semplice rilevazione di numero e tipo di CPU si potrebbe scegliere la configurazione migliore...

In teoria è una bella idea, purtroppo l'esito è subordinato all’interdipendenza dei dati nei calcoli, dipende da quanto i dati si possono spezzare ed elaborare in parallelo. Per il calcolo matriciale, in genere è abbastanza semplice (caso banale, la somma), in altri molto meno. Comunque sarebbe interessante poter stabilire, ad alto livello (con un linguaggio ad hoc) delle “regole” per la suddivisione dei calcoli e il riordino (eventualmente la rielaborazione) dei risultati parziali, definendo una struttura di base per thread che possano essere replicati in numero proporzionale alle cpu e lavorare su una quantità variabile dei dati, in modo coerente al modello di coordinazione scelto e “schematizzato” con le regole. Ovviamente, tutto dipenderebbe sempre dal problema.

Chiarisco meglio il mio pensiero. Quello che ho descritto ricalca un po' la tecnica del double buffering, e risulta anche estremamente semplice da realizzare, poiché richiede la sincronizzazione fra le CPU di ogni pipe solamente alla fine del loro lavoro, senza appesantire il sistema con la gestione di thread, locking e politiche di gestione di code o allocazione di risorse.

Il concetto chiave è che quando una "pipe" utilizza un buffer, vi accede in maniera esclusiva, e lo stesso avviene per l'altra "pipe" che lavora esclusivamente sull'altro buffer.

Provo a fare un disegnino che ricalca il funzionamento del meccanismo al variare dei "cicli" della "pipeline":


1 2 3 4 5
-----------------
Pipe1|A|B|A|B|...
Pipe2| |A|B|A|...
-----------------

All'inizio lavora solamente la prima pipe sul buffer A, e la seconda rimane ferma (non ha dati da processare, chiaramente). Quando la prima pipe completa il lavoro, lo "passa" alla seconda pipe, che lo processa, mentre lei comincia un nuovo lavoro sul buffer B. E così via.

E' il classico sistema del produttore-consumatore, oppurtunamente "parallelizzato" per realizzare giochi. Lo switch dei buffer di dipendenza è chiaramente "logico" e non fisico.

E' chiaro che potrebbe succedere che una "pipe" finisca il suo lavoro, mentre la seconda ancora no, per cui rimane in attesa, ma questo dipende anche da come viene strutturato il sistema: magari per AI e calcolo della fisica basta una sola CPU (pipe con 1 CPU), mentre per la generazione della geometria della scena ne servono due, e un'altra per il sonoro (pipe con 3 CPU), ecc.
Le CPU, inoltre, potrebbero essere completamente diverse sia come architettura sia come frequenza di lavoro: l'importante è che svolgano bene il particolare lavoro per cui saranno utilizzate.

Il problema, quindi, è di cercare di calibrare bene le pipe, senza sbilanciarle troppo. Questo si può fare con varie simulazioni per cercare di capire quanto potrebbe incidere ogni tipo di lavoro, per poi simulare il comportamento all'interno di una pipeline come quella ipotizzata.

Originariamente inviato da xeal
Forse non è necessario: sincronizzi i thread in modo che liberino la cpu appena terminano (o devono aspettare il risultato di altre elaborazioni) e lo notifichino agli altri, così, se le cpu sono due, mentre una è impegnata col thread più pesante, l’altra elabora sequenzialmente i thread più leggeri che erano stati pensati per un’esecuzione parallela.

Sì e no... Se ci sono più thread leggeri in esecuzione contemporanea...i thread (a meno che non siano in sleep) vengono comunque portati avanti da, probabilmente, entrambe le CPU...interferendo con il thread pesante... Quindi o si implementa una politica di semafori per determinare la sequenza dei thread o si richiamano in sequenza le varie funzioni dei thread leggeri (qualsiasi politica scelta farebbe poca differenza)... Ma se si mandano in esecuzioni tutti e non sono bloccati, verranno comunque portati avanti a scapito del thread pesante...
Originariamente inviato da xeal
In teoria è una bella idea, purtroppo l'esito è subordinato all’interdipendenza dei dati nei calcoli, dipende da quanto i dati si possono spezzare ed elaborare in parallelo. Per il calcolo matriciale, in genere è abbastanza semplice (caso banale, la somma), in altri molto meno.
Io comunque non parlavo di operazioni semplici, ma di macrooperazioni come il calcolo dell'IA, del sonoro e dei movimenti...
La tua idea sarebbe comunque interessante...mettiamo che la CPU A stia eseguendo un thread e questo thread abbia bisogno di una operazione lunga come potrebbe essere un calcolo matriciale molto complesso... Questo thread potrebbe mettere in una coda il tipo di operazione e l'indirizzo degli operatori e del risultato...e restare in attesa fino a quando questo risultato non ritorna... Nella CPU B gira un thread che si occupa di fare questi calcoli complessi...
Allo stesso tempo l'altra CPU (poi lo schedulatore le potrebbe tranquillamente invertire) svolge gli altri compiti fino a quando non hanno bisogno di un calcolo complesso...
Ovviamente sarebbe da valutare il "peso" dei calcoli e la freequenza ocn il quale questi avvengono...

Originariamente inviato da cdimauro
Chiarisco meglio il mio pensiero. Quello che ho descritto ricalca un po' la tecnica del double buffering, e risulta anche estremamente semplice da realizzare […]Il concetto chiave è che quando una "pipe" utilizza un buffer, vi accede in maniera esclusiva, e lo stesso avviene per l'altra "pipe" che lavora esclusivamente sull'altro buffer. […]All'inizio lavora solamente la prima pipe sul buffer A, e la seconda rimane ferma (non ha dati da processare, chiaramente). Quando la prima pipe completa il lavoro, lo "passa" alla seconda pipe, che lo processa, mentre lei comincia un nuovo lavoro sul buffer B. E così via.

Interessante, ma c’è una cosa che ancora non capisco: i buffer devono contenere di volta in volta dati diversi, oppure gli stessi modificati? Cioè, la pipe per l’AI e la fisica elabora i dati relativi ad alcuni personaggi ed oggetti sul buffer A, quindi lo passa alla pipe 2 per il calcolo della geometria per poi tornare ad elaborare nuovi oggetti sul buffer A, oppure dovrà rielaborare gli stessi oggetti (chiaramente elaborando ad ogni passo tutta la scena e non una parte)? Credo che la prima ipotesi debba essere quella giusta, perché nel secondo caso potrebbero nascere problemi di coerenza dei dati dovuti alla dipendenza dell’elaborazione di ciascuna pipe (in particolare la 1) sia dai calcoli effettuati in precedenza, sia da quelli dell’altra pipe, richiedendo una diversa sincronizzazione.

E' chiaro che potrebbe succedere che una "pipe" finisca il suo lavoro, mentre la seconda ancora no, per cui rimane in attesa, ma questo dipende anche da come viene strutturato il sistema: magari per AI e calcolo della fisica basta una sola CPU (pipe con 1 CPU), mentre per la generazione della geometria della scena ne servono due, e un'altra per il sonoro (pipe con 3 CPU), ecc.

Però non si può sapere a priori quante cpu/core si avranno a disposizione (a meno che non si progetti un gioco specificamente per una console); chiaramente si può stabilire la situazione ottimale, magari cercando, in condizioni diverse, di utilizzare le cpu dell’altra pipe quando sono in attesa, ma questo complicherebbe lo schema, ci riavvicineremmo alla gestione di thread tradizionali. Comunque non so fino a che punto la gestione della geometria e dell’audio sia molto più pesante dell’AI e della fisica in simulazioni con un certo realismo, considerando la gestione degli urti (per evitare l’attraversamento di oggetti, o simulare urti veri e propri) e la visibilità degli elementi della scena (e dei personaggi) per i personaggi (ok, era un esempio :)). In genere, per quanto ne so, si usano dei bound (prevalentemente una o più sfere combinate) per delimitare i contorni degli oggetti e, credo, anche il campo di visibilità. Per gli urti si calcolano le intersezioni tra gli inviluppi che definiscono i contorni degli oggetti, probabilmente calcolandone preliminarmente la distanza, riferita a punti specifici, per evitare calcoli inutili (lo z-buffer potrebbe servire anche qui); per la visibilità si può calcolare l’intersezione tra la sfera di visibilità e i “contorni” dei vari elementi presenti nello stesso ramo del grafo di scena (mi pare che ormai si usino grafi un po’ dappertutto), valutando l’eventuale copertura parziale o totale da parte di altri oggetti, con algoritmi simili a quelli per determinare la “visibilità” di un poligono da una luce (ci sono meno calcoli, non dovendo valutare tutti i vertici e i lati, ma il peso dipende da quanto è “preciso” l’inviluppo attorno all’oggetto). Poi, ci possono essere tutte le semplificazioni possibili e gli “artefatti” (teste sporgenti da un muro e gente che ti spara dalla stanza accanto) immaginabili, come mille “trucchetti” che non conosco per ottenere buoni risultati con pochi calcoli. Ovviamente una simulazione mirata darebbe informazioni precise sulla configurazione “migliore” e sul peso effettivo, come hai detto tu.

Originariamente inviato da cionci
Sì e no... Se ci sono più thread leggeri in esecuzione contemporanea...i thread (a meno che non siano in sleep) vengono comunque portati avanti da, probabilmente, entrambe le CPU...interferendo con il thread pesante... Quindi o si implementa una politica di semafori per determinare la sequenza dei thread o si richiamano in sequenza le varie funzioni dei thread leggeri (qualsiasi politica scelta farebbe poca differenza)... Ma se si mandano in esecuzioni tutti e non sono bloccati, verranno comunque portati avanti a scapito del thread pesante...

Beh, si, dipende dalla gestione delle risorse da parte del sistema operativo, in particolare con i time slice e la schedulazione round robin. Però non si otterrebbe lo stesso risultato dando al thread più pesante una priorità superiore? Oppure col round robin non funziona (non ricordo questo particolare…)? Comunque, l’uso dei semafori forse può consentire una variazione più facile del numero di thread da eseguire in parallelo in base al numero di cpu.

Originariamente inviato da xeal
Interessante, ma c?è una cosa che ancora non capisco: i buffer devono contenere di volta in volta dati diversi, oppure gli stessi modificati? Cioè, la pipe per l?AI e la fisica elabora i dati relativi ad alcuni personaggi ed oggetti sul buffer A, quindi lo passa alla pipe 2 per il calcolo della geometria per poi tornare ad elaborare nuovi oggetti sul buffer A, oppure dovrà rielaborare gli stessi oggetti (chiaramente elaborando ad ogni passo tutta la scena e non una parte)? Credo che la prima ipotesi debba essere quella giusta, perché nel secondo caso potrebbero nascere problemi di coerenza dei dati dovuti alla dipendenza dell?elaborazione di ciascuna pipe (in particolare la 1) sia dai calcoli effettuati in precedenza, sia da quelli dell?altra pipe, richiedendo una diversa sincronizzazione.
In effetti dovevo essere più chiaro. :p
I due buffer sono suddivisi logicamente in due parti, a seconda del tipo di dati da manipolare. L'utilizzo del buffer precedente per generare i dati di quello successivo è ammesso, chiaramente a sola lettura.

Ciclo B (pipe1) / A (pipe 2)
La pipe 1 elabora AI e fisica utilizzando i dati di questo tipo del Buffer A e mette i risultati nella parte del buffer B, sempre per questo tipo di dati.
La pipe 2 preleva dal buffer A i dati generati per AI e fisica, e li utilizza per generare quelli dalla geometria che trasferisce nell'apposita parte del buffer A.

Ciclo A (pipe1) / B (pipe 2)
La pipe 1 elabora AI e fisica utilizzando i dati di questo tipo del Buffer B e mette i risultati nella parte del buffer A, sempre per questo tipo di dati.
La pipe 2 preleva dal buffer B i dati generati per AI e fisica, e li utilizza per generare quelli dalla geometria che trasferisce nell'apposita parte del buffer B.
Però non si può sapere a priori quante cpu/core si avranno a disposizione (a meno che non si progetti un gioco specificamente per una console); [...]Ovviamente una simulazione mirata darebbe informazioni precise sulla configurazione ?migliore? e sul peso effettivo, come hai detto tu.
Era soltanto un esempio. :) E' chiaro che chi progetta una console farà delle simulazione per cercare di capire in che modo bilanciare il sistema.

Forse la soluzione migliore sarebbe quella di avere a disposizione molte CPU "generiche", e lasciare poi a chi sviluppa i giochi il compito di utilizzarle a piacere per implementare il meccanismo a pipeline. :D

Originariamente inviato da cdimauro
I due buffer sono suddivisi logicamente in due parti, a seconda del tipo di dati da manipolare.[...]

Ok, adesso è chiaro :). Dovrebbe funzionare bene, os permettendo (non vorrei che si mettesse a rompere le scatole perchè comanda lui, le cpu le distribuisce lui, se non glielo lasci fare si mette a piangere e con te non ci gioca più... :D). A parte gli scherzi, una console credo che lasci sufficiente autonomia, con un pc magari ci si può arrangiare lo stesso (qualche os lascia decidere su quale cpu far girare un processo? forse giocando con la priorità dei thread e usando un oggetto con i due buffer che presenta dei metodi di lettura e scrittura non sincronizzati, più uno sincronizzato per lo switch chiamato al termine dell'esecuzione da parte di una "pipe", che si "addormenta" se l'altra non è ancora pronta, qualcosa si riesce a fare...).

Veramente questo sistema a "pipeline" l'ho pensato proprio per evitare di avere un s.o. con cui avere a che fare: molto meglio avere il controllo completo della macchina, eventualmente supportato da alcune librerie per semplificare l'accesso alle risorse...

Quindi pensavi prevalentemente alle console, giusto?

Esattamente.

Originariamente inviato da cdimauro
Forse la soluzione migliore sarebbe quella di avere a disposizione molte CPU "generiche", e lasciare poi a chi sviluppa i giochi il compito di utilizzarle a piacere per implementare il meccanismo a pipeline. :D
E' molto simile a quella che sembra sarà la struttura della Playstation 3. Infatti per le console è un'architettura molto potente e versatile.

Appunto. Ma bisognerà imparare a sfruttarla come si deve. Anche il Saturn aveva due processori per il calcolo, ma c'è voluto tempo per riuscere a sfruttarli come si deve (nel frattempo la console è defunta... :D :( ) Lo stesso si è verificato con la PS2: delle due unità vettoriali, generalmente se n'è usata soltanto una...

Per la PS3 si parla dell'uso di OpenGL embedded come libreria di supporto.
E' una buona soluzione dare libreria ma anche strumenti che permettano di gestire direttamente i processori. Non si costringe gli sviluppatori a prendere confidenza con l'architettura sin dall'inizio.
Con a PS2 erano fornite librerie di supporto ma erano parecchio limitate e con qualche bug. E infatti ha fatto bestemmiare parecchi sviluppatori :D :D

Mi chiedo se un'architettura ibrida SIMD/MIMD, cioè più ALU gestite da un'unità generica e più unità nello stesso chip sfonderà anche nei PC.
E' difficile aumentare il numero di core con unità complesse come quelle attuali. Infatti per ora si parla di 4 core con i 65 nm, che sono ancora lontani...

Originariamente inviato da Banus
Per la PS3 si parla dell'uso di OpenGL embedded come libreria di supporto.
E' una buona soluzione dare libreria ma anche strumenti che permettano di gestire direttamente i processori. Non si costringe gli sviluppatori a prendere confidenza con l'architettura sin dall'inizio.
Bisogna vedere se questa scelta comporterà vincoli nell'utilizzo delle CPU.
Con a PS2 erano fornite librerie di supporto ma erano parecchio limitate e con qualche bug. E infatti ha fatto bestemmiare parecchi sviluppatori :D :D
Non è un caso che le grandi software house abbiano preferito scrivere i loro engine facendone a meno... ;)
Mi chiedo se un'architettura ibrida SIMD/MIMD, cioè più ALU gestite da un'unità generica e più unità nello stesso chip sfonderà anche nei PC.
Penso di sì: il futuro è nel multicore, causa vincoli della tecnologia che stiamo raggiungendo. Ma non penso che ci saranno "unità dedicate" per il controllo e il coordinamento delle altre, ma saranno tutte equivalenti.
E' difficile aumentare il numero di core con unità complesse come quelle attuali. Infatti per ora si parla di 4 core con i 65 nm, che sono ancora lontani...
Considera che i tre core presenti nel G5 saranno integrate nella CPU con processo a 65nm: mettere assieme 4 core x86 non lo vedo così complicato, con la stessa tecnologia.
Siano essi RISC o CISC, ormai bene o male i chip hanno raggiunto tutti un'elevata complessità, e un notevole numero di transistor occupati...

Originariamente inviato da cdimauro
[...]
E' chiaro che potrebbe succedere che una "pipe" finisca il suo lavoro, mentre la seconda ancora no, per cui rimane in attesa, ma questo dipende anche da come viene strutturato il sistema: magari per AI e calcolo della fisica basta una sola CPU (pipe con 1 CPU), mentre per la generazione della geometria della scena ne servono due, e un'altra per il sonoro (pipe con 3 CPU), ecc.
Le CPU, inoltre, potrebbero essere completamente diverse sia come architettura sia come frequenza di lavoro: l'importante è che svolgano bene il particolare lavoro per cui saranno utilizzate.
[...]
mi ricorda l'Amiga
(bei tempi!)

Però aveva una sola CPU... ;)