Newsgroup: it.comp.hardware.cpu
Titolo: Intel P4 3 GHz HT (Hyper Threading)

INTEL INTRODUCE LA TECNOLOGIA HYPER-THREADING
CON IL NUOVO PROCESSORE Pentium® 4 A 3 GHz
Grazie alla tecnologia Hyper-Threading il processore virtualmente raddoppia:
per il sistema operativo e il software applicativo è (quasi) come se ce ne
fossero due!
Milano, 14 novembre 2002 - Intel Corporation presenta l`innovativa
tecnologia Hyper-Threading (d`ora in poi HT) in occasione dell`introduzione
del processore Intel® Pentium® 4 a 3,06 GHz per i PC desktop. La tecnologia
HT può aumentare fino a +25% le prestazioni dei PC e consente di gestire
rapidamente più applicazioni contemporaneamente.
Oltre a introdurre la tecnologia HT nei PC desktop, Intel ha raggiunto un
altro importante traguardo con il lancio del processore Pentium 4 a 3,06
GHz. Si tratta del primo microprocessore commerciale a operare a 3 miliardi
di cicli al secondo grazie alla tecnologia di produzione a 0,13 micron, la
più evoluta del settore. Il processore Pentium 4 è il microprocessore più
potente finora disponibile per i PC desktop.
"Ormai ci ritroviamo sempre più spesso a fare diverse cose alla volta, e ci
aspettiamo che anche il PC operi in multitasking", commenta Louis Burns,
Vice President e General Manager del Desktop Platforms Group di Intel. "La
tecnologia Hyper-Threading è un`innovazione all`avanguardia nel computing
che consente agli utenti domestici e professionali di realizzare di più in
meno tempo".
Secondo un recente sondaggio commissionato da Intel, oltre il 75% degli
utenti afferma di utilizzare il computer più o meno frequentemente in
modalità multitasking. Dallo stesso sondaggio, condotto da Harris
Interactive, emerge che la combinazione più diffusa di multitasking consiste
nel giocare a un videogame durante la masterizzazione di un CD. Circa il 50%
degli utenti che possiedono un PC da almeno tre anni afferma di non ritenere
i computer precedenti in grado di gestire più di un`attività ad elaborazione
intensiva alla volta.
I PC basati sul processore Pentium 4 a 3,06 GHz con supporto per la
tecnologia HT sono già disponibili presso i principali produttori di
computer nel mondo. Gli acquirenti possono identificare tali PC dalla
dicitura "HT" riportata sul logo del processore Pentium 4.
Che cos`è la tecnologia Hyper-Threading?
Con la tecnologia HT, gli utenti di PC possono ottenere prestazioni più
elevate in due modi: eseguendo programmi multithreaded oppure utilizzando il
software in un ambiente multitasking. Le applicazioni software scritte per
utilizzare più parti di codice, denominati thread, "vedono" il processore
Pentium 4 a 3,06 GHz con tecnologia HT come se se si trattasse di due
processori. Tramite la tecnologia HT, il processore è in grado di gestire
due thread separati contemporaneamente anziché uno alla volta. Inoltre, le
applicazioni eseguite con sistemi operativi come Windows* XP o Linux*
possono trarre vantaggio da questa tecnologia negli ambienti multitasking,
in cui vengono eseguiti due o più programmi differenti contemporaneamente.
In entrambi i casi, gli utenti ottengono prestazioni più elevate e tempi di
attesa inferiori.
Vantaggi per gli utenti domestici con l`editing di audio e video digitali
I più recenti PC a elevate prestazioni garantiscono la massima creatività
con i contenuti digitali, un`esecuzione veloce dei videogame on line e una
maggiore flessibilità con il multitasking. I sistemi basati su processori
Pentium 4 con supporto per la tecnologia HT continuano a offrire tempi di
risposta rapidi anche durante l`elaborazione di task in background.
Gli utenti possono ad esempio giocare a un videogame realistico mentre
trasferiscono un album di fotografie di famiglia su DVD, oppure masterizzare
un CD musicale durante l`editing di filmati amatoriali. Il mixaggio di
musica e l`editing di video possono essere eseguiti contemporaneamente a una
velocità fino al 21% più elevata con un PC basato su processore Pentium 4 a
3,06 GHz con supporto per la tecnologia HT, rispetto a un sistema senza
questa nuova tecnologia.
I vantaggi del multitasking per gli utenti professionali
I sistemi basati sul nuovo processore Pentium 4 a 3,06 GHz aumentano la
produttività delle aziende: la tecnologia HT offre infatti ai responsabili
IT la possibilità di migliorare l`efficienza e la sicurezza
dell`infrastruttura con nuovi servizi, riducendo allo stesso tempo i tempi
di fermo per gli utenti finali. Le applicazioni in background, ad esempio la
scansione antivirus, la crittografia o la compressione, possono essere
eseguite contemporaneamente senza compromettere la rapidità dei tempi di
risposta. Ad esempio, per la compressione di una cartella di Outlook*
durante l`esecuzione di WinZip* è stato riscontrato un aumento delle
prestazioni del 35% con la tecnologia HT abilitata. Adobe Photoshop* può
essere eseguito a una velocità del 21% più elevata durante una scansione
antivirus con MacAfee*.
Prezzi, prestazioni e disponibilità
Il processore Pentium 4 a 3,06 GHz offre le prestazioni più elevate oggi
disponibili per i PC desktop basati su Microsoft Windows*, secondo le
misurazioni del benchmark SPEC CPU 2000*, con un punteggio SPECint_base2000*
di 1099 e un punteggio SPECfp_base2000* di 1077. Ulteriori incrementi delle
prestazioni possono essere raggiunti utilizzando il software threaded o in
specifici scenari di utilizzo multitasking (ulteriori informazioni sono
disponibili all`indirizzo 
http://www.intel.com/performance**
.)
I sistemi basati sul processore Pentium 4 a 3,06 GHz con supporto per la
tecnologia HT sono già disponibili sul mercato***. Intel ha inoltre iniziato
a fornire ai distributori autorizzati Intel le versioni "in box" dei
processori Intel Pentium 4 a velocità fino a 3,06 GHz, destinate agli
integratori di sistemi di tutto il mondo.
Il processore Pentium 4 a 3,06 GHz è disponibile al prezzo unitario di 637
dollari USA in lotti da 1000 unità.
Intel, il maggiore costruttore al mondo di chip, è inoltre uno dei maggiori
fornitori di prodotti per il mercato personal computing, networking e
communication. Per ulteriori informazioni su Intel, consultate il sito World
Wide Web all`indirizzo 
www.intel.it/pressroom
.

 CON IL NUOVO PROCESSORE Pentium® 4 A 3 GHz
Finalmente hyperthreading sui desktop: ammetto che l'SMT è una tecnologia
che mi piace molto...
Sono 81 W da dissipare, cmq...
Saluti.
--
//   Xelloss da Bologna  || in real life: Wilmer Ricciotti   \\
|  
wirix...@libero.it
 (elimina il demone per rispondermi)  |
|    ICQ: 3233084        IRC: Xelloss@AzzurraNet, @ChatNow    |
| Hardware Information & Technology: 
http://hit.edengames.net
 |
\_______Like the Phoenix I rise from the ashes of life________/

 che mi piace molto...
viva intel che è sempre all'avanguardia....
altro che AMD che non ha uno straccio di Hyper Threading!

altro che AMD che non ha uno straccio di Hyper Threading!
senz'offesa ma secondo me sei finanziato dall'Intel per gettare fango
sull'AMD inutilmente...
--
Rhymes (
rhymes_...@myself.com
)
http://www26.brinkster.com/rhymes
" ride or die "

 ha scritto nel messaggio
news:Gt9B9.12843$744.4...@news1.tin.it...

Comunque dalle prove non mi sembra che un P4 stracci un XP2800+...
Considerando che poi un PIII 3GHz al momento costa circa 930 euro.
Ciao

 disponibili all`indirizzo 
