Athlon64 vs Pentium4...

[joesabba]

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?

[checo]

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

[checo]

io volgio vedere quanto sta corsini a cambiare i server database del sito con degli opteron

[zavfx]

Originally posted by "cionci"


Il controller di Opteron è un dual channel PC3200... Quello di Athlon64 dovrebbe essere un single channel PC3200...

No, é un 2700.

[cionci]

Eh sì...ora che l'ho letto sulle recensioni ho visto pure io

[cionci]

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!

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...

[cionci]

Guardate la recnesione di Ace's Hardware... E' davvero notevole !!!

[gigggi]

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!!!

[cionci]

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]

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

[gigggi]

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?

[cionci]

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)...

[gigggi]

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!

[cionci]

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...

[cionci]

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...

[telnet]

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).

[gigggi]

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

[telnet]

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

[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....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.....
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.........

[cionci]

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 ?!?!?!? 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.....
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...