Newsgroup: it.comp.hardware.cpu
Titolo: SSE3 anche per i prossimi A64

Così anche questo "vantaggio" che ha il P4 Prescott sfumerà tra qualche
mese...
http://www.dinoxpc.com/News/news.asp?ID_News=6826&What=News
Saluti

 Saluti
seeeee come x le prime sse... 
ora che AMD le mette  intel avrà già  pronte le SSE4
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 ora che AMD le mette  intel avrà già  pronte le SSE4
Credo che le 3 non avranno, almeno nel breve/medio periodo alcuna
evoluzione......
-- 
Ciao mine
Sony Ericsson FAQ 1.5
http://tinyurl.com/6afr
http://metropolis.blogs.com/

 mese...
ah perchè il prescott ha dei vantaggi?!??!
a proprosito...ho visto dei data sheet a ingegneria sul k8 confrontato con
il prescott a livello di cicli di clock...mediamente il prescott ha un
10-30% di latenza in più (tipo k8 4 cicli, prescott 7 cicli) in operazioni
"standard" x86-xx....
---
Outgoing mail is certified Virus Free with AVG Free Edition!
Checked by AVG anti-virus system (
http://www.grisoft.com
).
Version: 6.0.594 / Virus Database: 377 - Release Date: 24/02/2004

 ora che AMD le mette  intel avrà già  pronte le SSE4
stavolta no....è una specie di scambio di favori....intel non deve pagare
neinte per avere il supporto a 64bit simile ad amd, e amd (sempre pagando)
potrà mettere subito le ss3 nei suoi proci....ovviamente IMHO..ma derivato
dalle news in rete...



si infatti...aggiunte e aggiunte di istruzioni nuove....sclerano i
programmatori (che hanno cominciato ad usare le sse2 solo negli ultimi mesi)
e a sto punto tanto conviene creare un nuova logica per le cpu
---
Outgoing mail is certified Virus Free with AVG Free Edition!
Checked by AVG anti-virus system (
http://www.grisoft.com
).
Version: 6.0.594 / Virus Database: 377 - Release Date: 25/02/2004

 e a sto punto tanto conviene creare un nuova logica per le cpu