http://www.intel.com/performance**
.)
In effetti le prestazioni sono molto alte, anche se per me il P4 rimane un
processore troppo costoso da produrre e troppo spinto sul fronte della
frequenza operativa. Comunque complimenti ad Intel, ha prodotto una CPU
veramente veloce. Rimango comunque della mia idea: non comprerei mai un
processore con degli assorbimenti (81 W) da locomotiva per il mio PC di
casa.
Saluti.


Hahahhaa   !!
^_^    Non mi importa il costo ! lo voglio subito, si Può montare su una
CuBX ???    ^_^
Ti immagini se ci fosse che prestazini avrebbe ? Altro che P4....   :o)
Ciao,
Zante.

 casa.
Beh, invece uno da 76W fa molta differenza per i consumi del PC? O forse ti
preoccupa l'affidabilità/stabilità?

 Considerando che poi un PIII 3GHz al momento costa circa 930 euro.
Su questo concordo. Ma se tiene questi prezzi, si vede che gli acquirenti li
ha comunque, e quindi chi non lo farebbe?  ;-)

 Grazie alla tecnologia Hyper-Threading il processore virtualmente
raddoppia:
Di prezzo!


Accidenti... con 930 euro mi faccio un signor pc completo ;-)
Ciao

> Accidenti... con 930 euro mi faccio un signor pc completo ;-)
A chi lo dici...  ma "noi" siamo pochi in confronto all'universo dei
potenziali acquirenti.
E chi se lo compra a 930 euro c'è, eccome. Quindi Intel dal canto suo fa
bene a sfruttare questo fatto.
Ovvio che per noi è peggio. Ma il mercato è così...

 più veloce del nuovo nato Intel.
Vedi ad es test di grafica OpenGL Spec, dove il 2800+ distanzia il P4 di
un'enormità...

Adesso che Intel ha una CPU che dissipa 81W e che usa dissipatori che
occupano quasi 1/5 della MoBo, spero che tu la smetta di sparare cazzate su
quanto scaldano gli Athlon.
Devo ammettere che l' HT non e' male come tecnologia, ma considerando che
col prezzo della sola CPU mi compro un buon' desktop completo, non mi sembra
poi tanto conveniente per il momento.
--
Max
"...strange game, the only way to win is not to play."
Joshua aka W.O.P.R.

 ha scritto nel messaggio
news:m68B9.17848$Yw.7...@news2.tin.it...
<megacuttone>
Ma postare direttamente il link no?
7kb di ca**ate mi son dovuto scaricare...
Con cosa lo raffreddano il p4 a 3ghz? Col frigorifero?
Quando esce Hammer non riderai più così tanto...
Ciao tifoso
PS: Ci sono tre possibilità sul tuo comportamento:
1) Intel ti paga
2) Intel non ti paga e allora saresti proprio fesso a farle pubblicità
aggratis
3) Sei proprio così e non c'è niente da fare, sei un tifoso

 preoccupa l'affidabilità/stabilità?
