PDA

View Full Version : On-Chip Multi-Threading


[IGI]
18-05-2002, 18:24
Negli ultimi mesi abbiamo assistito ad una sorta di rincorsa al Gighertz, intendendo con ciò l’adozione di processori con clock sempre più spinti. È stato da poco annunciata la disponibilità del Pentium 4 a 2.4 GHz: se, dalla nascita del pc, abbiamo dovuto attendere 19 anni per veder raggiunta la soglia del gigahertz, ne sono occorsi meno di due per raddoppiare questo valore.
Per migliorare le prestazioni di un processore, (tralasciando le complicate e costosissime architetture dei moderni supercomputer di cui abbiamo dato una rapida panoramica nell'articolo sul Cray) esistono diverse strade.
La più semplice è appunto quella di salire in frequenza (frequency ramping), non modificando l’architettura di base: per salire in frequenza si può diminuire la dimensione del transistor, oppure adottare degli accorgimenti in sede di integrazione del chip.
Quella più "difficile" prevede invece l’adozione di architetture interne più complesse: soluzioni superscalari, pipeline profonde, esecuzioni fuori ordine, accorgimenti che in altri termini permettono l’esecuzione di più istruzioni al secondo sfruttando il fatto che ci sono a disposizione più ALU, più registri, buffer più capienti...insomma, più risorse .
Qual è il lato negativo in tutto questo? La complessità nel design del processore: se il codice digerito dal processore è sullo stile x86, che è un codice contorto, poco parallelizzabile, con istruzioni spesso collegate fra di loro, la soluzione sicuramente più semplice è salire di molto in frequenza. È questa la strategia seguita dal Pentium4, che prevede una pipeline profonda, composta da molti stadi, ognuno dei quali dotato di poca logica e dunque in grado di eseguire il compito assegnatogli in frazioni di nanosecondo.
Da un pò di tempo è saltata fuori la notizia che il Pentium4 ha una marcia in più rispetto all’Athlon: la capacità di gestire in hardware il multithreading simultaneo. In realtà si tratterebbe di una forte predisposizione dell'architettura che però, per politiche Intel non è ancora stata implementata sull'attuale Pentium4. Con molta probabilità ce l’avrà invece il suo successore, il Foster, che, a detta della stessa Intel, sarà equiparabile ad una sorta di doppio processore per le applicazioni che vi gireranno!


Bello eh? Ci avete capito qualcosa? no? :lol: :lol:

I post seguenti sono rivolti a coloro che sono interessati a capire cosa sia il tanto misterioso on-chip multi-threading targato Intel, che dovrebbe fare la sua comparsa con il successore dell’attuale P4; sappiate da subito che la Intel non si è inventata nulla, e che la soluzione che il suo ufficio marketing ha battezzato con l’altisonante sigla "hyper–threading" è un aspetto del concetto di on-chip multithreading, sulla cui teoria e sulle cui implicazioni e problematiche si è lavorato molto negli ultimi 8 anni.

enjoy :)

[IGI]
18-05-2002, 18:40
suddividero' a punti per facilita' di comprensione. :)

1. cosa e' un Thread ?

