Newsgroup: it.comp.hardware.cpu
Titolo: skeda 3d

Sono molto indeciso sulla scheda 3dfx da comprare, sapreste consigliarmi??
io ho una mistique 220 e mi hanno detto che con la monster ci sono casini, è
vero?
ciao
Your 
War...@geocities.com
Home: 
http://www.Warlos.home.ml.org
Icq: 4601847
PowWoW: 
War...@pow.it

La monster non e' una scheda particolare l'unica cosa particolare e' il 3dfx
quindi qualunque scheda tu decida di prendere se ha montato il gioiello
Voodoo
non troverai differenza con la monster!
Comunque oggi io comprerei la Maxi ganer 3dfx ( che credo sia distribuita
dalla Ubisoft Italia)
Ciao.


se ti dicessi che non l'ho mai sentita?


Se Vi dicessi che non date neanche il tempo di far nascere un NG che siete
gią OT

 gią OT
Sono d'accordo con Nicola.
Cerchiamo di non far diventare questo NG il mercatino di mb, cpu, schede
usate.
Lancio una provocazione:
Risce CISC, che cosa succedera' in 4 anni?
CXhi se la sente di sparare dei pronostici.
Andrea Troll Meneghini

Scusa, ma     it.comp.hardware.video.3D  a cosa serve?
Anche per le donne nude ci sono NG appositi

allora, chiariamo una cosa,
io non chiesto di vendere ne di comprare niente a nessuno... ma ho solo
fatto una domanda pertinente al NG, quindi si mi  potete spiegare perchè non
avete risposto al  mio problema e perchè avete mandato un messaggio con il
mio oggetto??????
e secondo voi cosa dovremmo fare? dobbiamo parlare di donne nude?

 Anche per le donne nude ci sono NG appositi
Grazie Nick.
Mi vedevo gia' ad iniziare un flame al primo intervento...
Andrea Troll Meneghini

CXhi se la sente di sparare dei pronostici.
Raccolgo la provocazione molto volentieri, vediamo se si puo' fare un discorso
un po' piu' "filosofico" di quelli che si fanno di solito sui ng di ich... 
Secondo me e' difficile capire come staranno le cose... al tempo della nascita
dei risc, i cisc dominavano il mercato (bella forza, c'erano solo loro :) ),
poi ci si e' accorti che per varie ragioni era meglio cambiare direzione.
Che io sappia i difetti del cisc erano all'epoca:
1- il 90% del tempo si eseguivano il 10% delle istruzioni, e quelle piu'
semplici. quindi c'era un notevole spreco di spazio sul die.
2- c'erano molti modi (molte sequenze di istruzioni) per ottenere lo stesso
risultato (per i saputelli: non mi nominate il pumping lemma che ne ho nausea,
grazie :) ), il che non semplificava la vita ai compilatori, quindi o si
ottimizzava bene ma i tempi di compilazione erano... esponenziali, o si
ottimizzava male.
3- per motivi di spazio disponibile, c'erano pochi registri. Il problema di
allocazione delle variabili nei registri e' molto intricato con pochi registri,
poco con molti. Quindi ecco un ulteriore vantaggio per i compilatori nell'usare
risc al posto di cisc.
4- il formato variabile delle istruzioni (avete presente il set del Vax? :) )
complica la fase di fetch.
5- cisc significa molte unita' di esecuzione specializzate, risc poca
specializzazione, quindi piu' standardizzazione, quindi vantaggi economici
nella progettazione e velocita' nel mettere sul mercato il prodotto e quindi un
vantaggio notevole.
spero di aver detto tutte le cose piu' importanti.... a questo punto, per
esemplificare, prendiamo un tipico risc di successo: lo Sparc. Questo ha avuto
un successone all'inizio quando i die erano piccoli, e le sue prestazioni erano
notevoli rispetto a un tipico cisc come gli x86.
Poi pero', con l'ingrandimento della superficie dei chip, le cose sono
cambiate: l'economia di scala ha permesso ai vecchi x86 di investire molto e
quindi di "scalare" le prestazioni verso quelle delle workstations, d'altro
canto ai primi risc sono state aggiunte prima le unita fpu e poi le istruzioni
tipo-DSP (vedi UltraSparc, MIPS R5000).
Il fatto e' quindi che adesso come adesso ci troviamo secondo me in una
situazione in cui non c'e' una fortissima differenza fra cisc e risc, ci sono
"tracce" nella maggiore razionalita' del design e delle caratteristiche e a
volte in un maggior numero di registri, ma la differenza, soprattutto dal punto
di vista prestazionale, sta scemando.
Un'altra osservazione che secondo me e' da fare e' che i cisc ormai non sono
piu' quelli di una volta :), nel senso che basta guardare la tendenza dei vari
ppro, k6, merced... si va verso il risc e il vliw nel "core", e si lasciano gli
aspetti "da cisc" all'interfaccia.
E adesso arriviamo al "sodo": secondo me la strada che si sta percorrendo sara'
quella vincente nel mercato (intendo che ci assesteremo su chips spesso x86
compatibili e anche quando non lo saranno avranno dei set di istruzioni ben
piu' "consistenti" di quelli dei risc "duri e puri" dei primi tempi, magari con
una struttura interna vliw), ma non la piu' ragionevole.
Secondo me un'aspetto piu' interessante sarebbe stato percorrere la strada del
multiprocessor "estremo" piu' che quella dei chips
superpipeline-superscalari-branchprediction-condueDSPcosi'-eduecentomila
miliardiditransistors ottimizzati solo per eseguire programmi sequenziali
eseguiti in timesharing.
Qualche tempo fa ci aveva provato la iNMOS con i suoi transputers, secondo me
erano prodotti interessanti anche se forse un po' troppo "leggerini". Poi
purtroppo la mancata accettazione da parte del mercato ha fatto fallire il
tentativo.
Insomma, per farla breve secondo me invece di andare verso il malefico merced,
si dovrebbe tentare la strada di integrare in un solo chip un intero nodo di
elaborazione(per i piu' tecnici: partizionato in istruction processor, kernel
processor, etc...), con tutto cio' che serve eventualmente includendo anche la
ram. Volete mettere un bel matricione di 128-256 nodi di elaborazione? Un
processore per ogni processo, nessuna commutazione di contesto... e quando si
vuole andare "piu' forte" si aggiungono semplicemente altri nodi. E magari la
struttura interna potrebbe essere di tipo vliw, ma senza le "sofisticazioni"
dei processori di oggi che mi paiono eccessive (l'insorgenza di cosi' tanti
bugs mi pare significativa, da questo punto di vista...).
Forza, io la sproloquiata l'ho fatta, ora sta a voi! (e complimenti a quelli
che hanno avuto la costanza di leggere fino a questo punto... :))) ).
ciao,
gabriele.
--
Gabriele Zugliani - Student at Pisa University (Dept. of Computer Science)
NOTE: the email address in the header is modified; please remove "nzpm".
For Linux OS informations: http//
www.linux.org
 