Chiariamoci, io non comprerei mai neanche un Athlon XP, per il mio PC di
casa. Lo preferisco al P4, ma comunque è troppo spinto anche lui. Secondo me
una CPU per un PC di casa non deve superare i 10 W medi. Poi ovviamente
ognuno fa quello che vuole. Se dovessi cambiare computer, monterei
probabilmente un P3 Ultra Low Voltage, oppure un Banias Ultra Low Voltage
quando sarà disponibile.
Saluti.

 questa nuova tecnologia.
"un sistema" e' da leggersi "rispetto ad un P4 senza HT".
 

 thread condividono lo stesso segmento di codice, due processi no...
e allora???? hyper treading sfrutta i thread, indipendentemente che siano in
uno stesso processo o in 2 processi separati! (ovviamente!)

P4 wrote:

Uhm! Mi sa che non ti e' chiaro il motivo per cui lo
hanno chiamato HyperTHREADing invece di HyperTASKing.
I thread *condividono* le page table di gestione della memoria
virtuale, mentre di solito i task *non* lo fanno (a parte la mappatura
delle zone di codice e dati del S.O. , ma non in tutti i S.O.
e non in tutte le versioni del kernel).
Significa che se vuoi *sperare* di veder aumentare le prestazioni
del sistema devi tenere in esecuzione thread che condividono
la stessa page table (due thread di una stessa applicazione
oppure un thread di un applicazione ed un thread "di sistema"
che usa la porzione di page table comune a tutti i task).
L. Micheletto


E messaggio promozionale con il gingle dove lo metti?

 porzione di page table comune a tutti i task).
Dove  hai  letto  'sta  cosa?  I  threads  appartenanti  a  processi
diversi, dovrebbero beneficiare  del HT piu` ancora  dei threads che
condividono porzioni  di memoria,  proprio perche` non  rischiano di
bloccarsi reciprocamente con i vari mutex, semafori, ecc...
-- 
http://fantoibed.da.ru
    |   linux   |  
http://www.spippolatori.com
 UIN:62959208             | addicted  |  email:  
fant...@libero.it

fantoibed wrote:
 > Lorenzo Micheletto ha scritto:
 >
 > >Significa che se vuoi *sperare*  di veder aumentare le prestazioni
 > >del sistema  devi tenere in  esecuzione thread che  condividono la
 > >stessa page table (due thread di una stessa applicazione oppure un
 > >thread di  un applicazione ed  un thread  "di sistema" che  usa la
 > >porzione di page table comune a tutti i task).
 >
 >
 > Dove  hai  letto  'sta  cosa?  I  threads  appartenanti  a  processi
 > diversi, dovrebbero beneficiare  del HT piu` ancora  dei threads che
 > condividono porzioni  di memoria,  proprio perche` non  rischiano di
 > bloccarsi reciprocamente con i vari mutex, semafori, ecc...
Se si legge per bene la documentazione relativa a come e' implementato
l'SMT sui P4 si trovano le seguenti informazioni:
1) In ogni caso i thread che "coabitano" condividono le cache.
2) I TLB delle istruzioni (ITLB) sono replicate e le TLB dati (DTLB)
    sono partizionate, quindi oltre a dover condividere le cache
    *nell'accesso ai dati* pure il meccanismo di traduzione indirizzi
    ne risente (ma se l'indirizzo fisico caricato a cui accedono
    e' lo stesso si usa la stessa linea di cache,niente doppioni).
3) Se si commuta tra due thread appartenenti allo stesso task
    buona parte della page table "privata" e' la stessa
    quindi il thread schedulato si trova la page table
    "parzialmente precaricata" e quindi ci sono meno tempi morti.
4) Le maggiori penalizzazioni si hanno quando due thread
    usano le stesse unita funzionali (es: due thread che fanno un sacco
    di calcoli in floating point ed usano poco il resto).
Questo in altre parole significa che se hai due thread di task
diversi e' *sicuro* che "si fregano le cache" tra loro, se invece
i due thread appartengono allo stesso task (e chi ha scritto
l'applicazione ha fatto ricorso al multithreading con raziocinio)
si ritrovano con dati e/o codice in comune "precaricato"
dall'altro task (es: la classica coppia produttore-consumatore
di una "pipeline software"), inoltre e' piu semplice realizzare
un bilanciamento nell'uso delle unita funzionali della
cpu in modo da sfruttarla per bene.
Lo stesso accade se si sta eseguendo un thread di una applicazione
ed un "thread di sistema" (quelli di solito "muovono qualcosa"
o fanno altre cose che per la maggior parte comportano
attesa di eventi esterni, quindi *di solito* "portano avanti i lavori
in corso" senza ingolfare la cpu limitandosi a sfruttare i "buchi"
lasciati liberi dal thread "applicativo").
Se invece girano due thread di applicazioni diverse ti possono
capitare thread che seppure non logicamente in conflitto tra loro
sono in conflitto continuo per l'uso delle stesse risorse
lasciandone altre inutilizzate.
Ripeto, e' per questo che Intel stessa parla di HyperThreading
e *non* di HyperTasking (quello e' molto meno "hyper").
L. Micheletto

 dall'altro task (es: la classica coppia produttore-consumatore
              ^^^^
Oops! Intendevo "thread", non "task".
L. Micheletto

 Dove  hai  letto  'sta  cosa?
uhm.... un buon libro di sistemi operativi ? no scusa, per queste cose ne 
basta uno appena decente...

 e *non* di HyperTasking (quello e' molto meno "hyper").
HyperTasking sarebbe limitativo.... ;-)

 no scusa, per queste cose ne basta uno appena decente...
Che bello! C'e' un super esperto di sistemi operativi, qui! :-)))
Io ho letto "Sistemi Operativi" di Tanenbaum che, visto che sei un
esperto, conoscerai a memoria! Mi puoi dire a che pagina parla
dell'implementazione dell'HyperThreading sulle CPU Intel? Sai, mi
dev'essere sfuggito.... ;-)

 1) In ogni caso i thread che "coabitano" condividono le cache.