Un programma, una volta compilato e tradotto in linguaggio assembler, è visibile come una lunghissima sequenza di istruzioni più o meno complesse poste di seguito l’una all’altra.
Un thread altro non è che un insieme di istruzioni, isolabile in mezzo a tutte le istruzioni che compongono il programma, che non soffre di dipendenze rispetto ad altre sequenze, e che pertanto può essere eseguito come se si trattasse di un blocco istruzioni indipendente, che può essere maneggiato dalla CPU in totale libertà. I thread possono essere impliciti o esplici. Sono impliciti quando nel codice sono presenti ad esempio cicli di elaborazione isolabili dal resto del programma ma questa condizione non viene dichiarata "esplicitamente" dal programmatore. Di contro il thread è esplicito quando il programmatore scompone il proprio programma "esplicitamente" in sottoporzioni indipendenti che vengono dichiarate al sistema operativo come tali.
mmm forse e' ancora un po' troppo "profescional" :elfhat:
vediamo di fare un esempio :
il rendering di una immagine 3D può essere suddiviso logicamente nel rendering di sotto-porzioni più piccole dello schermo. Il rendering in ogni area è indipendente dalle altre. Questa condizione è favorevole alla suddivisione in thread dell'elaborazione. Se i programmatori realizzano l'intero programma di rendering tenendo conto di ciò e dichiarando esplicitamente i thread indipendenti la situazione è ancora migliore come avremo modo di vedere.
Spero che cosi sia un po' piu' comprensibile oltremodo non so come spiegarvelo :awk:
Ma andiamo avanti,se si hanno due threads all’interno di un programma, si può decidere di assegnarli ognuno a una diversa CPU (in configurazioni multi-processore), oppure di assegnare e suddividere all’interno della stessa CPU il tempo macchina e le risorse tra i vari thread. Le possibilità offerte sono diverse e le vedremo nel dettaglio nei post a venire. La capacità di gestire più threads è detta appunto multi-threading ma c'e' da distinguere tra la gestione multi-threading offerta dai moderni sistemi operativi multi-tasking e la gestione eseguita direttamente dal processore.

[IGI]
18-05-2002, 18:49
2.Le differenze fra multi-threading hardware e multitasking

A questo punto alcuni di voi si domanderanno che differenza passa fra il multithreading e il multitasking...in fondo, anche col multitasking si eseguono diversi programmi in "contemporanea", no? quindi vediamo di fare delle puntualizzazioni : :ghgh:

Per Multi-tasking si intende la capacità di un sistema operativo di eseguire più compiti "contemporaneamente". Nelle configurazioni multiprocessore i vari programmi vengono smistati fra i processori diponibili secondo varie politiche, nel caso della tipica macchina mono-processore l'effetto di contemporaneità lo si ottiene invece suddividendo il tempo-macchina tra i vari task attivi. Il vantaggio è notevole ed è alla base del passaggio dal DOS, intrinsecamente mono-task, ai sistemi operativi grafici dove convivono aperte contemporaneamente molte applicazioni.
La prima versione di Windows aveva un multi-tasking molto primitivo, detto non-pre-emptive, dove erano le applicazioni stesse a cedere arbitrariamente il controllo alle altre applicazioni. La conseguenza era che se si bloccava una applicazione si bloccava l'intero sistema perchè l'applicazione in stallo non era in grado di passare il controllo nè ad altre applicazioni nè al sistema operativo. Su Window9x, Linux e i vari Unix abbiamo invece il Multi-Tasking Pre-emptive nel quale è il sistema operativo che si occupa di allocare il tempo macchina in piccole porzioni da distribuire fra i vari programmi in base alle relative necessità. Con l'aumento della complessità dei programmi sono nati poi anche sistemi operativi di tipo Multi-Tasking con funzionalità Multi-Threading. Si tratta di un livello di suddivisione ulteriore all'interno del medesimo programma la dove la creazione di un nuovo task indipendente sarebbe superflua. Ogni task ha una propria area di memoria ed è generalmente "esigente" in termini di risorse, i theads sono suddivisioni dell'elaborazione all'interno di uno stesso task e sono tipicamente più leggeri e semplici da gestire.
In ogni caso, quando si passa da un processo all’altro, si esegue un context switch, cioè una commutazione fra i processi durante la quale alcune routines del sistema operativo, necessarie per effettuare l’avvicendamento fra i processi, vengono eseguite . Queste routine rubano cicli preziosi di clock per cui il multi-tasking non fa nulla per migliorare la performance complessiva. Anzi, se ci sono troppi task o insiemi di threads che si vengono ad alternare, complessivamente l’overhead dovuto all’esecuzione di pezzi di codice propri del sistema operativo appesantisce parecchio il sistema.
E il multi-threading hardware (detto anche on-chip multi-threading)? images/advsmilies/confused/5.gif
Il multi-threading hardware, essendo una features eseguita a livello del processore, è per sua natura portato ad escludere il sistema operativo dalla gestione dei singoli threads. Pertanto, l’avvicendamento fra i threads avviene senza le chiamate al sistema operativo, una volta che il S.O. abbia deciso quali debbano essere i processi da mandare in esecuzione sui vari processori. Ovviamente per supportare il multi-threading è necessario avere un sistema operativo opportunamente capace e scritto anch'esso in modo da sfruttare queste capacità multi-threading dei processori. :rolleyes:

[IGI]
18-05-2002, 19:08
3.Varianti del Multithreading Hardware

Esistono diverse varianti dell' On-chip multi-threading, e le esamineremo una per una fornendo per ognuna un esempio di microprocessore che la implementa . ;)

- On chip multiprocessing (CMP)
- Course-grained multithreading (CMT)
- Fine-grained multithreading (FMT)
- Simultaneous multithreading (SMT)

3.1 On-chip multiprocessing (CMP)

Questa soluzione consiste nello stipare all’interno del die di silicio due o più processori. Anzichè avere ad esempio un singolo processore con 4 unità funzionali fra ALU e FPU e 64 registri interni, si decide di avere due processori ognuno con 2 unità funzionali e 32 registri.
Il vantaggio di una tale scelta è presto detto: nei processori superscalari moderni la maggior parte delle risorse non vengono impiegate nell’esecuzione dei processi, perchè i micro sono sovradimensionati per poter sopportare i burst, cioè i picchi di elaborazione parallela del codice che ogni tanto possono capitare. La maggior parte delle volte le unità funzionali sono "scariche" e quindi inutilizzate questo anche in presenza di unità capaci di riordinare il codice e di eseguirlo fuori sequenza, infatti prima o poi ci saranno dei riferimenti tra le istruzioni capaci di rendere inefficiente l'esecuzione fuori ordine.
Se per esempio,per oltre il 85% del tempo di esecuzione dei processi su 8 unità funzionali solo 3 stanno lavorando a pieno regime , mentre le altre oziano in mancanza di dati da macinare, è evidente che è uno spreco di area su chip impiegare altre 5 unità funzionali se magari queste verranno utilizzate per meno del 15% del tempo di esecuzione complessivo del codice.
Che fare allora? Una strada è quella del CMP. Se per esempio abbiamo due CPU sul medesimo die, ognuna di queste può occuparsi a pieno regime di un singolo thread, ottimizzando le risorse e diminuendo lo spreco causato dall’ inattività di alcune unità funzionali. Ogni thread è per definizione indipendente dagli altri e quindi si ottengono maggiori vantaggi rispetto ad un 'approccio superscalare esasperato.

I vantaggi di questa soluzione sono parecchi :

1) è più semplice progettare il singolo processore perchè c’è meno logica di controllo .

2) avere meno logica significa avere meno transistor e dunque poter raggiungere clock più spinti .

3) se si riescono ad individuare dei thread su cui lavorare in parallelo lo speed-up è notevole.

Gli svantaggi sono essenzialmente due:

1) se i thread non si trovano o non sono stati esplicitamente definiti abbiamo in sostanza un "mezzo processore" che lavora su un singolo task: il che comporta un peggioramento prestazionale rispetto alla soluzione a singolo processore.

2) maggior complessità e maggiori latenze nella gestione della cache L2, che viene condivisa dai due processori. Non entriamo in questa sede nella risoluzione di questo problema.

La soluzione CMP lavora sostanzialmente nell’ottica di limitare lo spreco delle risorse hardware del processore. È ovvio tuttavia che per ogni sottoprocessore si hanno gli stessi problemi della soluzione a singolo processore quali: lo stalling della pipeline, il context- switch eccetera.

FINE PRIMO TEMPO :rotfl: :rotfl:
adesso vado a mangiare continuo appena ho tempo , intanto a voi le considerazioni su questo prima parte ciaoz :hello:

[IGI]
18-05-2002, 20:53
scusate se interrompo i numerosi reply :D :D mah
vabe' vediamo di andare avanti . :look:
dove ero rimasto ? :gha: ah si ..... :)

Un altro sistema per implementare il multithreading mira ad evitare gli stalli della pipeline e contemporaneamente a non avere context-switches che rubino cicli di clock. In breve, anzichè evitare lo spreco delle risorse hardware, si cerca di evitare lo spreco di preziosi cicli di clock.

Le soluzioni sono due: il coarse-grained e il fine-grained multithreading.

3.2 Coarse-Grained Multithreading (CMT)

Mentre in una soluzione a più processori realizzati sul medesimo die di silicio corrono più threads contemporanemanete, in una soluzione a grana grossa (coarse-grained, per l’appunto) il processore è uno solo ed esegue un thread alla volta, come nel multitasking. Solo che, quando si verifica un problema capace di far perdere cicli al processore (tipicamente un cache miss), anzichè attenderne la risoluzione, viene salvato tutto lo stato del thread in esecuzione in appositi registri interni alla CPU e vien fatto partire il thread successivo che nel frattempo ha tutte le risorse pronte per poter essere eseguito. Il thread congelato potrà ripartire quando il problema risulterà risolto. È la logica di controllo del processore che si incarica di eseguire questo avvicendamento.
Se il processore è in grado di salvare un massimo di N thread, dopodichè è costretto a salvare il tutto in memoria e se ne incarica il sistema operativo, si parla di processore a N-vie (N-way CTM processor).L’avvicendamento tra i thread si verifica tipicamente in seguito ad un cache miss (a livello di cache L2, a più alta latenza rispetto ad una cache L1) nell’esecuzione del codice. Mentre viene caricato dalla memoria di sistema il blocco di cache necessario a far ripartire il thread che è entrato in stallo, viene attivato il successivo. Quindi tutto il tempo che verrebbe altrimenti sprecato nel caricamento del blocco di cache viene "mascherato" dall’esecuzione di un altro pezzo di codice. Ingegnoso e relativamente semplice da realizzare nelle architetture tradizionali dei processori.

3.3 Fine-Grained Multithreading (FMT)

Il multithreading a grana fine è basato anch’esso sull’avvicendamento dei threads, solo che, anzichè commutare fra i threads solo quando si perviene ad una cache miss o ad un esaurimento del codice eseguibile, lo switching viene eseguito ad ogni ciclo di clock . A che serve tale soluzione? A mascherare il più possibile i lunghi intervalli di latenza che si possono venire a creare in seguito all’esecuzione di istruzioni complesse che richiedono più cicli di clock per essere eseguite e che manderebbero in stallo la pipeline di esecuzione. L’avvicendamento fra i threads, invece, consente di mascherare i cicli di clock persi per le latenze. Complessivamente, l’ FMT consente un throughput complessivo maggiore rispetto a quello conseguibile con una soluzione CMT perchè più "capillare".
Una visione efficace del FMTe' stato adottato fra l’altro nel supercomputer Cray MTA (multi-threaded architecture)

3.4 Simultaneous Multithreading (SMT)

Quest’ultima soluzione, che pare sarà impiegata nel futuro Pentium4 Foster di Intel con l’altisonante sigla di hyper-multithreading, unisce la flessibilità dellla soluzione fine-grained alla efficienza nello sfruttamento dele risorse tipica del CMP.
In questa soluzione il throughput e' massimizzato in conseguenza del fatto che più thread sono mandati in esecuzione contemporaneamente, cercando di ottimizzare l’impiego di tutte le unità di calcolo disponibili (ALU, FPU, registri a scorrimento) questo è possibile grazie al fatto che i thread sono pezzi di codice tra loro non correlati e quindi è molto probabile trovare istruzioni che utilizzano unità funzionali in quel momento libere.

[IGI]
18-05-2002, 21:03
4 Il sistema operativo e le risorse del processore

