vado un po OT, scusate.
In quel post, per la domanda che ponevi c'e' parecchio da scrivere (per questo che Mikael ha tagliato un po' corto... è praticamente descrivere dettagliatamente un processore matematico).
posso dirti pero' che la considerazione che facevi è in parte sbagliata.
un calcolo a 64 bit non è necessariamente piu' lento di uno a 16 bit, perchè se compi una serie di operazioni ben definita per entrambi, ed entrambi vengono eseguiti su una ALU di pari estensione dei data, il tutto viene processato in un determinato numero di clock, per entrambi, quindi il tempo è il medesimo.
puoi però, per necessità, dover processare ad una definizione maggiore o inferiore della base che hai a disposizione, e in quel caso le cose cambiano.
usare una base maggiore si puo' fare, ma devi frammentare il calcolo in modo che i singoli frammenti siano almeno pari alla base che hai, che sono essenzialmente bit operazionali, quindi transistors.
quando si parla di rateo di calcolo a doppia precisione (DP o DL: Double Leight o longdouble) su un processore a 32bit dovrai dividere in tante operazioni tale da ridurre la dimensione iniziale al formato della base, e teoricamente costa 16 frazioni; ecco perchè vedi ratei da 1:16 (ma parliamo di un valore teorico, in quanto devi impegnare il processore anche per dividere e sommare le frazioni, oltre che metterle da parte nella caches... i TF reali diventano perciò inferiori ad 1:16).
scendere di base, invece, è piu' facile.
normalmente si usava un processore a 32 bit in decurtazione 16 bit ponendo almeno 16 cifre del banco data uguali a zero, quindi avevi un data formalmente a 32 bit.
in questo modo calcolavi con inferiore precisione, ma il processore non è seriale (come parte del nostro cervello), ma parallelo a base prefissata (e scritta letteralmente sul silicio).
in pratica, se deve fare la somma di 2 numeri a 16 bit su banchi a 32 in decurtazione di base, ti somma anche gli zeri... per lui sono comunque significativi.
in questo caso la potenza di calcolo è la medesima per entrambi le basi, ma per il semplice fatto che il processore calcola sempre con la stessa base (32 bit, nel nostro esempio), quindi i Tflops espressi in una base sono identici nell'altra.
la seconda possibilità deve essere invece operativa in HW.
significa semplicemente che il banco che usi deve avere la possibilità di separarsi e computare distintamente 2 calcoli sullo stesso percorso di calcolo (tipicamente una ALU).
per farlo, pero', devi indicizzare i singoli spezzoni di calcolo (le singole operazioni), quindi devi avere un registro di identificazione che segue i singoli stadi della pipeline (o, se è a stadio finito, ossia senza possibilità d'interruzione e quindi senza possibilità di salvare ogni volta il risultato di un'operazione in un registro adiacente, averne uno in testa su cui salvare partenza e poi arrivo).
tra queste due modalità c'e' una terza, ossia la base è splittabile ma i calcoli da eseguire devono essere sincroni, ossia esegui le stesse identiche operazioni sui due data distinti in parallelo, che ti daranno comunque due risultati distinti (a base dimezzata).
questo dipende propriamente da come è costruita l'ALU e l'AGU (in pratica nel modo indipendente è come se avessi 2 ALU e 2 AGU unite, nell'altro una delle due è unica).
https://en.wikipedia.org/wiki/Address_generation_unit
qui hai la descrizione di cosa sia e a cosa serve una AGU; tutte le CPU ormai la hanno separata, ma non tutte le GPU ne hanno propriamente una per ALU... alcune volte sono unità generalizzate a fine pipeline e servono piu' pipeline (dipende sempre se a stadio finito o stadio "libero").
perchè è utile oggi il calcolo a 16 bit (o INT8 non ce lo eravamo tolto di mezzo 20 anni fa?!).
perchè se l'ambito di calcolo non richiede precisione assoluta ma ne devi calcolare a bizzeffe, il 16 bit permette ALU grandi (quasi - ci sono sempre i registri da considerare) la metà, ma soprattutto occupano la metà in RAM (e non sempre, altra cosa che devo aggiungere al discorso); hai percio' il raddoppio della potenza e dello spazio di allocazione a pari superficie con lo stesso processo litografico.
non occupano sempre lo stesso spazio in RAM e non è detto che aumenti la banda passante tra ram e processore perchè dipende da molteplici altri fattori, tipo l'indirizzamento e soprattutto il controller (ma generalmente è cosi').
se l'indirizzamento, o la ram, consente di storare un solo indirizzo a riga... le ram hanno tipicamente 32 bit riga... usi 4 o 32 bit di quella singola riga, stai usando comunque una riga (ma è una concezione un po' datata).
stessa cosa sul controller:
se non ha un buffer di accumulo e somma, dovrà sempre mandare la singola chiamata per quanto è esteso il bus sulle memorie, ed è la stessa cosa di riempirli di zero o usare cifre significative (ma anche questa è cosa un po' datata, soprattutto guardando l'ampiezza dei bus dati della memoria di oggi, che possono arrivare a 1024 bit sulle HBM... e non ci sono, almeno per quello che io sappia, processori a 1024 bit).
i processori sono pallottolieri paralleli e ad operazioni definite, ossia, per ogni ciclo, devono fare un'operazione che tu hai indicato e la devono fare nella base che è possibile usare per costruzione fisica (per come è fatto) o logica (per come riesci ad emulare il processo dell'operazione usando piu' operazioni).
per quanto riguarda le differenze tra le architetture AMD e nvidia (fino a pascal), parliamo di due concezioni simili ma distinte.
la base di calcolo è la medesima; oggi vega puo' separare i suoi banchi in sotto basi inferiori e far crescere la potenza di calcolo (ma occhio che sono basi diverse), mentre nvidia lo fà con i cuda core GP10B (che sono presenti anche nelle pascal consumer e pro, ma in numero limitato a 1 in FP64 frazionabile a 4x16 bit per SM, gli altri cuda core sono GP10A e computano solo 32 bit), ma questi sono propri delle soluzioni HPC quali P100 e del tegra X1 (perchè per il settore del tegra si usa ancora grafica 16 bit e conveniva usare i B e non gli A).
la differenza maggiore non è l'ampiezza del banco, quanti bit ha la base, ma l'estensione (quante operazioni puoi fare per ogni stadio).
AMD ha sottoprocessori corti, insufficienti a garantire l'esecuzione di un calcolo tipico della grafica 3D (posizionamento del singolo punto nel mondo 3D, il cambiamento di base da 3D a 2D ed il colore, oltre a tutte le funzioni di post processing), ma sono a stadio "libero" e si possono tranquillamente sommare, anche se richiede lavoro di logica e gestione (overwork drive), mentre nvidia usa stadi finiti su maxwell e stadi "liberi" su Pascal, dividendo l'estensione dello stadio maxwell in 2 parti, e questo porta, a dare una risposta ogni cuda (che in effetti è diviso in 2 parti su pascal) per ogni richiesta fatta, con un'enorme risparmio di gestione; la limitazione sono pero' le parti secondarie, ossia quelle che si caricano dell'esecuzione ad alto livello del lavoro... in nvidia sono i GPC, che dividono il lavoro per quanti SM si hanno al loro interno... piu' GPC hai piu' effettivamente puoi suddividere il lavoro generale, anzi DEVI suddividere, sennò non usi quella risorsa.
ecco perchè una GPU che ha 4 GPC come il GP104 si sfrutta bene con 4 o 8 thread (visto che puo' segmentare i cuda in 2 parti), ma lo stesso processore non è il massimo per una GP102, visto che questo conta 6 GPC.
per AMD invece è il ricucire il tutto sotto 4 o 8 thread che è un bel lavoro di gestione, ma è anche vero che le sue parti secondarie (gli engine processor) sono comunque 4, anche se il loro lavoro è inferiore rispetto a quello che devono eseguire le SIMD... nello specifico sono richiesti meno cicli per l'impostazione delle SIMD di quanto è il mero lavoro che devono fare queste, quindi ha il tempo per settare altre SIMD... (ma ne disconosco le reali capacità, quindi è inutile chiedermi quanti SP riescono ad impostare per un dato tempo macchina, che significa chiedere quanto sono saturi per il lavoro che svolgono).
Volta V100, invece è tutto un'altro affare.
V100 è un vectors processor e, come tale, ragiona su vettorializzazione del dato, potendo eseguire conti distinti su banchi adiacenti, basta che non siano occupati.
i vector processor sono processori a stadio "libero", in cui ogni stadio è praticamente a se stante.
offrono versatilità totale (essendo a stadi unitari), ma logicamente, per farlo hanno un sacco di registri e si viene ad occupare un sacco di spazio.
una SIMD AMD, un SP, è anch'esso uno stadio "libero", ma non unitario (sono 4 SIMD a stadio) ed un singolo stadio non credo sia nemmeno completo (in quanto, su polaris, una unità finita è composta da 16 SIMD, o sia 4 sottogruppi da 4 SIMD).
Navi, guardando i brevetti AMD, potrebbe essere un processore sempre a stadio "libero" ma non con una lunghezza fissa (ne puoi avere da uno, da due o da 32 stadi... il resto non si sa, leggendo le carte)... diventa insomma lo stadio di congiunzione tra un maxwell e un V100, solo che credo richieda una gestione molto raffinata del flusso dati, perchè è come se avessi tanti processori piccoli e meglio adatti ad un certo tipo di codice uniti in uno solo... se non lo gestisci bene inserisci latenze assurde (e potresti incorrere anche nel problema di poter far tutto al meglio, ma quel tutto dev'essere ben poco, perchè per farlo al meglio non sfrutti l'intero processore, o fare tanto, ma fatto nel modo piu' brutto e dispendioso che ci sia)... ma in effetti di Navi non si sa proprio nulla, e non è detto che AMD sfrutti quell'idea per quell'architettura (e soprattutto nel campo consumer).
ho marcato un po' di linee, ma il discorso è realmente molto piu' grande... ci sono processori che hanno na logica architetturale che è solo loro, propria...
e comunque ogni processore è simile ad un'altro, ma distinto (senno avremmo solo cloni!).
anche il funzionamento di diversi processori appartenenti alla stessa famiglia, per cui condividono la stessa architettura base ma non lo stesso disegno, alla fine, si dovranno gestire, ad alto livello, in modo diverso (esempio 1080 e 1080 Ti)...
le casistiche sono decisamente tante, ma almeno spero che ti sia chiaro il discorso sulle basi di calcolo.
