Il futuro dei processori è nel Dual Core

[Denton84]

Originariamente inviato da task-
scalderanno anche di meno, ma non consumeranno il doppio?
Avanti di questo passo tra un annetto o 2 tra schede video a molex e proci 2dual core un PC non consumerà un pochino troppo?
Oltre che l'abbonamento adsl servirà pagare anche un abbonamento dedicato all' ENEL

non penso che sarà così, anzi secondo me l'introduzione del dual core ha come obiettivo principale anche il poter scalare maggiormente i consumi.

Del resto le applicazioni principali non sfruttano mai completamente la cpu, anzi una minima parte di quelle recenti, ma le cpu monocore non possono disattivare dei transistor ma al limite scalare di freqeunza, intel per sfruttarli maggiromente quindi ha introdotto l'ht.

Ma con una soluzione dual core penso sia possibile disattivare un core quando non serve delegando il compito all'altro, e si hanno consumi sensibilmente inferiori con due core da 2ghz rispetto a uno di 3ghz di pari architettura se si utilizzano in questo senso, dato che quando non c'è l'utilizzo massimo lavora solo uno di questi due.

Io penso agiranno in questo modo.

Alla fine tranne i giochi niente va a occupare la cpu completamente, anche con programmi pesanti c'è ingente richiesta di memoria, ma la cpu viene sfruttata appieno molto rararemente, forse all'avvio e in alcuni processi come la renderizzazione, ma non durante tutto l'utilizzo del programma.


edit, alla fine era stato tutto già detto sono arrivato tardi come al solito

sorry

[cionci]

Originariamente inviato da Trabant
Mi chiedo - premetto: da ignorante in materia! - perchè invece di rincorrere ottimizzazioni sempre più spinte delle CPU, non si pensa ad introdurre delle piattaforme multiprocessore anche nel mercato consumer?

E' quello che stanno cercando di fare con queste CPU multicore... Sono di fatto equivalenti ad un sistema dual CPU...l'unica differenza è che condividono lo stesso canale con la memoria...
Ed è un modo per far calare i costi di produzione delle schede madri dual (layout + semplice) e dei processori (costruire due CPU che condividono la circuiteria di interfaccia verso l'esterno ed il package costa meno di produrre due CPU separate in due package)...

[cionci]

Originariamente inviato da Banus
L'HT è fatto in modo da essere completamente trasparente all'applicazione, è il processore a riordinare le istruzioni secondo una certa euristica e mandarle in unità separate... Non ho idea invece di come si potrebbe rendere trasparente a un processo non multithreaded l'uso simultaneo di 2 CPU... è estremamente complicato..

Le rioridna, ma sono di fatto applicazioni multithreaded !!! Di fatto nella CPU ci sono due flussi di istruzioni separati (due thread) "mescolati" ad hoc per occupare in percentuale maggiore le unità di esecuzione

[cionci]

Originariamente inviato da lucusta
e anche possibilmente dello stesso lotto ( credo che arrivi a dire anche la massima distanza che dovrebbe esserci tra le due cpu sul wafer, o che devono appartenere allo stesso quadrante, ma non sono sicuro); questo perche' le minime differenze di assorbimento potrebbero procurare dei problemi in quanto a stabilita'.. in un singolo die con due core, il tutto si annulla, essendo core adiacenti.

Guarda...questo è opinabile... Se leggi la recensione dell'Opteron 250 su Techreport vedrai che per sbaglio hanno ricevuto un sistema dual Xeon funzionante in cui una CPU lavorava a 3.2. Ghz e l'altra 3.06 Ghz !!!

[lucusta]

se e' per questo, e' piu' che opinabile..
ricordo di esperimenti con p3 a differenti mhz (e funzionavano), con differenti tipi di cpu, come celeron mendocino e p3, e funzionavano, e con tutto il marasma che c'e' sulle mod per bp6 (che scheda!), dove si potevano montrare i mendocino anche a differenti moltiplicatori;
questo non significa che nei datasheet intel non c'era scritto quello che ti ho detto.
Intel ci tiene a puntualizzare certe cose..

di sicuro oggi le cose sono molto diverse, in quanto le schede dual hanno molte volte vrm separati, dovuto anche al consumo di un singolo processore.

[BlackBug]

Bella scoperta han fatto alla AMD...è come se venissero da me e mi dicessero dobbiamo aumentare la potenza di sto motore e io gli dicessi...aumentiamo la cilindrata!!!Ora con il costo del petrolio che abbiamo dovrebbero cercare di ottenere di + spendendo meno energia elettrica(che specialmente in italia arriva dal petrolio)...

[Denton84]

Originariamente inviato da BlackBug
Bella scoperta han fatto alla AMD...è come se venissero da me e mi dicessero dobbiamo aumentare la potenza di sto motore e io gli dicessi...aumentiamo la cilindrata!!!Ora con il costo del petrolio che abbiamo dovrebbero cercare di ottenere di + spendendo meno energia elettrica(che specialmente in italia arriva dal petrolio)...

è quello che stanno cercando di fare.
che a qualcuno appena sente parlare di due core senza conoscere niente in merito (come tutti o la maggiorparte del resto) sbotti con la sua idea che raddoppiano i consumi non vuol dire che sia la verità.

Sicuramente consumano il doppio di un sistema monocore di pari frequenza a regimi al massimo, ma:
1) non sappiamo come si comportano a regimi + bassi e quindi su tempi di utilizzo benm maggiori che quelli di regimi di occupazione cpu alta.

