Due tagli di cache per le cpu Conroe

[^TiGeRShArK^]

Originariamente inviato da -fidel-

Azz mi è venuta un'altra domanda:

ma se fosse così, a parità di transistor, non posso fare una pipe più corta ma con lo stesso numero di trasistor di una lunga? Così quelli "che avanzano" (eheheh ) li uso per altro?

non "avanzano" transitor da una pipeline....
I transitor necessari per le operazioni da compiere sono praticamente equivalenti.....
casomai in ogni stadio della pipeline lunga, dovendo svolgere operazioni + elementari, potrai mettere meno transistor...
ma i transistor di TUTTA la pipeline sono piu' o meno simili sia ke hai una pipeline corta che lunga.
i termini "corta" o "lunga" non indicano in alcun modo il numero di transistor totali della pipe, ma solo il numero di stadi utilizzati...

[darkquasar]

Originariamente inviato da ^TiGeRShArK^

non "avanzano" transitor da una pipeline....
I transitor necessari per le operazioni da compiere sono praticamente equivalenti.....
casomai in ogni stadio della pipeline lunga, dovendo svolgere operazioni + elementari, potrai mettere meno transistor...
ma i transistor di TUTTA la pipeline sono piu' o meno simili sia ke hai una pipeline corta che lunga.
i termini "corta" o "lunga" non indicano in alcun modo il numero di transistor totali della pipe, ma solo il numero di stadi utilizzati...

questo l'avevamo già chiarito io e fidel, poi lui ha posto questa domanda così, tanto per fare un'ipotesi...

Cioé tu prendi un'architettura, chessò, x86 a 100 milioni di transistor con una pipeline a 20 stadi.
Di questi 100 milioni di transistor, 60 sono usati per la pipeline e 30 per tutto il resto (cache eccetera).
Facendo una rapida divisione, 60/20=3, vuol dire che ogni stadio della pipeline ha 3 milioni di transistor.
A questo punto decidi che fai diventare la pipeline a 10 stadi facendo rimanere 3 milioni il numero di transistor per ogni stadio.
Ti avanzano 3*10=30 milioni di transistor (usando un wafer di silicio delle stesse dimensioni).
La sua domanda era: quei 30 milioni di transistor posso usarli x fare qualcos'altro?

Io comincerei col dire che innanzitutto le prestazioni con cui vengono eseguiti i processi sulla pipeline principale calerebbero di brutto (ovvio), secondariamente dico che quei 30 milioni di transistor, essendo ALTRO rispetto alla pipeline, probabilmente potrebbero essere utilizzati o per ampliare la cache on-die, oppure per mettere on-die un altro core, o con la stessa architettura o con un'architettura diversa... ad esempio una sorta di dsp ottimizzato per il calcolo floating point...
ma non so fino a che punto avrebbe senso stravolgere l'architettura di un processore in questo modo... tanto vale riprogettarlo da zero...

[-fidel-]

Originariamente inviato da ^TiGeRShArK^

non "avanzano" transitor da una pipeline....
I transitor necessari per le operazioni da compiere sono praticamente equivalenti.....
casomai in ogni stadio della pipeline lunga, dovendo svolgere operazioni + elementari, potrai mettere meno transistor...
ma i transistor di TUTTA la pipeline sono piu' o meno simili sia ke hai una pipeline corta che lunga.
i termini "corta" o "lunga" non indicano in alcun modo il numero di transistor totali della pipe, ma solo il numero di stadi utilizzati...

Sì in effetti dovresti rileggere i post precedenti

La domanda a questo punto resta: PERCHE' una pipe più lunga permette frequenze di clock più elevate, se ogni stadio di pipeline ha pressoché lo stesso numero di transistor sia che essa abbia più stadi o meno, e quindi i tempi di propagazione sono gli stessi?

[^TiGeRShArK^]

Originariamente inviato da darkquasar

questo l'avevamo già chiarito io e fidel, poi lui ha posto questa domanda così, tanto per fare un'ipotesi...

Cioé tu prendi un'architettura, chessò, x86 a 100 milioni di transistor con una pipeline a 20 stadi.
Di questi 100 milioni di transistor, 60 sono usati per la pipeline e 30 per tutto il resto (cache eccetera).
Facendo una rapida divisione, 60/20=3, vuol dire che ogni stadio della pipeline ha 3 milioni di transistor.
A questo punto decidi che fai diventare la pipeline a 10 stadi facendo rimanere 3 milioni il numero di transistor per ogni stadio.
Ti avanzano 3*10=30 milioni di transistor (usando un wafer di silicio delle stesse dimensioni).
La sua domanda era: quei 30 milioni di transistor posso usarli x fare qualcos'altro?

