Newsgroup: it.comp.hardware.cpu
Titolo: Tutta (o quasi) la verita' sulla FPU del K6

In questi ultimi tempi si e' discusso molto dell' unita' floating
point del K6 dal punto di vista delle sue prestazioni rispetto
alle controparti Intel. I confronti tra le FPU del K6 e dei
Pentium, PII sono stati sempre basati su risultati di un numero
piu' o meno vasto di benchmark per la pittaforma Win32, decretando
il PII vincitore di tutti o quasi i test.
Permetto subito che questo non sara' un articolo per riattizzare
vecchie polemiche ma solo una imparziale analisi tecnica dei fatti.
Premetto anche che ai fini del raggiungimento di tale scopo il
confronto non sara' basato su nessun benchmark ma su un'analisi
dei cicli di latency e throughput delle istruzioni nonche' le
capacita' di scheduling delle stesse in entrambi i processori.
Per completezza considerero' anche il Pentium.
Un'ultima cosa, nel seguito citero' spesso l'istruzione FXCH.
Per chi non lo sapesse questa istruzione effettua lo scambio
(FXCH infatti sta' per exchange) tra due registri della FPU.
Detto questo iniziamo con il Pentium (i Pentium MMX sono uguali):
Le tre istruzioni fondamentali della FPU fadd, fsub, fmul sono
"fully pipelined" in una pipeline lunga 3 stadi. La latenza
cosi' e' di 3 cicli e il throughput e' di un ciclo di clock.
Cio' significa che un'istruzione che si trova nello stadio X2
rende immediatamente disponibile lo stadio X1 all'istruzione
seguente. Significa anche che se vengono eseguite solo fadd, fsub
fmul e fxch e la pipeline si mantiene sempre piena, la velocita'
effettiva di esecuzione e' di 1 ciclo per ogni istruzione.
Ecco la pipeline fp del Pentium:
      +----+----+----+
      | X1 | X2 | WB |
  --> |    |    |    |
      +----+----+----+
X1 e X2 stanno per execute 1 & 2 mentre WB sta' per writeback.
Nota:
Le istruzioni fp prima di arrivare a X1 devono passare (per forza)
nei quattro stadi di una delle due pipeline intere. PII e K6
sembrano non avere questo limite essendo basati su un motore
con sheduling delle istruzioni fuori ordine.
Il Pentium II:
La pipeline fp del PII e' fondamentalmente identica a quella del
Pentium.
L'unica cosa importante profondamente diversa e' la capacita' di
eseguire istruzioni fuori ordine, da cui la presenza di
rename-registers per evitare le false dipendenze a causa della
congenita mancanza di registri nell'architettura x86.
Altri miglioramenti vengono dall'istruzione FXCH che ora e'
implementata in hardware insieme a ritocchi dei cicli di clock
delle varie istruzioni fp complesse.
Tutto questo, unito alla presenza di una cache L2 ampia e veloce
fornisce un incremento delle prestazioni fp di circa il 60-70%
in media rispetto al Pentium di pari frequenza.
Attenzione che una cache L2 velocizza molto le operazioni fp
perche' i dati (almeno quelli in doppia precisione) sono a 64 bit
il doppio degli interi. Ad esempio e' stato dimostrato che le
suite di benchmark SPEC92 e 95 sono molto (relativamente)
dipendenti dalla presenza di una cache L2 veloce. Vi ricordate
i numeri del Pentium Pro 200Mhz ?
Passiamo ora al K6:
L'unita' di esecuzione della FPU e' tipo single-stage a bassa
latenza (2 clock contro i 3 del Penty) ma non-pipelined.
Le tre istruzioni fadd, fsub e fmul hanno una latenza di esecuzione
di 2 clock dal tempo che la FPU riceve gli operandi a quando
produce il risultato. Anche il throughput e' di 2 cicli di clock.
Cio' significa che in condizioni ottimali la velocita' effettiva
di esecuzione e' di 1 istruzione fp ogni 2 cicli di clock.
Questo e' uno dei grandi svantaggi della FPU del K6. Comunque
quello che nel puro codice fp e' uno svantaggio, si traduce in
un vantaggio se tra le istruzioni fp vengono interposte delle
istruzioni intere.
Infatti il K6 permette l'esecuzione simultanea di istruzioni di
multiplicazione intera e floating point, qundi ad esempio:
mul ebx    ; edx:eax = eax*ebx    tra interi
fmul st(2) ; st(0) = st(0)*st(2)  tra numeri fp
lo sheduler le mandera' in esecuzione in parallelo.
Il pentium deve fare una cosa per volta, come pure il PII che
ha il silicio per un solo moltiplicatore da usare sia per la
moltiplicazione intera che fp.
Come fa a funzionare non me lo chiedete perche' non lo so!
Naturalmente gli esempi non finiscono qui perche' molte altre
risorse sono condivise oltre al moltiplicatore nei processori
Intel, tra le quali lo shifter dell'unita' MMX.
Infine ecco la vera debolezza della FPU del K6:
AMD raccomanda di evitare l'uso di FXCH perche' mettendola
insieme ad altre istruzioni fp non aumentano le prestazioni.
Quindi si ha un inutile sovraccarico del motore RISC86.
Questo fatto e' importantissimo perche' spiega il vero motivo
per il quale il K6 e' debole sul codice di Quake I & II che e'
ottimizzato per i Pentium sfruttando pesantemente FXCH.
Inoltre AMD raccomanda anche l'uso di istruzioni fp load-execute
che lavorano direttamente con operandi in memoria piuttosto
che caricare prima i dati e poi fare i calcoli tra registri.
Purtroppo (per il K6) la tendenza generale dei compilatori di oggi 
e' di ottimizzare secondo l'ultima filosofia che e' quella seguita
da tutti i processori RISC.
Questo non significa che il PII sia un processore RISC e il K6
no, anzi... si potrebbe aprire un capitolo intero su questo tema.
Un'informazione per chi sviluppa in C/C++ che forse conosce gia':
il compilatore GNU GCC 2.8.0 della Free Software Fundation
include le ottimizzazioni per il K6 e pare siano molto efficaci.
Conclusioni:
La FPU del PII e' in generale leggermente superiore a quella
del K6 ma quest'ultima non e' mai stata sfruttata a dovere.
Non mi piace fare considerazioni indimostrate ma mi sento di
dire che se si ottimizzasse per il K6 si potrebbe ottenere un
guadagno dal 10% a 15%, colmando del tutto o in parte il gap
con il suo antagonista.
Riassumendo, ecco i risultati.
                Latency      Throughput
             +------------+--------------+
Pentium I&II |     3      |      1       |
             +------------+--------------+
    K6       |     2      |      2       |
             +------------+--------------+
Come gia' detto questi dati sono validi solamente se si eseguono
istruzioni tipo fadd, fsub e fmul che sono pipelined e se la
pipeline della FPU e' sempre piena (niente stalli dovuti a cache
misses, predizione sbagliata di un salto, ecc).
Il discorso non vale se si eseguono istruzioni tipo fdiv, fsqrt
fsin, fcos, fsincos, eccetera che non sono pipelined in nessun
processore al mondo (per ora). Per la cronaca il Pentium richiede
39 clock per una divisione in doppia precisione (fdiv) e 70 clock
per la radice quadrata (fsqrt). Il PII va meglio ma non di molto.
Non sono disponibili dati sul K6 che tuttavia dovrebbero essere
simili a quelli del Pentium.
Tirando le somme, il K6 e' piu' debole dei Pentium I & II nel
calcolo fp _puro_ ma possiede un migliore sheduling delle
istruzioni favorito anche da un maggiore parallelismo tra unita'
intere e la FPU. Questa e' una caratteristica molto importante
e sottosfruttata del K6.
Come si e' visto, un'analisi semplice e precisa e' tutt'altro che
banale date le numerossisime incognite in gioco.
Questa e' solo la punta di un iceberg e tutta la storia forse la
sanno solo i progettisti di Intel e AMD.
Spero comunque di aver dato un punto di vista diverso dal solito
confronto a forza di benchmark. I benchmark vanno bene ma a patto
che si sappia cosa ci sia sotto!
Lorenzo Allegrucci
par...@tin.it

 con il suo antagonista.
