AMD fornisce nuovi dettagli sull'architettura delle CPU Zen

[MaxFabio93]

Originariamente inviato da DukeIT

Del resto sostenere che in presenza di concorrenza i prezzi rimangano invariati va contro ogni legge di mercato. Certamente non mi aspetto grandi differenze inizialmenente (ma considerando la politica dei prezzi di AMD qualcosa meno dovranno costare), ma se veramente AMD riprende ad essere concorrenziale e riprende quote di mercato, il rapporto prestazioni/prezzo dei prodotti (sia AMD che Intel) non può che migliorare.

Tutto dipenderà anche dal mercato e dalle persone, come ragioneranno e soprattutto se useranno la testa prima di acquistare!

[demon77]

Originariamente inviato da MaxFabio93

Per me già le attuali CPU AMD competono con Intel solo per quelli che non li conoscono e non li usano tutti i giorni non è così per cui. Lo so benissimo quanto costavano visto che comprai proprio un PC con Athlon 64, il mio primo AMD con una Nvidia Geforce GT8600, la soluzione Intel (non mi ricordo quale) con stesse caratteristiche, e stesso hardware a parte la CPU costava molto di più.

Le nuove CPU AMD per forza di cosa costeranno meno di quelle Intel, già così è difficile vendere AMD agli ignoranti, figuriamoci con un prezzo alto.

Non ci sono dubbi sul fatto che anche con una cpu AMD fai tutto. Io in ufficio uso un vetusto core2 quad e non ho problemi, non è quello il nocciolo della questione.
Il fatto è che la vedi troppo come una guerra dove l'utente corre dietro al marchio e ti assicuro che non è così.
Io quando uscirono i primissimi athlon avevo un vecchio intel pentium.. al momento di mettere insieme il nuovo pc guardai i test e non ci pensai neanche un secondo a prendermi un AMD.
E con AMD sono rimasto fino a che mi conveniva. Con il mio attuale pc (core i7 2600K) sono tornato ad intel perchè al momento (2011) era Intel la migliore.
Se quando cambierò questo ci sarà una migliore proposta AMD cambierò di nuovo senza esitare.
E come me un sacco di gente.

[lucusta]

DukeIT,
il problema e' che una fabbrica sola non puo' soddisfare l'eventuale richiesta di soluzioni pari prestazionali ma piu' convenienti, quindi prevedo che inizialmente ci sara' speculazione su questi prodotti, tanto da renderli paragonabili al prezzo delle soluzioni intel con cui si andranno a confrontare.
non e' una cosa dipendente da AMD, ma dalla richiesta del mercato.
per ora, con quella sola fabbrica, AMD riuscirebbe solo a scalfire lo share di Intel, indipendentemente dalla bonta' e prezzo del prodotto.
la FAB 2 puo' gestire al massimo 35000 wafer al mese; stiamo parlando di 80-100 CPU lorde a wafer, a cui devi togliere quelle inutilizzabili per difetti, ossia al massimo di 35-40M di CPU; il mercato vende 250M di sistemi, probabilmente nella fascia da considerare non piu' di 200M; la FAB 2 puo' prendere massimo tra' il 15 ed il 20% del mercato della fascia considerata, e togliendo quelle server, siamo ben piu' sotto del 15%.

venderà, e guadagnera' il giusto, tanto magari da poter pensare al futuro, e GF alla costruzione di una nuova FAB, ma... arrivare alla concorrenza diretta significa produrre 100M di CPU, significa vendere per il 50%.
solo a quel punto si avra' reale concorrenza, e ci vuole almeno un'altra FAB piu' le linee TMSC per APU e cose varie.

[Yrbaf]

Originariamente inviato da lucusta