Io comincerei col dire che innanzitutto le prestazioni con cui vengono eseguiti i processi sulla pipeline principale calerebbero di brutto (ovvio), secondariamente dico che quei 30 milioni di transistor, essendo ALTRO rispetto alla pipeline, probabilmente potrebbero essere utilizzati o per ampliare la cache on-die, oppure per mettere on-die un altro core, o con la stessa architettura o con un'architettura diversa... ad esempio una sorta di dsp ottimizzato per il calcolo floating point...
ma non so fino a che punto avrebbe senso stravolgere l'architettura di un processore in questo modo... tanto vale riprogettarlo da zero...

appunto...
è sbagliato il ragionamento di fondo...
se per una pipeline a 20 stadi avrai bisogno di 3 milioni di transistor per ogni stadio, per una pipeline a 10 stadi avrai bisogno di circa 6 milioni di transitor ad ogni stadio..
quindi alla fine i transistor utilizzati nella pipeline sono sempre uguali sia con la pipe corta che con quella lunga...

[^TiGeRShArK^]

Originariamente inviato da -fidel-

Sì in effetti dovresti rileggere i post precedenti

La domanda a questo punto resta: PERCHE' una pipe più lunga permette frequenze di clock più elevate, se ogni stadio di pipeline ha pressoché lo stesso numero di transistor sia che essa abbia più stadi o meno, e quindi i tempi di propagazione sono gli stessi?

appunto..
una pipeline lunga permette frequenze piu' elevate perchè ogni stadio necessita di un numero minore di transistor dovendo fare operazioni piu' semplici di uno stadio di una pipeline corta che necessità di piu' transistor.

[-fidel-]

Originariamente inviato da ^TiGeRShArK^

appunto..
una pipeline lunga permette frequenze piu' elevate perchè ogni stadio necessita di un numero minore di transistor dovendo fare operazioni piu' semplici di uno stadio di una pipeline corta che necessità di piu' transistor.

Ok ora ho capito Il fatto è che non mi risultava che una pipe più corta dovesse fare operazioni più complesse ad ogni stadio rispetto ad una più lunga, da qui la necessità di usare più transistor ad ogni stadio di una pipe corta.

[^TiGeRShArK^]

perfetto

[sirus]

Originariamente inviato da darkquasar

Frena frena frena... tutte le innovazioni tecnologiche, per svariati motivi, vengono sempre introdotte PRIMA nelle soluzioni hardware high-end, cioé nel caso di Intel e AMD parlamo di server e workstation di fascia alta.
Sia IA64 che x86-64 sono state introdotte sul mercato su processori di fascia alta, rispettivamente Itanium e Opteron, solo che IA64 non ha avuto successo e quindi non é stata portata sui desktop, mentre x86-64 ha avuto successo eccome E PERCIO' é stata portata sui procesori di fascia desktop.
Non rimescoliamo le carte...
Limitandosi al confronto fra le soluzioni server, l'Opteron ha avuto molto più successo dell'Itanium...

mamma mia...
allora IBM (Power5) e SUN (Ultra SPARC4) hanno fallito con le loro architetture simil Itanium perché non le hanno portate sui desktop
non tutto nasce per essere immesso sul mercato desktop, nello specifico Itanium (1 prima e 2 dopo) ha prestazioni general purpose non degne di nota, questa CPU è adatta al calcolo matematico e poco altro ed è quello il motivo per cui è nata (e poi la IA64 nulla a che vedere con X86 ne tantomeno con X86-64 e non è minimamente paragonabile).

forse tu usi Windows che é ancora a 32 bit?
Comunque l'architettura K8 é ha 64 bit ma ha 1 riprogettazione intelligente in funzione di quello, che le permette di avere vantaggi notevoli anche nell'esecuzione di processi a 32 bit.
Mentre invece l'EMT64 é stato aggiunto ai Pentium solo come "una pezza" per stare dietro ad AMD, quindi sui processi a 32 bit non ha vantaggi prestazionali apprezzabili...

ovvio che uso Windows e Linux a 32bit, non dispongo di processori a 64bit, sai faccio upgrade del ogni 5/6 anni e l'ultima volta ho preso un P3 (ora con qualche € meno di 100 per l'esattezza ho preso mobo e memorie ed ho omontato un vecchio P4 1.8@2.4)
concordo con te che comunque l'implementazione dei 64bit Intel è "penosa" ed è una pezza, tuttavia da 3 anni a questa parte non si sono ancora visti i vantaggi dei 64bit, questo lo dovrai ammettere (con un Windows XP x64 disponibile in versione OEM e basta c'è poco da vedere)