2) anche a regimi alti un sistema dual core non consuma probabilmente + corrente di un sistema monocore di PARI PRESTAZIONI anzichè pari frequenza.

è ovvio che due core consumano + di uno, ma vanno anche + di uno, quindi il confronto di consumi deve essere fatto con un monocore che va uguale, non con un monocore che va la metà

[painlord2k]

Locusta e gauss75 hanno fatto degli ottimi posts.

La soluzione multi-CPU, inoltre ha dei vantaggi non citati:

1) Minor tempo sprecato per passare da un processo ad un'altro sulla stessa CPU (ottimo se uno ha molti processi e programmi aperti nello stesso momento);

2) il S.O. non può venir bloccato da una applicazione che non rilascia il controllo della CPU.

3) C'è meno bisogno di usare gran parte della CPU per prevedere quali saranno le istruzioni che saranno eseguite, quindi meno tempi morti nei quali la CPU non fa nulla mentre le pipe si svuotano e si riempiono, e sopratutto pipe più corte di quelle follemente lunghe che ci sono ora.

3) Nello stesso silicio lasciato libero da questa circuiteria, si potra implementare qualche cosa di diverso, come ha fatto VIA con le sue ultime CPU:
AES, RSA, SHA-1, SHA-2 e un vero generatore di numeri casuali.
Oppure cominciare a implementare dei FPGA all'interno delle CPU, per poter elaborare istruzioni specifiche, altamente impegnative, all'interno della CPU, quando queste sono richieste e su richiesta del programma o del S.O. (per esempio, se il programma deve usare la CPU intensivamente per calcolare lo SHA-1 hash, l'FPGA viene programmato per calcolare lo SHA-1; un'altro programma potrebbe fare in seguito lo stesso per un'altra istruzione specifica).
L'approccio FPGA da molta più flessibilità, ma è più complesso da realizzare (non moltissimo, basterebbe avere delle librerie adatte) e meno performante di quello di implementare direttamente in HW le stesse funzioni (circa 10x).

[cdimauro]

Originariamente inviato da painlord2k
La soluzione multi-CPU, inoltre ha dei vantaggi non citati:

2) il S.O. non può venir bloccato da una applicazione che non rilascia il controllo della CPU.

A meno che non si trovi all'interno di sezioni critiche.

3) C'è meno bisogno di usare gran parte della CPU per prevedere quali saranno le istruzioni che saranno eseguite, quindi meno tempi morti nei quali la CPU non fa nulla mentre le pipe si svuotano e si riempiono, e sopratutto pipe più corte di quelle follemente lunghe che ci sono ora.

Questo non c'entra nulla col fatto di avere sistemi dual-core.

3) Nello stesso silicio lasciato libero da questa circuiteria, si potra implementare qualche cosa di diverso, come ha fatto VIA con le sue ultime CPU:
AES, RSA, SHA-1, SHA-2 e un vero generatore di numeri casuali.

Un generatore di veri numeri casuali, caso mai...

Oppure cominciare a implementare dei FPGA all'interno delle CPU, per poter elaborare istruzioni specifiche, altamente impegnative, all'interno della CPU, quando queste sono richieste e su richiesta del programma o del S.O. (per esempio, se il programma deve usare la CPU intensivamente per calcolare lo SHA-1 hash, l'FPGA viene programmato per calcolare lo SHA-1; un'altro programma potrebbe fare in seguito lo stesso per un'altra istruzione specifica).
L'approccio FPGA da molta più flessibilità, ma è più complesso da realizzare (non moltissimo, basterebbe avere delle librerie adatte) e meno performante di quello di implementare direttamente in HW le stesse funzioni (circa 10x).

Non solo è più complesso e richiede un approccio diverso, ma bisogna vedere anche se effettivamente il guadagno computazionale è rilevante rispetto al costo aggiuntivo dovuto all'introduzione dell'FPGA.

[lucusta]

prima di vedere un FPGA o l'SHA-2, preferirei vedere integrati i controller, dentro al core, tipo quelli della memoria, ma anch i bus "lenti" e di comunicazione, in modo da riuscire ad ottenere una decisa riduzione dei chips totali su una scheda, oltre al significativo guadagno in stabilita' e velocita'.
Efficeon e Athlon-64 sono solo all'inizio, e confesso, e' un mio sogno vedere una CPU multicore con i sottosistemi video, audio, lan e di comunicazione integrati (sia verso il sistema, sia con link per ulteriori CPU), piuttosto che avere caches a volonta' e potenze esagerate e mal sfruttate..

[cdimauro]

Non sono d'accordo: integrare tutto richiede troppe risorse, e tarpa le ali agli aggiornamenti. Oltre a ciò, in caso di problemi di una sezione, potresti dover buttare l'intero chip.
Certamente l'integrazione del controller della memoria e l'adozione del controller HyperTransport per la comunicazione aiuta molto a limitare il numero di strati necessari per realizzare una scheda madre, ma se volessimo puntare su una maggior integrazione, preferirei che fossero inclusi su chip il controller degli interrupt, del DMA e di qualche periferica di I/O "legacy", lasciando tutto il resto all'esterno.
Magari una buona cosa sarebbe l'adozione di piccoli "moduli" da collegare direttamente al bus HT per avere il southbridge, la scheda audio, e la scheda video: in questo modo aggiornare una parte del sistema risulterebbe comoda ed economica.