...
hyper threading non e' simultaneous multi thread.
HT e' un sistema della logica della ALU che permette d'iniziare un nuovo thread negli stadi lasciati liberi da un thread in operazione.
in effetti nelle prime implementazioni in willamette funziona cosi':
hai una pipeline a 20 stadi (il doppio di PIII tualatin);
viene messo in esecuzione un thread che, per calcolare il risultato, sarebbe finito al 14° stadio di pipeline; a quella data le architetture intel non potevano uscire direttamente fuori dalla pipeline alla fine del calcolo, ma dovevano skippare gli stadi eccedenti della pipeline fino all'ultimo (cosa corretta poi su netbrust).
quindi avresti dovuto iniziare dal primo, finire al 14° e skippare i restanti 6 stadi.
s'inventarono percio' l'HT.
invece di skippare 6 stadi introducevi un thread breve, da meno di 6 stadi, e poi lo facevi seguire dal thread piu' lungo (o skippavi prima 6 stadi, poi mettevi quello da 14 e in coda quello da >6).
nelle migliori delle ipotesi usavi la catena di calcolo della pipeline a ciclo continuo, ossia senza saltare un solo stadio per flushing.
su netbrust hanno migliorato soprattutto per l'uso dei 64 bit, che consente di estendere le istruzioni, ma era il periodo della corsa dei ghz e la pipeline fu' portata a 31 stadi; HT sembrava la panacea di tutti i mali, ma... i 10 ghz non si presero e si capi' che la strada era il multicore.
viene percio' abbandonato sui Core, che avevano pipeline piu' corte e quindi poco funzionali con HT.

O il concetto è espresso male o è proprio falsa l'affermazione.

Ci sono varie possibilità di Multithreading a livello di cpu ed SMT è una delle forme (la terza secondo i testi di riferimento che le classificano di solito proprio in 3).

E HyperThreading è il nome commerciale di Intel per il SMT.
Che tra l'altro non funziona proprio come lo descrivi tu (con il thread breve) o si capisce male la tua spiegazione.

E non sono a dirlo io, ma gente del calibro di Andrew S. Tanenbaum, David A. Patterson e John L. Hennessy.
Gli ultimi due sono due pilastri del mondo risc e l'ultimo tra l'altro è il fondatore di MIPS

[OttoVon]

"Ma se intel sta facendo solo +3% a nuova cpu"

Fino ad oggi Intel faceva concorrenza a se stessa.
Ovvio che tra un processore e l'altro ci sia, al massimo, una differenza del 10%.

Anzi che ha continuato a rilasciare cpu nuove, nonostante l'immobilità del settore.

[Piedone1113]

Originariamente inviato da lucusta

no, non l'ho dimenticato, e' che risulta difficile entrare nei dettagli di una presunta architettura che in effetti e' sconosciuta.
probabilmente ci voleva un bel IMO davanti...
comunque:

in Zen, grazie al compilatore (guardacaso si parla proprio di usare le stesse funzioni ed ottimizzazioni di intel che ci sono nel compilatore) puoi associare 2 istruzioni 64 e farla diventare una a 128; non e' una nuova ISA, perche' le istruzioni a 128 sono esclusivamente la combinazione di 2 da 64 (come alcune da 64 sono 2 da 32, e cosi' via... in precedenza si e' fatto cosi' perche' era necessario condensare ed estendere il set d'istruzioni, oggi, con le 64 bit, non conviene estendere ancora l'ISA per nuove funzioni... gia' alcune di quelle che ci sono sono sottoutilizzate... pero' e' vantaggioso comunque condensare il comando).
il decode della CPU ne riceve cosi' una sola a 128 bit, e lo scheduler amministra quelle 2 istruzioni come se fosse una.
e' il decode che poi le divide e le manda a due ALU 64 bit separate.

bene, BD ha 4 cluster, ogni uno formato da 2 alu 64 bit ed una FPU 128 bit condivisa (una soluzione che si e' rilevata pessima senza un coprocessore a virgola mobile, chip a se stante o GPU che sia, che comunque avrebbe apportato notevoli latenze);
Zen avrebbe 8 cluster, in cui pero' ogni cluster vale per un solo core; in piu', per ogni cluster, ha un decode come quello intel, che puo' prendere istruzioni a 128 e dividerle per le due ALU; quindi esegui 2 thread per cluster, ma facendo vedere che ne stai usando uno solo.

hyper threading non e' simultaneous multi thread.
HT e' un sistema della logica della ALU che permette d'iniziare un nuovo thread negli stadi lasciati liberi da un thread in operazione.
in effetti nelle prime implementazioni in willamette funziona cosi':
hai una pipeline a 20 stadi (il doppio di PIII tualatin);
viene messo in esecuzione un thread che, per calcolare il risultato, sarebbe finito al 14° stadio di pipeline; a quella data le architetture intel non potevano uscire direttamente fuori dalla pipeline alla fine del calcolo, ma dovevano skippare gli stadi eccedenti della pipeline fino all'ultimo (cosa corretta poi su netbrust).
quindi avresti dovuto iniziare dal primo, finire al 14° e skippare i restanti 6 stadi.
s'inventarono percio' l'HT.
invece di skippare 6 stadi introducevi un thread breve, da meno di 6 stadi, e poi lo facevi seguire dal thread piu' lungo (o skippavi prima 6 stadi, poi mettevi quello da 14 e in coda quello da >6).
nelle migliori delle ipotesi usavi la catena di calcolo della pipeline a ciclo continuo, ossia senza saltare un solo stadio per flushing.
su netbrust hanno migliorato soprattutto per l'uso dei 64 bit, che consente di estendere le istruzioni, ma era il periodo della corsa dei ghz e la pipeline fu' portata a 31 stadi; HT sembrava la panacea di tutti i mali, ma... i 10 ghz non si presero e si capi' che la strada era il multicore.
viene percio' abbandonato sui Core, che avevano pipeline piu' corte e quindi poco funzionali con HT.
nasce SB ed intel sfrutta l'idea di AMD: usare SMT (e si, perche' AMD dichiaro' che voleva produrre una tecnologia che faceva vedere un multi core come un unico core, lanciata nel 2002, ma mai messa in pratica nei phenom e non riuscita in BD, che non e' altro che una CPU riciclata da un progetto per server dove la parallelizzazione esiste e non serve nemmeno avere la FPU, visto che se ti serve fortemente calcoli in virgola mobile, usi HW dedicato... mancanza di risorse e di ingegneri capaci di farlo).
invece Intel lo fa', e se ne inventa anche un'altra: unire HT a SMT semplicemente usando la combinazione di 2 istruzioni a 64 bit e poterla fare anche assimmetrica, ossia un'istruzione da 128 bit in cui i primi o gli ultimi 64 bit sono zero, in modo da skippare l'ALU che si presume ancora occupata, quindi HT in un'ottica di vedere se le singole ALU sono libere, o con i primi stadi pipeline pronti per eseguire nuove istruzioni.

quindi, non considerando l'enorme lavoro svolto sulle latenze, l'associativita' di cache, la fine gestione della frequenza (e si spera anche voltaggio, questa volta) dei singoli core, Zen lo puoi vedere come l'unione di due BD octacore, in cui il cluster e' diventato propriamente un core fisico (e quindi con 2 ALU64 e 1 FPU128), con un decode che rispecchia il disegno architetturale di Intel, per assicurarsi sia compatibilità che lavoro gia' fatto....

il resto sono nuove istruzioni a metrica fissa SIMD e nuovo processo produttivo, oltre che l'adeguamento alle nuove tecnologie, all'integrazione di NB e gran parte del SB e ad altre chicche che pero' verranno "montate" in secondo tempo e sul refresh (si parla di un controller on die per nand e del controller HBM per una specie di caches L4 grande ed ad alta velocità da usare all'occorrenza come unica ram primaria... in pratica le APU potrebbero montare GNC4 on die, naturalmente, ma anche memoria HBM e disco flash su interposer, facendole diventare dei SiC a pieno titolo.. SiC= System In a Chip, ossia un sistema completo di ram, memoria di massa e tutto il resto in un unico chip).

ora, di tutto questo, la realta' e' che se non si hanno notizie piu' precise e benchmark, rimane solo un bel sogno ad occhi aperti.

si deve sapere come e' implementato SMT, quanta latenza aggiunge, e le frequenze operative, perche' una ALU64 AMD e' piu' veloce di una ALU64 intel dai tempi del K6III, mentre le FPU lo sono dai tempi dell'athlon (keller); da SB pero' le cose sono cambiate perche' intel usa 2 ALU, quindi diventa difficile confrontare 2 sistemi che computano in modo totalmente differente.

sotto la didascalia del +40% c'e' scritto che sono test interni di comparazione tra core zen ed excavator, quindi singolo core per ciclo di clock.
a grandi linee puoi vedere che quel +40% verra' mangiato dalla differente frequenza operativa dei core (in godavari si arriva a superare i 4ghz in default, che e' uno pseudo excavator, perche' godavari non e' propriamente excavator, ma un rifacimento di kaveri configurato piu' o meno come excavator nella dimensione dei registri);
se Zen viaggia a 2.8ghz il singolo core andra' piu' o meno come un godavari a 4.1ghz, ma in totale, in Zen, sono il doppio, quindi andra' il doppio di un 7870K.
il 6700K a 4ghz va' circa il 90% in piu' in multithread rispetto al 7870k a 4.1ghz, quindi se non lo supera, le prestazioni saranno ben allineate.

