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

Analisi prestazionale dell'efficacia della tecnologia Hyper Threading utilizzando 3d Studio MAX 5

Click sul link per visualizzare la notizia.

che quando attivi l'HT sul P4 3GHz i consumi aumentano (come se non fossero' gia' elevati) e l'interno del case puo' tranquillamente essere usato come forno ! :D

Se le prestazioni aumentassero del 30%-50%, allora sarebbe giustificato, ma per un incremento medio del 2,5 % bisogna rischiare di "fumare" tutto !?

non aumenta un bel niente... (temperatura)
Aumentano le operazioni che fa nello stesso ciclo di clock non aumentano i mhz
Un po come se fossi un corriere che per portare un pacco a destinazione, utilizzi due braccia (HT attivato) invece di una sola (P4 senza HT)... invece di fare il doppio dei viaggi perche non vuoi sforzarti troppo perche sei uno scansafatiche...

Basta alimentare queste false voci, ed anche se fosse la differenza di temperatura sarebbe di 0.2 gradi, sai che dispendio di energia.

ma, vorrei proprio vederli questi migliormento di architettura cpu...

questo ht e utile solo a chi usa questi programmi che sfruttano questa tecnologia altrimenti porta solo un calo di prestazioni

Credo che nella news ci sia in errore.
Si parla di aumento di prestazione in multithreading (più processori), ma credo si tratti di Multitasking (più sessioni aperte).

Originally posted by "Giax"

Credo che nella news ci sia in errore.
Si parla di aumento di prestazione in multithreading (più processori), ma credo si tratti di Multitasking (più sessioni aperte).

Invece direi di no visto ke HT stà per Hyper-Threading... Ovviamente non con processori "fisici" ma "virtuali"...

Originally posted by "J0J0"

non aumenta un bel niente... (temperatura)
Aumentano le operazioni che fa nello stesso ciclo di clock non aumentano i mhz
Un po come se fossi un corriere che per portare un pacco a destinazione, utilizzi due braccia (HT attivato) invece di una sola (P4 senza HT)... invece di fare il doppio dei viaggi perche non vuoi sforzarti troppo perche sei uno scansafatiche...

Basta alimentare queste false voci, ed anche se fosse la differenza di temperatura sarebbe di 0.2 gradi, sai che dispendio di energia.
Non penso proprio che sia ridotto l'aumento di temperatura e mi pare pure di averlo letto da qualche parte che sono svariati gradi.....

Originally posted by "Giax"

Credo che nella news ci sia in errore.
Si parla di aumento di prestazione in multithreading (più processori), ma credo si tratti di Multitasking (più sessioni aperte).
Guarda che thread e processore non c'entrano niente...........
I thread sono varie parti di un unico processo......sono nati per permettere commutazioni di contesto più leggere.........

bhè su anandtech, tanto per nn fare nomi dicono che l'aumento sia del 6% con HT attivato......

che sia poco che sia tanto, loro son passati da 46 a 49 gradi.

x ErPazzo74

mi dispiace non sono daccordo...
avro esagerato a scrivere 0.2... ma difficilmente superera gli 1-2 gradi...
solo perche fa piu operazioni non vuol dire che riscaldi di piu (anche se in teoria sembrerebbe la cosa piu ovvia).
Il p4 e' fatto male (chiamale 20 pipeline troppo lunge o come ti pare), non scendo sul tecnico altrimenti da un post andiamo su un'altro...
Ma tu per portare 10 euro (banconota cartacea), invece di 11 o portare 10 euro in monetine, quanto torni a casa ti sei reso conto di sudare di piu o di mangiare di piu a tavola?
Il dispendio di energia ci sara, ma e' minimo.