vai errando in senso stretto perché AMD é uscita poco prima, ma soprattutto vai errando in senso lato perché i Dual-core AMD sono stati fin da subito accessibili da un'utenza molto più vasta degli intel, vista la differenza di costo iniziale.
E il dual core AMD é stato lanciato praticamente in contemporanea anche sulle soluzioni server con Opteron.
Se a ciò aggiungi che mentre AMD ha fatto i dual-core su un wafer unico, come si deve, ottimizzando i consumi, mentre Intel ha messo 2 wafer sullo stesso connettore, si osserva come Intel abbia lanciato i suoi dual core in contempoaranea con AMD giusto per poter dire "li abbiam fatti anche noi", ma la soluzione Intel inizialmente era MOLTO meno fruibile, anche in questo caso fatta per star dietro ad AMD che era in vantaggio sul tempo...

molto probabile che mi sbagli, ma comunque è questione di giorni e non di mesi comunque tu sbagli sui prezzi perché da subito le CPU DC Intel hanno avuto un prezzo inferiore agli AMD (ora invece stanno ad un livello simile)
per quanto riguarda il Core, i Pentium D 8xx e il Pentium XE 8xx avevano due core sullo stesso "pezzo" di silicio, mentre solo con la serie 9xx i core sono stati separati per permettere una maggior flessibilità delle linee produttive in favore dei costi.
(per la cronaca i Core Duo posseggono due CORE sullo stesso "pezzo" di silicio)

si ma il momento in cui AMD ha superato Intel mantenendo un'architettura con un numero ragionevole di stadi nella pipeline, é stato con l'introduzione dell'architettura K7.
La NetBurst di Intel é uscita dopo col P4 per cercare di recuperare, ma senza successo...
NetBurst ha "tenuto" sul piano delle vendite facendo leva sulla "pecoraggine" degli acquirenti che guardano il numero di MHz senza sapere cosa significa, ma non ha recuperato dal punto di vista tecnologico.

Quindi adesso Intel se torna ad un'architettura di QUELLA concezione, con molti meno stadi nella pipeline, deve rincorrere anche il K7, perché la migliore architettura mai avuta per le mani da Intel con QUEL tipo di pipeline era quella del Pentium3, che era inferiore all'architettura del K7.

Poi ripeto: magari il Conroe sarà meglio dei processori AMD, ma in tal caso questo significherà semplicemente che la "rincorsa" di Intel sarà riuscita!!


PS: il K7 é uscito quasi 4 anni prima del Banias, per la precisione 3 anni e 9 mesi prima.

sono con te quando dici che l'architettura NetBurst non era corretta ma bisognava continuare con l'architettura P6+ (Pentium III) però per un certo momento ha avuto i sui vantaggi
comunque non mi sento di dire che nel suo ritorno agli albori (P6+) Intel stiamo imitando AMD ne tantomeno che debba recuperare dato che la base di cui dispone (core Dothan, ora Yonah) è quantomeno alla pari con AMD nella maggior parte dei campi di utilizzo

[Saved_ita]