come dicevo nell'altro post, pero', se hanno usato una fine gestione delle frequenze in relazione all'uso che fa' dei core il programma principale in esecuzione, non e' detto che anche con i programmi che usano solo 4 core (giochi in DX11) andra' a 2.8ghz, ma probabilmente molto di piu', tale da poter egualiare il computo almeno di un 6700 (non k e a default) quad core, cosi' come potrebbe avere un clock sopra i 4ghz quando ne usa solo uno o due core (e solo su quelli in uso).
si avrebbe percio' un processore competitivo in single thread, ma anche di quad thread (principalmente giochi DX11 e pseudo DX12) ed ottenere ulteriore boost prestazionale in quelli che fanno uso di piu' core insieme (DX12 con ACE e AC o programmi professionali).
i pratica, fermo restando il TDP massimo, inalzi la frequenza operativa per ottimizzare l'esecuzione solo su una parte dei core, mentre ti poni su una frequenza ottimale quando li usi tutti, ottenendo le massime prestazioni dell'architettura.

non so' se l'hanno fatto cosi', ma sarebbe molto bello ed utile.

Sicuro?
Spiegami allora perchè in Montecito Intel ha introdotto HT con una pipeline di solo 8 stadi ( OTTO )?
Hyper Threading è il nome commerciale della sua implementazione di smt (che sono di diversi tipi).
Poi mi vai a parlare dell'idea che ebbe AMD sul super core o "Reverse HT" dove qualche costuttrore di bufale mise in giro la notizia che AMD avesse trovato il modo di unire due core nell'esecuzione di un singolo th per raddoppiarne la velocità di esecuzione, e che l'ipc totale sarebbe stata la somma dell'ipc dei due core.

[calabar]

Originariamente inviato da lucusta;

hyper threading non e' simultaneous multi thread

Come già fatto notare da altri, HT è il nome commerciale che Intel utilizza per la propria tecnologia SMT sui propri processori.

Ben diverso è invece CMT, l'approccio al multithreading utilizzato da AMD con Bulldozer, dove anziché cercare di sfruttare al meglio un singolo core INT eseguendo al suo interno in contemporanea più thread (due in HT) vi è una duplicazione fisica dei core INT in maniera tale che ogni thread abbia il suo core dedicato e non debba utilizzarlo in concorrenza con l'altro thread.