Il p4 purtroppo anche per arrivare al 15esimo piano di un edificio ed essere consapevole del risultato per elaborarlo deve per forza arrivare al 20esimo e tirare le sue conclusioni (altre operazioni e via dicendo)
Invece paradossalmente il risultato lo sapeva 5 piani prima... e' questo che lo frega...
Deve sempre arrivare all'ultimo piano prima di fare l'operazione, che guarda caso e' piu alto dei suoi concorrenti... da qui la sua lentezza, quindi ci mette di piu a prendere decisioni.
E si saranno inventato l'HT (2 picconi con una fava), pensando:"tanto deve percorrere lo stesso tutti i piani, tanto vale che nello stesso momento oltre a tenere a mente il numero mentre fa le scale, porta il boccione dell'acqua al capo con la gola secca che sta all'ultimo piano guarda caso, cosi puo continuare a fare le sue telefonate e contiunare a parlare blha blah blah )...
2 operazioni percorrendo lo stesso numero di scalini, nello stesso tempo.

Io la vedo cosi... poi fate vobis :)

quando invece ci sono due processori distinti si dividono i compiti per raggiungere un risultato comune... il primo si fa i primi 10 piani, il secondo gli ultimi 10, e ogni volta partono da 0 a 10 uno e da 10 a 20 l'altro... per milioni di volte al secondo. (non e' pienente esatto come ragionamento, ma voglio dire meglio fare solo 10 operazioni che 20 in una volta)
Mentre il nostro povero HT parte sempre e solo da 0 e deve arrancare fino a 20 e poi ritornare giu in un solo ciclo di clock...

scusate l'esempio infantile ma rendo molto l'idea. :D

Seeeeee, sono molto scettico...

jojo tu la vedi un po troppo rosea mi sa.....

nn e' proprio come dici tu....
il fatto del postino con due braccia e' il classico esempio di sistema con 2 processori :rolleyes:

ni sa ke hai le idee 1 pò confuse per quanto riguarda le pipeline......
nn è ke con l'hypertreading deve fare solo 10 stadi della pipeline per eseguire un'operazione......
mi spiego meglio:
le pipeline sono nate per effettuare una gestione concorrente dell'elaborazione dei dati come procedimento alternativo al parallelismo classico a multiprocessore, e funzionano nel seguente modo:
Supponiamo una pipeline a 3 stadi.
Essa è rappresentabile come una "catena di montaggio" fatta da unità di elaborazione messe in cascata.
Al primo ciclo di clock la prima istruzione viene elaborata dalla prima unità di esecuzione. Al secondo ciclo di clock questa istruzione viene passata alla seconda unità di elaborazione e viene elaborata, mentre, NELLO STESSO TEMPO, un'altra istruzione viene nuovamente elaborata dalla prima unità di esecuzione. Al terzo ciclo di clock, tutte e tre le istruzioni vengono elaborate nello stesso tempo dalle tre unità di esecuzione, quindi, A REGIME, si avrà un throughput di 3 istruzioni per ciclo di clock. Per questo questa situazione è paragonabile a quella di un sistema multiprocessore con tre unità di esecuzione, anche se ovviamente vi sono delle differenze sostanziali che nn sto qui a spiegare.
Ora torniamo al nostro bellissimo e potentissimo P4.
Vi siete chiesti mai perchè è necessario aumentare la lunghezza delle pipeline per salire più facilmente in frequenza?
Stando a quanto ho detto finora potrebbe sembrare che il P4 riesca in questo modo ad elaborare 20 istruzioni per ciclo di clock, che sarebbe un valore semplicemente mostruoso.
E qui casca l'asino. In realtà le istruzioni che elabora il P4 sono delle istruzioni CISC molto complesse che necessitano molto di più di un ciclo di clock per essere completate. Per questo, in mo do da sfruttare efficientemente il processore, cosa si è pensato di fare? SI è messa un'unità di "traduzione" che trasforma queste istruzioni CISC in micro-istruzioni RISC Like, che quindi necessitano solamente di un clock per essere eseguite (di solito, anche se ovviamente in realtà nn è sempre vero). Inoltre, visto che queste istruzioni possono essere eseguite in un ciclo di clock, e visto che sono strettamente sequenziali, è stato possibile inserire una pipeline per farle eseguire. Ora, ovviamente, tanti più stadi avrà la pipeline, tanto più semplici saranno le micro istruzioni da eseguire. Faccio 1 esempio, avendo una pipeline a 3 stadi che esegue un istruzione, è necessario dividere l'istruzione in 3 micro-parti, che ovviamente saranno molto più complicate da eseguire rispetto alle micro-parti ottenute dividendo la stessa istruzione in 20 sottoparti. In questo modo, essendo le micro-istruzioni più facili da eseguire tanto più lunga è la pipeline, è possibile ridurre il tempo necessario per eseguire un istruzione, e, di conseguenza, salire di clock. Ovviamente le pipeline non sono tutte rose e fiori. Vi sono delle penalità fortissime nel caso in cui un branching (un salto) viene predetto male, in quanto è necessario svuotare completamente la pipeline. Inoltre è molto probabile che vi siano delle unità di esecuzione che non fanno niente ad un certo istante, a causa del fatto che come ho detto prima non sempre è possibile terminare un'operazione in un ciclo di clock (vedi accesso alla memoria e I/o in generale). Quindi la tecnologia Hyper-treading non fa altro che ottimizzare questa situazione, andando a impiegare le unità di esecuzione che non fanno niente con un altro thread.
Penso che come spiegazione sia sufficiente, anke se ovviamente ho lasciato delle piccole imprecisioni, ma d'altro canto già questo post è diventato lungo quanto un articolo di Lithium, se mi fossi messo a sepcificare meglio tutte quelle piccole imprecisioni non avrei finito più.
Spero di essere stato chiaro cmq. :)
Se avete dubbi non esitate a contattarmi ! ;)