Mi ero dimenticato la cosa piu` banale e piu` lampante, cioe` se due
threads  coabitano e  condividono  le proprie  risorse (ram,  cache,
registri,  ecc), *non*  potranno essere  eseguiti contemporaneamente
*proprio* per questo motivo! Vedasi "il proplema dei lettori e degli
scrittori" e via dicendo...


 quando sarà disponibile.
Contento tu... Un P3 ULV a 600MHz costa più o meno il quintuplo di un
Celeron 1300, andando la metà. Beh, risparmi qualche watt, ma se non vai a
batterie il guadagno non lo vedo. A parte i 3 euro all'anno di Enel
risparmiati...

 risparmiati...
Il P3 Ultra Low Voltage è un processore oramai vecchio, anche se ha
caratteristiche molto interessanti. Mi sembra comunque che raggiunga
frequenze maggiori, anche se non di molto (ho verificato, 750 Mhz). Banias
raggiungerà i 900 Mhz nella versione Ultra Low Voltage, è grazie anche alla
cache di 1 Mega raggiungerà prestazioni invidiabili, paragonabili ai
P4-Mobile. Ovviamente per le prestazioni massime sarà meglio Banias 1,6 Ghz,
che avrà prestazioni paragonabili al P4 a 2,4 Ghz. Comunque il risparmio è
ben maggiore di quello che tu ipotizzi. Lasciando il PC acceso otto ore al
giorno, si può tranquillamente stimare una riduzione dei costi superiore ai
5 euro mensili, ovviamente da verificare. Dunque in un anno fanno 60 Euro, e
moltiplicato per il numero di anni in qui si utilizza il PC sono belle
palanche... Inoltre il consumo dei PC deve diminuire, come devono diminuire
i consumi delle automobili. Più consumo, più inquinamento totale... Per
quanto riguarda il costo del processore è solo una questione di volumi,
produrre un P3 Ultra Low Voltage non costa di più che produrre un Celeron
1300 Mhz. Anche Banias non costerà poco, ma perchè se ne venderanno pochi, a
causa della stupidità della gente... Viva i processori a basso consumo,
senza problemi di dissipazione, proprio come i vecchi PC... Il dissipatore
attivo sui processori è una sconfitta della tecnologia. Bisognerebbe imporre
limiti di consumo massimi, nel rispetto del bene della collettività. Abbasso
i tecnici Intel e AMD, e con loro quelli del marketing che spingono tutto
sulle prestazioni. Per il futuro comunque sono ottimista, si fa sempre a
tempo a cambiare strada ...
Saluti.

 ovviamente è il mio parere, anche se veritiero.
Non vendono sotto costo, semplicemente ammortizzano il costo degli
impianti su piu prodotti (non le sole cpu) ed i costi di ricerca
e sviluppo vengono "spalmati" sia sul prodotto che sui brevetti
(che fruttano soldi anche ad anni di distanza, basta pensare
  a quanto hanno fruttato ad Intergraph i brevetti di una cpu
"morta" anni fa).
L. Micheletto

fantoibed wrote:

Un buon libro di pesca non ti insegna a pescare il tonno, la trota
o il salmone, ma piuttosto ti insegna a pescare il pesce
e ti fa l'esempio del tonno, della trota ecc. ecc.
Se ne comprendi il significato profondo poi non ci sono problemi
a pescare anche storioni e squali ... e se sei particolarmente
dotato ti fai pure le balene (che pesci non sono) ;-)
un Lorenzo che poi il guaio grosso e' che i buoni libri
            sono merce rara.
P.S. Quello di Tanenbaum e' un buon libro, ovviamente, ma
      bisogna saper generalizzare i concetti espressi visto
      che ad esempio le caratteristiche peculiari di un sistema
      SMT sono diverse da quelle di un SMP o di un uniprocessore.

fantoibed wrote:
 > Lorenzo Micheletto ha scritto:
 >
 > >1) In ogni caso i thread che "coabitano" condividono le cache.
 >
 >
 > Mi ero dimenticato la cosa piu` banale e piu` lampante, cioe` se due
 > threads  coabitano e  condividono  le proprie  risorse (ram,  cache,
 > registri,  ecc), *non*  potranno essere  eseguiti contemporaneamente
 > *proprio* per questo motivo! Vedasi "il proplema dei lettori e degli
 > scrittori" e via dicendo...
Tu confondi il *problema* con l' *applicazione*.
Il problema dei lettori e degli scrittori tratta della sola
*sincronizzazione* tra task/thread/processi concorrenti
ma non si accenna ai *vantaggi* dovuti all'avere processi
concorrenti.
Esempio 1: supponi di dover eseguire due filtraggi
separati su uno stream di dati in ingresso
(es: compressione di un flusso video E analisi
       dell'immagine per inseguire la persona inquadrata
       con la telecamera con zoom ed orientamento
       controllati da computer)
