P4 3.06 GHz Hyper Threading, recensione con 3DS Max

No, la spiegazione è un'altra. Tutte le "micro-operazioni" eseguite ad ogni stadio di pipeline richiedono un certo per poter essere eseguite. Ogni operazione è realizzata tramite una serie di transistor che formano un circuito logico il cui compito è, appunto, espletare quell'operazione. I transistor sono configurati in modo da formare quelle che vengono chiamate "porte logiche". Esistono diversi tipi porte logiche (quelle fondamentali sono le AND, le OR e le NOT), e in genere per compiere il loro lavoro hanno bisogno di un certo tempo.

E' chiaro, quindi, che per realizzare una "micro-operazione" bisognerà "sommare" i tempi di tutte le porte logiche coinvolte nell'operazione (la cosa è un tantino più complessa, ma rende bene l'idea... ). Se adesso prendiamo il valore massimo di tempo richiesto fra tutte le micro-operazioni e ne calcoliamo il reciproco, avremo una stima della velocità massima raggiungibile dal processore.

Sia chiaro che questo discorso è MOLTO semplificato: giusto per dare un'idea.

Tornando a noi, più si sale in frequenza, più il tempo necessario per completare una micro-operazione diventa critico. Ecco perché si tende ad aumentare il numero di stadi di pipeline: le microoperazioni diventeranno più "piccole", e sarà necessario svolgere meno lavoro, per cui il tempo necessario per il loro completamento diminuirà e si potranno raggiungere valori di clock più elevati.

Una prova lampante di ciò è, ad esempio, il fatto che il Pentium 4 impiega ben due stadi di pipeline (quindi due clock) per poter accedere ad un registro. Sembrano quasi i tempi di una cache L1 (2-3 cicli di clock le migliori), ma ciò si è reso necessario perché il numero di transistor è molto elevato e il tempo necessario affinché dalla parte di CPU che ne ha bisogno si possa accedere a un registro sarebbe stato troppo elevato. Con due stadi di pipeline il problema è "risolto", perché praticamente il tempo di accesso è raddoppiato (due cicli anziché uno) senza andare a toccare gli altri stadi di pipeline...

Azz, mi sono dilungato un po' troppo, come al solito...



Mah. In effetti è abbastanza anomalo e ho difficoltà ad immaginare come possa verificarsi questa cosa. Bisognerebbe studiare il problema (e il sorgente) per arrivare ad una conclusione logica...

cdimauro

eh... sei tornato.. pensavo fossi morto
i pezzi ti sono arrivati?
Domani metto le mani su un 2400+ a 266 con abit KT400 vediamo fin dove arriva....

secondo me...
un processore senza HT deve lavorare a tranches, mentre quello con HT può lavorare contemporeaneamente su più processi ottimizzando i tempi.
Per esempio, se ho Seti e 3dmark che girano insieme, un processore senza HT dedicherà, mettiamo, 2500 cicli ad uno, poi passerà all'altro, tornerà sull'altro ancora, etc. dovendo svuotare spesso la cache per recuperare i dati che servono... perdendo molti cicli preziosi.
Con l'HT invece grazie al parallelismo questi tempi morti sono ridotti di molto... E le prestazioni così possono salire ben sopra al potenziale 200%.
Può essere una spiegazione valida?

Mortacci tua! Mi sto toccando gli attributi!!!

No, è che in questo periodo ho poco tempo per scrivere messaggi cicciottelli...



Macché. Siccome sono MOLTO fortunato, come al solito ho scelto il periodo sbagliato per fare l'aggiornamento. Infatti lo STESSO giorno in cui m'ero deciso a comprare piastra madre e memoria, tutti i negozi che m'interessavano avevano esaurito le scorte!!! Ho girato un po', ma niente. I fornitori in questo periodo sono praticamente in ferie e dopo le feste fanno anche l'inventario della roba che hanno in magazzino. E così dovro posticipare ai primi di gennaio (SPERO!) l'aggiornamento.

Nel frattempo i pezzi me li ero già venduti e mi sono dovuto accontentare di un Celeron 1,1Ghz per il momento... Sob! 9 ore per comprimere un DivX di quasi due ore, quando il mio XP 1600+ ne impiegava soltanto 3!



Beh, dipende molto dalla bontà delle memorie e delle periferiche: in genere fino a 180Mhz ci si potrebbe arrivare... Il resto è questione di ehm, fondoschiena...

Ah. Ho scaricato i sorgenti di Prime95 ma non ho ancora avuto modo di darci un'occhiata come si deve. A prima vista sembra che utilizzi un algoritmo FFT, per cui il ricorso alla FPU è quasi d'obbligo. Quindi avevi ragione: impegna l'FPU. Vediamo se dopo le feste posso studiarmelo con più calma...

Non esattamente, ma è abbastanza valida... In realtà l'HT sfrutta gli stalli che si vengono a creare nella pipeline quando un processo attende una "risposta" dalla memoria, dall'I/O, oppure effettuato l'errata predizione di un salto che lo costringe a buttare a mare tutto il lavoro effettuato e ricominciare da capo, oppure se aspetta il risultato di un'operazione vincolante (es: il risultato di una precedente divisione intera o in virgola mobile, che richiede parecchi cicli di clock), oppure se l'operazione eseguita impegna poche risorse (es: soltanto una ALU mentre l'altra rimane libera, ecc.).

In poche parole: dove trova un "buco", cioè delle risorse che non vengono impiegate dal primo thread, le assegna SE E' POSSIBILE, al secondo thread. Ad esempio: il primo thread lascia libera una ALU e il secondo, giust'appunto necessità di una ALU per continuare, ecc.