http://sunsite.unc.edu/LDP

dopo il tuo intervento quasi quasi mi rimangio quello che ho detto finora...

 bugs mi pare significativa, da questo punto di vista...).
Di merced cio' che mi fa piu' paura e' che c'e' di mezzo anche Intel :)
Speriamo che, come forse sara', facciano fare la parte di progettazione
alla HP e la parte di produzione alla Intel.
Per quel che riguarda l'integrazione di piu' processori in un solo chip,
magari con un po' di RAM, e' un idea che e' studiata da tempo (IEEE
Computer di Settembre 1997) ma credo che per un po' non se ne possa
parlare. Il problema maggiore dovrebbe essere nella comunicazione fra
processi e quindi nella gestione della memoria.
Infine nei processori vliw le "sofisticazioni" sono escluse per
definizione :). Tutto viene lasciato al compilatore.
P.S.
Spero che vi siano molti thread di questo tipo nel seguito (forse
finalmente si potra' parlare di qualcosa di tecnico su un gruppo che non
sia della gerarchia comp.* :) ) e che ai caxxoni che postano messaggi
offtopic gli si rompa la tastiera e gli si sgonfi la palla del mouse.
-- 
Andrea Vettori
------------------------
vet...@computer.org
http://www.dei.unipd.it/~vettori
    (italiano)
http://www.geocities.com/ResearchTriangle/9236
   (english)

offtopic gli si rompa la tastiera e gli si sgonfi la palla del mouse.
:)
ciao!


 parlare di queste cose sul serio e' meglio che mi documenti per bene :)))
Vai alla mia pagina web versione inglese (inglese italianizzato, of
course) che uso come indice per i siti piu' interessanti.
Come testo generale, se non lo hai ancora letto, ti consiglio vivamente
"Hennessy Patterson, Computer Architecture, A quantitative approach,
MKP".
P.S.
Se continuamo la discussione, come spero, magari con lo zampino di
qualche altro partecipante, proporrei di cambiare il subject dal
prossimo post.
Bye


Innanzitutto non capisco come mai questa discussione sia nata con un oggetto
così distante dal tema.
Non si poteva fare un'altra lettera?
Comunque noto che nessuno ha ancora pensato al data-flow!!!!!!!!!!!!!!!
E pensare che TUTTE le architetture si stanno lanciando in questa direzione
Noi si sta ancora parlando di architetture superscalari, di doppia e tripla
pipeline, di branch prediction (che comunque è sempre stata solo un
palliativo), mentre in realtà le CPU si stanno spostando in direzione del
data-flow.
Quando una CPU esegue istruzioni "a caso" tra quelle che sono disponibili
per l'esecuzione e poi le riordina per mantenere il flusso di output, voi
come lo chiamate? è forse anche questo un branch predictor? A me sembra più
un "inseguire" il flusso di dati più che delle istruzioni, poi il nome
datelo voi.
Del resto con delle CPU che girano 10 o 15 volte più veloci della RAM, non
si può certo pensare di inseguire la linearità del codice. Cache a parte,
forse la scelta migliore è proprio quella di inseguire i flussi di dati (e
di istruzioni che li generano) e pertanto investire sulla logica di
controllo.
Datemi un parere.