i due thread operano sullo stesso dato ma l'unica sincronizzazione
avviene al cambio di frame.
Esempio 2: due thread di un web server *condividono* il codice.
Esempio 3: pipeline software che elabora un flusso di dati in ingresso
             il primo thread legge un pacchetto, lo elabora, lo passa
             al secondo thread che esegue la seconda passata.
             Il "pacchetto in transito" prodotto dal primo thread
             e' altamente probabile sia gia in cache pronto
             per essere elaborato dal secondo thread.
             La sincronizzazione e' banale.
L. Micheletto

fantoibed wrote:
 > >Se si legge per bene la documentazione relativa a come e'
 > >implementato l'SMT sui P4 si trovano le seguenti informazioni:
 >
 >
 > Ti riferisci a
 > 
http://www.intel.com/technology/itj/2002/volume06issue01/vol6iss1_hyper_threading_technology.pdf
 > ?
Se intendi citare:
   "The second optimization is in scheduling software
    threads to logical processors. In general, for best
    performance, the operating system should schedule
    threads to logical processors on different physical
    processors before scheduling multiple threads to the
    same physical processor. This optimization allows
    software threads to use different physical execution
    resources when possible."
Ricorda che l'ottimizzazione descritta non serve per sfruttare
meglio l'Hyperthreading quanto piuttosto per NON AFFOSSSARE
le prestazioni di applicazioni scritte supponendo *anche* di farle
girare su sistemi SMP.
Le ottimizzazioni per un sistema SMP "puro" sono diverse
rispetto a quelle per un SMT "puro".
Con un SMT hai le cache e le unita funzionali in coabitazione
(condividere dati in cache e' vantaggioso, ma la "coabitazione"
   a livello di unita funzionali e' svantaggiosa), con un SMP puro
invece ogni task o thread ha la *SUA* cache e le *SUE* unita
funzionali ma la condivisione/sincronizzazione di dati in cache
(su cpu diverse) e' molto piu onerosa (bisogna "uscire fuori").
Praticamente i vincoli sulle prestazioni tra SMT ed SMP sono
diversi, per questo, visto che la maggior parte del software
in circolazione al massimo e' ottimizzato per SMP i tipi
della Intel dicono esplicitamente di dare la preferenza
agli schemi di utilizzo previsti per SMP.
 > >1) In ogni caso i thread che "coabitano" condividono le cache.
 >
 >
 > Questo e' vero, ma i thread *elaborano* anche l'informazione, non
 > leggono e scrivono solamente in ram e/o cache... E poi, hanno messo
 > 512kb di cache sui Pentium4 proprio perche' ci stia un po' di roba...
 > Bei tempi quando i 64kb complessivi di RAM del mio C=64 mi parevano
 > sufficienti a fare tutto.... ;-))
Guarda che per i S.O. e le applicazioni attuali 512KB di cache
ci si mette poco a riempirli e cominciare a caricare/scaricare
in massa le linee di cache
 > >2) I TLB delle istruzioni (ITLB) sono replicate e le TLB dati (DTLB)
 > >   sono partizionate, quindi oltre a dover condividere le cache
 > >   *nell'accesso ai dati* pure il meccanismo di traduzione indirizzi
 > >   ne risente (ma se l'indirizzo fisico caricato a cui accedono
 > >   e' lo stesso si usa la stessa linea di cache,niente doppioni).
 >
 >
 > ....E secondo te e' un caso che dal P4-2800 in poi la tlb sia stata
 > raddoppiata? (64->128 entries)
 > 
http://www.lostcircuits.com/cpu/p4_2800/
Eh! Ma l'aumento dei DTLB avvantaggia anche le applicazioni
single threaded.
Uno dei motivi per cui gli Athlon con core Palomino (Athlon XP)
hanno prestazioni superiori a quelli con il core precedente e' che
nei Palomino hanno aumentato le TLB.
 > >3) Se si commuta tra due thread appartenenti allo stesso task
 > >   buona parte della page table "privata" e' la stessa quindi
 > >   il thread schedulato si trova la page table "parzialmente
 > >   precaricata" e quindi ci sono meno tempi morti.
 >
 >
 > Vero, anche se in sistemi multitasking/threading, non "real time", la
 > cpu deve gestire migliaia di threads (sia a ring3 che a ring0) e non
 > si
 > ha spesso la fortuna che lo scheduler esegua uno switch di contesto
 > tra due thread "paralleli" che condividono le proprie "risorse".
 > Inoltre, il fatto che sia il sistema operativo a doversi preoccupare
 > della gestione di risorse condivise con mutex e semafori per evitare
 > deadlock e altre amenita', potrebbe far spendere alla cpu piu' tempo
 > di quanto ne spende a passare dalla page table di un thread a quella
 > di un altro thread appartenente ad un processo diverso: la GDT e'
 > infatti gia' caricata in cpu.... :-)