Avevo detto di non scendere sul tecnico :)
l'avevo detto io che poi il post diventava qualcos'altro!!! (eravamo partiti dalla temperatura)
Questa si che e' una predizione. hihihih :D

Quando mi riferivo alla frase "pipeline o come le volete chiamare" era inteso come una cosa qualsiasi che rende il p4 piu lento o meno lento al suo modo di operare.
Altrimenti e' semplice dire.. il p4 e' lento perche ne ha 20... l'amd ne ha 3 (AD ESEMPIO!!! ORA NON PRENDETEMI IN PAROLA) allora e' piu veloce l'amd... :) (mi davo la zappa sui piedi? io ho un p4) ehhehe

Secondo te l'esempio del pacco e del postino si adatta a pipeline, salti di predizione, istruzioni processi e clock?? :)
Sono solo delle fantasiose metafore onomatopetizzate...
E' stata la prima cosa che mi e' saltata in mente, non voleva essere legge, ma divertente da leggere.
:D

PacManZ
no x i 2 processori e': tu porti un pacco che io porto l'altro...
le due braccia per l'appunto e' HT perche il postino e' uno, ma virtualmente fa x due (xche usa due braccia invece di 1)

Sti postini non hanno mai voglia di lavorare!!!
:)

quote:
------

non aumenta un bel niente... (temperatura)
Aumentano le operazioni che fa nello stesso ciclo di clock non aumentano i mhz
Un po come se fossi un corriere che per portare un pacco a destinazione, utilizzi due braccia (HT attivato) invece di una sola (P4 senza HT)... invece di fare il doppio dei viaggi perche non vuoi sforzarti troppo perche sei uno scansafatiche...

Basta alimentare queste false voci, ed anche se fosse la differenza di temperatura sarebbe di 0.2 gradi, sai che dispendio di energia.

----

Non penso proprio che sia ridotto l'aumento di temperatura e mi pare pure di averlo letto da qualche parte che sono svariati gradi.....

---

JOJO.... non so tu che mestiere fai di vita... ma se sei un assemblatore... complimentoni. Non credo che tu ne abbia mai provato uno di P4 HT altrimenti non ti accaniresti contro chi per altro dice la verita'. La temperatura non sale !? Prova... prova... e poi ci risentiamo ! Cosi' per curiosita' sai quanti watt si piglia il P4 HT !?