Vorrei sapere perchè la gente continua a sperare che su una CPU come questa venga supportato l'HT... guardando i bench, al momento già è difficile sfruttare due core e sulle CPU dualcore che hanno l'HT si vedono solo skazzi del SO (con addirittura cali di prestazioni).
Oltre a questo, ovviametne stiamo ancora aspettando, in ambito Home user dei software veramente ottimizzati per i dualcore perchè è impossibile pretendere che l'HT (o i dualcore) abbiano giovamenti in programmi non ottimizzati per il multithreading e di conseguenza, gli unici ambiti in cui si traggono giovamenti, sono il multitasking.
Io smetterei quindi di dire che l'HT serve ad ottimizzare l'uso delle pipe lunghe perchè senza software adatto, l'unico vantaggio che si ha, lo si ha nel multitasking.
Questo però và anche ridimensionato perchè al giorno d'oggi, solo nei bench delle recensioni non si fà uso di multitasking sul PC e solo per questo un P4 HT può essere ancora paragonato ad un Athlon XP e ci si può permettere di dire che reggevano il confronto perchè, nella realtà, fare partire due applicazioni contemporaneamente, significava vedere crollare gli XP (e ancora adesso con gli A64).
Per quanto mi riguarda, sebbene AMD abbia progettato molto prima i dualcore (ovvero gli A64 sono usciti con in progetto la funzione di dualcore... ad esempio già sugli A64 singlecore era presente il SRQ... inutilizzato ma c'era)... ormai si stà "fossilizzando".
Effettivamente c'è da dire che sulle estensioni a 64bit è in vantaggio... ma è proprio questo che c'è di innovativo nei Merom, il fatto che dovrebbero essere una 64bit nativa (anzichè lo Yonah o i Conroe) e, a quanto pare, ormai in casa Intel hanno abbandonato l'idea di usare l'ambito server come segmento top per introdurre le innovazoioni e sia passato all'ambito Notebook per sfornare i prodotti più evoluti.
Io non capisco poi a cosa serva dire chi rincorre chi: Intel con la Netburst ha avuto il suo momento di superiorità... e manco troppo breve... e ancora adesso in svariati ambiti non la si può certo considerare fallimentare (se non per i consumi).
Di sicuro, nelle varie case a livello di progettazione sono molto più avanti di quanto si sappia per cui, dire cosa è uscito prima è assolutamente ridicolo: magari Intel o AMd hanno sfornato un certo prodotto solo dopo averlo tenuto nel cassetto per anni.

[-fidel-]

Originariamente inviato da sirus

tuttavia da 3 anni a questa parte non si sono ancora visti i vantaggi dei 64bit, questo lo dovrai ammettere (con un Windows XP x64 disponibile in versione OEM e basta c'è poco da vedere)

Con XP 64 non saprei, io ho provato linux con kernel a 64 bit e i miglioramenti li ho visti in ambito videostreaming (per ovvii motivi), poi non ho potuto fare test più approfonditi in ambito general purpose. Per quello che ho potuto provare, miglioramenti generali non ne ho visti. D'altro canto, a volte l'architettura 64 bit porta svantaggi sugli algoritmi di calcolo, che farebbero volentieri a meno dell'allineamento dei puntatori in memoria sui 64 bit. Magari bisogna aspettare ancora un po' per vedere miglioramenti (se ce ne saranno)? La possibilità però di superare il limite dei 4 giga di memoria sta diventando sempre più allettante, visto anche il cerescente aumento delle risorse richieste dalle applicazioni anche non di fascia server.
Sarà un caso, ma proprio ieri dovevo masterizzare un file di 4,2 giga e K3b mi ha detto "Impossibile masterizzare files più grandi di 4 Gigabytes" Non so se questo limite sia superabile però, non mi intendo a livello programmativo della masterizzazione.

[-fidel-]

Originariamente inviato da Saved_ita

Io smetterei quindi di dire che l'HT serve ad ottimizzare l'uso delle pipe lunghe perchè senza software adatto, l'unico vantaggio che si ha, lo si ha nel multitasking.

Evidentemente non hai letto i post precedenti. Per quanto mi riguarda, ho proprio affermato che il multitasking e il multithreading nella tecnologia HT va ad ottimizzare l'uso della pipe più lunga.
Va da sè che senza multitasking/multithreading, i miglioramenti della tecnologia HT non esistono. Meglio leggere prima di postare
Per il resto quoto quasi tutto

[darkquasar]

Originariamente inviato da ^TiGeRShArK^

appunto...
è sbagliato il ragionamento di fondo...
se per una pipeline a 20 stadi avrai bisogno di 3 milioni di transistor per ogni stadio, per una pipeline a 10 stadi avrai bisogno di circa 6 milioni di transitor ad ogni stadio..
quindi alla fine i transistor utilizzati nella pipeline sono sempre uguali sia con la pipe corta che con quella lunga...

eh, dipende... in linea di massima sì... se vuoi mantenere un processore che abbia un'architettura dalla complessità paragonabile...
ma se ti accontenti di un'architettura molto meno evoluta, puoi diminure il numero di stadi della pipeline lasciando invariato il numero di transistor per ogni stadio.
Ovviamente l'architettura cambia diventando meno complessa, quindi gli stadi della pipeline pur mantenendo lo stesso numero di transistor non saranno UGUALI ai precedenti, perché con la metà dei transistor totali devono svolgere gli stessi compiti...
Infatti se noti ho scritto che in questa ipotesi, sulla pipeline ci sarebbe un calo pesante di prestazioni nell'esecuzione dei processi, proprio perché si avrebbe un'involuzione dell'architettura...

Ovviamente siamo nel campo delle ipotesi eh...
era per rispondere alla domanda di fidel!!


PS: per fare un esempio, il Pentium MMX aveva 4,5 milioni di transistor, mentre il primo Pentium 3 (core Katmai a 250nm) aveva 9,5 milioni di transistor.
Cioé: puoi ridurre il numero totale di transistor, ovviamente TORNANDO ad un'architettura molto meno evoluta
(e poi per la domanda di fidel, coi transistor che ti avanzano puoi fare altre cose)

[darkquasar]

Originariamente inviato da sirus

mamma mia...

...dammi 100 lire che in America voglio andaaaaaaaaaar!

Originariamente inviato da sirus

allora IBM (Power5) e SUN (Ultra SPARC4) hanno fallito con le loro architetture simil Itanium perché non le hanno portate sui desktop
non tutto nasce per essere immesso sul mercato desktop, nello specifico Itanium (1 prima e 2 dopo) ha prestazioni general purpose non degne di nota, questa CPU è adatta al calcolo matematico e poco altro ed è quello il motivo per cui è nata (e poi la IA64 nulla a che vedere con X86 ne tantomeno con X86-64 e non è minimamente paragonabile).

1) allora innanzitutto sta di fatto che Intel aveva intenzione di portare IA64 anche sui desktop ma ha dovuto abbandonare il progetto. Poi é ovvio che non tutte le soluzioni server vengono portate su desktop, ma nelle intenzioni di Intel, IA64 doveva esserlo, infatti dentro Itanium inizialmente era incluso un "emulatore" hardware per le istruzioni a 32 bit.
2) Dici che IA64 non é neanche lontanamente paragonabile a x86-64: dal punto di vista tecnico e architetturale certo che non lo é, ma nel campo delle prestazioni nel medesimo ambito applicativo (in parole povere, sul mercato), i fatti parlano chiaro: Opteron ha avuto la meglio...
(e infatti io li stavo paragonando da QUEL punto di vista, cioé quello dei risultati, é ovvio che le architetture siano MOLTO diverse... )