Se qualcuno scrive codice che sfrutta *MALE*, *MOLTO MALE* il multitasking
ed il multithreading e' un conto, ma di norma questo non succede.
Per esempio gli scheduler di solito "schedulano in sequenza" i thread
appartenenti ad uno stesso processo, in questo modo evitano
di dover ricaricare da zero la page table (che e' diversa dalla GDT)
ed aumentano le probabilita di ritrovare dati e codice incomune sulle
cache.
In secondo luogo chi scrive applicazioni multithreaded sta molto
attento alla granularita ed alle dipendenze in modo tale
che quel che si spende a sincronizzare gli accessi non pesi
troppo sulle prestazioni complessive.
Sempre su questo armomento ho risposto nell'altro messaggio.
 > >4) Le maggiori penalizzazioni si hanno quando due thread usano le
 > >   stesse unita funzionali (es: due thread che fanno un sacco
 > >   di calcoli in floating point ed usano poco il resto).
 >
 >
 > .... E questo accade *sicuramente* quando i due thread contengono
 > lo stesso algoritmo, e cioe' quando sono la duplicazione di una
 > certa ruotine! Se i due thread appartengono a due processi aventi
 > funzioni completamente diverse, accadra' *molto raramente* che
 > usino le stesse unita' di esecuzione.... ;-)
No, tutt'altro se chi scrive il codice sa quel che fa.
Di solito ad esempio nell'eseguire un filtraggio hai delle
elaborazioni floating point da fare (il filtraggio vero
e proprio), delle operazioni sugli interi (decremento contatori
ed incremento puntatori) e delle operazioni di load/store
*ma* per le dipendenze tra i dati non le puoi
eseguire tutte simultaneamente anche quando il thread
ha la cpu "tutta per se".
Se due thread eseguono lo stesso filtro su parti diverse
di un immagine hanno il codice in comune, non hanno dipendenze
sui dati e proprio perche usano le stesse unita funzionali
ma *non tutte contemporaneamente* possono sfruttarle meglio
(es: mentre il thread A usa le unita floating point, l'altro
      usa quelle sugli interi).
Se poi i filtri vengono usati "in pipeline" si ha che
il primo in catena "prepara in cache" i dati dell'altro
(ovvero lo stress sul FSB corrisponde ad un singolo filtro
   che legge/scrive, ma in realta nel core sono in esecuzioni
   due filtri con il primo che legge dalla ram esterna
   i dati, pre-elabora e mette in cache i dai per il secondo
   e poi il secondo thread esegue la sua elaborazione
   e rilascia i dati pronti per essere "rilasciati in ram").
Un simile livello di accoppiamento e' difficile da ottenere
con processi appartenenti ad applicazioni diverse
(che presumibilmente non hanno codice in comune, che hanno
   mappa di memoria diversa, ecc. ecc.).
L. Micheletto

 Un buon libro di pesca non ti insegna a pescare il tonno...
Se voglio  sapere come  pescare la  trota, mi  serve un  libro sulla
pesca, ma se voglio sapere come e` fatta e come "funziona" una trota
mi serve ul libro di  ittiologia. Perche` mi si dovrebbe consigliare
un libro  di sistemi operativi  e non  un datasheet per  capire come
funziona  un processore? Siamo  nella  gerarchia ic.*hardware*,  non
*software*!!! ;-)
-- 
http://www.fantoibed.da.ru
 |   linux   | 
http://www.spippolatori.com


 non hanno codice in comune, che hanno mappa di memoria diversa
All'accoppiamento  deve  pensarci  il   sistema  operativo,  non  il
programmatore! ...E  poi le  cpu dal  386  in poi  sono pensate  per
funzionare in un ambiente multiprogrammato, quindi e` impensabile di
dover ritornare ad  usare un solo programma alla  volta per ottenere
il 5% di prestazioni in piu`.... ;-)


            La sincronizzazione e' banale.