L'HT non dovrebbe essere altro che un controller aggiuntivo che si occupa di riempire le pipeline libere appena può, in modo da recuperare tempo macchina... naturalmente se mi ricordo bene...


per precisare solo una cosa... la pipeline è appunto una specie di catena di montaggio... quindi in una pipeline di 20 stadi come quella del P4 ogni pipeline dovrebbe occuparsi di 20 parti dell'esecuzione di una istruzione diversa...

chiedo scusa sew mi son sbagliato o per la poca chiarezza ;)

più logica, più transistor che commutano per ciclo di clock -> maggiore dissipazione

x Scezzy

e se ti dicessi che lo sono invece?
E posso anche ammettere che non l'ho ancora montato su nessun pc... per il momento.

Poi io non mi accanisco, anzi il contrario...
Da come alcuni parlano... e' come se prendesse 10 gradi in piu...
hai mai visto qualche sito che facesse una prova e dice nel post.... "si HT bella cosa.. solo ha di contro che ti sale di 10 gradi la cpu"
Non ho mai visto una nota del genere in nessuna recensione o review, ne tantomeno una jpg con la foto del prima e dopo...
Anzi ora non ricordo, dove facevano vedere la differenza di temperatura con e senza HT attivato, ed era massimo di 1-2 gradi e nemmeno (troppo poco per iniziare un linciaggio all'intel), ma sappiamo tutti che la temperatura varia per mille fattori ed oscilla di un grado piu o un grado meno e puo avvenire in qualsiasi momento a prescindere da cio che si sta facendo, infatti nei test di solito si fanno le medie (bench in genere) sulle misurazioni...
Poi io parlo di temperatura (finale della CPU a contatto col dissipatore) e non di watt (magari assorbiti dal sistema, dalla piastra e via dicendo)...

E' cambiato il sistema di gestione interno, non la velocita' di punta della CPU (mhz e voltaggio aumentano a vista d'occhio la temperatura), per giustificare un aumento cosi allarmistico...

L'ho sempre detto che e' il p4 e' fatto male... mangia come un bue e tira come una formica...
ora tira come un asinello, ma continua a mangiare come un bue ugualmente...
se tanto mi da tanto.. meglio che tiri come un asinello che come una formica...
tanto consuma uguale! :)

"Prova... prova... e poi ci risentiamo ! Cosi' per curiosita' sai quanti watt si piglia il P4 HT !?"

e tu per curiosita' hai provato? posta qualche jpg e senza imbrogliare ;)
Grazie.

"Vi siete chiesti mai perchè è necessario aumentare la lunghezza delle pipeline per salire più facilmente in frequenza?"
me lo sono chiesto ma non hai risposto :D cmq probabilmente + è lunga la pipeline e + è stabile il processore alle alte frequenze, o una cosa del genere...
cmq non ho capito come si fanno ad avere prestazioni superiori del 500% se con l' hyperthreading puoi avere prestazioni (TEORICAMENTE...) del 200%, in quanto è come avere 2 processori(che condividono xò cache bus e tutto il resto...)
quindi,nn mi fido tanto di sto test :D

Come fa ad avere il 500% invece di 200%???

proprio perche utilizza quella parte di processore, registri, unita' o chiamatele come vi pare che in quel ciclo di clock non usa... (potenza sprecata o latente e lavora e che non lavora, mangia sempre come un bue)

Ricordiamoci che il nostro facchino... ha due braccia ma normalmente ne usa solo una... ma nel frattempo cammina, invece di ritornare al piano terra per ricevere altri ordini.... gli squilla il cellulare col capo che gli dice... quanto torni giu passa prima al 3° piano e intanto pensa a quanto fa 2+2 e riferisci il risultato al capo del piano, intanto lui ci va ci pensa durante il tragitto... da la risposta esatta che era 4 al capo chegli ordina di riandare al 10 per portare un documento e di aggiungere 1 al risultato di prima... porta sto documento al piano 10 e gli dice... il risultato di prima piu quell'altro e' 5...
Quando ritorna al piano terra il facchino, ha fatto piu cose, perche per ogni ordine non e' dovuto ritornare al piano terra e poi risalire per poi riscendere perche dal ventesimo piano ci deve passare per forza :)

quando hai due cpu.... le due cpu si dividono i compiti... mezza io mezza tu...
ma sempre in modo non efficente... cioe non sono sfuttate come la soluzione precedente... su e giu.... per ogni ordine prima invece ha fatto 4 cose invece di una alla volta... con lo stesso viaggio (ciclo)
Quindi hai esettamente il doppio (200%) di inefficenza... di un qualcosa che e' gia inefficente di per se... perche il nostro omino prima non faceva una mazza.... ora durante il viaggio si spacca il c..o :)
ecco perche raggiungi a volte e dico a volte il 500%....
Ripeto l'esempio e' banale ma ci calza a pennello...

Originally posted by "magomerlinopaolo"

"Vi siete chiesti mai perchè è necessario aumentare la lunghezza delle pipeline per salire più facilmente in frequenza?"
me lo sono chiesto ma non hai risposto :D cmq probabilmente + è lunga la pipeline e + è stabile il processore alle alte frequenze, o una cosa del genere...

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... ;)


