Citazione:
|
Originalmente inviato da dogma
Programmare in multithreading, cioè creare programmi dove il codice sia diviso per essere sfruttato da più core è veramente utopistico
|
Prova a dirlo a chi scrive i motori di rendering 3D, o CODEC audio/video. Me compreso, visto che ho passato tre anni della mia vita a sviluppare un CODEC video H.263 per terminali mobili, CODEC che girava su un tri-core (come il prossimo Phenom di AMD).
La programmazione multi-threaded non è affatto un'utopia. C'è gente che devolve la sua intera carriera professionale allo studio di tecniche per suddividere il carico di lavoro di un algoritmo in più entità indipendenti che poi possono essere mappate su thread eseguiti in modo concorrente. Certamente, programmare in multi-threading non è cosa che si fa tutti i giorni, e non è certo un argomento su cui un programmatore può avvicinarsi con leggerezza, specie se c'è di mezzo l'accesso a risorse condivise. Ma il multi-threading esiste e funziona, eccome.
Citazione:
|
In sostanza il problema era del surriscaldamento
|
IL problema del surriscaldamento era un'esclusiva, anche se non credo che sia di quelle esclusive di cui andare fieri, dell'architettura NetBurst del Pentium 4 di Intel. Quell'architettura era fatta per scalare di brutto in frequenza, al costo di un'efficienza ridicola in termini di istruzioni per ciclo di clock (l'Athlon64 di AMD ne faceva molte di più). Purtroppo Intel quando aveva pensato la NetBurst aveva fatto i conti senza l'oste, nel senso che riteneva che nel giro di alcuni anni i progressi sulle tecnologie basate sul silicio avrebbero fatto passi avanti molto più sostanziosi di quanto in effetti non si sia poi verificato. Col risultato che i P4 erano condannati a morte: per funzionare bene dovevano essere tirati a frequenze di funzionamento spaventose per l'epoca (il P4 serie 500 è arrivato a 3,8 GHz...) ma così facendo ne venivano fuori correnti di leakage assurde (problema intrinseco della tecnologia costruttiva impiegata), con consumi di corrente da forno industriale (e anche le temperature sviluppate erano di quel genere lì).
L'introduzione del multi-core nel mondo consumer in realtà è arrivata anche, ma non solo, per questo motivo. IL fatto è che ormai i tempi erano maturi per poter integrare più cores a prezzi accessibili. Ne è riprova il fatto che le CPU dual-core (e le quad-core poco dopo) si sono diffuse con una velocità impressionante, ben superiore alle previsioni degli stessi produttori. E anche le tecniche di programmazione multi-threading erano ormai abbastanza ben consolidate, perlomeno nel settore del software professionale. E' bastato che Intel e AMD mettessero a disposizione degli strumenti di sviluppo un minimo intelligenti per rendere il multi-threading accessibile anche al mondo dei giochi.
Citazione:
|
e poi si devono considerare i tempi di latenza per immagazzinare i dati dai due core. e si è passato ai dual, quad core, con tutti i problemi in essere sia tecnici che di programmazione
|
Il problema delle latenze di scambio dati tra i cores è stato ormai ben risolto, semplicemente introducendo caches di secondo livello condivise con dimensioni generose. Per dirti: se vai a vedere i benchmark dei nuovi Penryn di Intel, che hanno caches condivise da 6 MB (per i dual-core, i quad-core arrivano a 12), vedrai che i risultati sono pressoché gli stessi anche se disgraziatamente disabiliti la gestione della memoria in dual-channel, cosa questa che fino a poco tempo fa avrebbe messo in ginocchio il PC. Segno che ormai le architetture delle memorie cache, dedicate e condivise, sono così efficienti anche in ambiente multi-core, da rendere pressoché irrilevante la prestazione offerta dal sottosistema della RAM.
Ciao
Filippo