Se continuamo la discussione, come spero, magari con lo zampino di
Te la sei cercata... :) 
Anch'io vorrei invitare tutti gli interessati a partecipare, non importa se si
dicono corbellerie (io ne sparo una dietro l'altra, ma e' meglio dire qualche
ca??ata e essere corretti che tenersi dei dubbi o delle curiosita'). Forza,
fatevi coraggio! :)


Datemi un parere.
Sono pienamente daccordo....
ciao!


 fra questi problemi e' quelli che sorgono in un multiprocessor convenzionale?
Quasi nulla. In un CMP tutto e' in un solo chip quindi i ritardi di
accesso alle memorie sono ridotti rispetto a quelli di un sistema SMT.
In un CMP i singoli nodi dovrebbero essere abbastanza piu' semplici di
un processore "odierno" e quindi anche la suddivisione dei task che
vanno a finire su un singolo processore dovrebbe essere diversa.


 controllo.
Questo e' certo. La discussione di questo periodo e' la seguente: "E'
meglio una logica hardware, quindi dinamica ma che costringe il
processore ad una complessita' maggiore e quindi ad un clock ridotto o
una logica software, nel compilatore, statica ma adatta a processori
semplificati e quindi con clock elevato ?"
Il merced e' un processore del secondo tipo (vedere BYTE dicembre 1997). 


vero?
Assolutamente NO, anzi č quella che va meglio in assoluto, la prima ad
uscire col chipset 3Dfx. Cmq ti consiglierei la MAXI 3D!
BYE


: wrote:
: Anch'io vorrei invitare tutti gli interessati a partecipare, non importa se si
: dicono corbellerie (io ne sparo una dietro l'altra, ma e' meglio dire qualche
: ca??ata e essere corretti che tenersi dei dubbi o delle curiosita'). Forza,
: fatevi coraggio! :)
Personalmente mi piacerebbe un casino partecipare, perché vorrebbe dire che ne
so davvero tanto... In ogni caso, pur avendo capito si e no 1ppm di quello che
avete detto, vi seguo con assiduità, tanto per leggere (anche se poi non ci
capisco) cosa diavolo succede dentro il mio povero 166MMX (meno male che ho 
abbastanza dimestichezza da mandarlo a 210MHz!)...
--
Saluti, Kap.
*********************************************************
E' in costruzione, ma ci siamo... l'indirizzo nuovo è:
http://pclib1.cedi.unipr.it/kap/Ihu/IHUfacce.html
-----------------
http://pclib1.cedi.unipr.it/kap/Gabbiano/gabbiano.html
-----------------
P.S.: Non mandate mail tra Venerdì alle 18.00 e Lunedì
		     alle 10.00: il mail-server è spento.
*********************************************************

 gabriele.
Bene, ho iniziato questo thread, anzi, l'ho dirottato, un mese fa circa
e ho seguito con grande attenzione (e notevole sforzo, devo dire) i
vostri interventi.
Mi ha particolarmente interessato l'accenno ai multiprocessori.
Spero di non sbragare troppo affermando che il grosso problema della
soluzione MP e' sicuramente il software.
Mi sembra concettualmente complesso (ma spero di potermi sbagliare)
scrivere software che possa 
- riconoscere q7unati processori sono attivi nel sistema
- dividere il programma in task paralleli (se fosse una gestione
sequenziale si tratterebbe al piu' di un velocissimo monoprocessore)
- far elaborare ai diversi processori il comando indirizzato
- riassemblare i dati risultanti in ram.
I colli di bottiglia (permettetemi di usare un linguaggio non tecnico,
anche perche' quello tecnico non lo conosco) sarebbero a mio parere il
pipelining, la gestione della memoria, l'ottimizzazione del
parallelismo.
Invece su una struttura fissa (ad esempio una gestione video in cui il
numero dei byte utilizzati e' fisso) un tipo di gestione di questo
genere sarebbe piu' semplice.
Forse e' questo (assieme alla esponenziale crescita di potenza dei
'normali' processori cisc e risc.
Sono anche d'accordo che oggi una divisione netta tra i due tipi non
esiste piu' e che le architetture si stiano in qualche modo
contaminando.
Spero di non aver vaneggiato troppo e vi ringrazio per le informazioni
passate. Continuate cosi'. 
Andrea

contaminando.
...peccato... io ero felicissimo quando vedevo che gli intel arrancavano
(quando erano cisc veri) e gli sparc volavano alla velocita' di decine
di MIPS... :) all'epoca pareva fantascenza....
ok, ho finito... andrea, ora tocca a te, comincia a correggere!!! ;)
ciao,
gabriele.
--
Gabriele Zugliani - Student at Pisa University (Dept. of Computer Science)
NOTE: the email address in the header is modified; please remove "nzpm".
Linux infos: 
http://www.linux.org
 
http://sunsite.unc.edu/LDP

 contaminando.
Il CISC, come concetto, e' morto. Esiste solo per compatibilita'.



Mi sei sembrato sufficientemente lucido... :)
