View Full Version : Athlon64 vs Pentium4...
joesabba
17-04-2003, 16:40
da un articolo su lithium:
"Per precisione si deve aggiungere che a Santa Clara un pensiero all'integrazione dei 64bit nel mercato consumer l'hanno fatto. Il progetto si chiama Yamhill, avrebbe dovuto ricoprire il ruolo della serie Hammer (Athlon64 per la fascia consumer, Opteron per quella business) attraverso l'uso di istruzioni chiamate x86-64, lasciando così a Itanium un futuro incerto. Stando alle dichiarazioni ufficiali di Intel Yamhill è un progetto chiuso, ma fino a poco tempo fa qualcuno dubitava ancora dell'integrazione di x86-64 in Prescott. Ultimissime notizie tuttavia confermerebbero l'esclusione di x86-64 da Prescott, il cui lancio è previsto per il Q4 del 2003. Con Athlon64 in produzione entro la seconda metà del 2003, il primo round dei 64bit sul desktop si chiuderebbe a favore di AMD, sempre a patto che Athlon64 riceva un adeguato supporto dagli sviluppatori. In quel caso Intel dovrebbe ripescare, salvo repentini e non impossibili cambiamenti nella roadmap, Yamhill, e affrettarsi a integrarne le funzionalità in Prescott. Ad oggi si può soltanto concludere che la scelta di Intel appare più attendista, ma non irreversibile.
La parola sta dunque agli sviluppatori: se troveranno vantaggioso seguire la strada indicata da AMD, per Intel si tratterà di rettificare i propri progetti e senz'altro di accusare qualche ritardo: l'attendismo ha le sue controindicazioni. Se i 64bit di AMD saranno poco seguiti, la casa di Sunnyvale sarà probabilmente scavalcata nel mercato consumer, poichè la reale forza dell'Athlon64 non sta nella sua pur migliorata capacità di esecuzione del codice a 32bit (tant'è che AMD ha posticipato il lancio da aprile a settembre 2003 per aspettare il rilascio di Windows 64). Senza supporto degli sviluppatori AMD resterà a competere con Intel in un mercato, quello business, tradizionalmente più duro da scalare e favorevole all'avversario. Per rigore va specificato che, per quanto le prospettive di sviluppo di AthlonXP - Barton siano oggi piuttosto deludenti, il supporto all'FSb a 400mhz potrebbe garantirgli altri mesi di presenza sul mercato."
Bi8sogna vedere appena esce il primo Athlon64 come se la vedra' con l'ultimo degli Athlon XP in termini di prestazioni con le normali applicazioni.
E il prezzo di vendita!
Poi si apre anche il discorso palladium :(
Bi8sogna vedere appena esce il primo Athlon64 come se la vedra' con l'ultimo degli Athlon XP in termini di prestazioni con le normali applicazioni.
E il prezzo di vendita!
Poi si apre anche il discorso palladium :(
Athlon64 è a tutti gli effetti anche un ottimo processore a 32 bit... Usandolo in SO a 32 bit avresti solo vantaggi...
Come ho detto già molte volte...la principale innovazione di Hammer non sono i 64 bit, ma il controller della memoria integrato e il bus HyperTransport...
AMD ha posticipato il lancio probabilmente perchè ha visto che Thoro e Barton reggevano benissimo il confronto con Intel...
joesabba
17-04-2003, 20:46
in effetti io comincio a vedere un raggio di sole per AMD... uscirà in autunno win a 64 bit e se piano piano si comincia a programmare per i 64... ma questo è tutto da vedere, e forse solo per sistemi server. O sbaglio?
win a 64 bit esiste già ed è stato sviluppato per le cpu che hanno architettura IA64.....chi la produce?
inoltre rammendo a tutti la storia del 80386 che aveva una singola pipeline a 32 bit....che programmi ci giravano?
ricordo anche che noi avanzatissimi utilizzatori di pc usiamo ora win xp che altro non è che una versione "ammansita" di win nt.....in particolare il kernel e le routine primarie sono le medesime......ricordo inoltre che il suddetto s.o. è stato sviluppato prima del 1993 e poi riveduto per le varie versioni....inoltre noi utilizziamo cpu a 32 bit dal 92 mentre la diffusione massiccia di un s.o. realmente a 32 avviene solo ora........
rammendo inoltre che il codice a 64 bit non darà benefici in termini di velocità o di "funzioni" innovative ma permetterà agli sviluppatori di non avere più il limite odierno all'indirizzamento del codice del programma stesso........
ho acceso la miccia?? bye!
mi sono dimenticato anche di ricordare che attualmente il controller memoria integrato nella fantasmagorica cpu amd e per mem in configurazione dual channel con mem pc2100.....che è già superato ancor prima di uscire dai controller esterni per gli athlon xp.........vedi nforce.....cmq anche se userà pc 2100 si avranno cmq prestazioni superiori a all'uso di controller esterni per via di una maggiore "sincronizzazione" dei dati in lettura e scrittura nella ram.......
bye
joesabba
17-04-2003, 21:00
Originally posted by "gigggi"
win a 64 bit esiste già ed è stato sviluppato per le cpu che hanno architettura IA64.....chi la produce?
inoltre rammendo a tutti la storia del 80386 che aveva una singola pipeline a 32 bit....che programmi ci giravano?
ricordo anche che noi avanzatissimi utilizzatori di pc usiamo ora win xp che altro non è che una versione "ammansita" di win nt.....in particolare il kernel e le routine primarie sono le medesime......ricordo inoltre che il suddetto s.o. è stato sviluppato prima del 1993 e poi riveduto per le varie versioni....inoltre noi utilizziamo cpu a 32 bit dal 92 mentre la diffusione massiccia di un s.o. realmente a 32 avviene solo ora........
rammendo inoltre che il codice a 64 bit non darà benefici in termini di velocità o di "funzioni" innovative ma permetterà agli sviluppatori di non avere più il limite odierno all'indirizzamento del codice del programma stesso........
ho acceso la miccia?? bye!
in linea di massima credo ke tu abbia fatto un buon ragionamento... ma cosa rammendi? una calza bucata? :D :sofico:
joe ti rammendo che rivoglio il mio c1!!! quando lo strapiantiamo? c'è luna nuova?
Originally posted by "gigggi"
mi sono dimenticato anche di ricordare che attualmente il controller memoria integrato nella fantasmagorica cpu amd e per mem in configurazione dual channel con mem pc2100.....che è già superato ancor prima di uscire dai controller esterni per gli athlon xp.........vedi nforce.....cmq anche se userà pc 2100 si avranno cmq prestazioni superiori a all'uso di controller esterni per via di una maggiore "sincronizzazione" dei dati in lettura e scrittura nella ram.......
Il controller di Opteron è un dual channel PC3200... Quello di Athlon64 dovrebbe essere un single channel PC3200...
Originally posted by "gigggi"
rammendo inoltre che il codice a 64 bit non darà benefici in termini di velocità o di "funzioni" innovative ma permetterà agli sviluppatori di non avere più il limite odierno all'indirizzamento del codice del programma stesso........
Non è solo questo...
Tutti gli algoritmi che attualmente utilizzano interi a 64 bit, simulandoli con due interi a 32 bit, otterranno quasi un raddoppio delle prestazioni sulla manipolazione di questi interi...
Un altro vantaggio di Opteron è che anche il codice a 32 bit solamente ricompilato (anche senza usare istruzioni a 64 bit) potrà essere un 5-10% più veloce grazie all'uso degli ulteriori 8 registri general purpose presenti nella ALU che permettono di ridurre l'uso dello stack...
Inoltre ci dovrebbe essere un aumento delle entry del Traslation Lookaside Buffer che è una memoria cache associativa ad insiemi che permette di individuare dall'indirizzo virtuale l'indirizzo fisico corrispondente senza dover effettuare due accessi alla memoria per individuare all'interno delle tabelle di pagina la pagina che contiene l'indirizzo a cui vogliamo accedere... Anche se porta ad un incremento di prestazioni minimo...
lombardp
18-04-2003, 08:25
Originally posted by "cionci"
Athlon64 è a tutti gli effetti anche un ottimo processore a 32 bit... Usandolo in SO a 32 bit avresti solo vantaggi...
Come ho detto già molte volte...la principale innovazione di Hammer non sono i 64 bit, ma il controller della memoria integrato e il bus HyperTransport...
C'è anche un altra cosa, non è una innovazione, ma al tempo stesso è una novità assoluta per AMD:
il supporto al codice SSE2 !!! :eek: :eek: :eek:
Dove il P4 surclassava Athlon a causa del codice SSE2 ottimizzato (che gli XP non gestiscono), Athlon64 farà un vero e proprio balzo prestazionale.
Originally posted by "cionci"
Athlon64 è a tutti gli effetti anche un ottimo processore a 32 bit... Usandolo in SO a 32 bit avresti solo vantaggi...
Come ho detto già molte volte...la principale innovazione di Hammer non sono i 64 bit, ma il controller della memoria integrato e il bus HyperTransport...
AMD ha posticipato il lancio probabilmente perchè ha visto che Thoro e Barton reggevano benissimo il confronto con Intel...
Davvero mi fai vedere pure ma e i bench dell'Athlon 64! :D :D
Cmq prima di azzardare qualsiasi previsione io aspetterei il 22 per vedere l'opteron (anche se più di tanto non ci frega) e settembre per l'A64.
la mia modesta opinione a "pelle" è che l'A64 reggerà abbastanza bene in confronto con il Nortwood-800, come è già stato detto la più grande innovazione sono le SSE2. Il Bus integrato la vedo come un arma a doppio taglio, ok, permette di annullare le latenze, ma di contro è limitato dalle scelte di AMD (vedi un single Channel DDR400 o 333 che oramai è sorpassato), non permette di avvantagiarsi delle migliorie dei produttori di chipset (Via, SIS e nVidia) e soprattutto renderà le sk madri molto poco longeve, a ogni cambio di Mem Controller corrisponde cambio di socket! :eek: Se già si vocifera il supporto DDR2 per il successore dell'A64, è quasi sicuro il cambio di soket. ;)
Dall'altra parte abbiamo Intel, che mi pare abbia posizionato tutte le sue pedine in modo eccellente. A maggio tira fuori una nuova piattaforma (875/865) gli da 4 mesi di rodaggio così da far trovare al Prescott un base solida. Il prescott stesso sembra sulla carta un vero mostro. A fine 2004 si cambia tutto, PCI express, Socket T, uso massiccio del S-ATA, bus a 1Ghz e il tejas (+ una versione Soket T del Prescott). Se AMD avrà successo con l'A64, la tecnologia Yawmill sarà implementata nel Tejas. ;)
cmq anche se la cpu amd 64 porterà notevoli benefici e novità architetturali ricordo a tutti che gli sviluppatori non sono tutti pronti a riscrivere il codice......tantomeno il codice macchina o il kernel degli s.o.......quindi al momento anche se il chip avrà funzioni mirabolanti con interi mezzi e trequarti di interi riscritti come cinqueottavidimezziinteri tutto questo non verrà assolutamente sfruttato......così come le sse2 che non vengono ancora massicciamente utilizzate...........ricordatevi che finora sono stati i produttori hardware a correre per accelerare i software esistenti...e non il contrario come dovrebbe essere sempre stato....purtroppo!!
bye
Originally posted by "Betha23"
Davvero mi fai vedere pure ma e i bench dell'Athlon 64! :D :D
Io parlo di quello che è sulla carta... Non ha nessun svantaggio sull'esecuzione delle istruzioni a 32 bit...
Unità di branch prediction migliorata, latenza della moltiplicazione a 32 bit diminuita di un ciclo rispetto all'Athlon, latenza della memoria diminuita...
Usandolo in un sistema a 32 bit è come usare un Athlon XP...dopotutto è derivato da quello...
Originally posted by "gigggi"
cmq anche se la cpu amd 64 porterà notevoli benefici e novità architetturali ricordo a tutti che gli sviluppatori non sono tutti pronti a riscrivere il codice......tantomeno il codice macchina o il kernel degli s.o.......
Sì ? Allora andiamolo a dire a chi ha già sviluppato il kernel di Linux per x86-64 che mi sa che non l'hanno capito ;)
M$ ha già annunciato il suporto a x86-64... Quale codice a basso livello c'è ancora ?!?!?!? Tutto il codice assembler è retrocompatibile...e per tutto il resto basta una ricompilazione !!!
joesabba
18-04-2003, 12:08
Originally posted by "cionci"
Sì ? Allora andiamolo a dire a chi ha già sviluppato il kernel di Linux per x86-64 che mi sa che non l'hanno capito ;)
M$ ha già annunciato il suporto a x86-64... Quale codice a basso livello c'è ancora ?!?!?!? Tutto il codice assembler è retrocompatibile...e per tutto il resto basta una ricompilazione !!!
bella M$ questa mi piace come abbreviazione!!
quindi basterà ricompilare i programmi a 32 e passarli a 64, non saranno ottimizzati ma ki se ne frega, sarà probabilmente solo un periodo di transizione... secondo me amd ha puntato bene sui 64 bit. E a pensarci bene forse intel ha deciso di non supportarli sperando di fare abortire il progetto di amd... che invece da parte sua ora supporta anche le SSE2 (altra bella mossa)
joesabba
18-04-2003, 12:13
Originally posted by "gigggi"
.....quindi al momento anche se il chip avrà funzioni mirabolanti con interi mezzi e trequarti di interi riscritti come cinqueottavidimezziinteri tutto questo non verrà assolutamente sfruttato
hai detto "al momento", ma tra un anno magari già si comincerà a vedere qualche applicazione a 64 bit
Originally posted by "joesabba"
bella M$ questa mi piace come abbreviazione!!
quindi basterà ricompilare i programmi a 32 e passarli a 64, non saranno ottimizzati ma ki se ne frega, sarà probabilmente solo un periodo di transizione... secondo me amd ha puntato bene sui 64 bit. E a pensarci bene forse intel ha deciso di non supportarli sperando di fare abortire il progetto di amd... che invece da parte sua ora supporta anche le SSE2 (altra bella mossa)
Se AMD supporta le SSE2 è perchè Intel gliele ha "gentilmente" concesse! :D ;)
Originally posted by "joesabba"
quindi basterà ricompilare i programmi a 32 e passarli a 64, non saranno ottimizzati ma ki se ne frega
Ricompilando si ottimizzano per x86-64 (la dimensione di default degli interi rimane comunque 32 bit, ma nel caso di utilizzo degli interi a 64 bit si sfruttono direttamente le istruzioni aggiuntive di x86-64)... I programmi preesistenti non è necessario ricompilarli...certo non sfrutteranno gli 8 registri aggiuntivi (cosa che avverrebbe nel caso di ricompilazione), ma comunque potranno trarre beneficio da tutte le altro feature dell'Hammer...
joesabba
18-04-2003, 14:49
uhm ma gli interi a 64 bit sono numeri astronomici... forse ne trarranno vantaggio solo applicazioni per i calcoli della fisica...
maiks900
18-04-2003, 16:00
Originally posted by "gigggi"
joe ti rammendo che rivoglio il mio c1!!! quando lo strapiantiamo? c'è luna nuova?
OT :D :D :D Vengo anch'io :D
/OT
Originally posted by "joesabba"
uhm ma gli interi a 64 bit sono numeri astronomici... forse ne trarranno vantaggio solo applicazioni per i calcoli della fisica...
Prinicipalmente database e programmi di criptazione/decriptazione...
joesabba
18-04-2003, 21:18
non molto... :rolleyes: beh meglio ke niente
ragazzi se andiamo a vedere in dettaglio a che cosa deve ricorrere una povera cpu per poter far uscire un risultato da una pipeline scopriremo che TUTTO il codice odierno è scritto da schifo!! e non mi dite che una ricompilazione risolverebbe tutto!! il fatto stesso che le cpu di oggi (ma anche qualcuna di ieri!!) abbiano al proprio interno una unità di branch prediction significa che devono "prevedere" il codice che entrerà nella cpu dopo quello in esecuzione......ma vi rendete conto?
R.I.S.C. rulez! solo con codice scritto ad hoc si avrà un certo miglioramento ed un taglio con tutti i bug software del passato! ma a voi xp sempra un s.o. stabile e senza bachi? ma vi ricordate win nt 4.0?
dimenticanza!! mamma ms che ha già annuciato il supporto al codice a 64 bit è stata anche quella che ha sviluppato il codice a 32 bit da far funziare sui pentium 1 .........chi ha orecchie per intendere intenda.......il suddetto codice si chiamava win 95 (una bomba!!) e win 98 (veramente eccezionale e molto stabile !! ricordo a tutti che erano e sono software a 32 come diceva mamma ms infatti dopo insistenti richieste anche in casa ms hanno ammesso (dopo averne venduto trilioni di copie però...) che in realtà erano per circa l'85% scritti a 16 bit.....in parole povere il buon vecchio dos utilizzato in dpmi quando funziava a 32 bit!!
Originally posted by "gigggi"
il fatto stesso che le cpu di oggi (ma anche qualcuna di ieri!!) abbiano al proprio interno una unità di branch prediction significa che devono "prevedere" il codice che entrerà nella cpu dopo quello in esecuzione......ma vi rendete conto?
Cerchiamo di non fare fanta-informatica... Non ti fai una grande pubblicità con queste affermazioni scorrette ;) L'unità di branch prediction non serve assolutamente a prevedere il codice che entrerà nella CPU :) Anche con il codice scritto meglio al mondo la CPU ha bisogno dell'unità di branch prediction...
Alcune istruzioni del linguaggio macchina sono istruzioni di salto condizionato... L'istruzione dopo il salto può essere quella successiva al salto o quella a cui si riferisce il salto (in caso di verifica della condizione)...quindi l'istruzione (e quelle successive) che deve essere caricata in pipeline dipende dalla condizione che si può determinare solo dopo la fase di esecuzione dell'istruzione di salto...
In questo modo la pipeline si arresterebbe fino alla determinazione della condizione di salto....
L'unità di branch prediciton secondo un particolare algoritmo decide (predizione) quale dei due rami (branch) di esecuzione caricare in pipeline...
Al momento della fase di esecuzione dell'istruzione di salto...se la predizione ha scelto bene abbiamo guadagnato una marea di cicli di esecuzione...se la predizione è errata (misprediction) viene fatto un flush della pipeline (si svuata la pipeline) e si ricomincia caricando l'istruzione giusta in pipeline (per produrre il primo risultato ci vogliano tanti cicli di clock quanti sono gli stadi delal pipeline)...
E' da notare che in caso di misprediction il risultato è lo stesso che si avrebbe in assenza di branch prediction...
Originally posted by "gigggi"
R.I.S.C. rulez!
Tra un x86 di oggi ed un RISC c'è molta poca differenza...e sta tutta nell'unità di decodifica... Sia P4 che Athlon traformano le istruzioni CISC in istruzioni a lunghezza fissa...caratteristica determinante delle ISA RISC...
Originally posted by "gigggi"
ma a voi xp sempra un s.o. stabile e senza bachi? ma vi ricordate win nt 4.0?
Win XP non molto e in questi giorni ne ho avuta la conferma... 3 registri di sistema partiti in una settimana su 3 macchine diverse...
Comunque Windows 2000 è ottimo....
alura..........POTA: branch prediction unit ovvero unità di predizione di salto incondizionato...ovvero il processore elabora e ad un certo punto si ritrova a dover scaricare la pipeline perchè gli serve un "risultato" che nel codice eseguito viene dopo a quello che stava elaborando......nel caso del p4 la pipeline è di 20 stadi se non ricordo male......quindi pensate ai cicli di clock persi per fare ciò......considerate poi che questo avviene normalmente milioni di volte....se non miliardi....
CISC ovvero complex instruction set computing.......il codice macchina ha una serie incredibile di istruzioni molto complesse che la cpu (quelle di oggi...) deve decodificare ridurre in istruzioni più semplici (ovvero le cosiddette simil-risc ma che non centrano nulla con le vere risc!!) dopodichè la cpu assegna un "numero" ad ogni porzione di codice generato e le invia alle varie sezioni di elaborazione.....a seconda che siano istruzioni floating point...sse....sse2...mmx....per interi ect. ect. poi vengono effettivamente elaborate ed alla fine viene "ricomposto" il risultato in uscita ed inviato alla ram.....mentre decompila o scompone e ricompone la signola istruzione non avviene una vera e propria elaborazione utile ai fini del programma in esecuzione ma è solo una perdita di tempo e cicli di clock........se poi intervengono dei "salti" allora siamo a posto......e questo è il modo di lavorare delle cpu odierne...
POTA GNARI......RISC reduced instruction set computing ovvero un sistema di elaborazione con un set di istruzioni ridotte all'osso non ci sono branch prediction perchè il codice è praticamente scritto in base alla cpu su cui dovrà rullare non ci sono salti incondizionati non ci sono decompilazioni e ricompilazioni e nel caso di cpu con molte pipeline (praticamente tutte ormai...) siamo tranquilli che ogni pipeline darà il suo bel risultato in uscita ad ogni ciclo di clock!! solo recentemente poi sono state incluse nelle cpu le unità di floating poin in quanto prima venivano eseguite solo operazioni per interi.......non pensiate che le cpu risc per il fatto che sono più semplici siano meno potenti! sono sempre state dei mostri è solo che in ambito pc il cisc ha sempre dominato!! e questo è il vero risc...
io mi spiego sempre in parole chiare e semplici così può capire chiunque...se volete documentarvi in merito ci sono diversi articoli (sempre che siano online...) sù lithium
ecco a voi la fantainformatica!! ciao a tutti
dimenticavo se il codice macchina è scritto apposta per una cpu la stesse deve avere una unità di branch prediction?????? ma che dici!!
io ovviamente mi stavo spiegando in modo semplice....la branch prediction allora che cosa fà nella cpu?
ti faccio un esempio.....pota......le cpu pentium 1 integravano un primo abbozzo di unità di branch....mentre il power pc 604 non l'aveva...il pentium aveva 2 pipeline mentre il power 4.....il pentium aveva il suo daffare con i salti mentre il power dava i suoi bei 4 risultati per ciclo di clock immancabilmente.....qual'è l'architettura più efficente?
Confermi quanto detto da cionci , la presenza di una pipeline implica la presenza di una branch prediction unit.
Questo e' dovuto al fatto che la pipeline introduce una latenza di esecuzione e nel caso di salti condizionati la condizione non sempre e' disponibile al momento dell' istruzione di JUMP.
Ovviamente si puo' cercare di ottimizzare il codice inserendo delle istruzioni tra il calcolo della condizione e l'esecuzione del salto
codice non ottimizzato
z=a+b
x=c+d
y=e+f
If x>y then
codice ottimizzato
x=c+d
y=e+f
z=a+b
If x>y then
in pratica si mettono delle istruzioni di riempimento tra il calcolo della condizione e l'esecuzione del salto
Originally posted by "Athlon"
Confermi quanto detto da cionci , la presenza di una pipeline implica la presenza di una branch prediction unit.
Questo e' dovuto al fatto che la pipeline introduce una latenza di esecuzione e nel caso di salti condizionati la condizione non sempre e' disponibile al momento dell' istruzione di JUMP.
Ovviamente si puo' cercare di ottimizzare il codice inserendo delle istruzioni tra il calcolo della condizione e l'esecuzione del salto
codice non ottimizzato
z=a+b
x=c+d
y=e+f
If x>y then
codice ottimizzato
x=c+d
y=e+f
z=a+b
If x>y then
in pratica si mettono delle istruzioni di riempimento tra il calcolo della condizione e l'esecuzione del salto
Mi dispiace contraddirti Athlon, non sono espertissimo per quanto riguarda la computazione dei processori odierni, ma sulla "storia informatica" qualcosa ricordo. La PRIMA branch prediction mai esistita è stata integrata sul Pentium1 (o P5). La prima struttura a pipeline risale al 386 che aveva un unica pipeline a 4 stadi. Successivamente allungata nel 486 (5 stadi). Il Pentium aveva una pipeline completa (5 stati) e una integrativa (stiamo sempre parlando di ALU), in pratica la seconda non poteva eseguire determinate operazioni.
Sulla BPU (Branch Prediction Unit) posso dire solo quello che io ho sempre saputo. Nasce con il P5, consiste in dei registri dove vengono annotati i salti effettuati dal codice, la BPU prima di mandare in esecuzione il codice controlla questi registri, se trova un probabile salto agisce di conseguenza, la BPU è utile soprattutto per parallelizzare i calcoli su più pipeline.
X Cionci: "L'unità di branch prediciton secondo un particolare algoritmo decide (predizione) quale dei due rami (branch) di esecuzione caricare in pipeline... " okkio, hai fatto un errore madornale, un processore NON DECIDE MAI NULLA! Sembra una cretinata ma è un punto fondamentale per capire come "pensa" un procesore. ;)
cazzo mi ero perso sto 3d!
cmq a grandi linne la penso come cionci ;)
la bpu serve se hai una cpu con un pipe, in ogni caso
se poi il codice è straottimizzato l'utilità della bpu vine meno, ma un codice perfetto non c'è quindi è vero che la bpu verrà usata meno su codice ottimizzato, ma verrà usato.
i vantaggi dell a64 dove stanno
controller ddr400 single channel integrato
non so se sia come un dual su chipset ma non è molto lontano( vedremo le differenze opteron a64)
cambiare controlle vuol dire cambiare socket? non lo so
cmq resta il fatto che qualora sia necessario si puà sempre disabilitatare il controller integrato e usare il controller su chipest (se il chipset lo ha)
penso che quando uscirà la ddr 533 ad esempio esisteranno chipset con un dual ddr 533 ad esempio, certo si perde un vantaggio(latenza) ma non si deve cambiare cpu.
altro vantaggio in ordine sse2
bus a 800mhz
poi ottimizzazioni del core
poi l2 duplicata
infine i 54bit, che sono quelli che porteranno un minore apporto di prestazioni per me vuoi perchè il loro utilizzo è limitato, vuoi per il programmatori.
cmq a parità di frequenza un a64 ed un xp sono ben distanti e questo fa ben sperare
Originally posted by "checo"
cmq a parità di frequenza un a64 ed un xp sono ben distanti e questo fa ben sperare
Vorrei sperare! L'hammer è un Athlon rivisitato....... un po come fu il Pentium2 per il PentiumPro ........... beh forse un po di più! :D
Originally posted by "Betha23"
X Cionci: "L'unità di branch prediciton secondo un particolare algoritmo decide (predizione) quale dei due rami (branch) di esecuzione caricare in pipeline... " okkio, hai fatto un errore madornale, un processore NON DECIDE MAI NULLA! Sembra una cretinata ma è un punto fondamentale per capire come "pensa" un procesore. ;)
E' l'algoritmo che decide ;)
Originally posted by "checo"
se poi il codice è straottimizzato l'utilità della bpu vine meno, ma un codice perfetto non c'è quindi è vero che la bpu verrà usata meno su codice ottimizzato, ma verrà usato.
No...in ogni caso anche nel caso di cidice perfetto ogni volta che c'è un salto condizionato entra in esecuzione la BPU...
Pensa ad un for:
for(i=0; i<10; i++)
{
...
}
Portato in assembler:
movl $0, i
inFor:
cmpl i, $10
je fineFor
.... #esecuzione del corpo del for
incl i
jmp iniFor
fineFor:
La bpu probabilmente per 10 volte dopo la jump condizionata (salta se i è uguale a 10) caricherà il corpo del for...e di conseguenza non si avrà uno stallo della pipeline e non verrà sprecato nemmeno un ciclo di clock...
All'undicesima volta per coerenza con le volte precedenti continuerà ad operare nel solito modo e caricherà il corpo del for in pipeline... Questa volta però ha sbagliato e si avrà uno stallo della pipeline...di conseguenza un flush e lo spreco di tot cicli di clock (solitamente n-1 o n-2 rispetto al numero di stadi della pipeline visto che l'esecuzione delle jump condizionate potrebbe venire anticipata in attesa della fine dell'istruzione precedente)...
Quindi il codice perfetto sarebbe quello in cui non ci sono salti condizionati... Cosa alquanto improbabile...
Originally posted by "checo"
cambiare controlle vuol dire cambiare socket? non lo so
Non è detto... Un solo aumento di frequenza non comporterà un cambiamente del socket...
Un cambio del tipo di memorie potrebbe portarlo... Non so se questo avverrà anche per le DDR-II...
[/quote]
Originally posted by "cionci"
E' l'algoritmo che decide ;)
Ma ti piace proprio tanto la parola "decide" ?? :D
Ok fraternizzare con la macchina ma attribuirgli capacità umanoidi........... :rolleyes:
Originally posted by "gigggi"
alura..........POTA: branch prediction unit ovvero unità di predizione di salto incondizionato...ovvero il processore elabora e ad un certo punto si ritrova a dover scaricare la pipeline perchè gli serve un "risultato" che nel codice eseguito viene dopo a quello che stava elaborando......
Direi che non è proprio così...
Originally posted by "gigggi"
CISC ovvero complex instruction set computing.......il codice macchina ha una serie incredibile di istruzioni molto complesse che la cpu (quelle di oggi...) deve decodificare ridurre in istruzioni più semplici (ovvero le cosiddette simil-risc ma che non centrano nulla con le vere risc!!) dopodichè la cpu assegna un "numero" ad ogni porzione di codice generato e le invia alle varie sezioni di elaborazione.....a seconda che siano istruzioni floating point...sse....sse2...mmx....per interi ect. ect. poi vengono effettivamente elaborate ed alla fine viene "ricomposto" il risultato in uscita ed inviato alla ram.....mentre decompila o scompone e ricompone la signola istruzione non avviene una vera e propria elaborazione utile ai fini del programma in esecuzione ma è solo una perdita di tempo e cicli di clock........
Attualmente le CPU x86 hanno tutte le caratteristiche storiche delle CPU RISC... Istruzioni interne a lunghezza fissa...out-of-order execution...ed altre che ora non mi vengono in mente...
L'unità di decodifica occupa circa il 30% della superficie necessaria per le unità di esecuzione... Chiaramente la trasformazione da istruzioni a lunghezza variabile a istruzioni a lunghezza fissa è uno spreco di clicli di clock, ma in ogni caso l'unità di decodifica occupa fra 1 e 4 stage della pipeline di conseguenza lo spreco effettivo si ha solamente nel caso di stallo della pipeline mentre a regime non si sente visto che comunque queste operazioni vengono svolte in parallelo alle altre della pipeline...
Non capistoc osa tu intenda per "ricomporre" il risultato...
Originally posted by "gigggi"
POTA GNARI......RISC reduced instruction set computing ovvero un sistema di elaborazione con un set di istruzioni ridotte all'osso non ci sono branch prediction perchè il codice è praticamente scritto in base alla cpu su cui dovrà rullare non ci sono salti incondizionati non ci sono decompilazioni e ricompilazioni e nel caso di cpu con molte pipeline (praticamente tutte ormai...) siamo tranquilli che ogni pipeline darà il suo bel risultato in uscita ad ogni ciclo di clock!!
Qui confermi la mia tesi... I salti condizionati ci saranno sempre... I MIPS (soricamente il RISC per eccellenza) hanno i salti condizionati...
Esisteno alternative alla BPU...ma comportano comunque una perdita di cicli di clock...
Originally posted by "gigggi"
non pensiate che le cpu risc per il fatto che sono più semplici siano meno potenti! sono sempre state dei mostri è solo che in ambito pc il cisc ha sempre dominato!! e questo è il vero risc...
Ti dico soltanto che AMD con i K6 affermava escplicitamente nella documentazione che traduceva le istruzioni x86 in istruzioni RISC;)
Originally posted by "gigggi"
io mi spiego sempre in parole chiare e semplici così può capire chiunque...se volete documentarvi in merito ci sono diversi articoli (sempre che siano online...) sù lithium
Infatti non si capiva...
Originally posted by "gigggi"
ecco a voi la fantainformatica!! ciao a tutti
Io non ti volevo offendere...è che quando uno si espone in questa maniera su un forum pubblico deve essere sicuro di quello che dice... Sia quello che hai detto prima che quello che hai detto ora sulla branch prediction unit è errato...
Originally posted by "gigggi"
dimenticavo se il codice macchina è scritto apposta per una cpu la stesse deve avere una unità di branch prediction?????? ma che dici!!
Dico così e l'ho dimostrato poco sopra...
Originally posted by "gigggi"
io ovviamente mi stavo spiegando in modo semplice....la branch prediction allora che cosa fà nella cpu?
L'ho scritto nel mio primo post...
Originally posted by "gigggi"
ti faccio un esempio.....pota......le cpu pentium 1 integravano un primo abbozzo di unità di branch....mentre il power pc 604 non l'aveva...il pentium aveva 2 pipeline mentre il power 4.....il pentium aveva il suo daffare con i salti mentre il power dava i suoi bei 4 risultati per ciclo di clock immancabilmente.....qual'è l'architettura più efficente?
Sul fatto che il Power PC 604 non abbia una branch prediction unit o meno non lo so e di conseguenza non lo posso negare...e come ho già detto ci sono metodi alternativi alla branch prediction unit... Quindi anche il Power PC 604 aveva il suo bel da fare con i salti...
Anzi ho trovato ora che il Power PC 604 ha una branch prediction unit...ed è stato il primo Power PC ad averla... Quindi mi sa che hais celto amle il modello :)
http://www.mactech.com/articles/develop/issue_20/20balance.html
http://www.mackido.com/Hardware/G2.html
http://www.csse.monash.edu.au/~davida/teaching/cse3304/Web/Chapter8/
Originally posted by "Betha23"
Ma ti piace proprio tanto la parola "decide" ?? :D
Ok fraternizzare con la macchina ma attribuirgli capacità umanoidi........... :rolleyes:
Il "decidere" non implica un'intelligenza, ma semplicemente "prendere una delle possibili soluzioni ad un problema", in questo caso, secondo un algoritmo ;)
quello che dicevo io la branche serve sempre, serve meno se il codice è ottimizzato, ma serve
Originally posted by "checo"
quello che dicevo io la branche serve sempre, serve meno se il codice è ottimizzato, ma serve
Ah...ok :)
joesabba
22-04-2003, 16:27
Originally posted by "gigggi"
CISC ovvero complex instruction set computing.......il codice macchina ha una serie incredibile di istruzioni molto complesse che la cpu (quelle di oggi...) deve decodificare ridurre in istruzioni più semplici (ovvero le cosiddette simil-risc ma che non centrano nulla con le vere risc!!) dopodichè la cpu assegna un "numero" ad ogni porzione di codice generato e le invia alle varie sezioni di elaborazione.....a seconda che siano istruzioni floating point...sse....sse2...mmx....per interi ect. ect. poi vengono effettivamente elaborate ed alla fine viene "ricomposto" il risultato in uscita ed inviato alla ram.....mentre decompila o scompone e ricompone la signola istruzione non avviene una vera e propria elaborazione utile ai fini del programma in esecuzione ma è solo una perdita di tempo e cicli di clock........se poi intervengono dei "salti" allora siamo a posto......e questo è il modo di lavorare delle cpu odierne...
Questo punto è importante direi... è una perdita di tempo enorme utilizzare la cpu per tradurre al volo istruzioni in istruzioni più semplici.
Il postulato del risc è proprio quello di avere poche istruzioni assembler, esattamente il contrario delle cpu x86... quindi pure-risc rulez! :p
la branch prediction cmq sarà sempre un algoritmo utile nel calcolo parallelo
joesabba
22-04-2003, 16:35
Originally posted by "checo"
...cmq a parità di frequenza un a64 ed un xp sono ben distanti e questo fa ben sperare
ma quanto sono distanti in prestazioni?
Originally posted by "joesabba"
ma quanto sono distanti in prestazioni?
diciamo che un athlon64 a 1.6ghz ha lo stesso pr di un xp a 2.08 ghz
realisticamente ciò avverrà solo con chip e schede definitive, cmq il pr è lo stesso con 483mhz di differenza
un po come è ora tra xp e p4 :D
io volgio vedere quanto sta corsini a cambiare i server database del sito con degli opteron :D
Originally posted by "cionci"
Il controller di Opteron è un dual channel PC3200... Quello di Athlon64 dovrebbe essere un single channel PC3200...
No, é un 2700.
Eh sì...ora che l'ho letto sulle recensioni ho visto pure io ;)
Originally posted by "joesabba"
Questo punto è importante direi... è una perdita di tempo enorme utilizzare la cpu per tradurre al volo istruzioni in istruzioni più semplici.
Il postulato del risc è proprio quello di avere poche istruzioni assembler, esattamente il contrario delle cpu x86... quindi pure-risc rulez! :p
Se le CPU sono pipelined ed hanno una buona unità di branch prediction la perdita di tempo sia ha solamente in caso di flush della pipeline...
Guardate la recnesione di Ace's Hardware... E' davvero notevole !!!
azz rieccomi!! ho ritrovato il 3d perchè non mi arrivavano più le notifiche di risposta.....
a questo punto allora mi sembra di capire che per voi oggi sembra ovvio avere all'interno di una cpu che gira a 3 giga il core dell'8086 per garantire prima di tutto una retrocompatibilità che in realtà non esiste! (provate ad installare il dos sulle macchine di oggi....) dopodiche direi che mamma microzozz vi ha contagiato! infatti da quando ha smesso (praticamente subito...) di aggiornare i software per le nuove cpu è sempre successo che i produttori di cpu sono ricorsi a stratagemmi inutili ed enormemente complessi per cercare di far girare il software non ottimizzato..........e poi siete convinti che con una ricompilazione si risolve tutto......io non sono un esperto di programmazione ma cmq vi ricordo che agli inizi della storia informatica veniva elaborato il software ad hoc per ogni cpu!! oggi non è più così! e nel caso dei sistemi cisc non lo è mai stato!! inoltre siccome se non ricordo male le cpu risc avevano solo 8 istruzioni andate a vedere quante ne vengono generate scomponendo le istruzioni cisc! siccome le vere istruzioni risc sono 8 se se ne generano 300 mi pare di capire che tutte quelle oltre le 8 non siano risc originarie...... quindi è inutile dire che le cpu odierne siano risc!! è assurdo......cmq confidiamo in mamma microsoft e negli sviluppatori che ricompilano codice detto retrocompatibile x86!! incrediiiiiibbbbbbiile!!!
Originally posted by "gigggi"
(provate ad installare il dos sulle macchine di oggi....)
A me funziona...
Originally posted by "gigggi"
e poi siete convinti che con una ricompilazione si risolve tutto......io non sono un esperto di programmazione ma cmq vi ricordo che agli inizi della storia informatica veniva elaborato il software ad hoc per ogni cpu!!
La ricompilazione genera codice ad hoc per ogni CPU per definizione... Sempre che il compilatore supporti la CPU che ci interessa...
Originally posted by "gigggi"
inoltre siccome se non ricordo male le cpu risc avevano solo 8 istruzioni andate a vedere quante ne vengono generate scomponendo le istruzioni cisc! siccome le vere istruzioni risc sono 8 se se ne generano 300 mi pare di capire che tutte quelle oltre le 8 non siano risc originarie...... quindi è inutile dire che le cpu odierne siano risc!!
Non sono sicuramente 8 le istruzioni... E' impossibile...
Minimo minimo ci devono essere 8 istruzioni aritmetiche (interi con segno e senza segno), 5 (o più) istruzioni di confronto e salto, 1 per lo spostamento fra registri, 2 per l'accesso alla memoria, 4 operazioni logiche, 4 di shift, 2 per l'I/O, 2 (almeno) per la chiamata e il ritorno da procedure
E tutto questo senza onctare le operazioni floating point...di fatto introdotte successivamente...
Come ho già detto le differenze fra RISC e CISC si sono assottigliate nel tempo...
Io non ho detto che sono RISC, ho detto che una CPU x86 odierna ha acquistato molte delle caratteristiche tecniche dei RISC di un tempo e di quelli attuali...
L'ISA degli ultimi RISC è tutt'altro che così limitata... Si è sicuramente ampliata nel tempo...
Di conseguenza il RISC si è avvicinato al CISC e il CISC si è avvicinato al RISC... Di conseguenza le differenze, se non storicamente, non sono così nette...
Originally posted by "gigggi"
è assurdo......cmq confidiamo in mamma microsoft e negli sviluppatori che ricompilano codice detto retrocompatibile x86!! incrediiiiiibbbbbbiile!!!
Che intendi ???
joesabba
28-04-2003, 20:04
Originally posted by "cionci"
L'ISA degli ultimi RISC è tutt'altro che così limitata... Si è sicuramente ampliata nel tempo...
se non sbaglio quando avevo studiato il risc all'università un precetto era: "un buon set di istruzioni per risc non dovrebbe contenere più di 20/30 istruzioni" quindi se ora i risc hanno per es. un set di 250 istruzioni allora è caduto questo precetto e non sono più dei veri risc.... per questo hai ragione dicendo che cisc e risc si sono un po' avvicinati. Ma il cisc a mio avviso è una strada sbagliata che porta solo a complicare sempre più le cpu
cmq se anche usi il dos non usi le potenzialità del tuo pc quindi che senso ha la retrocompatibilità fino a questo punto?
anche parlando tecnicamente forse vi sfugge il nocciolo della questione........cioè una complicazione assurda del codice cisc che porta prima di tutto ad uno spreco enorme di risorse di calcolo per ogni cpu impiegata....una complicazione esagerata del codice macchina da cui poi deriva anche una generazione del codice da parte degli sviluppatori indietro di parecchi anni rispetto alla potenzialità delle cpu e gpu odierne!
accade spesso che delle software house aspettino anche degli anni per presentare i propri prodotti per far sì che il loro codice ottimizzato da schifo possa essere eseguito decentemente da cpu di generazioni future per rendere così più fruibile il software stesso!! è assurdo o no?
io cercavo più che altro di far capire quello!! non mi interessa avere ragione sul numero di istruzioni risc o cisc......io credo che l'hardware non dovrebbe MAI inseguire il software!!
a proposito di compilatori secondo voi chi li fà? anche coloro che li sviluppano devono tenere conto della retrocompatibilità ed altre amenità varie che come con l'introduzione dei 32 bit ritardata di 10 anni farà si che questo succeda anche con i 64bit (anche se mi auguro di no...) gli sviluppatori non producevano software dato come a 32 bit mentre invece era a 16 ed eseguito in dos dpmi??? non è stato così per 10 anni? e mi raccontate che basta il compilatore che sia ottimizzato per la cpu? come mai non ne era stato fatto uno in tutto questo tempo?
Originally posted by "gigggi"
cmq se anche usi il dos non usi le potenzialità del tuo pc quindi che senso ha la retrocompatibilità fino a questo punto?
Si sfruttano tutte le caratteristiche della CPU con indirizzamento segmentato a 20 bit... Le caratteristiche tecniche si sfruttano lo stesso... Non si vanno a sfruttare le caratteristiche date dal codice aggiuntivo... SSE, SSE2, MMX, 3dNow! e del codice a 32 e 64 bit...
Ma è normale visto che stiamo sfruttando la retrocompatibilità...
Originally posted by "gigggi"
anche parlando tecnicamente forse vi sfugge il nocciolo della questione........cioè una complicazione assurda del codice cisc che porta prima di tutto ad uno spreco enorme di risorse di calcolo per ogni cpu impiegata....una complicazione esagerata del codice macchina da cui poi deriva anche una generazione del codice da parte degli sviluppatori indietro di parecchi anni rispetto alla potenzialità delle cpu e gpu odierne!
Come ho già spiegato lo spreco di risorse si ha solo in caso di stallo della pipeline... E si ha uno spreco di 3-4 cicli di clock per ongi volta che succede...
Originally posted by "gigggi"
accade spesso che delle software house aspettino anche degli anni per presentare i propri prodotti per far sì che il loro codice ottimizzato da schifo possa essere eseguito decentemente da cpu di generazioni future per rendere così più fruibile il software stesso!! è assurdo o no?
Ti assicuro che è colpa dei programmatori e non dei compilatori... E non sono convinto che succeda spesso... Se ti riferisci al mondo dei giochi...in cui questo può accadere...allora non aspettano la CPU più potente, ma la scheda video più potente...
Originally posted by "gigggi"
io cercavo più che altro di far capire quello!! non mi interessa avere ragione sul numero di istruzioni risc o cisc......io credo che l'hardware non dovrebbe MAI inseguire il software!!
Secondo me non succede... Poi pensala come ti pare...
Originally posted by "gigggi"
a proposito di compilatori secondo voi chi li fà? anche coloro che li sviluppano devono tenere conto della retrocompatibilità ed altre amenità varie che come con l'introduzione dei 32 bit ritardata di 10 anni farà si che questo succeda anche con i 64bit (anche se mi auguro di no...) gli sviluppatori non producevano software dato come a 32 bit mentre invece era a 16 ed eseguito in dos dpmi??? non è stato così per 10 anni? e mi raccontate che basta il compilatore che sia ottimizzato per la cpu? come mai non ne era stato fatto uno in tutto questo tempo?
Chi scrive compilatori non deve tenere conto di alcuna retrocompatibilità... Deve solo rispettare i limiti imposti dal sistema operativo...
Un codice scritto con le contropalle può essere compilato per x86-32, x86-64, PowerPC, Power4, 680x0 e per molte altre CPU... Dipende solo dal compilatore... Guarda il mondo di Linux e guarda lo stesso codice scritto in C con quante CPU è compatibile (e per ogni CPU viene ottimizzato)...
Il codice eseguito sotto i vari DOS extender era completamente a 32 bit...
Il fatto è che non esisteva un sistema operativo compatibile con il software a 32 bit...da Windows 95 in poi i software potevano essere scritti completamente a 32 bit (tranne le system call che magari ritornavo a lavorare nel sottosistema a 16 bit, ma quelle non li scrivono i programmatori di applicativi)...
cionci ti faccio solo una domanda:
ma questo miracoloso compilatore si manifesta durante la festa di san gennaro o lo produce qualche umano?
poi cmq in caso di stallo della pipe con il p4 si perdono 20 cicli di clock solo per vuotare la pipe..........e poi si riprende l'elaborazione! se poi ci mettiamo che succede miliardi di volte.......non è uno spreco!! di sicuro....
se dici che chi scrive i compilatori deve conoscere solo il sistema operativo allora forse hai una visione un pelino limitata........se è il sistema operativo stesso che non sfrutta la cpu di conseguenza anche chi scrive codice per quel s.o.!!!
cmq guarda che chi ha usato il dos + win 3.11 oppure win 95 con le cpu pentium 1 usava codice a 16 bit su una cpu a 2 pipeline a 32 bit....questo non è spreco di risorse? come mai gli dei che creano i compilatori non si sono svegliati prima? considera poi che questi s.o. vengono usati ancora da parecchia gente!!!!!!! forse ti limiti a guardare che cosa accade diciamo ad un livello più alto rispetto all's.o. allora potrei essere d'accordo.....ma a basso livello è veramente uno schifo!
Originally posted by "gigggi"
ma questo miracoloso compilatore si manifesta durante la festa di san gennaro o lo produce qualche umano?
No, si chiama GCC e lo puoi trovare qua: http://gcc.gnu.org/install/specific.html
Al limite si può dire che la qualità del codice generato dal compilatore dipende dall'architettura della CPU...ma non è certo x86 l'ISA più complicata per i compilatori...non so se hai presente IA64 ;)
Originally posted by "gigggi"
poi cmq in caso di stallo della pipe con il p4 si perdono 20 cicli di clock solo per vuotare la pipe..........e poi si riprende l'elaborazione! se poi ci mettiamo che succede miliardi di volte.......non è uno spreco!! di sicuro....
Si sprecano solo i 3-4 cicli di clock necessari per la decodifica... Gli altri li avresti anche su un RISC... Il flush della pipeline c'è anche sui RISC...
Originally posted by "gigggi"
se dici che chi scrive i compilatori deve conoscere solo il sistema operativo allora forse hai una visione un pelino limitata........se è il sistema operativo stesso che non sfrutta la cpu di conseguenza anche chi scrive codice per quel s.o.!!!
Non ho detto questo ho detto che deve generare codice per quella CPU nei limiti e nelle modalità richieste dal sistema operativo...
Originally posted by "gigggi"
cmq guarda che chi ha usato il dos + win 3.11 oppure win 95 con le cpu pentium 1 usava codice a 16 bit su una cpu a 2 pipeline a 32 bit....questo non è spreco di risorse? come mai gli dei che creano i compilatori non si sono svegliati prima?
Su Windows 95 gli applicativi erano a 32 bit, mentre il sistema operativo aveva diverse parti a 16 bit...ma non vedo cosa c'entri con l'architettura della CPU se alla M$ non sapevano fare un sistema operativo pienamente a 32 bit retrocompatibile con le applicazioni a 16 bit...
Originally posted by "gigggi"
considera poi che questi s.o. vengono usati ancora da parecchia gente!!!!!!! forse ti limiti a guardare che cosa accade diciamo ad un livello più alto rispetto all's.o. allora potrei essere d'accordo.....ma a basso livello è veramente uno schifo!
Come ho già detto non è colpa dell'architettura della CPU... Allora ci infili Linux ed il tuo bel Pentium 1 lo sfrutti...
Originally posted by "joesabba"
se non sbaglio quando avevo studiato il risc all'università un precetto era: "un buon set di istruzioni per risc non dovrebbe contenere più di 20/30 istruzioni"
Pensa che fra 20/30 ci sono solo le istruzioni base, vi sono state aggiunte le istruzioni FPU (altre 20/30) e qualcuno ha aggiunto istruzioni SIMD e sono convinto che con i vari ampliamenti e il mantenimento di retrocompatibilità (verso il codice a 32 bit per le CPU a 64 bit ad esempio) le 200 istruzioni si superano tranquillamente...
Certo...nei CISC saremo sicuramente oltre le 500-600 per IA32 con MMX, SSE e SSE2...
Sono d'accordo anche io che il punto di partenza dei CISC era sbagliato...ma ormai le differenze sono soltanto che i RISC hanno una unità di decodifica più semplice rispetto ai CISC...che si riduce a 1-2 cicli di clock di differenza in caso di flush della pipeline... Una differenza infinitesimale...
Originally posted by "gigggi"
ma questo miracoloso compilatore si manifesta durante la festa di san gennaro o lo produce qualche umano?
ti posso assicurare, come ha detto cionci, che il compilatore si chiama gcc.
a parte la versione 2.96 (uno schifo) con la 2.95 e la ultima 3.2.2 il codice in c lo ricompili e funziona su qualsiasi architettura supportata dal compilatore, tant'è vero che i programmi forniti in versione sorfgente per linux non cambiano di una virgola sia che si usi un x86 che un g3,un g4, un xp, un thoro, un p4, un p3 un p2 un p1 un k6 un k6-2, devo andare avanti? tutto sta alla bontà del compilatore, e per ora non ho avuto nessun problema (tranne con il gcc 2.96, e, per inciso, i sorgenti che non si compilavano col 2.96 si compilavano perfettamente col 2.95).
allora per sfruttare un pentium 1 OGGI ci devo mettere linux....interessante! allora scusatemi ma non capite che cosa intendo dire.....forse non riesco a spiegarmi....
cmq per il discorso compilatori a voi interessa che il programma generato funzioni....ma non gliene frega niente a nessuno se vengono sprecate enormi quantità di potenza di calcolo......sono d'accordo con voi sui vari discorsi.....a parte il discorso risc.......cmq non vi è chiaro il problema di fondo........ fà niente! continueremo ad usare a metà le nostre macchine!! ciao a tutti
Originally posted by "gigggi"
cmq per il discorso compilatori a voi interessa che il programma generato funzioni....ma non gliene frega niente a nessuno se vengono sprecate enormi quantità di potenza di calcolo......sono d'accordo con voi sui vari discorsi.....a parte il discorso risc.......cmq non vi è chiaro il problema di fondo........ fà niente! continueremo ad usare a metà le nostre macchine!! ciao a tutti
il fatto che la potenza di calcolo va sprecata nn è da attribuire al compilatore (almeno non tutta, diciamo il 10%) ma al programmatore, e un programma scritto male gira male sia su un risc che su un cisc ;)
logico che la colpa và al programmatore ma non quello delle applicazioni ma a quello (o meglio quelli..) dei compilatori...........e non credo che esiste qualcuno in grado di dire che la perdità di potenza di calcolo si attesta sù un 10% circa....è una pura congettura....inoltre il codice per le poche cpu risc rimaste senz'altro è scritto sicuramente meglio in quanto i suddetti sistem non hanno mai e dico mai avuto problemi di instabilità.........cmq il discorso è sempre sbagliato rispetto a quello che volevo dire io............chi utilizza oggi tutte le funzioni di un p4?
un esperto in programmazione mi ha risposto inoltre che per utilizzare il mio pentium 1 cmpletamente 10 anni fà dovevo installare linux..... :D
sbaglio o linux non c'era? c'era unix ma di sicuro non era alla portata di tutti e men che meno le applicazioni....
avete capito ora che cosa intendo?
cmq per sfruttare il pentium completamente c'era anche os2.....solo che ovviamente mamma microzozz ha fatto in modo di ucciderlo ancor prima di nascere.........
Originally posted by "gigggi"
logico che la colpa và al programmatore ma non quello delle applicazioni ma a quello (o meglio quelli..) dei compilatori...........e non credo che esiste qualcuno in grado di dire che la perdità di potenza di calcolo si attesta sù un 10% circa....è una pura congettura....
I compilatori ci sono sia per le CPU RISC che per le CPU CISC... Molte volte un compilatore riesce a realizzare codice macchina più efficiente di quello scritto a mano... Sicuramente altre volte non ci riuscirà, ma continuo a non vedere un nesso fra l'architettura e questa fantomatica (perchè non vedo come tu possa dimostrarla) inefficienza dei compilatori...
Fa più danni un programmatore ad alto livello che il compilatore...stanne pure certo... Lavorando su un sorgente si può aumentare l'efficienza di un programma anche di 100 o 1000 volte... Chiaramente dipende da quanto è buono il codice di partenza...
Originally posted by "gigggi"
inoltre il codice per le poche cpu risc rimaste senz'altro è scritto sicuramente meglio in quanto i suddetti sistem non hanno mai e dico mai avuto problemi di instabilità.........
Mah ?!?!?!? :confused: Che vuol dire ? E poi come fai a dirlo ? Ripeto i compilatori usati sono gli stessi...cambia solamente la parte di traduzione in codice macchina...
Originally posted by "gigggi"
cmq il discorso è sempre sbagliato rispetto a quello che volevo dire io............chi utilizza oggi tutte le funzioni di un p4?
Sicuramente pochi software, ma ciò che vuol dire ?
Originally posted by "gigggi"
un esperto in programmazione mi ha risposto inoltre che per utilizzare il mio pentium 1 cmpletamente 10 anni fà dovevo installare linux..... :D
sbaglio o linux non c'era?
C'era...la prima volta l'ho installato nel '94 su un 386...
Comunque in ogni caso hai travisato quello che dicevo... Sei tu che hai detto che non ti andava bene Windows 95 perchè aveva parte del SO a 16 bit...di consguenza se non ti andava bene dovevi cercare altre strade... Ma ripeto non è colpa nostra...ma della Mcirosoft...
Continuo a non capire cosa intendi...
intendo dire che la maggior parte degli utenti continuano ad usare il pc al 50% della proprie possibilità.....solo ora che si è arrivati ai 32 bit reali siamo già pronti per i 64 con l'hardware ma non col software......
linux nel 94 c'era? e sotto forma di che s.o.?
dai!! non scherziamo!!
Se te lo dico vuol dire che è vero...non è che me la invento...
http://www.distrowatch.com/table.php?distribution=slackware
Era mi sembra la fine del '94 quando andai dal un provider per cui facevo anche qualche lavoretto (e che mi faceva connettere gratis)...e mi disse di provare questo nuovo sistema operativo... E mi prestò i CD della Slackware se non sbaglio 2.0.1...
Originally posted by "gigggi"
.
siccome le vere istruzioni risc sono 8 s
come no!!!!
hai idea della cavolata che hai detto?
con 8 istruzioni non ci fai nemmeno una calcolatrice
Comunque non vedo cosa c'entri il fatto che non sfruttiamo l'hardware che abbiamo (su cui mi potrei trovare d'accordo, per colpa dei programmatori e non dei compilatori) con il discorso sulle architetture RISC e CISC...
Se avessimo avuto delle CPU RISC probabilmente ci saremmo trovati gli stessi problemi...
Originally posted by "gigggi"
logico che la colpa và al programmatore ma non quello delle applicazioni ma a quello (o meglio quelli..) dei compilatori...........
hai bevuto vero? :D
scherzi a parte, imho non hai la + pallida idea di quello di cui stai parlando, o hai un'idea molto confusa....
un compilatore lavora MOLTO meglio di un programmatore, e stai sereno che, se un programma va lento, non è colpa del compilatore che lo traduce in codice macchina, ma dell'imbecille che lo ha scritto.
Originally posted by "gigggi"
un esperto in programmazione mi ha risposto inoltre che per utilizzare il mio pentium 1 cmpletamente 10 anni fà dovevo installare linux..... :D
sbaglio o linux non c'era?
sì hai bevuto :D
ps: quando ho preso io il pentium1 (un p133) era uscita da un po di tempo la red hat 6.0, sorry ma non ricordo l'anno...
OT il gcc esiste funzionante bene pure per windows?
vorrei fare dei test sulle ottimizzazioni,
www.mingw.org
Oppure scarichi Dev-C++ e c'è già...
quanto è grabnde dev-c++?
sai com'è con un 56k :(
mingw è un compilatore c++?
basta quel file da 12 mb?
http://prdownloads.sourceforge.net/dev-cpp/devcpp4980.exe
C'è l'ambiente di sviluppo ed il compilatore completo (pari pari al GCC)...12 Mb...
Originally posted by "cionci"
http://prdownloads.sourceforge.net/dev-cpp/devcpp4980.exe
C'è l'ambiente di sviluppo ed il compilatore completo (pari pari al GCC)...12 Mb...
grazie mille! ;)
benissimo ragazzi avete ragione tutti quanti!! infatti nel 94 sì linux c'era e ci giravano all'incirca 3 programmi......come per os2 del resto......io parlo di utenti medi che utilizzano pc!!!!!
e cmq continuo a ripetere che anche quando una cpu esce passano anni prima che si sfrutti completamente infatti la tecnologia di tale cpu diventa obsoleta prima ancora che si riesca ad utilizzarla........invece come dite voi sembra quasi che appena esce una nuova istruzione siano tutti lì pronti a rifare i compilatori per utilizzare la suddetta istruzione...quando dalla prima cpu a 32bit ad un utilizzo generale di software a 32 bit sono passati più di 10 anni......ma parlo arabo? cmq avete ragione voi! il codice è perfetto e gli sviluppatori lavorano da dio ed anche quelli che creano 600 istruzioni per cpu ultracomplesse che poi vengono scomposte in istruzioni semplificate nella cpu hanno lavorato da dio!!!
leggete quì se volete:http://www.lithium.it/articolo0029p4.htm
e magari questo.....http://www.dizionarioinformatico.com/allegati/PPC.html
se poi volete guardare quà leggerete a che cosa devono ricorrere perchè l'architettura cisc non prevede l'elaborazione parallela ect. ect.
http://www.hardware-mania.com/amd/duron/duron.htm
oppure questo:http://www.ing.unife.it/elettr/CE/ArchCPU02-03.pdf
cmq avete ragione! ciao a tutti
http://www.gest.unipd.it/materiale-didattico/ece2/pipeline.htm
questo è l'ultimo! bye
pardon....mi è scappato anche questo!!
http://www.wup.it/print.php?sid=3403
Originally posted by "gigggi"
http://www.gest.unipd.it/materiale-didattico/ece2/pipeline.htm
questo è l'ultimo! bye
No, basta calcolatori elettronici :p
ma cosa mi tiri fuori, le mie dispense ? :p
Cmq il problema, gigggi e' che il sw e' scritto dalle persone, quindi l'evoluzione e' molto piu' lenta dell'hw essendo ormai progettato tutto (o quasi) dalle macchine.
xtian......hai ragione....quello che cercavo di far capire a qualcuno è esattamente quello che hai appena detto tu!!!!
ciao
Originally posted by "gigggi"
se poi volete guardare quà leggerete a che cosa devono ricorrere perchè l'architettura cisc non prevede l'elaborazione parallela ect. ect.
http://www.hardware-mania.com/amd/duron/duron.htm
è il codice x86 che non lo prevede, non l'architettura.
se l'isa non ha istruzioni per il parallelo metti che cpu vioi, ma il risulatato è lo stesso, ovvero è la cpu che si ingegna i parallelismi.
un athlon fa 3 operazioni per ciclo di clock, solo in teoria, nel 90% dei casi ne fa 1
Originally posted by "gigggi"
http://www.gest.unipd.it/materiale-didattico/ece2/pipeline.htm
questo è l'ultimo! bye
cosa centra?
Originally posted by "gigggi"
pardon....mi è scappato anche questo!!
http://www.wup.it/print.php?sid=3403
come sopra, non capisco di cosa tu stia parlando rimane tu linki un articolo su package delle cpu ed hai fatto un minestrone :D
scorpionkkk
29-04-2003, 22:56
Scusami giggi voglio capire bene...tu stai affermando che le nsotre CPU non vengono sfruttate al 100% e che quindi la corsa ai 64 bit è uno spreco...giusto?
Quetsa affermazione potrebbe anche essere condivisibile se tu non stessi facendo una immensa confusione tra compilatori programmatori e SO che c'erano o meno nel 94 il tutto condito da errate convinzioni e definizioni di bpu,cisc,risc e quant'altro torni utile nella discussione...
Ricominciamo da zero..qui tutti abbiamo dato calcolatori elettronici e anche qualcosina di +....voglio capire perchè un maledetto compilatore ,che è un traduttore in assembler (la hopper si rivolterebbe nella tomba per questa affermazione ma vabbè),influisca sullo sfruttamento della cpu...o cosa c'entrino le quantità d'istruzioni nel registro...
ho sempre saputo che se la cpu nn è sfruttata è colpa del programma e di chi lo ha redatto..nulla più....di fatto tutte le applicazioni di fisica (parliamo ovviamente di calcoli importanti come le traittorie delle particelle e cosi via)..sono estremamente ottimizzati per le macchine su cui girano che sfruttano al 100% (altrimenti si perdono $$)..
aspetto un chiarimento..
bene concordo su quanto dici e cercherò di darti una spegazione
perchè un maledetto compilatore ,che è un traduttore in assembler (la hopper si rivolterebbe nella tomba per questa affermazione ma vabbè),influisca sullo sfruttamento della cpu
semplice, tu scrivi un programma in un qualsiasi linguaggio ad alto livello, facciamo in c++
ora di programmazione sono a secco da un po, perciò faccio un ragionamento teorico.
ammettiamo che il tuo programma legga da un file 100 numeri , li ordini e poi li riscriva su file.
te scrivi il programma usi mettimo un quick sort per l'ordinamento e per te il programma è fatto a regola d'arte.
mettiamo però che la cpu che stai usando abbia una istruzione che in un ciclo di clock ordina 10 numeri( so che andrebbe contro l'algoritmo di ordinamento, ma è teoria pura)
bene se il compilatore prevede otimmizzazioni per la tua cpu, basterà specificare prima dei compilare , che vuoi ottimizare per quella cpu.
avrai come risultato un programma nettamente più veloce, che sfrutta bene tutta la potenzialità della cpu , ma che funzionarà solo su quella, a meno di routine che verifichino che cpu è presente, e di 2 "pezzi" di programmi che fanno la stessa cosa, ma per cpu diverse.
se non specifichi nulla l'eseguibile non sfrutterà la nuova funzione della cpu.
e questo vale sia a livello di isa e di nuove istruzioni( vedi otttimizzazioni mmx.sse,sse 3dnow) si a livello architetturale, ovvero se una cpu ha 10 registri ed un'altra 20 se ottimizzo il codice per la seconda , usando 20 registri, otterrò dei benifici
se evito al minimo i salti, sfrutterò appieno l'architettura di una pipeline a 20 stadi
scorpionkkk
29-04-2003, 23:21
si scusa..probabilmente mi sono spiegato male caro checo (ormai sono abituato a leggerti sul forum di lithium da tempo immemore quindi ti do del tu :) )...
la mia in realtà era una domanda retorica perchè proprio non capisco come un compilatore possa essere scritto in un modo tale da impedire lo sfruttamento della CPU come ha scritto giggi...mi spiego meglio utilizzando il tuo esempio:
se il compilatore è stato scritto in modo da avere una ben determinata ottimizzazione per QUELLA cpu..allora è stato scritto bene e non ci sono problemi di sorta che, o possono essere imputati al programma o al cattivo utilizzo che si fa del compilatore..
il compilatore di per sè non è scritto male (parliamo dei compilatori standard obviously di qualsiasi linguaggio..anche i vecchi turbo pascal della borland che usavamo all'università :)) e non ha alcuna influenza sul rendimento della CPU...
scorpionkkk
29-04-2003, 23:31
per carità..ottimizzazioni di gcc e degli altri sono all'ordine del giorno perchè il tradurre istruzioni complesse lascia alle spalle bugs,distrazioni e qualcosa sfugge...ma non è che se il compilatore ha una minima falla il mio programma (qualsiasi) rende la metà e io nn sfrutto la cpu...è un idea alquanto strana questa...
Originally posted by "scorpionkkk"
si scusa..probabilmente mi sono spiegato male caro checo (ormai sono abituato a leggerti sul forum di lithium da tempo immemore quindi ti do del tu :) )...
la mia in realtà era una domanda retorica perchè proprio non capisco come un compilatore possa essere scritto in un modo tale da impedire lo sfruttamento della CPU come ha scritto giggi...mi spiego meglio utilizzando il tuo esempio:
la cpu viene sempre sfruttata al 100% anche senza ottimizzazioni.
solo che un compilatore generico sfrutta la cpu per 10 secondi
un compilatore che prevede ottimizzazioni la sfrutta per 8 ad esempio.
in entrambi i casi si sfrutta l acpu al 100% , ma nel secondo si guadagna tempo.
mi ricordo all'uni quando facevo assemblere sul motorola 68K che molti esercizi erano improntati sull'otimizzaione del codice.
programmini del cavolo, massimo 100 righe , però venivano fatti tenedo conto dei cicli di clok necessari per eseguire ogni singola operazione ed alla fine bisognava minimizzare il totale.
sia per le move che per gli accessi in memoria che per le operazioni sui dati.
purchè grezzo, questo vuol dire sfruttare al massimo una cpu
Originally posted by "scorpionkkk"
per carità..ottimizzazioni di gcc e degli altri sono all'ordine del giorno perchè il tradurre istruzioni complesse lascia alle spalle bugs,distrazioni e qualcosa sfugge...ma non è che se il compilatore ha una minima falla il mio programma (qualsiasi) rende la metà e io nn sfrutto la cpu...è un idea alquanto strana questa...
in parte è vero.
ci sono compilatori che rendono di più di altri.
cioè i primi compilatori specie quelli di linguaffi ad alto livello erano meno efficienti di quelli odierni, ma ugualmente efficaci.
pensa anche al visual basic.
dalla versione 3 alla 6 vi sono stati netti miglioramenti sui tempi di esecuzione del codice generato.
ovvero alla fine il programma andava lo stesso, ma in più tempo.
scorpionkkk
29-04-2003, 23:47
ok..alla fine concordiamo appieno...
vedremo che ci dirà giggi..forse qualcosa ci è sfuggito negli ultimi vent'anni..
Originally posted by "gigggi"
benissimo ragazzi avete ragione tutti quanti!! infatti nel 94 sì linux c'era e ci giravano all'incirca 3 programmi......come per os2 del resto......io parlo di utenti medi che utilizzano pc!!!!!
Se le cose non le sai non le dire... Il Kernel di Linux è nato nel '91... I programmi che ci giravano erano i classici programmi con licenza BSD che erano tipicamente Open Source da ormai molti anni... Quindi Linux aveva lo stesso supporto software dei vari BSD... Poi come al solito...ricompilata del sorgente e funzionava tutto...
Originally posted by "gigggi"
ma parlo arabo? cmq avete ragione voi! il codice è perfetto e gli sviluppatori lavorano da dio ed anche quelli che creano 600 istruzioni per cpu ultracomplesse che poi vengono scomposte in istruzioni semplificate nella cpu hanno lavorato da dio!!!
Mi sembra di parlare arabo a me... E' chiaro che non vengono sfruttate tutte le potenzialità delle CPU, ma non è certo colpa dell'architettura della CPU stessa...
Preso da un tuo link: "La vera potenza del 604e e', da una parte, la versatilita' del linguaggio assembler, con istruzioni "non eccessivamente RISC" come quelle dell'Alpha e del MIPS" e come vedi el differenze si assottigliano...
Originally posted by "scorpionkkk"
per carità..ottimizzazioni di gcc e degli altri sono all'ordine del giorno perchè il tradurre istruzioni complesse lascia alle spalle bugs,distrazioni e qualcosa sfugge...ma non è che se il compilatore ha una minima falla il mio programma (qualsiasi) rende la metà e io nn sfrutto la cpu...è un idea alquanto strana questa...
Senza contare che se questo avviene per una CPU CISC può avvenire anche per una CPU RISC...
Ed anche l'ISA delle CPU RISC non sta ferma...quindi il discorso di checo sui flag di ottimizzazione è riapplicabile in qualsiasi contesto di qualsiasi CPU RISC o CISC... E non solo...non è detto nemmeno che mantendo la stessa ISA, ma cambiando il funzionamento interno di una nuova CPU rispetto alla precedente lo stesso codice sia l'ottimo anche per questa nuova CPU...
Originally posted by "scorpionkkk"
Ricominciamo da zero..qui tutti abbiamo dato calcolatori elettronici e anche qualcosina di +....
Eh sì...gigggi non so... Bisognerebbe chiederglielo...
Originally posted by "cionci"
Eh sì...gigggi non so... Bisognerebbe chiederglielo...
veramente io non ho dato un'esame di calcolatori elettronici, ne ho dato solo uno di fondamenti, ma se non so una cosa non la dico :) , punto.
su la mano chi ha dato calcolatori elettronici!
Originally posted by "cionci"
E non solo...non è detto nemmeno che mantendo la stessa ISA, ma cambiando il funzionamento interno di una nuova CPU rispetto alla precedente lo stesso codice sia l'ottimo anche per questa nuova CPU...
certo concordo in pieno.
molto carino devc++ tnx
un athlon fa 3 operazioni per ciclo di clock, solo in teoria, nel 90% dei casi ne fa 1
ecco che cosa intendevo dire.....tutto ciò non è un fantastico spreco di risorse?
se poi i progettisti di cpu creano nuove istruzioni e poi si ingegnano per creare una cpu che le smembra e le "riduce" in microoperazioni non è un cane che si morde la coda?
tutto lì quello che volevo far capire!! è logico poi che per ogni cpu possa anche esistere un s.o. e dei prog che la sfruttano al 100 ma per la maggior parte degli utenti non è così!!!
la cpu viene sempre sfruttata al 100% è l'efficienza che non è ottimale. ;)
una notizia presa da GMC,dove nell'articolo sul GDC 2003,Mike Wall (ingegnere AMD) sostiene che nei prossimi anni,ludicamente parlando,ci sara' un balzo epocale reso possibile dal passaggio da un'architattura PC a 32 bit a una a 64 bit.Entro un paio d'anni la qualita' dei giochi per computer raggiungera' nuove vette di perfezione perche' la tecnologia a 64 bit consentira' di ottenere miglioramenti a livello estetico e di prestazioni,con effetti grafici sempre piu' realistici...... :D :D :D
Questi 64 bit sono sempre piu' una meraviglia! :D
parlando di giochi poi mi risulta (non uccidetemi se sbaglio!!) che doom 3 sia stato sviluppato utilizzando al massimo gli effetti e le potenzialità della gpu gf3.......benissimo.....si dice che uscire a fine anno quando ci saranno già in commercio delle gpu forse di 3 generazioni dopo!! inoltre se è stato sviluppato con la gf3 penso anche che sia ottimizzato per sfruttare le cpu che c'erano in circolazione con la gf3................inoltre pare anche che stiano ritardando l'uscita per far sì che gli utenti aggiornino i pc per poter far girare meglio il gioco..........
Originally posted by "gigggi"
parlando di giochi poi mi risulta (non uccidetemi se sbaglio!!) che doom 3 sia stato sviluppato utilizzando al massimo gli effetti e le potenzialità della gpu gf3.......benissimo.....si dice che uscire a fine anno quando ci saranno già in commercio delle gpu forse di 3 generazioni dopo!!
ma tu stai vaneggiando!!!
scusa e allora per cosa lo devono scrivere? per la radeon9700?
e chi caxxo lo compra poi?
Per la cronoca l'Athlon può eseguire 9 istruzioni contemporaneamente...
3 floting point, 3 interi e 3 per il calcolo degli indirizzi...
Questo avviene se non c'è dipendenza fra i vari dati ed in ogni caso deve essere rispettata la sequenza per la riscrittura dei risultati (cosa che avviene in ogni processore che esegue parallelamente più istruzioni, anche nei RISC se c'è dipendenza non ci può essere esecuzione parallela)...
Originally posted by "gigggi"
se poi i progettisti di cpu creano nuove istruzioni e poi si ingegnano per creare una cpu che le smembra e le "riduce" in microoperazioni non è un cane che si morde la coda?
Tradurre il codice x86 in MacroOP (o MicroOP) è l'unico modo che permette alle CPU odierne di avere un certo parallelismo di esecuzione e tante altre feature che altrimenti con le istruzioni a lunghezza variabile non avremmo potuto usare...
Che altro modo potresti studiare ? Anche io sarei contento se Alpha + NT avesse preso piede... Purtroppo non è successo e siamo qui a dover cercare di migliorare un'architettura che sicuramente inizialmente non era la migliore...ma che attualmente, con i recenti miglioramenti, ha recuperato notevolmente il GAP rispetto alle più potenti CPU RISC...
Originally posted by "gigggi"
tutto lì quello che volevo far capire!! è logico poi che per ogni cpu possa anche esistere un s.o. e dei prog che la sfruttano al 100 ma per la maggior parte degli utenti non è così!!!
E' esclusivamente una questione di sistema operativo e di codice scritto male dal 90% dei programmatori (che non pensano mai alle performance)...e, come ripeto, sarebbe così anche se Intel avesso prodotto una CPU RISC invece di una CPU CISC...
Originally posted by "gigggi"
parlando di giochi poi mi risulta (non uccidetemi se sbaglio!!) che doom 3 sia stato sviluppato utilizzando al massimo gli effetti e le potenzialità della gpu gf3.......benissimo.....si dice che uscire a fine anno quando ci saranno già in commercio delle gpu forse di 3 generazioni dopo!! inoltre se è stato sviluppato con la gf3 penso anche che sia ottimizzato per sfruttare le cpu che c'erano in circolazione con la gf3................inoltre pare anche che stiano ritardando l'uscita per far sì che gli utenti aggiornino i pc per poter far girare meglio il gioco..........
E' una questione di schede video...non certo di CPU...
Per la cronoca l'Athlon può eseguire 9 istruzioni contemporaneamente...
3 floting point, 3 interi e 3 per il calcolo degli indirizzi...
che poteva eseguire 3 operazioni non l'avevo detto io ma qualcuno che mi dice che dico cose non vere.......
ma tu stai vaneggiando!!!
scusa e allora per cosa lo devono scrivere? per la radeon9700?
e chi caxxo lo compra poi?
informati bene e vedrai che è così!!! e poi che cosa significa che lo devono sviluppare per la radeon? boh! io intendevo che lo vedremo usando delle gpu di 3 generazioni dopo........o forse hai capito che sono di parte ati o nvidia? mah! ragazzi scusate ma spesso non si capisce che cosa intendete....mi sà che è un limite della discussione in un forum.....per chiarire a volte bisognerebbe scrivere 20 pagine.....
Originally posted by "gigggi"
che poteva eseguire 3 operazioni non l'avevo detto io ma qualcuno che mi dice che dico cose non vere.......
informati bene e vedrai che è così!!! e poi che cosa significa che lo devono sviluppare per la radeon? boh! io intendevo che lo vedremo usando delle gpu di 3 generazioni dopo........o forse hai capito che sono di parte ati o nvidia? mah! ragazzi scusate ma spesso non si capisce che cosa intendete....mi sà che è un limite della discussione in un forum.....per chiarire a volte bisognerebbe scrivere 20 pagine.....
Doom3, essendo OGL, sfrutta non solo l'OGL 1.3 e le sue funzioni standard ma anche alcune estensioni proprietarie di ati o nvidia.
Originally posted by "gigggi"
che poteva eseguire 3 operazioni non l'avevo detto io ma qualcuno che mi dice che dico cose non vere.......
Non volevo riprendere te ;)
Originally posted by "gigggi"
informati bene e vedrai che è così!!! e poi che cosa significa che lo devono sviluppare per la radeon? boh! io intendevo che lo vedremo usando delle gpu di 3 generazioni dopo........o forse hai capito che sono di parte ati o nvidia? mah! ragazzi scusate ma spesso non si capisce che cosa intendete....
no, non hai capito un caxxo (strano :p ), non pigliartela sto scherzando ;)
riformulo la domanda: tu vorresti che escono giochi che sfruttano gpu di ultima generazione? (tipo ati 9700 o nvidia gf fx5600 ultra?)
se uscissero, chi li comprerebbe? forse (e sono ottimista) l'1% delle persone alle cui sarebbe indirizzato il gioco, visto che NON TUTTI, per non dire nessuno, hanno 600 euro da buttare nella scheda video...
telnet tu hai perfettamente ragione ma io lo dicevo per ricordare che ormai è il software a seguire e con molto ritardo l'hardware!!!
non volevo nè dire che un utente si debba comprare per forza una scheda da 500 e passa € e nè che gli sviluppatori debbano supportare un'architettura video rispetto ad unaltra anche perchè se il gioco è sviluppato per open gl (per fortuna...) vengono supportate tutte le schede video compatibili magari con qualche funzione diversa.......
dopo circa una cinquantina di messaggi mi sembra di capire che siamo andati un peletto off topic o sbaglio? :D
Originally posted by "cionci"
Non volevo riprendere te ;)
chiedo venia certo che questo articolo è scritto coi piedi!
http://www.hardware-mania.com/amd/duron/duron.htm
L'aspetto chiave di Athlon e Duron riguarda la loro capacità di elaborare fino a 3 istruzioni per ciclo di clock, con una pipeline di elaborazione di ben 10 stadi per gli interi e 15 per le istruzioni in virgola mobile (FPU).
mi sono confuso :muro:
scusate,io volevo chiedere a chi fosse in grado di rispondere,se e' vero che un'architettura a 64 bit potra' portare ad un aumento di prestazioni grafiche e di complessita' del gioco,come e' stato detto da quell'ingegnere dell'AMD al GDC 2003.O magari bisognera' aspettare anche un cambiamento dell'architettura delle GPU,tale da sfruttare i 64 bit?
In sostanza con le cpu a 64 bit avremo un qualcosa che si avvicinera' a quei mostri di calcolatori con cui ci fanno i film animati in computer graphic????
Originally posted by "STICK"
scusate,io volevo chiedere a chi fosse in grado di rispondere,se e' vero che un'architettura a 64 bit potra' portare ad un aumento di prestazioni grafiche e di complessita' del gioco,come e' stato detto da quell'ingegnere dell'AMD al GDC 2003.O magari bisognera' aspettare anche un cambiamento dell'architettura delle GPU,tale da sfruttare i 64 bit?
In sostanza con le cpu a 64 bit avremo un qualcosa che si avvicinera' a quei mostri di calcolatori con cui ci fanno i film animati in computer graphic????
mmm i 64bit in se non portano benefici di questo genere
Originally posted by "checo"
chiedo venia certo che questo articolo è scritto coi piedi!
http://www.hardware-mania.com/amd/duron/duron.htm
L'aspetto chiave di Athlon e Duron riguarda la loro capacità di elaborare fino a 3 istruzioni per ciclo di clock, con una pipeline di elaborazione di ben 10 stadi per gli interi e 15 per le istruzioni in virgola mobile (FPU).
mi sono confuso :muro:
Io sapevo che erano entrambi, FP e integer a 15 stadi, adesso cerco su arstechnica
Originally posted by "checo"
chiedo venia certo che questo articolo è scritto coi piedi!
http://www.hardware-mania.com/amd/duron/duron.htm
L'aspetto chiave di Athlon e Duron riguarda la loro capacità di elaborare fino a 3 istruzioni per ciclo di clock, con una pipeline di elaborazione di ben 10 stadi per gli interi e 15 per le istruzioni in virgola mobile (FPU).
mi sono confuso :muro:
Infatti
http://www.arstechnica.com/cpu/3q99/k7_theory/k7-one-4.html
15 per entrambi, mi sembrava di avelo letto al tempo.
E non ditemi che arstechnica sbaglia :o
Io ho sempre saputo 10 stadi per gli interi e 15 per i FP...
Originally posted by "cionci"
Io ho sempre saputo 10 stadi per gli interi e 15 per i FP...
Mi sa che arstechnica e' stato un po' ambiguo con quella frase :-\
http://www.sandpile.org/impl/k7.htm
Pipeline Depth 10 (Integer), 15 (FP)
Originally posted by "Xtian"
Mi sa che arstechnica e' stato un po' ambiguo con quella frase :-\
http://www.sandpile.org/impl/k7.htm
Pipeline Depth 10 (Integer), 15 (FP)
mi pare chiaro
10 integer
15 float
Originally posted by "checo"
mi pare chiaro
10 integer
15 float
Gia' :)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.