Tutto molto interessante, senonché temo che nessuno si metterà mai a
ottimizzare codice per il K6... Free software foundation a parte, che
sono gli unici che ottimizzano qualsiasi cosa gli passi tralle mani....A
me incuriosisce molto il fatto che nel K6 continuino a non mettere
pipeline alcuna. Ci sono della ragioni tecniche per questo (oggettiva
difficoltà di implementazione in questo tipo di processore) o fanno per
risparmiare sul silicio e basta?

include le ottimizzazioni per il K6 e pare siano molto efficaci.
Sapevo che la FsF ha (fortunatamente) il pallino delle ottimizzazioni dei 
suoi(ottimi) prodotti. Pero', in pratica, con un codice ottimizzato per K6, a 
parita' di frequenza, si otterrebbero , in FP, + o - le stesse prestazioni di un
PII?
Perche' se cosi' fosse e se tanto mi da tanto... per chi ha linux (o anche os/2 
dato che la GNU ha rilasciato un ottimo compilatore per questa piattaforma) 
basterebbe dare una ricompilata (con ottimizzazione) ai sorgenti per avere delle
schegge di processore anche in FP....
Puoi confermarmi questo, almeno in linea teorica ? 
uono
ache
qrt
un
hiede
clock
olto.
ere
l
ita'
te
o che
e la
lito
patto
Alessandro
--------------------------------------------------------
Nø6 : " Who are you ? "
Nø2 : " I' am the new number two... "
Nø6 : " Who is number O N E ? "
Nø2: " ... You are number S I X ... "
Nø6 : " I' am Not A Number ...   I' am a Free Man ! "
[The Prisoner]
--------------------------------------------------------