Quando un programma deve essere eseguito, esso si appoggia sul sistema operativo, il quale ha la totale visibilità delle risorse messe a disposizione dal sistema: memoria, registri del processore, dispositivi di input/output. In alcuni contesti, come ad esempio un Web Server, il processore esegue per il 60% del suo tempo istruzioni facenti parte delle routine del sistema operativo.

È quindi chiaro che un sistema operativo, essendo esso stesso un insieme di programmi, deve essere riscritto per poter girare adeguatamente all’interno di un processore preposto per il trattamento del multithreading. A differenza dei normali programmi, un sistema operativo presenta delle caratteristiche uniche che lo contraddistinguono: presenta spesso routine di esecuzione costituite da codice così esteso da eccedere la dimensione delle cache o del translation lookaside buffer (TLB,che consente la conversione dagli indirizzi virtuali generati dalla CPU a quelli fisici presenti effettivamente in memoria); inoltre, a causa dei frequenti salti e degli scarsi loops di esecuzione, l’esecuzione del codice mette a dura prova la performance delle unità di branch prediction; infine, l’esecuzione del sistema operativo è intermittente, a causa di chiamate di sistema, interrupts, eccezioni varie che in ultima analisi obbligano il processore a rimpiazzare i blocchi di cache, le tabelle di branch prediction e il TLB di continuo.
Il simultaneous multithreading ritorna quindi utile in massima parte quando è possibile individuare dei threads su cui lavorare in parallelo. Se il codice non viene ottimizzato, i vantaggi che ne conseguono sono ben pochi; per ovviare alla scarsità threads simultanei presenti nel codice natìo del programma, si può ovviare via hardware all’inconveniente facendo in modo che esista all’interno della CPU una unità preposta alla individuazione di loop trattabili come thread. È questa la soluzione proposta dalla Intel con il suo dynamic multithreading. Secondo questo approccio non è neanche necessario che sia il compilatore a tradurre in threads il programma scritto in linguaggio ad alto livello, giacchè se ne incarica l’hardware mantenedo in una grossa memoria interna al processore (una trace buffer analoga a quella presente nel Pentium4) la traccia delle istruzioni già decodificate all’interno delle quali pescare i thread da mandare in esecuzione simultanea.
Se sia questo lo schema di principio della tecnologia Jackson che Intel implementerà nelle prossime CPU a 32 bit non è ancora dato di saperlo. Evidentemente, all’atto del rilascio della tecnologia Netburst del P4, la Intel non aveva ancora abbastanza chiaro come implementare il multithreading simultaneo in una via non troppo dolorosa, tale cioè da continuare a permettere di far girare l’obsoleto codice x86 anche in questa nuova ottica di sviluppo.
Il SMT richiede alcune innovazioni , come la presenza di multi program counter (cioè di puntatori alla prossima esecuzione da eseguire), uno per ogni thread. Deve essere inoltre prevista la possibilità di selezionare uno o più program counter per la gestione simultanea di più threads in esecuzione.
Non solo: quando avviene l’avvicendamento, è necessario salvare i risultati di ogni thread in appositi registri. Ogni istruzione deve avere dei bit in più che la identifichino come appartenente ad uno specifico thread (ad, esempio, in un processore SMT a 4 vie, bastano due bit in più per ogni istruzione).
Anche le tabelle di branch prediction, register renaming, e quant’altro devono essere "indicizzate" per lo specifico thread cui fanno riferimento .
Al di là della necessità di disporre di più area sul die di silicio per ospitare tutti questi registri, c’è da considerare che la logica di controllo si appesantisce parecchio, giacchè deve essere sufficientemente raffinata da garantire una capacità di esecuzione, di branch prediction, di register renaming per le istruzioni del singolo thread.
Compaq, ora di proprietà della Hewlett-Packard, notoriamente vicina alla Intel, ha stimato che l’implementazione dell’ SMT in un processore superscalare (che supporti l’esecuzione fuori ordine delle istruzioni) comporta un aggravio del 10% dell’area del silicio necessaria ad ospitare le nuove funzioni ; il che, detto tra noi, pare un costo abbastanza contenuto visti i vantaggi che ne possono conseguire!

