Link alla notizia: http://www.hwupgrade.it/news/cpu/amd-fornisce-nuovi-dettagli-sull-architettura-delle-cpu-zen_64162.html

Si avvicina il debutto della prossima generazione di processori AMD, appartenenti alla famiglia Zen: l'azienda americana fornisce nuovi dettagli sull'architettura alla conferenza Hot Chips, ma per le versioni e le frequenze c'è da attendere ancora

Click sul link per visualizzare la notizia.

non siate timidi... ve la suggerisco io, slide !

Perchè si è visto altro?
Ah no, è vero. C' anche un fimato dell'oste che assaggia il suo vino e dice che è buono come quello dell'altro. :rolleyes:

Solito discorso. Si parlerà di roba concreta davanti a dettagliati benchmark comparativi VERI.

Per adesso SLIDE! :O

un ipc +40% ? mi sembra un po' tanto, lo spero ma ho paura che nel mondo reale non sarà così..

giusto per informazione, il +25% è quello fatto in MEDIA da Intel passando da Sandy Bridge a Skylake, fonte anandtech.

Sandy Bridge to Ivy Bridge: Average ~5.8% Up
Ivy Bridge to Haswell: Average ~11.2% Up
Haswell to Broadwell: Average ~3.3% Up
Broadwell to Skylake (DDR3): Average ~2.4% Up
Broadwell to Skylake (DDR4): Average ~2.7% Up

se non sbaglio da Nehalem a SB c'era un +15% MEDIO di IPC.

quindi +40% da excavator non è affatto tanto, è il minimo che potessimo sperare in realtà :read:
Ma se intel sta facendo solo +3% a nuova cpu, come farebbe AMD a fare +40% scusami?

Comunque dovremmo essere vicini al rilascio, magari si scopre che il +40% è il massimo e non il medio, oppure potrebbe essere anche segato dall'ipc int (dove amd andava comunque discretamente) e ritrovarsi con un +20 in calcoli int e +60 in fpu, buh....

Li buttassero in mercato, li compriamo e loro si fanno i soldi.

Manco un engineering sample..

Ma se intel sta facendo solo +3% a nuova cpu, come farebbe AMD a fare +40% scusami?

Comunque dovremmo essere vicini al rilascio, magari si scopre che il +40% è il massimo e non il medio, oppure potrebbe essere anche segato dall'ipc int (dove amd andava comunque discretamente) e ritrovarsi con un +20 in calcoli int e +60 in fpu, buh....


Penso sia proprio così.

giusto per informazione, il +25% è quello fatto in MEDIA da Intel passando da Sandy Bridge a Skylake, fonte anandtech.

Sandy Bridge to Ivy Bridge: Average ~5.8% Up
Ivy Bridge to Haswell: Average ~11.2% Up
Haswell to Broadwell: Average ~3.3% Up
Broadwell to Skylake (DDR3): Average ~2.4% Up
Broadwell to Skylake (DDR4): Average ~2.7% Up

se non sbaglio da Nehalem a SB c'era un +15% MEDIO di IPC.

quindi +40% da excavator non è affatto tanto, è il minimo che potessimo sperare in realtà :read:

normalizzato sulla frequenza (IPC)?
perche' mi sembra davvero tanto su int e FPU, evitando di usare le SIMD.
davo piu' o meno un +15-20%.