Diciamo che anche mamma Intel ci mette il $uo.
Detto questo detto tutto.

schegge di processore anche in FP....
c'e' anche il porting per dos-windows, per quanto sia portato un po'
male...
  (iao!!oai)                                     (ICQ: 10860566)
  //,aurizio
 
   I bimbi buoni vanno in paradiso.
   I bimbi cattivi vanno dove gli pare!

che si sappia cosa ci sia sotto!
L'ho trovato interessante il tuo post.
---
Lunga vita e prosperita'   
Roberto
-> Togliere la a finale per rispondere in e-mail <-


Alessandro


risparmiare sul silicio e basta?
Bisognerebbe chiederlo a loro.
Secondo me e' una scelta tecnica, il silicio ce l'hanno.
La progettazione di un processore credo sia piena di compromessi.
Avranno fatto i calcoli e avranno visto che gli conveniva.
Del resto il requisito principale del K6 erano le prestazioni
sugli interi. Intel si e' potuta avvantaggiare dal fatto che
aveva gia' bella pronta una FPU progettata per essere
(o volere essere) molto veloce, quella del PPro.
Comunque come ho detto nell'articolo la FPU del K6 non e' poi
cosi' male se si ottimizza il codice.
Lorenzo Allegrucci
par...@tin.it

Puoi confermarmi questo, almeno in linea teorica ? 
Confermo.
Ma non cadiamo in false illusioni, si parla di qualche punto
percentuale nelle prestazioni FPU.
Viceversa nel codice intero i miglioramenti sarebbero visibili.
La buona notizia e' che tutti i sistemi operativi sono pesantemente
basati sugli interi e non sulla FPU...
Lorenzo Allegrucci
par...@tin.it