Originariamente inviato da sirus

ovvio che uso Windows e Linux a 32bit, non dispongo di processori a 64bit, sai faccio upgrade del ogni 5/6 anni e l'ultima volta ho preso un P3 (ora con qualche € meno di 100 per l'esattezza ho preso mobo e memorie ed ho omontato un vecchio P4 1.8@2.4)

ti capisco, anch'io cambio il mio hardware di rado, purtroppo i soldi non crescono sugli alberi

Originariamente inviato da sirus

concordo con te che comunque l'implementazione dei 64bit Intel è "penosa" ed è una pezza, tuttavia da 3 anni a questa parte non si sono ancora visti i vantaggi dei 64bit, questo lo dovrai ammettere (con un Windows XP x64 disponibile in versione OEM e basta c'è poco da vedere)

x quanto riguarda windows: anche con windows a 32bit ci sono stati notevoli vantaggi nel passaggio dall'architettura AMD K7 all'architettura AMD K8, proprio per i motivi che dicevo prima... certo che avendo un Intel, passando da un P4 senza EMT64 a un P4 con EMT64, di differenza non se ne vede manco l'ombra...
Ad ogni modo, x chi usa linux, c'é a 64 bit già da MOOOOLTO tempo, ed é perfettamente uguale a quello a 32 bit (stesse applicazioni ecc), non come Windows 64bit che ha il problema della compatibilità delle applicazioni...

Originariamente inviato da sirius

molto probabile che mi sbagli, ma comunque è questione di giorni e non di mesi comunque tu sbagli sui prezzi perché da subito le CPU DC Intel hanno avuto un prezzo inferiore agli AMD (ora invece stanno ad un livello simile)
per quanto riguarda il Core, i Pentium D 8xx e il Pentium XE 8xx avevano due core sullo stesso "pezzo" di silicio, mentre solo con la serie 9xx i core sono stati separati per permettere una maggior flessibilità delle linee produttive in favore dei costi.
(per la cronaca i Core Duo posseggono due CORE sullo stesso "pezzo" di silicio)

Si ma come ti diceva qulacun altro nel thread, al di là che i 2 "quadratini" di silicio siano uniti o divisi, rimane la questione che ti ha detto prima anche tigershark, cioé (lo quoto così facciam prima ):

Originariamente inviato da ^TiGeRShArK^

mentre i PD sono semplicemente due core attaccati con necessità di scambiarsi i dati tra le cache passando per l'FSB esterno, i dual core AMD hanno una soluzione molto piu' raffinata che permette di scambiarsi i dati tra le due cahce SENZA uscire dal chip per mezzo di una System Request Queue e di un Crossbar Switch.

ripeto, questo indipendentemente che i 2 "quadratini" di silicio sui processori intel siano attaccati o divisi.

Originariamente inviato da sirius

sono con te quando dici che l'architettura NetBurst non era corretta ma bisognava continuare con l'architettura P6+ (Pentium III) però per un certo momento ha avuto i sui vantaggi