per chi invece critica sempre e comunque, se invece di farlo si leggessero le slide, si capirebbe anche il perche'.
l'aumento rispetto ad excavator deriva semplicemente dal fatto che ora usa SMT, e fa' 2 thread simultanei rispetto a uno (in realta' il 40% in piu' non e' probabilmente IPC, ma istruzioni totali, in quanto gira a frequenze piu' basse, di 3/4; diversamente avrebbero la stessa computazione finale tra' un quad ed un octacore).
nulla di piu', nulla di meno di quello che fa' intel da SB.
(e HT non e' SMT, ma si puo' sommare a questo).

di queste slide a me interessa principalmente la parte "Aggresive clock gating with multi-livel regions", che indica probabilmente che se gira con un solo core avra' una frequenza alta, con due un po' piu' bassa, con 4 ancora piu' bassa e con 8 si piazzerà a 2.8/3.2ghz, sempre rimanendo in un power limit dato dal TDP;
con queste premesse in single thread dovrebbe clockare a 4.0ghz per stare dietro ad un 6700K che ragiunge i 4.2 in turbo, a 3.6-3.7 per ugualiarlo in quad thread e anche se facesse 3ghz con tutti gli 8 core attivi, andrebbe il 40% in piu' (ecco la corsa di kaby lake ai 6 core nel mainstream).
non credo che inizialmente saranno quelle le frequenza (piu' propenso a pensare a 2.8x8/3.2x4/3.4x2/3.6x1 per rimanere sotto i 95W nell'uso normale e non sotto torture test, il che lo farebbe confrontare, in perdita, con un 6700), ma... processori a 140W si possono sempre tirare fuori, non sono certo uno scandalo, e una BE uno se la dovrebbe anche aspettare.

in pratica con 4 thread non sfigurerà, ed i monothread sono comunque garantiti con un'esecuzione ai giusti livelli, mentre nei programmi adatti puo' sfruttare tutte le risorse a disposizione, rendendolo molto piu' versatile delle CPU attuali.
se poi si da' retta ai grafici, sapere che a pari frequenza consuma la metà, mentre mantiene la stessa efficienza per ciclo di excavator garantendone il 40% in piu', fa' capire che ci hanno messo il doppio delle cose, e che questa volta sono in grado di usarle come fa' intel (altra cosa che fa' pensare questo e' l'integer rename ed il FPU point rename; a che scopo rinominare istruzioni se non le devi cambiare in qualche modo?)

si puo' vedere Zen come un dual BD, in cui le ALU di un cluster sono state accoppiate dal decode per eseguire 2 istruzioni a ciclo.

eppure segui il thread di Zen :stordita:

è molto chiaro, Zen non è altro che l'architettura Core come approccio, rivista e con aggiunta di tweak vari.

ragazzi fare +40% da 100 è come fare +20% da 200. il risultato è che hai sempre un +40 assoluto.

quindi devi considerare da dove parti, e parti da excavator che è CMT, mentre sandy bridge cos' come Zen sono SMT.

http://i.imgur.com/heGWi7H.png

come vedi skylake è +58% MEDIO in ST su excavator.

Vabbe, se non capisci l'ironia non ne ho colpa.
Comunque il valore di ipc è un dato statistico, e non è matematica (come la media di dati)
La statistica non è scienza :O

normalizzato sulla frequenza (IPC)?
perche' mi sembra davvero tanto su int e FPU, evitando di usare le SIMD.
davo piu' o meno un +15-20%.

per chi invece critica sempre e comunque, se invece di farlo si leggessero le slide, si capirebbe anche il perche'.
l'aumento rispetto ad excavator deriva semplicemente dal fatto che ora usa SMT, e fa' 2 thread simultanei rispetto a uno (in realta' il 40% in piu' non e' probabilmente IPC, ma istruzioni totali, in quanto gira a frequenze piu' basse, di 3/4; diversamente avrebbero la stessa computazione finale tra' un quad ed un octacore).
nulla di piu', nulla di meno di quello che fa' intel da SB.
(e HT non e' SMT, ma si puo' sommare a questo).

di queste slide a me interessa principalmente la parte "Aggresive clock gating with multi-livel regions", che indica probabilmente che se gira con un solo core avra' una frequenza alta, con due un po' piu' bassa, con 4 ancora piu' bassa e con 8 si piazzerà a 2.8/3.2ghz, sempre rimanendo in un power limit dato dal TDP;
con queste premesse in single thread dovrebbe clockare a 4.0ghz per stare dietro ad un 6700K che ragiunge i 4.2 in turbo, a 3.6-3.7 per ugualiarlo in quad thread e anche se facesse 3ghz con tutti gli 8 core attivi, andrebbe il 40% in piu' (ecco la corsa di kaby lake ai 6 core nel mainstream).
non credo che inizialmente saranno quelle le frequenza (piu' propenso a pensare a 2.8x8/3.2x4/3.4x2/3.6x1 per rimanere sotto i 95W nell'uso normale e non sotto torture test, il che lo farebbe confrontare, in perdita, con un 6700), ma... processori a 140W si possono sempre tirare fuori, non sono certo uno scandalo, e una BE uno se la dovrebbe anche aspettare.

in pratica con 4 thread non sfigurerà, ed i monothread sono comunque garantiti con un'esecuzione ai giusti livelli, mentre nei programmi adatti puo' sfruttare tutte le risorse a disposizione, rendendolo molto piu' versatile delle CPU attuali.
se poi si da' retta ai grafici, sapere che a pari frequenza consuma la metà, mentre mantiene la stessa efficienza per ciclo di excavator garantendone il 40% in piu', fa' capire che ci hanno messo il doppio delle cose, e che questa volta sono in grado di usarle come fa' intel (altra cosa che fa' pensare questo e' l'integer rename ed il FPU point rename; a che scopo rinominare istruzioni se non le devi cambiare in qualche modo?)

si puo' vedere Zen come un dual BD, in cui le ALU di un cluster sono state accoppiate dal decode per eseguire 2 istruzioni a ciclo.

Non c'ho capito una parola, ma:
Non sappiamo se quel +40% sia riferito all'ipc ST, o all'ipc per core (quindi core0 + core1), alla velocità di clock, al prapporto performance watt, alle pere della nonna o alle banane del fruttivendolo. Si presume che si tratti di ipc (e l'ipc si misura in istruzioni per clock su singolo th) altrimenti potrebbero essere Gflops o qualche altro valore.
Una cosa però che dimentichi di considerare (non so se dimentichi o vuoi coscientemente dimenticare) è che BD aveva 8 core int, ma solo quattro fpu.
Dalle mie parti, ma anche come recitava una vecchia pubblicità, si dice che dos is mejo che one, guia questo da solo dovrebbe permettere un ipc superiore del 25% sul singolo th.
Quindi l'ipc medio in st deve essere almeno il 25% più alto di excavator.
Magari mi sbaglio, sia ben chiaro, ma penso che Intel al contrario dei suoi utenti non dorme tranquilla, sopratutto considerando che (da mie personali fonti interne in intel) gli RMA dei 6700k sono 10 volte superiori a quelle delle precedenti cpu k, segnale che sono al limite superiore della commercializzazione insieme al fatto che nelle prossime cpu contrariamente a quanto immaginabile hanno ulteriormente alzato il tdp (e non facciamo una filippica sul fatto che 97w di tdp potrebbero non essere 97w di dissipazione etc, etc)

La parte in grasseto poi non l'ho capita, ero certo che HT è il nome commerciale (e registrato) che Intel ha dato alla sua implementazione dell'smt.

Di base è perchè Intel ha affinato il tutto nel cosrso di anni mentre negli stessi anni AMD non ha fatto una cippa. :O

Sono anni che AMD non fa una cippa sul silicio, ma credo che gli ingegneri IBM abbiamo lavorato sodo e hanno tirato fuori cpu dal loro silicio da far paura a tutti, intel inclusa. E non lavorando su una sola tipologia di cpu ma su diverse di diverso tipo e caratteristiche, cosa che fa pensare che abbiano molta più familiarità sulle implementazioni ad alte prestazioni rispetto quelli di intel.
Guarda caso gli stessi ingegneri e la stessa fonderia (fab 8 Malta ex ibm ora GF) che dovrà produrre ZEN

E' molto chiaro, Zen non è altro che l'architettura Core come approccio, rivista e con aggiunta di tweak vari.

E che avranno prestazioni più elevate con la metà del prezzo. Io intanto sono arrivato a quest'anno come sempre contento, con il processore in firma e un Phenom II X6 che ancora vanno alla grande e non deludono, e non ho speso 1000€ per una CPU.

nell'articolo è presente un errore non è vero che le unita in virgola mobile si possono unire per eseguire le istruzioni 256-bit AVX2, AMD non ha inplementato tali uonzioni nella cpu per mancanza di tempo. Quindi le singole unita eseguiranno le funzioni in 2 operazioni successive e non in parallelo.

E che avranno prestazioni più elevate con la metà del prezzo. Io intanto sono arrivato a quest'anno come sempre contento, con il processore in firma e un Phenom II X6 che ancora vanno alla grande e non deludono, e non ho speso 1000€ per una CPU.

Stai sognando.
I prezzi sono fissati sulla base diretta delle prestazioni in rapporto a quelle della concorrenza.
Se le nuove cpu saranno valide tanto da competere coi top di gamma intel è sicuro come la morte che il prezzo sarà simile.
Al massimo qualcosina in meno per aggredire il mercato.

Vai un po' a vedere cosa costavano gli athlon e gli athlon 64 quando amd teneva testa ad intel.

ragazzi fare +40% da 100 è come fare +20% da 200. il risultato è che hai sempre un +40 assoluto.

Post come questo confermano che matematica e logica non sono caratteristiche in cui noi italiani eccelliamo.

Stai sognando.
I prezzi sono fissati sulla base diretta delle prestazioni in rapporto a quelle della concorrenza.
Se le nuove cpu saranno valide tanto da competere coi top di gamma intel è sicuro come la morte che il prezzo sarà simile.
Al massimo qualcosina in meno per aggredire il mercato.

Vai un po' a vedere cosa costavano gli athlon e gli athlon 64 quando amd teneva testa ad intel.

ai tempi di athlon64 amd si era fatto un nome...totalmente smerdato da allora:(
i prezzi devono essere molto attraenti,difficilmente si rinuncia al logo intel per risparmiare qualche spicciolo

Una cosa però che dimentichi di considerare (non so se dimentichi o vuoi coscientemente dimenticare) è che BD aveva 8 core int, ma solo quattro fpu.

La parte in grasseto poi non l'ho capita, ero certo che HT è il nome commerciale (e registrato) che Intel ha dato alla sua implementazione dell'smt.

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.

Stai sognando.
I prezzi sono fissati sulla base diretta delle prestazioni in rapporto a quelle della concorrenza.
Se le nuove cpu saranno valide tanto da competere coi top di gamma intel è sicuro come la morte che il prezzo sarà simile.
Al massimo qualcosina in meno per aggredire il mercato.

Vai un po' a vedere cosa costavano gli athlon e gli athlon 64 quando amd teneva testa ad intel.
O c'è concorrenza o c'è "cartello", nel qual caso AMD non sarebbe nell'attuale situazione economica. In presenza di concorrenza i prezzi si abbassano sempre, e migliorano le prestazioni.
Se le nuove CPU saranno prestazionalmente concorrenziali ne trarremo beneficio anche dal punto di vista dei prezzi, magari meno nell'immediato ma sempre più con il passare del tempo... sempre che non vi siano accordi tra le aziende.

no, su questo ha ragione demon77:
si paga sulle prestazioni, non sul pezzo.
fosse costato 2 soldi di latta, se va' quanto un 6700k te lo faranno pagare quanto un 6700k, o poco meno, per invogliarti ad acquistarlo.... e' la legge di mercato.
probabilmente inizialmente ci sara' un netto vantaggio economico nell'acquistarli (un 20% in meno massimo, ossia 50 euro o poco piu' rispetto a 300), ma prima che intel si metta in chiaro allarme diminuendo i prezzi delle proprie soluzioni, AMD deve conquistare piu' di 1/3 del mercato, a ritmo serrato, tra' l'altro...
ad oggi c'e' il piccolo problema che si e' con una FAB contro decine (magari oggi mal sfruttate, ma son sempre tante).
se lo mettono al costo della meta' di un intel, anche vendendo ogni singola CPU che esce dalla catena di produzione, non riuscirebbero a fare piu' del 30% di quella fetta di mercato, ossia non piu' del 15% totale...
significherebbe che la richiesta andrebbe alle stelle, e che ci sara' speculazione selvaggia per ogni pezzo venduto...
AMD lo mette ad 1/2 rispetto ad un 6700K? sugli scaffali lo vedresti allo stesso prezzo, e probabilmente con scarsissima disponibilità...
e' un mero conto di produzione: poco prodotto, se appetibile e molto richiesto, ha un'enorme speculazione.
RX480 docet:
ne producono a vagonate, ma il prezzo e' ancora alto per la richiesta che c'e', perche' il mercato che sta' decidendo di cambiare HW tutti allo stesso momento (dovuto anche alle latenze di 4 anni di fermo prestazionale).
quindi me lo aspetto come un 6700 ma anche dal costo di un 6700.

Stai sognando.
I prezzi sono fissati sulla base diretta delle prestazioni in rapporto a quelle della concorrenza.
Se le nuove cpu saranno valide tanto da competere coi top di gamma intel è sicuro come la morte che il prezzo sarà simile.
Al massimo qualcosina in meno per aggredire il mercato.

Vai un po' a vedere cosa costavano gli athlon e gli athlon 64 quando amd teneva testa ad intel.

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.

@locusta
Mi quoto per sottolineare parte di quanto ho detto:
Se le nuove CPU saranno prestazionalmente concorrenziali ne trarremo beneficio anche dal punto di vista dei prezzi, magari meno nell'immediato ma sempre più con il passare del tempo
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.

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

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.

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.

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

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

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.

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

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.

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

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/2048F4484D9A73811151FD
http://image.slidesharecdn.com/10-intel-nehalem-design-slides-120427224225-phpapp01/95/intels-nehalem-microarchitecture-by-glenn-hinton-37-728.jpg?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/threads/sandy-bridge-vs-nehalem-vs-bulldozer-vs-piledriver-benchmarks.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/the-sandy-bridge-preview-three-wins-in-a-row/8
letteralmente lo massacra.

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

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

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.

@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 :p ).

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 (http://www.gamasutra.com/db_area/images/feature/4168/image20.png).

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 (http://arstechnica.com/features/2002/10/hyperthreading/) 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.

@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 :p ).

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 (http://www.gamasutra.com/db_area/images/feature/4168/image20.png).

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 (http://arstechnica.com/features/2002/10/hyperthreading/) 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.

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/2048F4484D9A73811151FD
http://image.slidesharecdn.com/10-intel-nehalem-design-slides-120427224225-phpapp01/95/intels-nehalem-microarchitecture-by-glenn-hinton-37-728.jpg?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.

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.

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.

Credo che si confonda con la prima implementazione di HT su P4.
Si, credo anche io.

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.

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)

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"

@Piedone1113
Questo immagino dipenda più dal sistema che dalla CPU.

Sui sistemi Linux per esempio questa distinzione non esiste, Thread e Processo sono i due estremi della condivisione delle risorse tra due task, per cui in che caso rientrano tutte le situazioni intermedie?

Non ho approfondito a riguardo, ma non saprei dire se questa distinzione sia davvero possibile a livello di processore. Non lo escludo, magari c'è qualche fattore che ora mi sfugge, ma mi parrebbe strano.
Non vorrei che fosse solo la teoria di qualche utente che ha provato a dare un senso alla parola "threading" dell'acronimo.

L'unica possibilità che mi viene in mente (ma sto ipotizzando, non necessariamente in modo corretto :D ) è che nelle prime implementazioni di Intel non duplicassero i registri che contenevano l'indirizzamento delle risorse, motivo per cui entrambi i task dovessero accedere alle stesse risorse. Ma non avrebbe molto senso, e richiederebbe comunque la necessità di segnalare in qualche modo al processore la presenza di risorse condivise (o la verifica che le risorse siano le stesse del task già in esecuzione). Altrimenti sai che svarioni...

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"

@Piedone1113
Questo immagino dipenda più dal sistema che dalla CPU.

Sui sistemi Linux per esempio questa distinzione non esiste, Thread e Processo sono i due estremi della condivisione delle risorse tra due task, per cui in che caso rientrano tutte le situazioni intermedie?

Non ho approfondito a riguardo, ma non saprei dire se questa distinzione sia davvero possibile a livello di processore. Non lo escludo, magari c'è qualche fattore che ora mi sfugge, ma mi parrebbe strano.
Non vorrei che fosse solo la teoria di qualche utente che ha provato a dare un senso alla parola "threading" dell'acronimo.

L'unica possibilità che mi viene in mente (ma sto ipotizzando, non necessariamente in modo corretto :D ) è che nelle prime implementazioni di Intel non duplicassero i registri che contenevano l'indirizzamento delle risorse, motivo per cui entrambi i task dovessero accedere alle stesse risorse. Ma non avrebbe molto senso, e richiederebbe comunque la necessità di segnalare in qualche modo al processore la presenza di risorse condivise (o la verifica che le risorse siano le stesse del task già in esecuzione). Altrimenti sai che svarioni...

Scusatemi, ma il pid del processo non funziona anche da segnaposto per la cpu ed ordinare i th di uno stesso pid nelle cpu ooo?
Se la cpu non potrebbe sapere a quali processi fanno capo i th come può organizzare l'esecuzione fuori ordine (che gestisce la logica della cpu in modo trasparente dall'os?)

Una esecuzione fuori ordine non contempla mica l'uso di più thread.
Il OoO si può fare benissimo, anzi è nato prima così, sul singolo pezzo di codice dello stesso processo / thread.
Esempio:

Carica contenuto $(indirizzo) in A
B = A + 3
C = B + 60
D = 20 x 3
farà probabilmente eseguire il computo di D prima di quello di C e B (se c'è una sola alu e la cpu è del tipo OoOrder)

All'interno della cpu probabilmente ci sono dei marcatori per indicare a quale thread appartiene l'istruzione.
Ma è inteso come thread interno della cpu (roba tipo da 0 a 3 in una cpu 4 thread), con il Pid del SO non c'entra nulla (di solito).

Piedone1113
"(e questo porta maggiori vantaggi in un architettura a pipeline lunga piuttosto che corta)"
"In definitiva l'HT Intel è un'implementazione semplicistica (sopratutto sul P4) dell'SMT"

quindi HT e' conveniente su pipeline corte? no
quindi HT e' SMT? si, ma non e' certo simultaneo, e' riempitivo, in cicli vuoti.

intel ha speso molto nel creare un compilatore per sfruttare l'implementazione di SMT iniziata con sandy bridge (e oggi AMD sfrutta quel lavoro per compatibilità sulle medesime istruzioni).

per assurdo, in un ciclo di pipeline sull'implementazione SMT di sandy bridge si possono produrre 2 thread che, per elaborarli, saturerebbero entrambi una pipeline di calcolo completa; HT questo non puo' farlo.
e' solo questa la differenza, ma non e' una piccola differenza.

calabar,
io non ti sto' scrivendo che SB non usa HT, ma che da SB la tecnologia usata e' ben oltre HT, in quanto replica tutte le singole unità di una ALU e richiede una AGU aggiuntiva, un decode apposito e un compilatore che riesca ad accoppiare gruppi di istruzioni nel migliore dei modi per questa implementazione di SMT.
usando questa strutturazione si riesce anche a sfruttare il riempimento della pipeline nel migliore dei modi, ma dev'essere prodotto con una strada diversa.
in effetti non ti saprei specificare se nehalem usa la stessa implementazione di HT che c'era su P4, ma la questione e' che un core sandy bridge ha essenzialmente il doppio delle risorse HW di un normale core, tanto da poterlo intendere come esso stesso un dual core se confrontato ai disegni precedenti (o a quello che faceva fino ad oggi AMD).

ed oggi AMD fa' la medesima cosa con Zen, e che un core Zen racchiude in se ben poche cose in piu' rispetto ad un modulo BD, se non la piu' importante, che e' il decode associativo delle 2 ALU per cluster, facendone diventare una in SMT.

cosi' ti sembra che mi sono spiegano piu' efficaciemente?

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


Una esecuzione fuori ordine non contempla mica l'uso di più thread.
Il OoO si può fare benissimo, anzi è nato prima così, sul singolo pezzo di codice dello stesso processo / thread.
Esempio:

Carica contenuto $(indirizzo) in A
B = A + 3
C = B + 60
D = 20 x 3
farà probabilmente eseguire il computo di D prima di quello di C e B (se c'è una sola alu e la cpu è del tipo OoOrder)

All'interno della cpu probabilmente ci sono dei marcatori per indicare a quale thread appartiene l'istruzione.
Ma è inteso come thread interno della cpu (roba tipo da 0 a 3 in una cpu 4 thread), con il Pid del SO non c'entra nulla (di solito).
L'unica cosa che ho trovato:
sui P4 2 th vengono uniti in un macrothread prima di passare alle unità di esecuzione, la logica di controllo la scompone e crea due microth che viene passata all'esecuzione ed assegnati alle due cpu logiche.
Può essere che condizione di questo fosse il fatto che i th arrivino dallo stesso processo (cioè la fusione).
Questo almeno accadeva nei p4, non so se sia comune a tutti i sistemi smt o meno, ma potrebbe essere li la chiave, sempre se la mia è vera.

Piedone1113
"(e questo porta maggiori vantaggi in un architettura a pipeline lunga piuttosto che corta)"
"In definitiva l'HT Intel è un'implementazione semplicistica (sopratutto sul P4) dell'SMT"

quindi HT e' conveniente su pipeline corte? no
quindi HT e' SMT? si, ma non e' certo simultaneo, e' riempitivo, in cicli vuoti.


Quindi l'ht funziona solo su compilatori Intel?

I p4 avevano 3 pipilene a core (e non una), se un th (o meglio l'istruzione di un th in un determinato momento) viene eseguito solo su una pipeline l'altro th ha praticamente l'esclusiva sulle pipeline rimanenti.
Secondo il tuo giudizio fin quando il th non ha profondita 16 l'altro non può entrare in pipeline (assolutamente falso perchè in ht entrano insieme, se ci sono risorse disponibili).
Quello che tu descrivi è una cpu OOO e non il funzionamento dell'ht.
Tutti i testi di settore descrivono l'ht di intel come smt a 2 vie.
Hai anche dimenticato di notare la prima parte (in grassetto).
In caso di pipeline corte sono i salti di stadio che portano i maggiori benifici con l'uso dell'ht (risorsa dall'alta capacità computazionale per un tempo più lungo).

Che poi riempitivo di che?, riempire le tre pipeline contemporaneamente con istruzioni di th differenti?
Non ti sembra che ci sia contemporaneetà di esecuzione?
Se il th 0 invia un istruzione di addizione che occupa una sola pipeline (in northwood ht la somma viene eseguita in 4 cicli completi su 20 stadi) l'ht aspetta i 4 cicli prima di inviare un'istruzione di moltiplicazione tra interi lasciando nel frattempo 2 pipeline a girarsi i pollici, mentre il th0 aspetta magari proprio il risultato del 2 th per continuare l'esecuzione? (perchè le dipendenze possono verificarsi anche tra th.
Spiegami pure allora a che serve nei P4 il comando logico HALT?
Se non lo sapessi impone con HALT 0 la pausa del core logico 0 e con HALT 1 la pausa del core logico 1, e viene usato quando ci sono delle dipendenze che tardano ad arrivare e si liberano risorse sull'altro core per velocizzarne l'esecuzione e arrivare prima al dato che causa dipendenza e che sarebbe del tutto inutile se i th non fossero eseguiti in contemporanea in quanto si dovrebbe svuotare la pipeline per aggirare lo stallo.

Piedone1113
"(e questo porta maggiori vantaggi in un architettura a pipeline lunga piuttosto che corta)"
"In definitiva l'HT Intel è un'implementazione semplicistica (sopratutto sul P4) dell'SMT"

quindi HT e' conveniente su pipeline corte? no
quindi HT e' SMT? si, ma non e' certo simultaneo, e' riempitivo, in cicli vuoti.

Simultaneo che ?
Non è simultaneo quanto 2 core fisici, ovviamente se devi fare 2 moltiplicazioni (in 2 thread diversi) è c'è solo una unità hw per la moltiplicazione è ovvio che l'esecuzione sarà seriale.
Ma se il thread 1 fa una cosa sull'unità funzionale A ed il thread 2 ne fa un'altra sull'unità B, la simultaneità c'è eccome.
Ed il tuo riempitivo di cicli vuoti è proprio la definizione di simultaneità.
Se non ci fosse simultaneità i cicli vuoti resterebbero vuoti.

Ripeto SMT è MT (a grana grossa) su processori superscalari alias processori (1 core) che sono in grado di eseguire più di 1 istruzione per ciclo di clock.


intel ha speso molto nel creare un compilatore per sfruttare l'implementazione di SMT iniziata con sandy bridge (e oggi AMD sfrutta quel lavoro per compatibilità sulle medesime istruzioni).

per assurdo, in un ciclo di pipeline sull'implementazione SMT di sandy bridge si possono produrre 2 thread che, per elaborarli, saturerebbero entrambi una pipeline di calcolo completa; HT questo non puo' farlo.
e' solo questa la differenza, ma non e' una piccola differenza.

HT e SMT sono la stessa cosa !
Quindi non puoi dire SMT lo fa ed HT non lo fa.
Al più puoi dire le prime implementazioni di HT erano più rudimentali e permettevano una peggiore saturazione della cpu anche pescando le istruzioni da 2 thread!


calabar,
io non ti sto' scrivendo che SB non usa HT, ma che da SB la tecnologia usata e' ben oltre HT, in quanto replica tutte le singole unità di una ALU e richiede una AGU aggiuntiva, un decode apposito e un compilatore che riesca ad accoppiare gruppi di istruzioni nel migliore dei modi per questa implementazione di SMT.
usando questa strutturazione si riesce anche a sfruttare il riempimento della pipeline nel migliore dei modi, ma dev'essere prodotto con una strada diversa.
in effetti non ti saprei specificare se nehalem usa la stessa implementazione di HT che c'era su P4, ma la questione e' che un core sandy bridge ha essenzialmente il doppio delle risorse HW di un normale core, tanto da poterlo intendere come esso stesso un dual core se confrontato ai disegni precedenti (o a quello che faceva fino ad oggi AMD).

Ok vuoi dire che HT v2.0 è più efficiente di HT v1.0
Ben diverso dal continuare a dire che SMT <> HT :D

Yrbaf,
scusa, ma se hai 2 ALU complete in un core, se devi operare una moltiplicazione su 2 thread, la puoi fare simultaneamente, una per singola unità; se hai solo uno stadio pipeline che fa' quell'operazione, saranno per forza consequenziali.... non c'e' altro modo.
quindi HT, per come lo vedo io, non lo reputo un vero SMT, perche' non mi permette di eseguire simultaneamente le 2 operazioni senza intalcio, ma una tecnologia atta a massimizzare la resa della pipeline, di una sola pipeline.
qui usano praticamente 2 ALU distinte in tutto, solo che partono da un decode molto piu' elaborato, capace di farle funzionare insieme sulle stesse cose.
anche il pentium pro P6 aveva 2 pipeline, solo che erano divise in funzioni, non le replicavano; era per OoO e certamente non mi azzardo a dire per il multithrading (ma neanche per il multitasking, anche se il fine ultimo era quello di supportare gli OS proprio in questo).

il punto di questa discussione e' capire se il +40% e' plausibile;
se e' possibile vedere AMD competitiva, almeno come architettura base, rispetto ad Intel, cosa che in molti commenti trasuda come se fosse fantascienza.

e si sta' dicendo che in effetti, sulla carta, sembra effettivamente di si.
rimane da sapere solo l'implementazione di questa architettura nei prodotti finali; dettagli che qui non sono affatto specificati (non se ne conoscono le frequenze, consumi e gli altri parametri base), oltre al fatto che non si sa' bene se hanno implementato una gestione piu' profonda delle frequenze sia rispetto agli ultimi AMD che d'intel (e non mi riferisco solo al turbo 3.0, ma al fatto che oggi, in turbo, un AMD si deve per forza di cose portare dietro anche i core non utilizzati nell'inalzamento della frequenza, tanto che un processore con 1 core a 4.2ghz e gli altri scarichi ma a 3.9ghz consuma poco meno di quando li usi tutti e 4 a 3.9ghz, e questo non lega bene con il risparmio energetico).

ad oggi non sono sicuro che superi in ogni ambito un 6700K, ma che sia una valida alternativa prestazionale si (se ha 8 core a 2.8ghz), e se hanno messo anche una gestione ottimale di scheduling in riferimento alle risorse ed al consumo, non si comportera' certo male, risultando piu' versatile dei quad e octa/deca intel (e non piu' potente, ma versatile, che per vedere un vero quad su un portatile mainstream siamo arrivati al 2017).

quindi, tralasciando la questione del "mio errore interpretativo" su HT (che reputo una buona tecnologia gia' in P4, ma certamente mi piace di piu' come l'hanno interpretata in SB, perche' ha un senso piu' compiuto ed utile), il senso della discussione dovrebbe ricadere su questo: sara' realmente competitivo prestazionalmente?

si, per me e' competitivo.
e non si ferma li', ma sara' anche versatile.

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.

Beh...devo riconoscere che comunque sai che i prodotti AMD funzionano come tutti gli altri, molti dicono proprio che non funzionano mai e che sono sempre diffettosi. ;)

Comunque non sono d'accordo sull'utente che corre dietro al marchio, purtroppo la questione è tutta li o comunque si avvicina molto, la maggior parte degli "utenti" compra Intel perchè sente in giro che è la migliore marca del mondo o comunque è convinto che sia l'unica presente, e siamo a percentuali alte eh, gli stessi utenti che ignorantemente vanno a chiedere al primo commesso che lavora in una grossa catena quale PC va meglio ed ha più memoria, non ho mai sentito consigliare un computer AMD, mai, solo a me è stato consigliato quando ero inesperto ed ho chiesto ad una persona veramente competente e non commesso qualunque. Tra l'altro basta vedere qualsiasi volantino delle grandi catene, i prodotti predominanti sono Intel, e fino a pochi anni fa i bollini presenti erano gli unici, quando c'era di mezzo AMD veniva citato un fantomatico "Processore Generico X", compresi gli anni truffa.

Una curiosità, perchè per te nel 2011 Intel era migliore? Io nello stesso anno acquistai un Phenom II X6 era un mostro e tutt'ora lo utilizzo per tutto, anche con giochi appena usciti.

Yrbaf,
scusa, ma se hai 2 ALU complete in un core, se devi operare una moltiplicazione su 2 thread, la puoi fare simultaneamente, una per singola unità; se hai solo uno stadio pipeline che fa' quell'operazione, saranno per forza consequenziali.... non c'e' altro modo.
quindi HT, per come lo vedo io, non lo reputo un vero SMT, perche' non mi permette di eseguire simultaneamente le 2 operazioni senza intalcio, ma una tecnologia atta a massimizzare la resa della pipeline, di una sola pipeline.
qui usano praticamente 2 ALU distinte in tutto, solo che partono da un decode molto piu' elaborato, capace di farle funzionare insieme sulle stesse cose.
anche il pentium pro P6 aveva 2 pipeline, solo che erano divise in funzioni, non le replicavano; era per OoO e certamente non mi azzardo a dire per il multithrading (ma neanche per il multitasking, anche se il fine ultimo era quello di supportare gli OS proprio in questo).

il punto di questa discussione e' capire se il +40% e' plausibile;
se e' possibile vedere AMD competitiva, almeno come architettura base, rispetto ad Intel, cosa che in molti commenti trasuda come se fosse fantascienza.

e si sta' dicendo che in effetti, sulla carta, sembra effettivamente di si.
rimane da sapere solo l'implementazione di questa architettura nei prodotti finali; dettagli che qui non sono affatto specificati (non se ne conoscono le frequenze, consumi e gli altri parametri base), oltre al fatto che non si sa' bene se hanno implementato una gestione piu' profonda delle frequenze sia rispetto agli ultimi AMD che d'intel (e non mi riferisco solo al turbo 3.0, ma al fatto che oggi, in turbo, un AMD si deve per forza di cose portare dietro anche i core non utilizzati nell'inalzamento della frequenza, tanto che un processore con 1 core a 4.2ghz e gli altri scarichi ma a 3.9ghz consuma poco meno di quando li usi tutti e 4 a 3.9ghz, e questo non lega bene con il risparmio energetico).

ad oggi non sono sicuro che superi in ogni ambito un 6700K, ma che sia una valida alternativa prestazionale si (se ha 8 core a 2.8ghz), e se hanno messo anche una gestione ottimale di scheduling in riferimento alle risorse ed al consumo, non si comportera' certo male, risultando piu' versatile dei quad e octa/deca intel (e non piu' potente, ma versatile, che per vedere un vero quad su un portatile mainstream siamo arrivati al 2017).

quindi, tralasciando la questione del "mio errore interpretativo" su HT (che reputo una buona tecnologia gia' in P4, ma certamente mi piace di piu' come l'hanno interpretata in SB, perche' ha un senso piu' compiuto ed utile), il senso della discussione dovrebbe ricadere su questo: sara' realmente competitivo prestazionalmente?

si, per me e' competitivo.
e non si ferma li', ma sara' anche versatile.

Da quello che emerge fino ad ora:
Ipc + 40% ( significa oltre il 40% secondo fonti esterne di laboratorio + 42% Vs excavator)
Se ci rifletti è lo stesso aumento di Ipc avuto da nehlamer ad oggi da Intel quindi non fantascenza).
L'Ipc totale Vs intel sarebbe circa -7%.
Il 14 finfet Lp di Gf IBM ha circa -10% di frequenza rispetto l'hp sempre finfet.
Il tdp dichiarato da AMD è di 95w per l'8 core.
Questo dato fa pensare ad una frequenza per il top 8 core compresa tra 3.2 e 3.8 ghz.
Le pipeline dovrebbero essere lunghe con un check Point a Circa metà stadi.
Una logica di controllo molto complessa con un SMT da circa +35% medio.
Adesso andiamo a considerare i pro ed i contro:
Ipc +40% .
Se non fosse vero sarebbe stato più conveniente evolvere excavator.
Frequenza da 3.2-3.6 ghz
C'è chi teorizza 4 ghz Def possibilissimo.
Chi dice 2.8 come l'es.
Mai AMD ha mostrato un es con frequenza uguale al prodotto finito, sempre inferiore, ma c'è sempre una prima volta.
Se analizziamo bene i fatti avremmo:
100+40%+35% = 163 × 3000 zen
90+80% = 162 × 4000 bd ( considero piledriver il 90% di Ipc di excavator).
Una CPU bd portata sul 14nm girerebbe a 4ghz in 95w con 8 moduli ( 16 core) avendo la stessa capacità di calcolo di zen a 3.0 ghz, quindi suicidio commerciale sui server.
Quindi per essere conveniente zen deve andare per forza sopra i 3.2 ghz.

mhm...
di calcoli ne ho fatti parecchio, e anche a me viene 3.2 per l'ottimale, ma per ora anche un 2.8ghz da confrontare al 6700 liscio non sfigurerebbe...
ad oggi non credo che possano clockarlo a piu' di 2.8/3ghz, e molto dipende dal modo di usare i core (con 4 core dev'essere il 90% delle potenzialita' di un 6700, con 8 un 15-20% in piu').
in finale dipende dal prezzo...a 500$ nessuno lo guarderebbe, anche se va' come un 6850K.
passare la soglia dei 500$ e' oltre il mainstream.
e' preferibile vederlo con le prestazioni di un 6700 ma al prezzo di questo.

Yrbaf,
scusa, ma se hai 2 ALU complete in un core, se devi operare una moltiplicazione su 2 thread, la puoi fare simultaneamente, una per singola unità; se hai solo uno stadio pipeline che fa' quell'operazione, saranno per forza consequenziali.... non c'e' altro modo.
quindi HT, per come lo vedo io, non lo reputo un vero SMT, perche' non mi permette di eseguire simultaneamente le 2 operazioni senza intalcio, ma una tecnologia atta a massimizzare la resa della pipeline, di una sola pipeline.
qui usano praticamente 2 ALU distinte in tutto, solo che partono da un decode molto piu' elaborato, capace di farle funzionare insieme sulle stesse cose.
anche il pentium pro P6 aveva 2 pipeline, solo che erano divise in funzioni, non le replicavano; era per OoO e certamente non mi azzardo a dire per il multithrading (ma neanche per il multitasking, anche se il fine ultimo era quello di supportare gli OS proprio in questo).

Quindi siamo passati da dire HT <> SMT a dire SMT non esiste :D
Quasi tutte le cpu moderne superscalari hanno una sola Pipeline (Intel ha abbandonato la doppia pipeline dal P6 Pro, era solo il Pentium che ne aveva 2), quindi lo stadio unico (se ti riferisci allo stadio Execution) c'è per tutti.

Però lo stadio di exec si rifà a più unità funzionali molte delle quali (non tutte) sono altre pipeline a loro volta.
E nello stadio di exec non viene mandata in esecuzione una sola istruzione, ma tutte le istruzioni per le quali c'è sia uno slot libero nelle unità funzionali (e per le unità funzionali pipelined lo slot ad ogni ciclo c'è sempre) ed al tempo stesso non c'è una dipendenza tra le istruzioni.

Il P4 mi pare che potesse eseguire (nel best case, raggiunto probabilmente mai) fino 9/10 istruzioni (ma non istruzioni x86, solo uOps anche se per alcune istruzioni x86 c'è il rapporto 1:1) per ciclo di clock distribuendole su 7/8 unità funzionali (9/10 viene fuori perché le due unità per ADD/SUB eseguono le istruzioni in 0.5 clock facendone quindi fino a 4 in 1 clock).
Il problema è averle tali istruzioni da eseguire senza dipendenze tra loro ed in tempo per tenere le unità sempre alimentate, ed il pescare da 2 thread aumentava almeno la % indipendenza.

Quindi la simultaneità sulla carta c'era.
Poi tra la teoria e la pratica ci sono naturalmente dei limiti.
Limiti magari più evidenti su P4 che sulle cpu più recenti, ...


quindi, tralasciando la questione del "mio errore interpretativo" su HT (che reputo una buona tecnologia gia' in P4, ma certamente mi piace di piu' come l'hanno interpretata in SB, perche' ha un senso piu' compiuto ed utile), il senso della discussione dovrebbe ricadere su questo: sara' realmente competitivo prestazionalmente?

SBridge raddoppia le prestazioni in HT rispetto i primi i7 (che a loro volta probabilmente erano meglio ancora di HT su P4) ma non cambia la tecnica implementativa, mi pare.
Hanno migliorato (rispetto i primi i7) solo l'architettura di contorno, in pratica le velocità di accesso alla cache e poi anche alla memoria ram, nonché aggiunto un livello di cache aggiuntivo la L0 o MicroOpsCache.

Non capisco dove SB implementa in modo giusto ed utile SMT ?
Cosa cambia (ma deve cambiare davvero non essere una tua idea interpretativa) ?
Non è che per caso ti riferisci che la seconda ALU del P4 (si il P4 ha 2 alu) può fare solo le ADD/SUB e le altre istruzioni da ALU sono eseguibili sono su ALU1 ?

da quello che ho letto all'uscita di SB, le sue ALU non hanno limitazioni di istruzioni; le dovrebbero poter eseguire tutte su entrambe le pipeline; anzi, visto he sono 2 ALU concepite come il radoppio delle precedenti, e che queste erano già 2 ma più specializzate non in grado di eseguire tutte le operazioni su entrambe le pipeline, ora in effetti sono 4, copie a due a due.

poi i P6 non avevano una pipeine corta per le op piccole?
é da questo processore che si inizió ad usare, invece di una sola pipeline capace di eseguire tutte le istruzioni, ma una per volta, 2 pipeline altamente specializzate, capaci di eseguire solo un determinato set op, ma di poterlo fare inipendentemente dall'altra.
da qui l'idea di non specializzare le pipeline in modo così radicale, ma di replicare su ogni una gli stadi reputati ad eseguire le op statisticamente più presenti nel codice, da qui l'idea di frammentare ulteriormente le pipeline in modo da eseguire più operazioni indipendenti allo stesso tempo e poi da questa la totale inipendenza di 2 o più thread grazie all'applicazione di registri separati (multithreading), fino a capire che replicare il tutto porta complicazione nella strutturazione del codice in entrata, ma alla fine rende in grado di fare molte più operazioni rispetto alle precedenti implementazioni, anche se il rendimento è inferiore ad un x2, e di molto, ma è comunque capace di aumentarlo in modo trasparente rispetto alla progrmmazione.

insomma, è più o meno questa, la storia, e probabilmente non si fermeranno ad un solo radoppio, anche se comporterà compilatori più elaborati e nuove macro istruioni.