Si`,  ma non  si  ha alcun  vantaggio ad  usare  threads invece  che
processi... ;-)
-- 
http://www.fantoibed.da.ru
 |   linux   | 
http://www.spippolatori.com


"morta" anni fa).
In effetti ha spillato a Intel un bel po' di milioni... i brevetti in
questione cosa riguardavano?
-- 
ZHELGADIS THE LIGHTBRINGER (ICQ 33134824)
BAG #008,DPPSJ #000,BAT #013,TFC #012, GAMERDA #026
"Aspettare non č mai stato un problema, per me.
Posso trascorrere piacevolmente ore e ore con l'aiuto di un buon caffč"

fantoibed wrote:
 > Lorenzo Micheletto ha scritto:
 >
 > >condividere dati in  cache e' vantaggioso, ma  la "coabitazione" a
 > >livello di unita funzionali e' svantaggiosa
 >
 >
 > Quindi sei d'accordo con me.... ;-)
Si ma e' solo un aspetto della cosa, le prestazioni complessive
si ricavano mettendo insieme tutti gli aspetti vantaggiosi o
svantaggiosi che siano.
 > >con un SMP puro  invece ogni task o thread ha la  *SUA* cache e le
 > >*SUE* unita funzionali ma la condivisione/sincronizzazione di dati
 > >in cache  (su cpu diverse)  e' molto piu onerosa
 >
 >
 > Uno dei problemi che aveva il P4  senza HT, da quanto mi e` parso di
 > capire,  e`  che le  unita`  funzionali  non venivano  sfruttate  al
 > massimo  della loro  potenzialita`! Due processi  paralleli eseguiti
 > contemporaneamente in  modalita` HT, dovrebbero "riempirsi  i buchi"
 > tra di  loro e sfruttare  meglio le unita`  funzionali. E` evidente,
 > poi,  che il  SMP effettivo  e` meglio  di quello  simulato (per  il
 > principio  "du gust  is  mei che  uan!"), ma  ogni  singola CPU  non
 > verrebbe sfruttata al meglio....
Si, "riempiono i buchi" da un lato ma ne fanno altri sull'altro
(aumentano le propabilita di cache miss in assenza di codice
   ottimizzato a livello di thread).
L'ottimizzazione e' un vero e proprio gioco di equilibro tra vantaggi
e svantaggi e per sfruttare bene l'SMT bisogna sfruttarne bene
le peculiarita (ovvero stare molto piu attenti a coem si organizzano
i thread in un processo).
 > >Per esempio  gli scheduler  di solito  "schedulano in  sequenza" i
 > >thread appartenenti ad uno stesso processo,
 >
 >
 > Certo, ma  se deve  essere eseguito un  evento generato  dal kernel,
 > (tipo una richiesta di interrupt), la "sequenza" viene interrotta...
Certo, ma si perde meno tempo a schedulare tra due thread di uno stesso
processo piuttosto che tra due thread di processi diversi.
Ricorda che la parte di mappa "del S.O." e' comune a tutte le
page table dei processi, quindi il "peso" di uno scheduling tra
due thread di uno steso processo e' pari ad una qualsiasi chiamata
al S.O. ("leggerissimo" rispetto ad una schedulazione tra processi
diversi).
Tieni presente che i vari S.O. hanno aggiunto il supporto dei thread
proprio perche sono molto piu "leggeri" da switchare quando
appartengono allo stesso processo, anche quando si usano "semplici"
cpu non-SMT.
 > >Se due  thread eseguono lo  stesso filtro  su parti diverse  di un
 > >immagine hanno il codice in  comune, non hanno dipendenze sui dati
 > >e proprio  perche usano le  stesse unita funzionali ma  *non tutte
 > >contemporaneamente* possono sfruttarle meglio
 >
 >
 > Hanno codice  in comune, ma i  dati sono diversi, quindi,  come dici
 > tu, "si  rubano la cache" a  vicenda, per quanto riguarda  i dati...
 > ;-)
Si, ma in tal caso quel che conta e' spremere bene le unita funzionali.
Se il filtraggio consistesse in un semplice spostamento di dati
non ci sarebbero vantaggi, ma se devi "lavorarci sopra" la cosa torna utile.
Inoltre tu non immagini neanche che schemi di ottimizzazioni si possono
usare sapendo che si usa una cpu SMT, per esempio:
    Se la matrice viene partizionata in modo che i thread A e B
    filtrino "in interleave" le linee di cache sei sicuro che, se
    sono gli unici thread del processo, "procedono insieme"
    praticamente senza rubarsi le linee di cache.
Nota che l'esempio e' grossolano e che ci sono molte altre
tecniche e "trucchetti" per sfruttare bene l'SMT, ma lo puoi
fare solo a livello di thread di uno stesso processo.
 > >(es: mentre il  thread A usa le unita floating  point, l'altro usa
 > >     quelle sugli interi).
 >
 > Questo deve  avvenire (e avviene)  anche su processori  senza HT. Da
 > esperienze personali,  con un  programmino di  attacco crittografico
 > brute-force  sull'algoritmo DES  (su  Win2k), ho  constatato che  le
 > migliori  prestazioni (su  mono-P-II e  mono-P-III) si  hanno con  4
 > thread in  contamporanea! Salendo a 6  e 8 thread  si ha un  calo di
 > performance e la  stessa cosa accade anche scendendo a  1 o 2 thread
 > contemporanei!
Sono cose diverse, su una cpu senza HT i thread non vengono eseguiti
contemporaneamente, quello che cambia semmai e' come viene scandito
lo spazio delle soluzioni e come un thread "precarica" il codice
o i dati in cache per gli altri.
 > >Se poi i filtri vengono usati "in  pipeline" si ha che il primo in
 > >catena "prepara in cache" i dati dell'altro
 >
 > Gia`, ma il primo deve stare attento a non leggere dalla cache prima
 > che il secondo non vi abbia scritto! La soluzione c'e`, ma a scapito
 > di un calo nelle prestazioni....