Con questo modello non è detto che i due thread possano andare sempre in parallelo, anzi! Molto spesso, senza codice ottimizzato appositamente, un thread potrebbe ciucciarsi quasi tutte le risorse lasciando il secondo praticamente "morto di fame". Oppure i due si potrebbero ostacolare a vicenda: uno impegna l'FPU con una divisione e l'altro nel frattempo è costretto a girarsi i pollici perché gli serve una moltiplicazione o un'altra divisione. Oppure appunto, entrambi utilizzando porzioni di codice e memoria diversi, per cui tutte le cache sono costrette ad essere svuotate e riempite in continuazione. Ecc. ecc. ecc.

Insomma, l'HT richiede parecchio "fine tuning" del sistema e dei programmi in particolare per poter essere sfruttato, soprattutto senza arrecare danni (cioè senza far calare le prestazioni anziché aumentarle...)

Il problema che qui si vuol spiegare una tecnica di miglioramento dello sfruttamento delle unità di esecuzione in maniera semplicistica, la cosa non è fattibile. Tutti gli articoli che ho visto spiegano l'HT ma accennano sempre a quello che fa e i risultati si vedono da questo thread dove le persone non hanno chiara la cosa. La colpa non è loro, ma il motivo è che c'è molta teoria da studiare dietro per capire il SIMULTANEOUS MULTITHREADING (altro che hyperthreadibng neanche l'avesse inventato intel, intel lo ha solo implementato adattandolo al P4), da articoli di ricerca si vede che a volte l'HT è migliore anche di un biprocessore, il motivo è che scrivendo codice ad hoc si può mandare particolarmente bene l'HT, ma si presume che compilatori come Watcom ad esempio non generano mai codice di questo genere (non cito intel che per chiari motivi potrebbe introdurre dei trucchetti per far sembrare migliore HT). Codice particolarmente schifoso potrebbe favorire molto l'HT, ma 500% è proprio tanto. L'unica situazione che riesco a immaginare è che uno dei due thread abbia un working set maggiore della cache di 1mo o di 2ndo livello, generando così vari miss. Nel caso sequenziale il tempo sale vertiginosamente (soprattutto se pensiamo ad un ciclo for) con l'HT l'altro thread prosegue sbattendosene............

x jojo:
Guarda che le temp come ti è stato riportato variano di 3 gradi beh tutta la fatica che facciamo per guadagnare 3 gradi e loro ce li fottono con una tecnologia che allo stato attuale il 90% delle volte ci rallenta l'esecuzione dei programmi....ma non è che mi convinca tanto.
Considera pure che più sale l'efficienza dell'HT coiè il guadagno che ottieni più sfrutti le risorse e + quindi generi calore cioè le cpu con l'HT scalderanno sempre di + ma almeno ce ne sarà motivo non come ora.
Comunque come ho già scritto in altri thread l'HT mi piace perché con un idea intelligente si utilizza ciò che è inutilizzato all'interno di una cpu, considernado che si parla poi di due thread diversi saranno rare anche dipendenza logiche sui dati e quindi che i due thread si ostacolino tra loro, insomma l'idea c'è va solo implementata a modo e generato codice x utilizzarla anche se la cosa è molto complessa infatti ancora non si riesce ad ottimizzare a modo il codice di un thread (infatti le unità sono libere x un altro thread) figuriamoci di 2 addirittura.....insomma alla intel devono lavorare molto ...........

Guarda che è proprio nel caso in cui due thread sono diversi fra di loro e non generano dipendenze dei dati che l'HT dà quasi sempre il peggio di sé. Il motivo è che nella già esigua cache L1 e nella cache L2 debbono coesistere working set completamente diversi.

Infatti se è vero che in quel test si sono raggiunte punte del 500% (anche se comunque è tutto da verificare perché è alquanto anomala la cosa) sarà dovuto MOLTO probabilmente al fatto che i thread appartengono allo stesso processo e fanno lo stesso tipo di lavoro, quindi il codice e parte dei dati è condiviso da entrambi per cui non c'è assolutamente spreco di spazio nella cache. Ecco che, in queste condizioni e con una sapiente miscelazione delle istruzioni (il codice di quel test è stato ottimizzato appositamente per sfruttare l'HT), i due thread possono andare d'amore e d'accordo, aumentando le prestazioni del sistema...

Hai ragione ho detto una caxxata
Infatti è chiaro che due thread dello stesso processo debbano stare in CPU, altrimenti si dovrebbe avere cache sufficienti per + processi cosa non impossibile ma impossibile per 1 p4, questo comunque già riduce di molto la probabilità di dipendenze sui dati.
Lo sò scrivo da cani............ma ho un mal di denti (maledetto dente ha aspettato le feste e natale!!!!!!!) ........
Ciaoooooooo.........
PS Nel tuo post per thread diversi fra loro intendevi di due diversi processi chiaramente.........

Ciao ragazzi, so' che non c'entra con la discussione ma ho una domanda da porvi alla quale non ho trovato nulla in merito: Il Masterizzatore Yamaha F1 supporta il disc t@2, io ho il nero 5.5.9.0, il masterizzatore ( per necessita' di colore ) l'ho preso in versione OEM, ora non riesco a trovare la versione di nero che supporti tale opzione... Qualcuno di voi sa' qualcosa a riguardo vi ringrazio e chiedo scusa x essere uscito dall'argomento