[IGI]
18-05-2002, 21:08
in conclusione la ricerca di sempre migliori performance si sta rivelando sempre più ardua; volendo tentare un paragone, è come cercare di scalare una parete che diventa sempre più verticale. Per incrementare le prestazioni finora le soluzioni proposte avevano sempre come finalità quella di lavorare sul maggior numero di istruzioni per secondo eseguite. In altri termini, l’"atomo" oggetto del massimo throughput era la singola istruzione x86. Nel caso di un approccio multithreading, il discorso è sostanzialmente diverso e il miglioramento prestazionale si basa sull’esecuzione di sequenze di istruzioni indipendenti (threads, appunto) cercando di minimizzare per quanto possibile il mancato utilizzo di risorse hardware e di mascherare le latenze indotte dagli stalli della pipeline e dalle cache miss . Chiaramente una visione più "dall’alto" come appunto è quella che consente la gestione di threads simultanei consente un ottimizzazione del sistema.

Il multuthreading fin qui visto può considerarsi la naturale evoluzione di processori in grado di eseguire istruzioni out of order (OOO: out of order execution), cioè di processori che immagazzinano un sacco di istruzioni in un buffer, a partire dal quale una logica di controllo incaricata di rilevare le interdipendenze preleva quelle che possono essere eseguite , anche se nel codice originale non erano poste in sequenza, cioè in ordine, appunto. Esempi di processori con esecuzione fuori ordine sono l’Athlon e il Pentium4 . Con la differenza che il Pentium4, nella propria esigua cache dati, contiene istruzioni già decodificate, "sminuzzate",e quindi per certi versi è di per sè un procesore quasi-thread. Forse è questo che intendono gli ingegneri della Intel; di sicuro dovremo aspettare ancora del tempo prima di vedere applicato il concetto di multithreading nei normali computer da desktop!

Kopl
19-05-2002, 12:57
In poche parole alla maniera dei primi Supercomputer, invece di tanti processori che eseguono ognuno le sue operazioni un singolo proc che opera in multi?

Radeon300
16-08-2002, 00:55
ehehheeh Tyrel è stato fin troppo complesso però ha spiegato tutto per filo e per segno come funziona solo che per i non esperti della materia risulta un pò difficile capire :)

vediamo di riassumere un pò spiegandolo in un altro modo :p