cmq non ho capito come si fanno ad avere prestazioni superiori del 500% se con l' hyperthreading puoi avere prestazioni (TEORICAMENTE...) del 200%, in quanto è come avere 2 processori(che condividono xò cache bus e tutto il resto...)
quindi,nn mi fido tanto di sto test :D

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?

Originally posted by "J0J0"

cdimauro

eh... sei tornato.. pensavo fossi morto :)

Mortacci tua! Mi sto toccando gli attributi!!! :D

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


i pezzi ti sono arrivati?

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! :cry:


Domani metto le mani su un 2400+ a 266 con abit KT400 :) vediamo fin dove arriva....

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... :D

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... ;)

Originally posted by "Ham"

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?

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 :D...........

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...

Originally posted by "cdimauro"

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 :D
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!!!!!!!) :D........
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

Originally posted by "ErPazzo74"

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é.
Hai ragione ho detto una caxxata :D

Secondo me hai cominciato ad alzare il gomito troppo presto: per le feste ci vuole ancora qualche giorno... :)


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.

Infatti. L'HT è ancora troppo immatura come tecnologia sia perché manca del codice ottimizzato appositamente sia perché i quantitativi di cache L1 in particolare (quella dei dati è di soli 8KB :(, mentre quella del codice può contenere soltanto 12mila istruzioni RISC-like) e L2 sono troppo scarsi. Infatti, se andiamo a vedere le altre architetture che integrano più core nella stessa CPU, sono sempre dotate di cache L1 e soprattutto L2 di generosissime dimensioni...


Lo sò scrivo da cani............ma ho un mal di denti (maledetto dente ha aspettato le feste e natale!!!!!!!) :D........

Mi spiace. Vorrà dire che mangerò una bella fettona di pandoro anche per te... :D A parte gli scherzi, spero che ti possa rimettere presto... E buone feste anche a te! :)


Ciaoooooooo.........
PS Nel tuo post per thread diversi fra loro intendevi di due diversi processi chiaramente.........

Esattamente. Comunque anche se due thread appartegono allo stesso processo non è detto che debbano utilizzare le medesime porzioni di codice e/o dati: possono benissimo essere delegati a funzioni completamente diverse, pur condividendo il medesimo working set (a parte lo stack e i dati locali, ovviamente).

Un esempio potrebbe essere dato da un emulatore che utilizza un thread per "prestare orecchio" ai messaggi di Windows e interfacciarsi col sistema operativo, mentre un altro thread si occupa di emulare effettivamente la CPU, un altro ancora potrebbe occuparsi del grafica, un altro del sonoro, e così via...