non dico che "bisognava", osservo semplicemente che in quel momento Intel era molto in difficoltà nei confronti di AMD, e non ha saputo far di meglio che tirare fuori dal cappello l'architettura NetBurst, che doveva, nelle sue previsioni:
1) inizialmente "tenere" sul piano delle vendite grazie alla pubblicità che deriva dall'alto numero di MHz (quindi grazie a un "falso" vantaggio prestazionale)
2) alla lunga superare e distaccare gli AMD grazie all'aumento vertigionoso dei MHz (quindi grazie a un "vero" vantaggio prestazionale)
Obiettivo 1 raggiunto, obiettivo 2 cannato in pieno, quindi per non farsi travolgere da AMD stanno correndo ai ripari.

Originariamente inviato da sirius

comunque non mi sento di dire che nel suo ritorno agli albori (P6+) Intel stiamo imitando AMD ne tantomeno che debba recuperare dato che la base di cui dispone (core Dothan, ora Yonah) è quantomeno alla pari con AMD nella maggior parte dei campi di utilizzo

insomma...

[-fidel-]

Originariamente inviato da darkquasar

x quanto riguarda windows: anche con windows a 32bit ci sono stati notevoli vantaggi nel passaggio dall'architettura AMD K7 all'architettura AMD K8, proprio per i motivi che dicevo prima... certo che avendo un Intel, passando da un P4 senza EMT64 a un P4 con EMT64, di differenza non se ne vede manco l'ombra...
Ad ogni modo, x chi usa linux, c'é a 64 bit già da MOOOOLTO tempo, ed é perfettamente uguale a quello a 32 bit (stesse applicazioni ecc), non come Windows 64bit che ha il problema della compatibilità delle applicazioni...

Come ho scritto nel precedent post, almeno usando linux, grandi incrementi di prestazioni non ne ho visti. Ribadisco (al massimo rileggere il mio precedente post ) sulle (non moltissime) prove che ho avuto modo di fare, ho avuto miglioramenti nel video streaming, ma non ho apprezzato miglioramenti sostanziali dall'uso dei 64 bit. Almeno io non me ne sono accorto.
Hai dei bench seri effettuati da terzi in proposito?

[sirus]

Originariamente inviato da darkquasar

...
ti capisco, anch'io cambio il mio hardware di rado, purtroppo i soldi non crescono sugli alberi

già...ma tra poco arriverà il notebook (causa progetti universitari)

x quanto riguarda windows: anche con windows a 32bit ci sono stati notevoli vantaggi nel passaggio dall'architettura AMD K7 all'architettura AMD K8, proprio per i motivi che dicevo prima... certo che avendo un Intel, passando da un P4 senza EMT64 a un P4 con EMT64, di differenza non se ne vede manco l'ombra...
Ad ogni modo, x chi usa linux, c'é a 64 bit già da MOOOOLTO tempo, ed é perfettamente uguale a quello a 32 bit (stesse applicazioni ecc), non come Windows 64bit che ha il problema della compatibilità delle applicazioni...

un momento...
se si usa Windows XP x32 i vantaggi dal K7 al K8 sono tutti dovuti al miglioramento architetturale e non hai 64bit, infatti utilizzando un compilatore assembly con annesso debugger i registri della CPU vengono visti a 32bit
con Windows XP x64 concordo con te che con AMD64 ci sono più vantaggi che con EM64T (che è a mio modo di vedere male implementata)
comunque le distro Linux 64bit sono ancora un po' acerbe e non c'è molto software!!!

Si ma come ti diceva qulacun altro nel thread, al di là che i 2 "quadratini" di silicio siano uniti o divisi, rimane la questione che ti ha detto prima anche tigershark, cioé (lo quoto così facciam prima ):

ripeto, questo indipendentemente che i 2 "quadratini" di silicio sui processori intel siano attaccati o divisi.

vero semplicemente perché quando si è trattato di introdurre i DUAL CORE in Intel si era già deciso che NetBurst sarebbe morta di li a breve e che qualsiasi sviluppo successivo sarebbe solo stato uno spreco.

non dico che "bisognava", osservo semplicemente che in quel momento Intel era molto in difficoltà nei confronti di AMD, e non ha saputo far di meglio che tirare fuori dal cappello l'architettura NetBurst, che doveva, nelle sue previsioni:
1) inizialmente "tenere" sul piano delle vendite grazie alla pubblicità che deriva dall'alto numero di MHz (quindi grazie a un "falso" vantaggio prestazionale)
2) alla lunga superare e distaccare gli AMD grazie all'aumento vertigionoso dei MHz (quindi grazie a un "vero" vantaggio prestazionale)
Obiettivo 1 raggiunto, obiettivo 2 cannato in pieno, quindi per non farsi travolgere da AMD stanno correndo ai ripari.