cosi' male se si ottimizza il codice.
Ho trovato una cosa interessante nel file 21924b.pdf, il file che riguarda
le ottimizzazioni per K6 / K6 2, riguardo un po' a tutti questi fatti.
Dunque, per prima cosa e' interessante notare che AMD, nel passaggio tra
K5 e K6 ha appunto introdotto una FPU non-pipelined quando quella del K5
era pipelined, cosa che sembrerebbe in controtendenza rispetto alle
abitudini... questo lo si puo' vedere nelle pagine finali del file, in cui
sono mostrate le differenze di comportamento (stalli e interlocks nelle
pipelines dei vari processori, ecc...) tra K6 e K5, K6 e Pentium, K6 e
PENTIUM MMX, K6 e P2/PPro.
I vantaggi di una FPU NON-pipelined stanno nel fatto che le istruzioni FPU
possono essere scritte in ordine qualsiasi: non e' necessario seguire
ordini ben definiti (allo scopo di rispettare le "pairing rules", le
regole di accoppiamento delle istruzioni nel codice).
Una ottimizzazione FPU per K6 e' ad esempio quella di farle caricare i
dati con un indirizzamento indiretto, cosa che invece e' controproducente
in una FPU Intel in quanto queste ultime hanno una maggiore velocita' se
il caricamento e' da registro invece che da memoria...
Secondo me un possibile motivo per cui AMD ha deciso di fare la FPU
non-pipelined nel K6 potrebbe essere un migliore comportamento del
processore con le istruzioni 3DNow!, che sono di tipo SIMD ed eseguono
calcoli in virgola mobile, ma qui potrei benissimo sbagliare...
Comunque, fatto sta che usando le 3DNow! e' possibile fare delle divisioni
MOLTO veloci: 4 cicli per una divisione FPU con 15 bit effettivi di
precisione nel risultato, e 10 cicli per una a 24 bit di risoluzione
effettiva...
Poi nel prodotto matrice x vettore il K6 2 e' una scheggia: sempre su quel
file c'e' un esempio di routine ottimizzata che fa il prodotto tra una
matrice 4x4 e un vettore 4x1, e si vede che si riesce ad ottenere un
throughput di 4 istruzioni per ciclo quando viene chiamata in causa
l'istruzione 3DNow! implicata, e in ogni caso vengono eseguite 2
istruzioni contemporaneamente senza stalli nelle pipelines in tutto il
blocco di codice interno al loop... vabbe' scusate se dico cose che magari
gia' sapete, ma se davvero vi interessa la cosa, allora vi consiglio di
scaricare quel file pdf dal sito AMD...
Ciao!
 ______________________________________________________
/  ### Marco Trevisan ###
| /*
|  * IEEE Student member 
|  *  |   | 
|  *  |   |-> 
http://www.dei.unipd.it/~oberdan
 
|  *  |-----> 
http://www.ieee.org
|  *  |-----> 
http://www.dei.unipd.it/~ieeesb
|  */
|             e-mail : 
m_tre...@ieee.org
 
|                      
obe...@dei.unipd.it
\______________________________________________________

