Newsgroup: it.comp.hardware.cpu
Titolo: futuro delle 3Dnow! AMD: ditemi la Vostra

Salve a tutti,
Sono abbastanza nuovo nel NG e se propongo un argomento già
abbondantemente discusso perdonatemi e ignorate il mio msg.
Sono in procinto di aggiornare (di già!) le budella del mio PC e non
so se puntare su Super7 o su Slot1...
CHE PC HO E COSA CI FACCIO
Uso il PC per hobby, come tantissimi altri.
Seguo con un certo interesse la caotica concorrenza AMD/Intel e
l'evoluzione dei rispettivi prodotti.
Ho un sistema basato su K6-233 classic, una CPU che "mi piace" e di
cui sono abbastanza soddisfatto.
MoBo QDI Titanium IB.
Uso frequentemente browser internet... browser jpg :), Oulook... e
altre applicazioni "da ufficio".
Non sono uno sfegatato di videogiochi ma "faccio parte" di una gang
che si riunisce il mercoledì sera per collegare i PC in rete (fino a 7
!!) e giocare come dei pazzi scemuniti per 3-4 ore :-D :-D
Per questa attività ludica ho preso tempo addietro una 3Dfx Vodoo 1.
COSA PENSO DELLA MIA CPU
K6... pare un progetto elegante e pulito...
Un lodevole sforzo da parte di AMD... 
Risultati ottimi in confronto alle Intel... finchè non si tocca FPU...
In tale campo il mio K6 risulta nettamente inferiore rispetto ad un P2
già a prima vista, quando su video si susseguono frenetici fotogrammi
3Dfx di Unreal, Ultim@te Race e altri giochini "FP-leggeri-leggeri"
dell'ultima generazione.
A me non importa un gran che di vedere le animazioni un po'
scattose... ma i simpatici amici della gang di deridono per il mio
amato tenero K6.
:)
PROGETTI
Visto che:
1) Ho preso il mio primo stipendio giusto ieri...
2) Prevedo di cambiare CPU tra 2-3 mesi...
3) Ci sono novità interessanti nel mercato delle CPU... 
4) ...ma anche una gran confusione riguardo al supporto SW di 'ste
istruzioni supplementari nelle nuove CPU
Mi chiedevo se conviene orientarmi su un Celeron con bus a 100 Mhz e
cache 256 k di prossima uscita (?) o s un K6-2 (o -3?) .
Nel primo caso c'è la potenza PF garantita...
Nel secondo un'ottima ed economica architettura per l'uso "normale"...
ma anche qualche dubbio sulle istruzioni 3Dnow! e sull'affidabilità
del supporto HW...
DOMANDE
1) Queste istruzioni 3Dnow! potrebbero realmente "cambiare faccia" ad
un videogioco ?
2) Saranno utili anche per applicazioni non-ludiche come programi di
modellazione 3D, decodificatori MPEG, ecc.?
2bis) Per i giochi che sfruttano le librerie grafiche Glide (3Dfx)
sarà necessario procurarsi una versione di Glide ottimizzatre per le
3Dnow! ?
3) Girano voci di problemi di compatibilità tra chipset per Super
Socket7 e alcune schede di espansione (come schede video). Sono voci
fondate?
4) So che le istruzioni 3DNow! eseguono calcoli "multipli" (SIMD) FP
a singola precisione anzichè doppia (come nelle KNI). Ha qualche
importanza per i videogiochi?
Ciao a tutti e buon divertimento!
Fabrizio

Risposta breve:
se vuoi qualcosa di potente => PII
se vuoi spendere poco => k6-2
Il prezzo č l'unica discriminante. Lascia perdere il Celeron.

...


Non è male, ma è anche quello frutto di una politica "in economia" per cui
valutane attentamente i prezzi!

importanza per i videogiochi?
il problema e' a monte: il programmatore puo' decidere di lavorare in
singola precisione, e allora ha certe alternative di programmazione,
altrimenti puo' decidere di lavorare in doppia, e allora ha altre
alternative. cmq in linea di principio le KNI sembrerebbero molto superiori
alle 3DNow (se qualcuno ne sa di piu' mi puo' tranquillamente correggere).
ciao

