[lucusta]

Originariamente inviato da Piedone1113

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.