Uhmm... Non la vedo cosi`. 
Contano i compilatori e non i programmatori, la stragrande maggioranza dei
programmatori non usa direttamente le istruzioni avanzate della CPU ma lo
demanda al compilatore per ovvie ragioni (lui il lavoro lo fa meglio).
Solo in pochi casi e` il programmatore che ci mette le mani di persona ma
sono pezzi di codice mai troppo grossi e abbastanza localizzati per cui la
fatica e` poca. 
Quello che e` difficile e` vedere la distribuzione delle nuove versioni
(che costano inevitabilmente).
-- 
Valentino Volonghi aka Dialtone
Linux User #310274, Gentoo Proud User
X Python Newsreader developer
http://sourceforge.net/projects/xpn/


E' noto che le cpu K7-K8 eseguono piů istruzioni per
ciclo di clock rispetto ai P4... comunuqe nei modello Prescott
č stata aumentata la larghezza del "bus" di comunicazione
con la cache L2, migliorando di conseguenza la larghezza
di banda tra il die e la suddetta memoria cache, cosa che
dovrebbe anche influire positivamente sulla latenza d'accesso.
Ciao

 (che costano inevitabilmente).
un buon programmatore si mette a fare ottimizzazione assembler....quelli che
fanno come dici te sono solo scarsi....
---
Outgoing mail is certified Virus Free with AVG Free Edition!
Checked by AVG anti-virus system (
http://www.grisoft.com
).
Version: 6.0.594 / Virus Database: 377 - Release Date: 24/02/2004


si si ma parlo di latenze vere e proprie...ossia di elevato tasso di stallo
dei dati all'interno delle pipeline...


 fanno come dici te sono solo scarsi....
Ma neanche per idea... Ma chi ti insegna ste cose?
Solo alcune piccole zone di librerie particolari vengono ottimizzate
usando direttamente l'assembly (l'assembler e` l'assemblatore e non il
linguaggio).
Un qualsiasi compilatore e` in grado di fare ottimizzazioni al codice che
un programmatore neanche si sogna e riesce a farle avendo sott'occhio
tutto il codice e non solo la piccola parte che puoi avere tu e quindi
riesce a fare le cose perche` tutto il software vada piu` veloce.
Il problema viene quando piccoli punti hanno bisogno di ottimizzazioni
spinte e allora ci mette le mani il programmatore, ma cosi` facendo sa
bene che sta rinunciando quasi completamente alla portabilita` del codice
(naturalmente andare cosi` a basso livello senza sfruttare gli extra del
processore e` una barzelletta).
Figuriamoci se ora bisogna andare a programmare direttamente in
assembly... Tu non sei programmatore e neanche ingegnere informatico vero?
-- 
Valentino Volonghi aka Dialtone
Now using Windows for Notebook Hw failure


fanno come dici te sono solo scarsi....
questo in teoria, in pratica un buon programmatore di solito deve
barcamenarsi con i tempi di sviluppo previsti dalla Casa ed il budget
stanziato e quindi scende a compromessi, altrimenti e' un buon
programmatore sotto un ponte...
-- 
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Il segreto per essere considerato un creativo sta nel non fare
    mai riconoscere le proprie fonti [A. Einstein]

dei dati all'interno delle pipeline...
mi spieghi cosa significa?


Questo dovrebbe essere simile al precedente P4 Northwood... semmai è
"esasperato" a causa del fatto che qui adesso le
pipeline sono 31... e in ogni caso permetteranno a Intel
(sistemando magari un pò la dissipazione termica) di salire
rapidamente in frequenza.


Ma LOL! ;)))

 programmatore sotto un ponte...
Al di la` di quello Maurizio, non conviene veramente andare a scriversi le
routine in assembly. E giudicare un programmatore da quanta roba scrive
direttamente in asm va abbastanza riere...
I compilatori x86, come ben sai, fanno le cose meglio e non e` il caso di
rompere le balle a un programmatore/ingegnere, che magari sta lavorando
all'architettura interna del software per renderla il piu` modulare
possibile, dicendogli che e` un'incapace perche` non programma in asm...
Esitono i JIT per ottimizzare al volo un software e farlo girare al meglio
delle sue possibilita` in qualsiasi situazione ma questi funzionano solo
per linguaggi come python, C#, java. In tutti gli altri casi il codice
generato dal compilatore e` gia` asm.
Nel 99,9% dei casi la colpa di certe prestazioni e` nell'algoritmo usato.
E tra parentesi l'uso dell'asm serve per limitare al minimo l'overhead
sull'uso della memoria per permettere al codice di stare completamente
nella cache, non certo prettamente per ragioni di prestazioni.
L'esempio piu` stupido che posso portare e` questo, in python per la
concatenazione di piu` stringhe.
====
ls=[]
for stringa in serie_di_stringhe:
    ls.append(stringa)
''.join(ls)
====
che e` parecchio piu` veloce di:
===
txt = ''
for stringa in serie_di_stringhe:
    txt += stringa
===
Al lavoro ho ottenuto a suo tempo un incremento di prestazioni su un
algoritmo di 40 volte, colpa del modo in cui chi mi ha preceduto ha
realizzato quella zona... Il buon programmatore non e` quello che scrive
codice asm, ma quello che e` in grado di usare gli algoritmi giusti al
posto giusto e che conosce abbastanza bene il linguaggio che usa da sapere
i vantaggi/svantaggi di ogni soluzione intrapresa.
Pretendere ad oggi di usare l'asm al di fuori dei suoi attuali campi (che
sono comunque troppi secondo me) e` folle... 
L'unico posto dove viene veramente usato e` nel kernel del sistema
operativo ma solo nelle parti basse :P.
-- 
Valentino Volonghi aka Dialtone
Now using Windows for Notebook Hw failure


 mi spieghi cosa significa?
E` il tempo/cicli che passa(no) tra la predizione sbagliata e il momento
in cui la pipeline torna disponibile per nuovi calcoli.
In un P4 E ci sono 31 stadi di pipeline e quindi vanno svuotati tutti e 31
prima di poter ricominciare a riempirla.


 prima di poter ricominciare a riempirla.
Uhm, io la sapevo in un'altra maniera: dal momento in cui si accorge di aver
sbagliato predizione, già inizia ad introdurre le nuove istruzioni nella
pipeline, ma da quando ciò avviene, fino a che viene elaborata completamente
(cioè esce dalla pipeline) la prima, passano 31 cicli di clock.
Come dici tu, sembra che deve aspettare prima 31 cicli per svuotare la
pipeline, e poi altri 31 prima di veder uscire una delle istruzioni del
nuovo percorso di codice... è giusto come dici tu e non ho capito quello che
hai scritto?
-- 
ColdShine
"L'esperienza è un'insegnante severa: prima ci esamina e solo dopo ci fa
lezione."
 - legge di Vernon Sanders

 hai scritto?
No, hai ragione tu, ho scritto una vaccata perche` sto pensando ad altro
attualmente e ho scritto abbastanza velocemente... 
Quello che ho scritto infatti e` assurdo :), lasciare per 31 cicli le
unita` vuote non ha vantaggi ne motivazioni particolari eh eh...