>>>   
fea...@tin.it
   <<<<
cin...@iperbole.bologna.it


si, e' un ragionamento molto sensato.
ciao

numerico).
Beh, le MMX erano tantissime e non so che fine abbiano fatto...
Stefano
Sostituire kappa con "k" x rispondere...oppure 
mar0...@ud.nettuno.it
ICQ# 15012689

molti, le KNI in pochi.
Parole sante.
MarcoSS

qualcosa, quindi mi sa che non la avremo ad un prezzo tanto basso.
Dalle price previews che ho visto, 567$ il 450 MHz e 809$ il 500 MHz (poi ho
fatto la media.....). Ma non ti preoccupare, per il 450 questo fa comunque
un milione e due (visti i precedenti).


Beh, le MMX erano tantissime e non so che fine abbiano fatto...
;-) Erano meno delle KNI, credo... forse 47? Dovrei andare a rivedere. Il
problemi con l'MMX sono stati due:
-la Intel non ha fornito adeguati strumenti di sviluppo, quindi per
sfruttare l'MMX occorreva scriversi codice assembly a mano (!)
-le MMX non acceleravano dove serviva.... il fatto č che per usare quelle
dovevi disabilitare il calcolo FP e nel momento in cui lo riattivavi la
transizione si "mangiava" buona parte dei cicli di clock risparmiati fin lě.
(O qcs del genere, non ricordo bene... ormai le ho sepolte :-)).


+AD4APg-Per la modellazione 3D, credo di s+AOw-.... ma per l'MPEG no (l+AOw- sono invece
+AD4APg-utili le KNI).
+AD4-in genere i decoder MPEG lavorano sugli interi, o al max sugli FP in
singola
+AD4-precisione per cui le 3DNow dovrebbero andare bene, a parte eventuali
+AD4-problemi di compatibilita' SW.
Boh? Forse hai ragione tu, io avevo letto affermazioni che dicevano il
contrario.
+AD4APg-Di sicuro sono
+AD4APg-pi+APk- complete (e infatti sono molte di pi+APk- delle 3DNow+ACE- dal punto di vista
+AD4-non solo. le KNI possono operare in SIMD sugli FP in doppia precisione, che
+AD4-e' l'optimum per i giochi 3D.
Di sicuro sono l'optimum, s+AOw-. Tuttavia forse, proprio essendo l'optimum,
sono pi+APk- necessarie per il CAD o simili. Di sicuro mi pare che le 3DNow+ACE- se
la cavino bene nei giochi, almeno in quelli attuali, no? Quindi forse la
doppia precisione non +AOg- cos+AOw- essenziale per quelli. Vedremo.
--
Federico Angiolini
+AD4APgA+AD4-   feangio+AEA-tin.it   +ADwAPAA8ADw-
cin0576+
AEA-iperbole.bologna.it

(O qcs del genere, non ricordo bene... ormai le ho sepolte :-)).
si, era + o - questo il discorso. il problema era che i registri su cui
operare con le MMX erano mappati su quelli per l'FP (non erano gli stessi,
come qualcuno ha scritto su una rivista a diffusione nazionale. mah... e poi
se la prendono con i cosiddetti smanettoni...) per cui ogni volta bisognava
fare un context switch che portava via un mucchio di clock (a meno di non
lavorare solo sugli int).
BTW, da questo pto di vista AMD paradossalmente ha enormemente migliorato la
situazione, introducendo una specifica istruzione che permette il context
switch in pochissimi clock.
ciao

certo
Immagino che POTENZIALMENTE la risposta sia sicuramente affermativa...
Ma io voglio sapere se le 3Dnow saranno effettivamente sfruttate in
detti campi.
Grazie della risposta.
Fabrizio
--------------
fo...@cyberg.it
ICQ #6861617

molti, le KNI in pochi.
...ma è anche vero che i prezzi caleranno rapidamente...
Ciaociao.
Fabrizio


 (O qcs del genere, non ricordo bene... ormai le ho sepolte :-)).
Certo una parte consistente ... comunque la stessa cosa vale per le 
3dNow!, così se uno deve mischiare calcolo a 32 e 64 bit si torna nello 
stesso problema. Per fortuna hanno introdotto l'istruzione FEMMS che 
"switcha" più velocemente (ma anche in maniera più "sporca").
-----------------------------------
\\//_  Live long and prosper .
   Lorenzo Gallucci