percentuale nelle prestazioni FPU.
Dunque...per curiosita' mi son preso POVRAY3.0 per OS2  (versione ottimizzata 
per Intel Pentium)
E l'ho avviato con il file *.POV e gli switch a riga di comando usati 
per i benchmarks ; poi ho confrontato i risultati con prove gia' fatte descritte
in un file XLS preso dal sito.
PII 300MHz / 64MB EDO DRAM	300 MHz	Windows NT 4 (sp3)	0:02:11	Some smaller processes were running at the same time.	
Pentium Pro (256K)	200 MHz	Windows NT 4.0 SP3	0:02:12		
Intell P6	200 MHz	NT 3.51	0:02:13		
Pentium Pro	200 MHz	DOS 6.2	0:02:15	more opt version	
2 x R10k	180 MHz	Irix 6.4 unpatched	0:02:16	again no optimizations (hints?)	
DEC Alpha CPU	400 MHz	Digital UNIX V4.0 build 564	0:02:16	Not a very optimized compile.	
Intel PII	233 MHz	Linux 2.0.27	0:02:23	(64Mb Ram 512kb cache)	
Intel P-II (512K L2 cache)	266 MHz	DOS 6.22	0:02:26		
Pentium Pro	200 MHz	DOS 6.2	0:02:28	Pentpov	
Alpha 275 MHz 4mb cache	275 MHz	OSF/1 3.0	0:02:29	Only one user logged in. -O3 compiler option	
Intel PentiumII	266 MHz	Linux 2.0.30	0:02:31		
Alpha AXP 21064A EV4.5	275 MHz	Digital UNIX (OSF/1) 3.2	0:02:39		
Pentium Pro	200 MHz	NT3.51	0:02:43	Foreground task	
pentium pro	233 MHz	w95	0:02:44		
Dual Pentium MMX	200 MHz	Linux 2.1.44	0:02:49	with PVMPOV extensions	
AMD K6	225 MHz	DOS 6.2	0:02:50	200 MHz processor overclocked 225 (=3*75)	
La mia prova:
K6 240(68x3.5) 48Mb EDORAM Mboard Freetech VIA/VPX97 OS/2Warp4----> [0:02:40] 
POVRAY3.0 per OS/2(Intel Pentium Optimized) Compilatore WatcomC 10.0
 
Non so quanto POV possa essere un benchmark affidabile ed indicativo pero' se 
anche nella peggiore delle ipotesi il guadagno, con un programma compilato in 
modo ottimale per K6, fosse solo del 10%  non vedrei tutta questa decantata 
supremazia di INTEL su AMD. Anzi, considerato che PPRo e P2 hanno la cache 
integrata ed il PII va sullo slottone direi che, fatte le dovute proporzioni, il
K6 si attesta su posizioni di tutto rispetto insieme ai suddetti processori. 
Comunque non mi interessa il confronto muscolare tra processori, non sono un 
fanatico dei giochi pero'anche da queste considerazioni si puo' capire quanto il
"consorzio" M$-Intel si sia dato da fare per prenderci tutti per i fondelli 


>PGP public key avaiable: do "finger 
xywza...@helen.cli.di.unipi.it
"<<
fingerprint: D1E7 641F 1821 74BA  1836 9B50 B37C 5FA3

scaricare quel file pdf dal sito AMD...
Io mi ero basato su una versione precedente del file: 21924a.pdf
per cui tutte queste cose erano assenti.
Ti rigrazio molto per le tue precisazioni.
Lorenzo Allegrucci
par...@tin.it

avere dei punti percentuale di vantaggio sui calcoli fp.
Se vogliamo seguire una proporzione lineare il K6 credo che vinca il
rapporto prezzo/prestazioni sia sugli interi che in fp.
Se c'e' qualcuno aggiornato sui prezzi potrebbe dare qualche esempio.
Lorenzo Allegrucci
par...@tin.it

il doppio degli interi.
Allora perchè il Celeron mantiene alte prestazioni FPU (sempre maggiori del
P55C nonostante la completa mancanza di cache?
Ciao!
    Saverio

P55C nonostante la completa mancanza di cache?
La cache non e' completamente assente, c'e' la cache L1.
In effetti per dirla tutta la cache L2 migliora molto le
prestazioni fp di processori RISC come Alpha e PowerPC.
Io mi riferivo (forse erroneamente) a questi processori.
Chissa' forse i processori Intel si avvantaggiano di una
densita' del codice maggiore avendo istruzioni a lunghezza
variabile.
Lorenzo Allegrucci
par...@tin.it

Ti rigrazio molto per le tue precisazioni.
Di nulla, anzi grazie a te per avere letto! :)
Ciao a tutti,