obiettivo 1 raggiunto in pieno direi il 2 è stato raggiunto per un certo periodo e ciò è a mio modo di vedere innegabile quando sono apparsi i Northwood C i Pentium 4 dominavano il mercato

comunque sono solo felice di questo "ritorno al passato" di Intel

[darkquasar]

Originariamente inviato da -fidel-

Come ho scritto nel precedent post, almeno usando linux, grandi incrementi di prestazioni non ne ho visti. Ribadisco (al massimo rileggere il mio precedente post ) sulle (non moltissime) prove che ho avuto modo di fare, ho avuto miglioramenti nel video streaming, ma non ho apprezzato miglioramenti sostanziali dall'uso dei 64 bit. Almeno io non me ne sono accorto.
Hai dei bench seri effettuati da terzi in proposito?

no non ho "bench seri effettuati in proprosito", d'altra parte bench su linux non saprei così su 2 piedi dove andarli a trovare.

Comunque, io non ho mica capito se hai fatto 'sti test con una CPU Intel o AMD, ma io ho provato a vedere linux x32 e linux x64 sulla stessa macchina, AMD Athlon 64, e l'aumento di prestazioni si vede.

Poi benchmark non ne ho... io non sono un grande appassionato di benchmark... e se trovo un benchmark in giro leggendo 1 articolo, di certo non sono quello che si tiene il bookmark per usarlo come argomento nei forum!!!

[darkquasar]

Originariamente inviato da sirus

già...ma tra poco arriverà il notebook (causa progetti universitari)


un momento...
se si usa Windows XP x32 i vantaggi dal K7 al K8 sono tutti dovuti al miglioramento architetturale e non hai 64bit, infatti utilizzando un compilatore assembly con annesso debugger i registri della CPU vengono visti a 32bit

Ma come fai a separare, da questo punto di vista, il "miglioramento architetturale" dai "64 bit"?
E' la stessa cosa...
Cioé: tu devi progettare una CPU che supporti 32 e 64 bit, qui gli approcci possibili sono molteplici:
==> AMD x86-64: fare un'architettura sfruttabilile in maniera ottimale sia a 32bit che a 64 bit, in questo modo anche facendo girare applicazioni a 32 bit si hanno miglioramenti rispetto alla vecchia architettura
==> Intel x86-32+EMT64: classica architettura a 32 bit con "appeso" il supporto a 64 bit, risultato: a 32 bit é uguale, e i 64 bit non sono ben sfruttati
==> Intel IA64 (itanium) con "appesa" emulazione hardware x86-32: prestazioni ottimali a 64 bit (sulla carta migliori di x86-64, nella realtà soltanto forse in alcuni ambiti ), prestazioni ridicole a 32 bit.

Sono diversi approcci, ma non é che puoi separare le 2 cose... é come dire che le prestazioni del motore di una macchina sono dovute al numero dei cilindri e non alla cilindrata totale!!

Originariamente inviato da sirus

con Windows XP x64 concordo con te che con AMD64 ci sono più vantaggi che con EM64T (che è a mio modo di vedere male implementata)
comunque le distro Linux 64bit sono ancora un po' acerbe e non c'è molto software!!!

Non capisco a che ti riferisci...
Le distro Linux a 64 bit sono le stesse che vedi a 32 bit, soltanto ricompilate a 64bit, quindi le applicazioni sono le stesse, perché la quasi totalità del software linux é open-source!!

Originariamente inviato da sirus

vero semplicemente perché quando si è trattato di introdurre i DUAL CORE in Intel si era già deciso che NetBurst sarebbe morta di li a breve e che qualsiasi sviluppo successivo sarebbe solo stato uno spreco.

ah certo, questo può anche darsi, non lo metto in dubbio, ma il discorso che facevo io é semplicemente che il dual-core Intel é molto meno raffinato di quello AMD!!

Originariamente inviato da sirus

obiettivo 1 raggiunto in pieno direi

ah su questo siam d'accordo!!

Originariamente inviato da sirus

il 2 è stato raggiunto per un certo periodo e ciò è a mio modo di vedere innegabile quando sono apparsi i Northwood C i Pentium 4 dominavano il mercato

C'é stato un momento in cui i Pentium 4 prestazionalmente, si sono avvicinati agli Athlon ma poi sono stati ridistaccati perché Intel ha incontrato le difficoltà tecniche che dicevo prima nel salire di MHz, ma il motivo per cui "dominavano il mercato" come dici tu, é lo stesso del punto 1...