Dunque,l'Hyper-Threading è una tecnologia sviluppata da Intel nello scorso autunno ed è finalmente apparsa sul mercato (nell'ultima generazione di processori Xeon) promettendo notevoli incrementi di prestazioni grazie al "raddoppio virtuale" delle CPU. L'Hyper-Threading di Intel è una tecnica che consente ad un singolo processore fisico di eseguire più thread (flussi di istruzioni) contemporaneamente, offrendo un throughput superiore e un livello di prestazioni più elevato. Questa soluzione non è una vera novità, infatti una tecnologia simile, la Simultaneous Multi-Threading (SMT), era apparsa per la prima volta negli ormai defunti e rivoluzionari processori Alpha EV8. :rolleyes:
Dal punto di vista operativo il funzionamento di Hyper-Threading è abbastanza semplice: per migliorare le prestazioni e l'efficienza i processori Hyper-Threading-enabled gestiscono le istruzioni in arrivo da due diversi thread software tenendo traccia dello stato di elaborazione di ciascun set di istruzioni. Con le attuali tecnologie dei processori, al contrario, i singoli thread vengono gestiti uno alla volta, mentre la pianificazione di più thread in arrivo nel processore viene affidata al sistema operativo secondo un ordine logico definito da un opportuno algoritmo di schedulazione. In sintesi, è possibile affermare che i processori abilitati per la tecnologia Hyper-Threading contengono due stati a livello di architettura in un singolo core, in modo da consentire a ciascun processore fisico di svolgere la funzione di due processori logici dal punto di vista del sistema operativo. Poiché tuttavia i due processori logici condivideranno comunque le medesime risorse di esecuzione del core del processore (execution engine, cache, system bus interface, firmware, ecc.) i vantaggi in termini di prestazioni non equivarranno a quelli garantiti dai sistemi multiprocessori simmetrici (SMP, Symmetric Multi-Processor).
Nei processori normali solo una parte dei circuiti disponibili nel core vengono utilizzati contemporaneamente (Intel stima il 35%); da questa osservazione nasce l'idea dell'Hyper-Threading: sfruttare al massimo l'hardware a disposizione facendo lavorare anche le unità funzionali non attive. Eseguendo quindi più thread contemporaneamente nel medesimo processore, la percentuale di sfruttamento dei circuiti integrati nella CPU aumenta notevolmente e con essa le prestazioni: il chipmaker stima un incremento di punta del 30 percento, mentre in media l'aumento delle performance risulterebbe essere sensibilmente più basso, circa il 10-20 percento. L'implementazione su silicio dell'Hyper-Threading ha un costo molto basso. Intel ha dichiarato che nei processori Hyper-Threading enabled l'area del core aumenta di un modesto cinque percento rispetto ad un processore "normale", non è infatti necessario aggiungere ulteriori blocchi funzionali alla CPU (l'obiettivo è quello di sfruttare al massimo quelli già presenti), ma è necessario integrare dell'ulteriore
logica di controllo che gestisca e sincronizzi (le risorse sono condivise, sono quindi possibili eventuali stati di stallo) i due thread paralleli in esecuzione.
Per quanto riguarda la programmazione, il funzionamento di Hyper-Threading è completamente trasparante, non necessita quindi di particolari interventi al codice per far migliorare le prestazioni delle applicazioni Multi-Threading, specialmente se queste sono già ottimizzate per sistemi Dual Processor (DP) e Multi Processor (MP) in genere. In realtà, per ottenere migliori prestazioni dalla tecnologia Hyper- Threading è necessario riorganizzare il codice opportunamente, perché i due processori che si hanno a disposizione sono pur sempre virtuali, quindi non potranno mai eseguire determinati compiti (conflitto risorse) in parallelo.
L'Hyper-Threading, in definitiva, appare come una soluzione molto interessante, permette infatti un sensibile incremento delle prestazioni a parità di clock con una relativamente semplice, ma efficace modifica architetturale.
Potete paragonare l'hyper-threading a un Hard-disk ripartizionato in due :)


è tutto buonanotte ;)

Goul_duKat
08-01-2003, 04:45
bhe cmq molta della fatica di continuare l'evoluzione e' legato al mantenere una certa compatibilita' all'indietro ...

se lanciassero un nuovo modo di fare tutto sapete si creerebbero troppi posti di lavoro da ricercatore da sviluppatore da studioso ecc ... per ora i ricchi vogliono rimanere sempre i soliti e dare un contentino ogni tanto a tutti

cmq tutto quello che scrivo e' sempre I.M.H.O.

Hell Spawn
30-03-2003, 19:46
Ma il multitrhead di intel è già disponibile da tempo...
tempo fa avevo un sistema con 2 pentium xeon.
questo vuol dire che come prestazioni erano molto inferiori a 2 attuali pentium 4?? (tralasciando la frequenza di clock) ??

Goul_duKat
31-03-2003, 00:07
Originally posted by Hell Spawn
Ma il multitrhead di intel è già disponibile da tempo...
tempo fa avevo un sistema con 2 pentium xeon.
questo vuol dire che come prestazioni erano molto inferiori a 2 attuali pentium 4?? (tralasciando la frequenza di clock) ??

il multi tread e' un'altra cosa ... non e' proprio avere 2 processori insieme ... diciamo che come core di calcolo cene sono 2 ma di controllo solo 1 non come 2 processori che proprio duplicano tutto ...

ecco perche' per supportare il multi tread ci vogliono versioni compilate apposta di so e applicazioni ... ed invece per supportare il smp basta un so smp senza ricompilazione