Di fatto un modulo Bulldozer (2 core INT è una FPU condivisa) è un rivale per un singolo core con SMT, come nelle CPU Intel:
- entrambi hanno una FPU (che a seconda del tipo di calcolo può essere utilizzata da più thread)
- entrambi gestiscono due thread INT (una dedicando un core per thread, l'altra condividendo un core tra due thread).
Difatti AMD ha dichiarato esplicitamente che un modulo BD era stato pensato per competere con un core + HT di Intel (teoricamente superandolo nei calcoli INT grazie ai due core, ma sappiamo bene come è andata).

Originariamente inviato da lucusta;

bene, BD ha 4 cluster, ogni uno formato da 2 alu 64 bit ed una FPU 128 bit condivisa (una soluzione che si e' rilevata pessima senza un coprocessore a virgola mobile, chip a se stante o GPU che sia, che comunque avrebbe apportato notevoli latenze);

La FPU è il coprocessore per i calcoli in virgola mobile, che oggi (e da tempo) è integrato nelle CPU x86 moderne.

[maghahas]

Spero facciano qualcosa di carino in stile broadwell-e / skylake-X di Intel, insomma qualcosa per workstation potenti e extreme gamer...

[lucusta]

Piedone1113,
montecito é IA64, non x86.
istruzioni diverse per compiti diversi.
ti sei chiesto perchè quell'ISA non viene usata al di fuori del suo specifico ambito di mercato? che ne so', magari nella telefonia mobile, in sistemi embadded? hai una ISA proprietaria e la usi solo per HPC e poco altro? probabilmente perche' e' adatta solo a quei compiti?

calabar,
al tempo di BD la nuova architettura INTEL era ancora a divenire.
BD è concorrenziale rispetto ad 1 core+HT, ma prima che i core intel fossero dotati di 2 ALU64.
la FPU integrata nel die non è un coprocessore, ma fà parte del processore.
un coprocessore ( cooperative processor) è un'unità esterna alla quale puoi far fare più velocemente un dato lavoro, che sia o meno nelle possibilità del processore principale.
FPU era un coprocessore sui 286 e i primi 386 (287 e 387).

HT non è un SMT, ma un consequenziatore di thread.
non processi 2 threads simultaneamente per ogni clock, ma ne fai, al massimo, 2 per per quanti clock sono necessari per eseguire l'intera pipeline, per ciclo di pipeline.
e enormemente diverso, sopratutto quando hai threads che riempono per intero una pipeline (e quindi non hai spazio, nello stesso ciclo di pipeline, di accodarne un'altro).
SMT, in queste implementazioni, possono eseguire un minimo di 2 threads completi e che occuperebbero per intero le pipeline a più threads a ciclo (utilizzando gli stadi vuoti delle pipeline).
un thread riempe la pipeline quando il dato ottenuto nel primo stadio e' ancora necessario per finire l'esecuzione dello stesso thread utilizzandolo congiuntamente anche nell'ultimo stadio, e quindi impossibile da cancellare.

per essere piu' chiari:
http://cfile8.uf.tistory.com/image/2...4D9A73811151FD
http://image.slidesharecdn.com/10-in...?cb=1335624867
questo e' HT nella sua prima implementazione.
oggi invece hai duplicata l'intera catena, e congiuntamente hai la replica dei primi due logici per ogni ALU, permettendoti di operare anche HT.
HT era il modo di massimizzare le pipeline, aumentando cosi' il rendimento;
SMT invece utilizza la forza bruta (raddoppio delle risorse) per massimizzare l'IPC, che diversamente non avrebbe modo di essere incrementato su una ISA ormai ben radicata ed esplorata, limitata da entrambe le parti da brevetti.
non e' il modo piu' efficiente per ottenere prestazioni (in quanto il decoding delle istruzioni non puo' fare miracoli ed essendo piu' complesso pretende di far consumare di piu' la macchina, congiuntamente al fatto che usi il doppio delle risorse), ma oggi sembra il solo modo d'incrementare le prestazioni nell'esecuzione non di un singolo thread, ma dei calcoli tipici in multithread.
un gran lavoro Intel lo ha fatto nel compilatore, ottimizzandolo per quelle istruzioni; AMD stà solo sfruttando questa ottimizzazione.

entrando nella questione a pie' pari, se mi dici che fai una AGU x2 che rifornisce ALU x4 per singolo core, e' come se mi stessi dicendo che hai 2x (AGU + x2 ALU), ossia propriamente 2 unita' elaborative che lavorano in contemporanea sullo stesso albero di thread, con la possibilità di utilizzare stadi intermedi non occupati (SMT+HT).
intel ha raddoppiato sia l'unità di generazione d'indirizzamento (AGU) che le ALU (precedentemente x2, ora x4) a singolo core proprio in Sandy Bridge, ed ora AMD lo sta' facendo su Zen.
su BD AGU+ALU erano in 2 core separati (ed e' per questo che si definivano core in numero di 2), mentre in SB 2xAGU+4xALU sono a singolo core.

e mi ripeto, il tutto e' possibile solo partendo dal compilatore (codice vecchio non avrebbe nessun giovamento, perche' compilato per un'altra concezione architetturale).

qui un test tra' nehalem e sandy bridge:
https://www.techpowerup.com/forums/t...hmarks.177251/
con adobe photoshop CS2 (ver. 9.0) del 2005, quando non esistevano assolutamente le istruzioni nel compilatore, bloomfield mena pesantemente sulla nuova architettura, perche' costretta ad eseguire con una ALU64 delle due a core e pure senza HT (in quanto la modalità e' differente).
qui invece con Abobe Photoshop CS4 (ver.11) del 2008 con varie patch, dove sono implementate le prime istruzioni adatte alla nuova architettura:
http://www.anandtech.com/show/3871/t...ins-in-a-row/8
letteralmente lo massacra.

[calabar]

@lucusta

Il modulo BD non è mai stato concorrenziale con l'architettura Core Intel, sebbene quelle fossero le intenzioni di AMD. Per lo meno non nel modo che intendeva AMD.
E questo vale già dalle prima incarnazioni dell'architettura core, senza aspettare le successive evoluzioni (che tra l'altro non sono stati degli stravolgimenti).

La FPU è il cosiddetto "coprocessore matematico", che (come dicevo prima) un tempo era esterno ma ormai da tempo (dai 486 se non sbaglio) è integrazione standard del processore.
Per cui non vedo di quale altro coprocessore possa esserci bisogno, a meno che non ti riferisci ad un qualche DSP per compiti specifici o alla GPU per calcoli altamente paralleli, ma non avrebbe comunque senso nel discorso che facevi prima.

L'SMT contempla l'esecuzione contemporanea di più thread/task su un singolo core Int. E questo è esattamente quello che fa HT (nella sua implementazione attuale sui processori Intel permette di eseguire due task contemporanei su in singolo core).
La definizione di SMT che scrivi sopra non è corretta, non occorrono un "minimo di due thread completi" (anche un solo thread può occupare per intero il core int), non "occuperebbero per intero le pipeline" (che è la situazione ottimale, ma è molto difficile che si verifichi). Il resto sono dettagli implementativi, che possono variare da un'implementazione ad un'altra, mantenendo la filosofia di base.
Credo non ci sia alcun dubbio sul fatto che HT sia un'implementazione di SMT.
E non si può parlare neppure di differenze implementative tra HT e SMT, dato che quest'ultimo non è un'implementazione ma un modo di fare multithreading.

[lucusta]

sono interpretazioni linguistiche, non certo tecniche.
HT puo' arrivare al massimo a 2 thread per ciclo pipeline (50% delle risorse a thread), SMT, da SB, parte da 2 thread per ciclo di pipeline ed il fatto che il thread non riempa per intero la pipeline e' indifferente, proprio perche viene poi usata la tecnica utilizzata su HT, di accodamento (e' in realta' la decodifica che abbassa il rendimento ad un fattore inferiore a x2).
sta' di fatto che ora questa implementazione di SMT e' sfruttabile solo se compili in modo adeguato, ed oggi AMD ha scelto di creare un'architettura che sfrutta questo modo di compilare e non di crearne una nuova (o meglio, un paio d'istruzioni in ambito server).
quindi, sostanzialmente, HT e' diverso da SMT ed anche sensibilmente, e si puo' vedere dal confronto tra' nehalem e sandy bridge, in cui nel primo si usa nuovamente HT come implementato inizialmente in P4, nel secondo si usa congiuntamente a SMT.

[Piedone1113]

Originariamente inviato da lucusta

Piedone1113,
montecito é IA64, non x86.
istruzioni diverse per compiti diversi.
ti sei chiesto perchè quell'ISA non viene usata al di fuori del suo specifico ambito di mercato? che ne so', magari nella telefonia mobile, in sistemi embadded? hai una ISA proprietaria e la usi solo per HPC e poco altro? probabilmente perche' e' adatta solo a quei compiti?

E che vuol dire, una pipeline è sempre una pipeline, ed ogni stadio è sempre deputato a fare qualcosa di specifico (ti va di instradare una discussione sulle pipeline per caso).
Ma il sunto è:
Hai detto un'inesattezza riferendoti al fatto che l'ht non apporta benefici su pipeline corte.
Dire che IA64 non è x86 non significa nulla, avresti dovuto dire che una è un'architetura VLIW e l'altra CISC.
Analogalmente sbagli nel legare l'HT intel alla lunghezza delle pipilene (e passare da 20 a 31 e 8 sempre con lo stesso nome dato dal produttore credo che sia più che eloquente).
L'ht serve a massimizzare l'uso della pipeline, dove ogni stadio ha un compito preciso e non sostituibile dagli altri (quindi è falsa pure la definizione di 16 e 6) occupando il più possibile la pipeline che offre degli stadi inutilizzati a causa di salti e/o th bloccati su uno stadio perchè in attesa di un evento (e questo porta maggiori vantaggi in un architettura a pipeline lunga piuttosto che corta).
Oltretutto il fatto stesso di ordinare le istruzione per uso pipeline porta a mettere in secondo piano le dipendenze tra th (ed invece che aumentare il throughput si appasserebbe).
In definitiva l'HT Intel è un'implementazione semplicistica (sopratutto sul P4) dell'SMT dove la logica di controllo riesce a gestire 2 th ma le risorse non sono comunque sufficienti a supportare al meglio questa tecnica, cosa che invece su Itanium II fu in parte fatta.
Se poi ti capita di voler portare a confronto l'HT intel (un smt a 2 vie) con SMT a 4 o 8 vie su architetture risc non dimenticarti che le architetture Cisc sono risc internamente (se non sbaglio gia dal PIII).

[Piedone1113]

Originariamente inviato da lucusta

sono interpretazioni linguistiche, non certo tecniche.
HT puo' arrivare al massimo a 2 thread per ciclo pipeline

Spiegami che vuol dire, perchè che io sappia le pipeline (sopratutto nelle cpu ooo) ogni stadio è occupato da un th diverso, ma in assenza di ht ne può uscire una la volta solo nello stesso ordine nel quale sono entrate.
In linea teorica sarebbe cosi, anche se in pratica non avviene a meno di software compilato appositamente per usare ogni singolo stadio della pipeline.

[calabar]

@lucusta
Puoi riportare una fonte affidabile in cui viene esplicitamente detto che Nehalem utilizzava HT mentre SandyBridge utilizzava entrambe le tecnologie?
(la richiesta è un po' provocatoria, dato che tale fonte... non dovrebbe esistere ).

Le prime implementazioni di HT partizionavano le risorse della CPU in maniera piuttosto statica, e da qui mi pare che arrivi la tua confusione. Le attuali implementazioni di HT hanno più risorse a disposizione, e sono più flessibili.
Una delle tante slide su HT che ne riassume graficamente il funzionamento: click.

PS: HT gestisce fino a 2 thread per core perchè al momento Intel ha deciso in questo modo (evidentemente ritengono due thread sufficienti o ottimali per riempire le pipeline), ma non esiste un limite della tecnologia in tal senso.

Ti consiglio la lettura attenta di questo articolo di Ars Technica, è datato (credo del periodo in cui Intel ha introdotto l'HT) ma spiega abbastanza nel dettaglio i concetti chiave.
Come puoi vedere, anche li HT e SMT sono intesi come lo stesso modello di multithreading.

[Piedone1113]

Originariamente inviato da calabar

@lucusta
Puoi riportare una fonte affidabile in cui viene esplicitamente detto che Nehalem utilizzava HT mentre SandyBridge utilizzava entrambe le tecnologie?
(la richiesta è un po' provocatoria, dato che tale fonte... non dovrebbe esistere ).

Le prime implementazioni di HT partizionavano le risorse della CPU in maniera piuttosto statica, e da qui mi pare che arrivi la tua confusione. Le attuali implementazioni di HT hanno più risorse a disposizione, e sono più flessibili.
Una delle tante slide su HT che ne riassume graficamente il funzionamento: click.

PS: HT gestisce fino a 2 thread per core perchè al momento Intel ha deciso in questo modo (evidentemente ritengono due thread sufficienti o ottimali per riempire le pipeline), ma non esiste un limite della tecnologia in tal senso.

Ti consiglio la lettura attenta di questo articolo di Ars Technica, è datato (credo del periodo in cui Intel ha introdotto l'HT) ma spiega abbastanza nel dettaglio i concetti chiave.
Come puoi vedere, anche li HT e SMT sono intesi come lo stesso modello di multithreading.

Credo che si confonda con la prima implementazione di HT su P4.
I Th simultanei dovevano essere generati dallo stesso processo, quindi accodati tra loro affinchè funzionassero, limitazione che SMT classico non aveva, che appunto nei p4 era implementato in modo semplicistico.

[Yrbaf]

Originariamente inviato da lucusta

HT non è un SMT, ma un consequenziatore di thread.
non processi 2 threads simultaneamente per ogni clock, ma ne fai, al massimo, 2 per per quanti clock sono necessari per eseguire l'intera pipeline, per ciclo di pipeline.
e enormemente diverso, sopratutto quando hai threads che riempono per intero una pipeline (e quindi non hai spazio, nello stesso ciclo di pipeline, di accodarne un'altro).
SMT, in queste implementazioni, possono eseguire un minimo di 2 threads completi e che occuperebbero per intero le pipeline a più threads a ciclo (utilizzando gli stadi vuoti delle pipeline).
un thread riempe la pipeline quando il dato ottenuto nel primo stadio e' ancora necessario per finire l'esecuzione dello stesso thread utilizzandolo congiuntamente anche nell'ultimo stadio, e quindi impossibile da cancellare.

per essere piu' chiari:
http://cfile8.uf.tistory.com/image/2...4D9A73811151FD
http://image.slidesharecdn.com/10-in...?cb=1335624867
questo e' HT nella sua prima implementazione.
oggi invece hai duplicata l'intera catena, e congiuntamente hai la replica dei primi due logici per ogni ALU, permettendoti di operare anche HT.
HT era il modo di massimizzare le pipeline, aumentando cosi' il rendimento;
SMT invece utilizza la forza bruta (raddoppio delle risorse) per massimizzare l'IPC, che diversamente non avrebbe modo di essere incrementato su una ISA ormai ben radicata ed esplorata, limitata da entrambe le parti da brevetti.

Ok vedo che sai cosa è HT, però non sai cosa è SMT o pensi sia di più di quello che deve essere e classifichi HT solo una implementazione parziale.

Ripeto i testi sacri riportano le cpu Intel con HT come cpu di tipo SMT e questo già al tempo di P4 (ora lo dicono degli i7 ma se prendi vecchie edizioni parlano del P4 come di una cpu con multithreading sotto il marchio commerciale HT).

SMT non è altro che il multithreading hw applicato ad un processore superscalare.

Originariamente inviato da Piedone1113

Credo che si confonda con la prima implementazione di HT su P4.
I Th simultanei dovevano essere generati dallo stesso processo, quindi accodati tra loro affinchè funzionassero, limitazione che SMT classico non aveva, che appunto nei p4 era implementato in modo semplicistico.

Questo mi suona strano, come può una cpu distinguere tra thread e processi (salvo l'uso dei microthread come su Mips con i ThreadContext).

Tratto dal Tanenbaum del 2005:

Intel calls the implementation of multithreading used in the Pentium 4 hyperthreading.
The basic idea is to allow two threads (or possibly processes, since the CPU cannot tell what is a thread and what is a process) to run at once. To the operating system, a hyperthreaded Pentium 4 chip looks like a dual processor in which both CPUs share a common cache and main memory. The operating system schedules the threads independently. If two applications are running at the same time, the operating system can run each one at the same time.

[Piedone1113]

Originariamente inviato da Yrbaf

Questo mi suona strano, come può una cpu distinguere tra thread e processi (salvo l'uso dei microthread come su Mips con i ThreadContext).

Tratto dal Tanenbaum del 2005:

Non ricordo di preciso chi affermò questo, ma fu nel forum, portando anche dei link ed indicando il limite come dovuti ai puntatori del registro.
Ps era qualcuno che lavora nel settore (mi sembra come programmatore hardware), ma potrei anche ricordare male (anche se sono quasi certo dell'autenticità della cosa).
Il fatto poi che l'os vede due core logici ed invia due processi separati non implica che vengano comunque eseguiti in contemporanea.

[calabar]

Originariamente inviato da Piedone1113;

Credo che si confonda con la prima implementazione di HT su P4.

Si, credo anche io.

Originariamente inviato da Piedone1113;

Il fatto poi che l'os vede due core logici ed invia due processi separati non implica che vengano comunque eseguiti in contemporanea.

Certo, ma in questo caso se non lo facesse non si tratterebbe di processori con SMT.
Nei processori con SMT due task si possono trovare contemporaneamente in esecuzione all'interno dello stesso core, altrimenti sono semplicemente due task in concorrenza sullo stesso core eseguiti apparentemente in contemporanea (caratteristica di qualsiasi sistema con multitasking).
"Apparentemente" perchè il passaggio da un task all'altro è sufficientemente veloce da dare la sensazione all'utente che vengano eseguiti insieme.

[Piedone1113]

Originariamente inviato da calabar

Si, credo anche io.


Certo, ma in questo caso se non lo facesse non si tratterebbe di processori con SMT.
Nei processori con SMT due task si possono trovare contemporaneamente in esecuzione all'interno dello stesso core, altrimenti sono semplicemente due task in concorrenza sullo stesso core eseguiti apparentemente in contemporanea (caratteristica di qualsiasi sistema con multitasking).
"Apparentemente" perchè il passaggio da un task all'altro è sufficientemente veloce da dare la sensazione all'utente che vengano eseguiti insieme.

Se una CPU è in grado di processare contemporaneamente due th di uno stesso processo, ma accoda due processi da eseguire in concorrenza sullo stesso core è sempre una CPU SMT, anche se limitata a thread dello stesso processo.
Ed è quello che faceva p4 (dal northwood al prescot)

[Yrbaf]

Ma thread e processo sono concetti noti al sistema operativo non alla cpu.

Per la cpu sono due flussi istruzioni puntati da 2 program counter e stop, poi a cosa puntino lei non lo sa.
La cpu non può, salvo usare istruzioni ISA specifiche di start e stop di un thread come mi pare faccia Mips con i TC, sapere da chi arrivano le istruzioni.

Poi i P4 potranno avere avuto dei limiti sul parallelismo possibile ma vedo molto difficile che fosse qualcosa come "ah sei un altro thread dello stesso processo allora ti eseguo in parallelo se posso, mentre tu sei un thread di un altro processo e ti eseguo serialmente a priori"