Originariamente inviato da sirus

comunque sono solo felice di questo "ritorno al passato" di Intel

mi verebbe da dire:
"anche a me, perché se si ravviva la concorrenza per noi utenti é sempre un bene"
ma purtroppo si osserva empiricamente (!! ) che per motivi "inspegabili", Intel abbia lo stesso in pugno tutt'ora una quota di mercato che é un multiplo di quella di AMD!!
Quindi se Intel recupera terreno, più che ravvivarsi la concorrenza ricomincia ad andare in coma...

[-fidel-]

Originariamente inviato da darkquasar

no non ho "bench seri effettuati in proprosito", d'altra parte bench su linux non saprei così su 2 piedi dove andarli a trovare.

Nono dicevo bench in generale, non solo per linux

Originariamente inviato da darkquasar

Comunque, io non ho mica capito se hai fatto 'sti test con una CPU Intel o AMD, ma io ho provato a vedere linux x32 e linux x64 sulla stessa macchina, AMD Athlon 64, e l'aumento di prestazioni si vede.

Provato su un Amd Athlon 64, installato sia linux 32 sia 64. Usato qualche giorno Si i miglioramenti c'erano, ma non in general purpose. Sostanziali in videostreaming, nell'uso quotidiano non me ne sarei accorto se non avessi saputo che c'era installata la versione 64 bit. Ah, tutto questo è pura impressione personale, non ho fatto alcun test di prestazioni (tipo tempo avvio programmi ecc.). Però siamo sulla buona strada

[leoneazzurro]

Originariamente inviato da ^TiGeRShArK^

non "avanzano" transitor da una pipeline....
I transitor necessari per le operazioni da compiere sono praticamente equivalenti.....
casomai in ogni stadio della pipeline lunga, dovendo svolgere operazioni + elementari, potrai mettere meno transistor...
ma i transistor di TUTTA la pipeline sono piu' o meno simili sia ke hai una pipeline corta che lunga.
i termini "corta" o "lunga" non indicano in alcun modo il numero di transistor totali della pipe, ma solo il numero di stadi utilizzati...

Insomma.. non è proprio così: a parte il fatto che architetture come quella del P4 e degli Athlon (e PIII) non sono confrontabili in maniera diretta (perchè nonostante siano entrambi processori X86 le differenze architetturali sono notevoli, basti pensare alle differenze tra la cache L1 degli Athlon e la trace cache dei P4, che sposta lo stadio di decodifica a monte delle pipeline, al diverso execution core, all'hyperthreading, ecc.) normalmente anche gli stadi in più servono a fare svolgere al singolo stadio meno lavoro, la circuiteria di controllo e di sincronizzazione della pipeline cresce all'aumentare del numero degli stadi, per cui è molto più probabile che pipeline più lunghe portino all'aumento del numero dei transistor totali che non delle pipeline più corte (a parità di "lavoro teorico totale" su tutti gli stadi, cosa che non ha poi un gran senso in realtà). tra l'altro nei P4 ci sono almeno 2 stadi di pipeline detti di "drive", che praticamente non svolgono nessun lavoro se non quello di trasmettere il segnale allo stadio successivo

[darkquasar]

Originariamente inviato da -fidel-

Nono dicevo bench in generale, non solo per linux

eh ma "bench in generale", se vuoi testare il vantaggio dei 64 bit, Windows a 32 bit non va bene, quindi o li fai su Windows a 64 bit oppure su linux a 64 bit.
Siccome Windows a 64bit é ancora poco supportato non credo ci siano in giro molti benchmark, quindi bisogna "accontentarsi" di quelli su linux...

Originariamente inviato da -fidel-

Provato su un Amd Athlon 64, installato sia linux 32 sia 64. Usato qualche giorno Si i miglioramenti c'erano, ma non in general purpose. Sostanziali in videostreaming, nell'uso quotidiano non me ne sarei accorto se non avessi saputo che c'era installata la versione 64 bit. Ah, tutto questo è pura impressione personale, non ho fatto alcun test di prestazioni (tipo tempo avvio programmi ecc.). Però siamo sulla buona strada

ah vabbé...
cmq dipende anche cosa intendi per "uso quotidiano", perché se intendi la lettura della posta elettronica, lì il collo di bottiglia é l'hard disk, cioé voglio dire in quanto a elaborazione dati é ovvio che non vedi differenze sostanziali tra cpu di ultima generazione e cpu di 2/3 anni fa... indipendentemente dal fatto che siano a 32 o a 64 bit.