hai scritto?
semplificando: se c'e' un errore di branch-prediction ad un certo
punto della pipeline, ne consegue che -tutti- i dati nella pipeline
sono sbagliati (o meglio, in teoria i dati precedenti all'errore sono
buoni ma causa out-of-order-execution spesso bisogna ripulire tutto
quanto), quindi quei 31 cicli saltano.
certo, nell'istante in cui si accorge dell'errore parte il fetch per
le nuove istruzioni "buone", a a quel punto deve comunque reintrodurle
al principio della pipe.



Secondo me questa č una buona spiegazione... anche se quello
che scrive la rece č chiaramente di parte ;-)))
http://www.hardwareirc.com/articoli.php?ID=205&Pag=2
Ciao

mi spieghi cosa significa?
grazie a tutti per le risposte.
"l'elevato tasso di stallo dei dati all'interno delle pipeline..." è
quindi da tradurre con "l'elevato numero di salti che ci sono nel
codice in esecuzione rende meno efficiente la pipeline..."
ciao

con la cache L2, migliorando di conseguenza la larghezza
?
Non usa il "solito" bus a 256 bit, come tutti gli Intel dal Coppermine
in poi?
-- 
ZHELGADIS THE LIGHTBRINGER (ICQ 33134824)
BAG#008,DPPSJ#000,BAT#013,TFC#012,GAM#026,ZZZZ#027,CID#027,PAN#015
"Aspettare non è mai stato un problema, per me.
Posso trascorrere piacevolmente ore e ore con l'aiuto di un buon caffè"

quanto), quindi quei 31 cicli saltano.
Beh, ma se non ho capito male la correttezza o meno della predizione
si capisce quando il jump č arrivato al fondo della pipe, quindi i
dati "precedenti" all'errore sono gią usciti... o no?
-- 
ZHELGADIS THE LIGHTBRINGER (ICQ 33134824)
BAG#008,DPPSJ#000,BAT#013,TFC#012,GAM#026,ZZZZ#027,CID#027,PAN#015
"Aspettare non č mai stato un problema, per me.
Posso trascorrere piacevolmente ore e ore con l'aiuto di un buon caffč"


Hai ragione... il bus di comunicazione è sempre a 256bit, solo
che è stata diminuita la latenza d'accesso, che ora è di circa
15 cicli di clock contro i precedenti 20 cicli, non sarà molto, ma
meglio di niente ;-)
Saluti

 dati "precedenti" all'errore sono già usciti... o no?
Ma gli altri n-1 stadi del pipeline contengono istruzioni
che _non_ devono piu` essere eseguite, quindi il pipe deve
essere re-inizializzato.
bye,
-- 
piergiorgio

dati "precedenti" all'errore sono gią usciti... o no?
dipende da come sono stati riorganizzati i dati in uops, ma in linea
di massima si.
quindi tutto quanto e' caricato in quel momento nella pipe appartiene
alla scelta di branch sbagliata e va cestinato, 31 cicli persi piu' il
tempo di fetch.



wrote:

d'altra parte sono aumentate le latenze di l1 (da 1,5-2 a 4cicli) e l2
(quasi raddoppiata pure questa).
non proprio una bella cosa.



In compenso è amentata la dimensione della cache L1 dati
e L2  ;-)
Saluti

 Saluti
Dunque il K8 in 90 nm non sarà un semplice shrink del K8 a 0,13 micron.

 Saluti
Le SSE3 non introducono novità sostanziali. Il vantaggio di Prescott sul K8
nell' eseguire le istruzioni SSE stà nella maggiore frequenza di
funzionamento. Quando il processo produttivo a 90 nm sarà a regime, Intel
manterrà un certo margine di vantaggio su AMD nell'eseguire istruzioni SSE.

tempo di fetch.
Ok, torna tutto