Nessun calo, si seleziona la dimensione ottimale del "blocco"
che i due thread elaborano e poi passano, usando un ring buffer
di *almeno* 2 blocchi (e' una cosa banale, mentre un thread scrive
un nuovo blocco, l'altro legge da quello gia pronto)
ed il peso della parte di sincronizzazione che tanto ti preoccupa
e' quasi nullo.
Es: se la parte "sincronizzazione" pesa come un filtraggio
     di un blocco di N bytes, selezioni una dimensione di blocco
     di N*100 bytes ed il peso della sincronizzazione e' automagicamente
     ridotto a meno dell' 1%.
Inoltre tieni presente che con l'istruzione x86
     LOCK CMPXCHG
    (compare & exchange atomico su un dato di 4 byte)
oppure con
     LOCK CMPXCHG8B
    (compare & exchange atomico su un dato di 8 byte)
la sincronizzazione con semafori la fai senza dover eseguire
chiamate al sistema operativo.
E' per queste ragioni che la sincronizzazione quasi neanche
la considero (un buon programmatore ne minimizza il peso
quasi automaticamente).
 > >Un simile  livello di accoppiamento  e' difficile da  ottenere con
 > >processi appartenenti ad applicazioni diverse (che presumibilmente
 > >non hanno codice in comune, che hanno mappa di memoria diversa
 >
 >
 > All'accoppiamento  deve  pensarci  il   sistema  operativo,  non  il
 > programmatore! ...E  poi le  cpu dal  386  in poi  sono pensate  per
 > funzionare in un ambiente multiprogrammato, quindi e` impensabile di
 > dover ritornare ad  usare un solo programma alla  volta per ottenere
 > il 5% di prestazioni in piu`.... ;-)
Non ti e' chiaro il concetto: l'accoppiamento *lo fa gia* il S.O.
"tenendo in gruppo" (a livello di schedulazione) fin quando e' possibile
i *thread* appartenenti ad uno *stesso processo* (uso il termine processo
perche potrebbero esserci in esecuzione due istanze diverse di
una stessa applicazione, sono i thread di uno stesso processo
che e' bene accoppiare, non quelli di processi diversi anche se
sono la stessa applicazione).
Spetta poi al programmatore sfruttare le prestazioni in piu
che si hanno usando i thread (e questo vale anche per sistemi
uniprocessore, non solo per SMP o SMT).
Se si vuole sfruttare *bene* l'SMT bisogna strutturare ad hoc
i thread dei processi tenendo conto delle peculiarita
dei sistemi SMT, altrimenti piu del 5..10% e' difficile averlo.
L. Micheletto

fantoibed wrote:
 > Lorenzo Micheletto ha scritto:
 >
 > >Es 1)  compressione di un flusso video E analisi dell'immagine per
 > >       inseguire la persona inquadrata  con la telecamera con zoom
 > >       ed orientamento controllati da computer)
 > >i due thread operano sullo stesso dato ma l'unica sincronizzazione
 > >avviene al cambio di frame.
 >
 >
 > Sinceramente non conosco un singolo  programma che faccia queste due
 > cose  contemporaneamente,  figurarsi  in due  threads  dello  stesso
 > processo.... ;-)
 >
 >
 > >Esempio 2: due thread di un web server *condividono* il codice.
 >
 >
 > ....E che c'entra con il problema lettori/scrittori? ;-)
C'entra perche io parlavo (cito dal precedente messaggio)
di " *vantaggi* dovuti all'avere processi concorrenti"
inoltre i thread di un web server hanno strutture dati in comuni
su cui leggono/scrivono altrimenti come fanno spartirsi
il carico ?
[N.B. in un processo di web server multithreaded, i thread non vengono
       lanciati "per richiesta", altrimenti l'overhead di creazione e
       distruzione thread diventerebbe sempre piu pesante al crescere
       delle richieste, di solito vengono "creati in gruppi" in base
       al carico e tenuti in esecuzione fino a quando il carico
       non scende al di sotto di una certa soglia che varia
       di gruppo in gruppo ]
 > >Esempio3:  pipeline  software che  elabora  un flusso  di dati  in
 > >           ingresso  il  primo  thread   legge  un  pacchetto,  lo
 > >           elabora,  lo  passa al  secondo  thread  che esegue  la
 >
 >                            ^^^^^
 > Quando  dici  lo  "passa"  significa   che  questi  due  thread  non
 > condividono  codice  ne  dati,  quindi tanto  vale  parlare  di  due
 > processi diversi... ;-)
Condividono il buffer "di transito" (pipe o ring-buffer che sia)
inoltre se appartengono allo stesso processo e' piu probabile
che vengano schedulati insieme (in una cpu SMT uniprocessore).
 > >           seconda passata.   Il "pacchetto in  transito" prodotto
 > >           dal  primo thread  e'  altamente probabile  sia gia  in
 > >           cache pronto  per essere elaborato dal  secondo thread.
 > >           La sincronizzazione e' banale.
 >
 >
 > Si`,  ma non  si  ha alcun  vantaggio ad  usare  threads invece  che
 > processi... ;-)
No, se usi processi diversi aumenti la probabilita che un thread
sia in esecuzione ... quando l'altro non c'e' !!!!
(sputtanamento completo del vantaggio di avere i due thread
   in esecuzione simultanea)
L. Micheletto

 *software*!!! ;-)
Perche la questione di cui si parlava non era "come e' fatto" (hardware)
un sistema SMT, ma piuttosto "come si usa" (software).
Il Tannenbaum "sta sul generico", ma i concetti che esprime
sono relativamente semplici da adattare alle peculiarita
delle varie architetture di sistemi di calcolo "convenzionali"
( qualsiasi cosa per cui abbia senso parlare di cpu e sistemi
   operativi).
Le ragioni per cui si e' arrivati ad ideare ed usare i thread
non dipendono da una singola architettura che se ne avvantaggia
in modo particolare ma quanto piuttosto dal fatto
che *in generale* sono "piu leggeri" dei processi.
Le cpu SMT (guarda la combinazione) traggono particolare vantaggio
nell' eseguire thread appartenenti ad uno stesso processo, questo
perche si suppone che tali tipi di thread "condividano piu roba"
che puo stare in cache, tutto li.
Se invece ci si ritrova con thread che "condividono poco", forse
e' il caso di rifattorizzare l'applicazione e separarli in processi
distinti in modo da avere una protezione della memoria piu
efficace (ma queste sono tutte rogne a carico di chi sviluppa
applicazioni).
L. Micheletto

 che vengano schedulati insieme (in una cpu SMT uniprocessore).
Il pipe  viene usato  nella comunicazione tra  *processi* e  non tra
*threads*.  I threads  condividono *direttamente* i loro  dati e non
se li devono passare... ;-)


 se li devono passare... ;-)
Se e' per questo il pipe lo usano anche gli idraulici, ma mi sembrava
chiaro il contesto. ;-)
Non pensare che solo perche una cosa te la fornisce un S.O.
non sia implementabile anche in altre forme.
L. Micheletto