Originally posted by "aht"

:( 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

Gira la tua domanda nella sezione apposita "Periferiche di memorizzazione" del forum! ;)

"......guardi le conviene perké appena arriva HT, potrà navigare come se avesse fastweb, anke con un 56k" :D

è quello ho sentito dire poki giorni fà in un negozio, il negoziante verso un cliente ke stava prendendo una P4PE :D

io mi sono avvicinato al banco e jo detto "MSI KT4-ULTRA Grazie" :D

byz

Io Aspetto solo che uscirà il 3000+
Addio Pentium. :)

non ne capisco molto, cmq adesso devo acquistere un nuovo pc ero intenzionato a prendere un amd athlon pero dopo tutto quello che ho letto sul forum ho cambiato un po idea....
ho sempre creduto che i processori intel erano + lenti e si bruciassero facilmente..e cosi?
cosa mi consigliate un amd athlon o un intel p4?
il mio indirizzo e-mail è bubici@hotmail.com
rispondetemi per favore!! ciao grazie

E' un po' troppo generica come richiesta: dovresti dirci almeno a cosa ti serve il PC e più o meno quanto vorresti spendere...

sarei disposto a spendere cira 1100,00 E

Non ci hai ancora detto a cosa ti serve il PC: è un'informazione fondamentale per stabilire quale sistema è più adatto alle tue esigenze...

bhee, ho 16 anni e col pc non ci faccio moltissimo, scarico da internet, gioco (mi piaciono i giochi con alta grafica) navigo, uso programmi per la creazione di musica, ci masterizzo,gurdo film (divx, dvd) e e ora sto iniziando a usare 3D studioMax e autocad ecc ecc.....

Con 1100€? Mmh... Le applicazioni che utilizzi sono molto varie. Ti conviene prendere un sistema con un Athlon XP 2000+ o 2200+ (vedi quando riesci a tirare sul prezzo di tutto il computer), scheda madre nForce2 (EPOX 8RDA+) e 512MB di DDR PC2700. Per la scheda video ti può andare bene una Radeon 9500PRO. Con quel che rimane ti compri il resto dei pezzi che mancano...

in un negozio di informatica la "B&D informatica Extreme store di Cavenago di Brianza" ho trovato una buona offerta e sono sicuro di prendere quella...
allora....Amd Athlon XP 2,6+ghz 512 mb ram ddr pc266 brand hdd da 40 gb a 7200 giri scheda video ge force 4 da 128....
secondo me è un'ottimo pc!!!

Peccato per la GF4... Con quei soldi potresti prendere una Radeon 9500 con 128MB che promette MOLTO BENE... ehehehe ;)

Vedi se puoi farti cambiare la piastra madre con una col chipset nForce2...

oggi lo ordinato allora ho preso un 2,4ghz+ athlon xp
gli ho fatto mettere 1giga di ram
e sfortunatamente la scheda video nn l'avevano...
cmq tu mi consigli una ati radeon 9500 da 128?? piuttosto che la ge force 4 da 1288??

Certamente: è DirectX 9 anziché 8, compete con la 4600 in termini di velocità, la qualità video è superiore (anche nei DVD), e poi circolano voci in rete che si possa facilmente modificare per farla diventare una 9700... :D

:rolleyes: Facilmente e' tutto da vedere :( , comunque io ho ordinato la Hercules 9500 pro ma non ho capito se x portarla al massimo devo cambiare resisteza e mettere il bios o solo il bios?, la' parlano inizialmente della 9500 pro poi della 9500 liscia e, io non ho capito molto... Ciao ! :p

Dalle notizie che ci sono in rete, dovresti cambiare la resistenza per abilitare il bus a 256 bit e cambiare il bios per abilitare tutte e 8 le pipeline della grafica...

:rolleyes: ma il modello pro non ha gia' le 8 pipeline ?... quindi dovrei fare solo la modifica x avere il massimo ??? ;)