-----------------------------------
"There are always chances" -  Spock

un milione e due (visti i precedenti).
Beh, tanto il dollaro sta letteralmente crollando......grazie Monica!
Ciao!
Francesco L
i3...@PROF.shineline.it
 (togliere PROF. dall'indirizzo)
Vota contro la TUT nel sito: 
http://notut.ml.org

"switcha" piů velocemente (ma anche in maniera piů "sporca").
Hai detto niente... questo mi pare risolva il problema dell'MMX, no???


 ...ma è anche vero che i prezzi caleranno rapidamente...
Per entrambi, però ... e partendo da categorie di prezzo MOOOLTO 
differenti, e come se non bastasse con differenze di tempo a disposizione 
ENORMI ...
3dNow!: meno costoso, uscito prima
KNI: più costoso in partenza, uscirà certamente dopo... quando, però? Per 
ora è solo vaporware...
-----------------------------------
\\//_  Live long and prosper .
   Lorenzo Gallucci
    ICQ#  19194057


 questo mi pare risolva il problema dell'MMX, no???
Il problema di switching, sicuramente sм, quello dell'utilitа, non c'и 
santo che tenga, cosм и e cosм resta. In realtа penso che AMD l'abbia 
introdotta per migliorare le 3dNow!, piщ che altro ... penso che delle 
MMX gliene freghi tanto quanto....


 Beh, tanto il dollaro sta letteralmente crollando......grazie Monica!
Anch'io sono contento del calo del dollaro, ma mi sembra doveroso 
ricordare che se da una parte Monica ci fa risparmiare tanti soldi, 
dall'altra questi sconti qualcuno tenta di tenerli a bada con il sangue 
di somali e jugoslavi ... il che quantomeno è disonorevole.... :-((((


ora è solo vaporware...
Avete notato che da CHL ormai il K6 2 266 lo vendono a meno di 200.000 i.c.?


MMX gliene freghi tanto quanto....
Naturalmente. Intendevo proprio che le 3DNow! hanno in partenza un problema
meno delle MMX.


 Avete notato che da CHL ormai il K6 2 266 lo vendono a meno di 200.000 i.c.?
E il 300 (supporto *ufficiale* per i 100 MHZ di FSB, anche se il 266 ci 
va tranquillamente), viene poco di più (250 mi pare). Certo che per 33 
MHZ di frequenza di core non vale la pena, specie se tutti i 266 vanno 
anche a 300 ... ma era così per dare l'idea ... i prezzi in effetti si 
stanno comprimendo sempre più...
Chissà come sarà lo scenario a Gennaio/Febbraio ... con il K7 e le KNI 
alle porte...


 -[ ).
Come mai per Intel? Per loro posso capirlo ... ma a Intel ...
Ah, aspetta, vuoi dire: "Così posso mettersi a costruire inutile miniere 
di rame necessarie per il software inefficiente che c'è in giro" ?


di rame necessarie per il software inefficiente che c'è in giro" ?
Bravissimo. :°(((((


 Bravissimo. :°(((((
:-((((((((((((
Stavo cercando di verificare quest'affermazione per WinAmp (che mi sembra 
un po' troppo esoso per essere 3dnow!-enabled), ma purtroppo dsassm02 [di 
Sang Cho], che per il resto è ottimo, non riconosce le 3dnow! e la nuova 
versione ha dei bug... qualche consiglio per un altro deassembler?


un po' troppo esoso per essere 3dnow!-enabled)
Hai provato a monitorare l'uso della CPU impostandolo per Pentium liscio o
per 3DNow!?


Certo. Forse nell'MPEG però questo aspetto è più secondario.
Dunque... mi pare di aver letto qualcosa di Sartori che diceva pressappoco che 
le KNI hanno qualcosa in piu' per il MPEG ma per il resto sono equivalenti al 
3DNOW in prestazioni.
AlessanDro
---------------------------------
Legge di Howe
   Ognuno di noi ha un piano che non funzionera'.
---------------------------------
IACT member
http://pages.cthome.net/iact/
http://www.ogcs.com/iact-italia/

3DNOW in prestazioni.
CREDO che questo fosse quello che sostenevo io all'inizio, il che mi fa
piacere. (Scusatemi, il thread va avanti da un mese, non mi raccapezzo più
benissimo.... ;)


 per 3DNow!?
Sì, l'ho fatto, con Wintop, ma non è esattamente ciò che mi serve....
Ora ti dico perchè... ho provato a fare un po' di reverse engineering sul 
codice di WinAmp, per tentare di migliorarlo (poi ne ho parlato con 
Justin Frankel, l'autore), e poi ho valutato i risultati (a proposito, 
3dNow occupa il processore per quasi metà del tempo rispetto 
all'algoritmo per Pentium). Però un codice di number crunching si valuta 
meglio se può andare in free running per tutto il tempo e misurando poi 
quanto tempo è trascorso. Per far ciò, bisognerebbe scrivere un null 
output plugin, in maniera che, appena il buffer si riempie, venga subito 
svuotato e il thread di decodifica lavori "a palla". La mia richiesta 
derivava proprio dal fatto che: 1) 'sto plugin non l'avevo (e non l'ho 
tuttora) trovato 2) mi seccava scriverlo io... :-)


Justin Frankel, l'autore),
Ah! E come e' andata? Sei riuscito a combinare qualcosa? Vedremo il tupo
nome nella prossima versione di winamp?
Ciao


video...no, non sono d'accordo.
Si parlava di cache ottimizzata, no? Bene, io ti ripeto che IMHO con tutto
quel macello di MB che vanno in su e in giù la cache ottimizzata (che già
non ottimizzata ha in media un hit rate del 95%, e in questa applicazione
forse di più) non può portare dei vantaggi notevoli. E anche delle PC200 (o
come le vuoi chiamare ;-) mi sembrano utili solo se poi in background vuoi
farci qualcos'altro. Si sa, tutti giocano anche a Quake mentre vedono un
film su DVD........... ;-)


 film su DVD........... ;-)
Tutti, certo! :-) E secondo te perchè in Win98 hanno messo il supporto 
per monitor multipli? Con l'occhio sinistro giochi a Quake, con l'altro 
ti guardi il film, e similmente per le orecchie! :-)))))))))) [...lo 
sconto per l'oculista che curerà il conseguente strabismo è incluso nella 
confezione... :-)]
Comunque, per tentare di chiudere, credo che possiamo sgolarci finchè 
vogliamo sulla questione ottimizzazione sì/ottimizzazione no ... ma 
soltanto il mercato, che taglia i prodotti (e i programmatori) che non 
riescono ad essere competitivi, potrà decretare se l'ottimizazzione in un 
certo punto era necessaria o no... e non mi dire che anche questo è 
scontato, lo so già! :-))) (ma penso vada detto comunque...)


 nome nella prossima versione di winamp?
Non ci sperare, il "mipo" nome non lo vedrai :-) Io che c'entro con 
loro?.... Io più che ho altro l'ho fatto per "sfruculiare" un po' il 
codice, e mettere alla prova l'esecuzione Out-Of-Order del K6, insomma 
soltanto per giocarci un po'... 
Pare che (almeno secondo Justin) le istruzioni PREFETCH (la cui mancanza 
è forse l'unico appunto che si può fare al decoder 3dnow) non sono utili 
con il K6-2, ma bisognerà aspettare il K7 perchè siano efficaci 
(lunghezza di una cache-line o che altro?). Dice lui che i dati sono 
sempre in cache (dato che aggiungendo le prefetch il TSC della routine 
non cambia), però un'interpretazione alternativa è che i dati non siano 
in cache nè prima nè dopo il cambio del codice, per cui, anche in questo 
caso, aggiungendo le prefetch non cambia nulla. Gli ho detto se può 
controllare il numero di prefetch usate e il numero di cache miss/hit che 
si verificano (basta abilitare e controllare alcuni dei Pentium-style 
counters) ... ma alla seconda missiva non ho avuto risposta, per ora.
La sai una cosa interessante? Ci sono considerevoli parti di quella 
routine che usano invece il "vecchio stile" di FPU (non è tutto 3dnow 
quello che luccica ... :-), pur lavorando comunque con numeri FP di 32 
bit (... si scoccia a sostituire la parte in C con l'equivalente in 
assembly), ed altre che invece sfruttano sì le 3dnow, ma per calcolare 
numeri a 32 bit (in effetti il calcolo avviene per le due metà del 
registro 3dnow a 64 bit, ma quella superiore viene scartata), per giunta 
senza di "raccogliere i termini comuni"... 
Per fortuna si tratta di parti di codice eseguite poco spesso (diciamo un 
migliaio di volte al secondo, mentre il "core" viene eseguito, in un 
secondo, un numero di volte superiore di almeno un ordine di grandezza) 
:-), ma per sua stessa ammissione (di Justin), c'è molto da migliorare. 
Mi sto preparando a vedere scendere quell'indicatore di occupazione 
della CPU scendere dal 10% a non più del 7% ... vabbè, in realtà non so 
quanto saranno efficaci le migliorie in preparazione (ovviamente ... :-), 
però è bello sognare... :-)


prossimi allo ZERO)???
Non fare confusione tra trashing e cache miss. Il fatto è che il controller
della cache, per quel che so, agisce in modo "stupido": appena riceve la
richiesta di un dato, se non è già in cache, lo va a leggere e in più legge
anche un tot di bit successivi. Se vede che effettivamente la CPU poi
richiede anche quelli, via che parte a raffica e legge i dati dalla RAM in
anticipo rispetto alle richieste della CPU. Ora tu immaginati tutti i MB di
cui si diceva sopra: transiteranno in blocchetti di, in media, 10 kb?
Mettiamo che sia così. Bene, il controller della cache totalizza 10.000 hit
prima di totalizzare 1 miss e "cambiare direzione". Percentuale 99,99%. Poi
fa altri 10.000 hit....
Chiaro che è una semplificazione. Ma il fatto è che, pur essendo l'MPEG una
applicazione indubbiamente pesantissima, secondo me la complessità della
struttura dei dati in memoria non è così eccessiva (cioè: i dati sono in
memoria in forma perlopiù abbastanza lineare). Secondo me come cache miss è
molto peggio avere in esecuzione 5 IE + GetRight + ViruScan + ICQ + .....
come ho spesso io, perché ad ogni task switch aggiungo un sacco di cache
miss oltre a quelli propri di ogni singola esecuzione. Anche se, ripeto, me
ne intendo poco di MPEG.
In pratica, hai un cache hit in due casi: quando il dato era già in cache e
quando il dato era in RAM, ma in una posizione "prevedibile" e quindi era
anche già stato precaricato.
La cache è utilissima quando una piccola quantità di codice viene eseguita
in continuazione: allora la CPU si trova continuamente alimentata senza
accessi in RAM. OK. La cache è utile anche quando si accede a dati perlopiù
sequenziali in RAM (secondo me l'MPEG vi potrebbe ricadere); ma il fatto
stesso che i dati siano perlopiù lineari
a) rende poco significativa un'ottimizzazione "leggimi questo in anticipo",
visto che viene già fatto in automatico;
b) limita in parte la velocità della cache legandola a quella della RAM che
deve sputar fuori gli stessi dati nello stesso ordine con cui la cache li
servirà poi alla CPU. Ecco perché dico che la cache si trova a fare da
buffer in entrata e poco più (è il tuo discorso: due ordini di
grandezza....). Del resto, siccome le PC100 hanno banda abbondantemente
sufficiente per l'MPEG (così almeno sembra), il collo di bottiglia è la CPU.
E da lì partivamo, no? Se non sbaglio, dicevo che sembra che il Katmai sarà
più veloce del K6 2 per via delle nuove istruzioni. Non credo che il
prefetch della cache delle 3DNow! (ma mi pare che poi una cosa analoga ci
sia anche nelle KNI) possa competere.
Bye,


 sia anche nelle KNI) possa competere.
Sai chi uscirà contemporaneamente al Katmai? Un certo K7, la "fioritura" 
del 3dnow!, con prefetch più lunghi e su memorie SDRAM-II o Rambus ... :-
)
Pensaci ... :-)
