Link alla notizia: http://news.hwupgrade.it/10675.html

Tejas verrà presentato alla fine del prossimo anno, dopo che Intel avrà lanciato tutti i modelli di Prescott fino a 3.60GHz

Click sul link per visualizzare la notizia.

dopo il socket T un'altro........
IL Nehalem sarà basato su una tecnologia non puramnete Netburst? Significa che Intel ha intenzione di fare un passo indietro oppure di raddoppiare gli stadi delle pipeline?

è inevitabile che prima o poi intel si ritrovi ad abbandonare la salita ai mhz in favore dell'efficenza architetturale.
Se continua di questo passo altrimenti avremo cpu raffreddate ad azoto liquido, in gradi di compiere una operazione ogni 600 cicli di clock ma operante a 8ghz con prestazioni pari ad un P3 450mhz.

Troppo casino....cmq 1gb di fsb...chissà dove si arriva in OC...spero che la ram vada di pari passo se no saranno guai......

Ma il Prescott 3.60 sarà commercializzato anche con socket 478??

"...specularmente alla strategia che verrà adottata per Prescott, ovvero dapprima compatibile con socket 478 e successivamente compatibile con Socket T.
"

Sembra di si riva.dani.

x lasa
nn credo che le ram siano il vero limite in futuro
e mi limito a questo altrim andiamo a vedere gli hdd, ecc...:D

secondo voi ci sarà un ritorno alle memorie rambus ???
secondo me con il bus a 1066 potrebbero rientrare a pieno ritmo

non credo che i costruttori di ram rimarranno a guardare , infatti se ricordi è molto interessante la soluzione di via che ha presentato una ram in grado di scambiare 4 dati per ciclo di clock , una doppia ddr in pratica , rimane da vedere le latenze e tutto il resto , ma due banchi in configurazione a 128bit , di banda ne garantiscono , eppoi sulle schede video le ram vanno già molto veloci , certo il loro costo per il momento è spropositato per un utilizzo come ram di sistema , ma le soluzioni certo non mancano .
D'ACCORDISSIMO CON RAVEMAN gli hd pata o sata sono il collo di bottiglia , e gli scsi sono troppo relegati alla fascia PROFFESIONALE ( anche perchè la controller mica te la tirano dietro )

Beh, per fine 2004 dovrebbero essere già uscite le DDR2 no?
Ciao.

no , le rimm sona già mrte e sepolte.. le ddr2 ono molto promettenti e performanti...

rambus sta per tornare alla ribalta con nuove memorie a loro dire ultra potenti, ma con un buon rapporto prezzo-prestazioni (la causa della loro rovina)

in sostanza credo ke le nuove rambus saranno molto performanti, ma per la loro data di uscita dovranno competere con le ddr2, che costano molto anche loro...... vedremo

I sata saranno a 750 mb al secondo nel 2005

il controller si....

ma non so se la meccanica del disco riuscira a riempire tutta questa banda ad un costo accettbile...

Guardate che ci sono gia memorie capaci di operare a frequenze di 533 MHz, quindi se affiancata ad una piastra con controller DDR dual-channel si ottera 533*2 = 1066 MHz bus , considerando che le cosair si trovano gia in vendita , e considerando che questi processori non usciranno prima di 2 anni io non mi starei a preuccupare della Ram, sicuramente non credo che vengano riutillizate le rambus! Io ho letto sul sito della silicon Image ,una delle principali costruttrici di controller serial-Ata che i controller arriveranno a 600 MB/s entro i prossimi 6 anni, quindi non credo per il 2005 ma piuttosto credo verso la fine del deccenio 2008-2010! A proposito ho fatto dei test con il mio xp 2800+ Barton , con windows server 2003 ita, e mi sembra che giri un pochino più veloce che sotto a win xp professional, qualcuno a gia fatto la prova??? Adesso voglio provare con il pc che sto scrivendo un Pentium 4 3.00 GHz bus 800 MHz , se qualcuno a fatto dei test con windows xp li confronti con i miei per verificare se windows server 2003 è effettivamente più veloce! Ciao a tutti

test xp 2800+ Gigabite KT400 Ultra windows server 2003 enterprise edition ita
http://service.futuremark.com/compare?pcm=1476676

teste Pentium 4 3.00 GHz P4C800 deluxe windows xp professional

http://service.futuremark.com/compare?pcm=1344369

Notate come viaggia di più Hardisk sotto windows 2003 server nonstante nel Pentium 4 l'Hardisk sia Serial Ata mentre quello dell'Athlon xp sia Ata-133

IL problema non è del controller ma del disco che non ne riescea saturare la banda, vi ricordo anche noi che usiamo dischi ata 100\133 o sata da 7200 rpm non raggiungiamo quasi mai nell'utilizo quotidiano un transferrate ssuperiore a 40 mb\s un un controler in grado di spostarne 750 non porta alcun beneficio. D'altronde penso che ormai l'attuale tecnologia degli hard disk sia ad un punto morto perchè per aumentare il bitrate bisogna aumentare il numero di rotazioni ma è quasi impossibile andare sopra i 15000, bisognerebbe puntare quindi su tecnologie completamente nuove (penso memorie magnetiche). Per quanto riguarda intel questa sua politica di continui cambi di soket mi ha rotto i cosiddetti; per esempio io ho istallato su una p4p800 un 2.4@3160 fiducioso di poter upgradare a basso costo tra un anno con uno degli ultimi prescot 478 j(e di portarlo parecchio sopra i 4 ghz) invece sono rimasto fregato come lo rimarra in fuutro chi cechera di compiere al mia stessa operazione

Le ram rispetto agli anni passati si stanno evolovendo in modo incredibile e secondo me il limite potrebbe di nuovo essere il bus della cpu. La soluzione di Via che è stata applicata alle ddr 1 può essere applicata benissimo alle ddr2 e si riuscirebbe a superare i 20 gb/s. Attualmente il bus che satura la banda effetiva delle ram è quello di Intel; Amd è riuscita ad abbassare le latenze ma il bus di Intel riesce a fornire la banda necessaria per sfruttare a pieno le attuali ram. Adesso ci sono anche le ddr 533 che hanno latenze alte (ma rispetto alle rambus) però permetterebbe di sfruttare il bus a 1066 ma la soluzione di via che riesce a generare un bandwith da 12,8 gb/s con delle ddr400 già inizierebbe a far sentire i limiti del bus che con un soluzione anologa con le ddr2 segneebbe un distacco netto. Intel cmq potrebbe sviluppare un bus a 64/128bit e già lo ha fatto con l'itanium 1 mi pare ma in soluzione ddr. AMd dovrbebe aggiungere un seconda connessione Ht o alzare la frequenza o ampiare anche lei il bus. Sulle ram ormai non ci bisogna + preoccupare, le rambus sono morte e sepolte e quello che si può fare con le rambus si riesce a fare lo stesso e anche meglio con le ddr (il sis quad channel con rambus 1200 generava 9,6gb/s, la soluzione di via 12,8gb/s (3,2 gb/s in +) a costo inferiore).
Il futuro è nelle ddr perché si sono affermate a furor di popolo, le rambus volevano essere imposte dall'alto.
Per gli HD dovrà passare parecchia acqua sotto i ponti e secondo me considerando la loro durata è meglio che migliorino prima la qualità (Gli IBM ernao i + veloci ma si rompevano dopo 1 mese :( :( :( )

Originariamente inviato da sslazio
è inevitabile che prima o poi intel si ritrovi ad abbandonare la salita ai mhz in favore dell'efficenza architetturale.
Se continua di questo passo altrimenti avremo cpu raffreddate ad azoto liquido, in gradi di compiere una operazione ogni 600 cicli di clock ma operante a 8ghz con prestazioni pari ad un P3 450mhz.
io invece penso che le pipeline aumenteranno ancora, e lo dico perche' e' sancito dai fatti che siamo arrivati ad un punto in cui e' piu' efficiente l'architettura "a bassa latenza" rispetto a quella "a basso impatto degli stalli". Athlon, con le sue pipeline a stadi complessi, non riesce piu' a salire, causa latenze, e sebbene abbia minor danno dallo stallo della pipeline, appunto perche' sono piu' corte e servono meno clock per vuotarle, alla fine il numero di operazoini che riesce a portare a temine a parita' di tempo e' minore di quello dei P4.
Il guaio e' che Athlon, per salire, deve abbassare le latenze intrinseche dei transistor, cosa possibile sono con nuove tecnologie. Tutti sanno che non siamo piu' agli albori della tecnologia elettronica e ormai per avere miglioramenti significativi devono passare 2-3 anni, e questo tempo e' destinato ad allungarsi. Io penso che gia' a0,09 micron le rese produttive saranno comunque piu' basse di quelle attuali, non penso si possa arrivare a dei fantomatici 0,001 micron o cose cosi', e SOI ho l'impressione che sia molto meno utile del previsto.
In questo contesto, aumentare il numero degli stadi di pipeline, semplificandoli, quindi riducendo le latenze del singolo stadio e potendo cosi' salire di piu' in frequenza, e' la mossa giusta, perche' grazie ai quantitativi di cache sempre maggiori e ad algoritmi di previsione dei salti (nonche' di programmi scritti apposta) il rischio di stallo della pipeline si sta riducendo moltissimo.
L'efficienza intrinseca dell'architettura dell'athlon non e' superiore a quella del P4, ma, anzi, viene ad essere inferiore quando, a parita' di tempo, elabora meno operazioni. Il confronto sull'efficienza ha senso solo sull'unita' di tempo, non sul clock, perche' quello che noi percepiamo e' il tempo, e l'unica differenza che vediamo e' che un processore impega 10 secondi e l'altro 12 a fare un rendering, non che uno elabora 1M di dati per clock a 100 Hz e l'altro 200K a 1000Hz.
Poi e' sicuro che se si vuole salire in potenza,bisogna salire in consumo, e su questo la frequenza di clock non mi pare abbia un'importanza fondamentale; molto di piu' lo ha la tecnologia utilizzata.

Originariamente inviato da +Benito+
io invece penso che le pipeline aumenteranno ancora, e lo dico perche' e' sancito dai fatti che siamo arrivati ad un punto in cui e' piu' efficiente l'architettura "a bassa latenza" rispetto a quella "a basso impatto degli stalli". Athlon, con le sue pipeline a stadi complessi, non riesce piu' a salire, causa latenze, e sebbene abbia minor danno dallo stallo della pipeline, appunto perche' sono piu' corte e servono meno clock per vuotarle, alla fine il numero di operazioni che riesce a portare a temine a parita' di tempo e' minore di quello dei P4.


Nel confronto tra Athlon e P4 c'è (giustamente) la tendenza a confrontare la CPU nel suo complesso. Però nel dare giudizi su "efficienza" e "architettura interna" non mi sembra l'approccio corretto.

Certo, l'Athlon è mediamente meno potente, però si deve tenere conto di diversi fattori. Per esempio il FSB è di gran lunga meno capace, al punto che le architetture a doppio banco di RAM non danno praticamente nessun vantaggio. Poi c'è la questione delle SSE2 del P4, che non presenti nell'Athlon. Altro dettaglio non da poco è la maturità dei processi tecnoligici del silicio, che danno a Intel un vantaggio di 6-9 mesi su AMD.

In un discorso complessivo è corretto trascurare questi fattori, perché si sta confrontando due CPU prese dallo scaffale del rivenditore. Se invece si confrontano le architetture interne per cercare di stabilire quale sia il migliore "core", non mi sembra l'approccio migliore.


Io penso che gia' a0,09 micron le rese produttive saranno comunque piu' basse di quelle attuali, non penso si possa arrivare a dei fantomatici 0,001 micron o cose cosi', e SOI ho l'impressione che sia molto meno utile del previsto.


Sono d'accordo con il fatto che le rese produttive saranno sempre più basse, ma proprio per questo occorre migliorare i processi già noti con le note tecniche "strained silicon", "matertiali low-k" e SOI.


In questo contesto, aumentare il numero degli stadi di pipeline, semplificandoli, quindi riducendo le latenze del singolo stadio e potendo cosi' salire di piu' in frequenza, e' la mossa giusta, perche' grazie ai quantitativi di cache sempre maggiori e ad algoritmi di previsione dei salti (nonche' di programmi scritti apposta) il rischio di stallo della pipeline si sta riducendo moltissimo.


Purtroppo la cache non ha alcun impatto sulla riduzione del rischio di stallo, semmai riduce l'entità dello stallo. La previsione dei salti riduce effettivamente il rischio degli stalli, ma preferisco di più l'approccio "predicated execution" usato nella famiglia Itanium.

Inoltre, con l'aumento indiscriminato degli stadi di pipeline, oltre ai noti problemi di consumo e impatto degli stalli, ci sono dei problemi intrinseci che non possono essere trascurati.

http://www.lithium.it/articolo.asp?code=52&pag=7


L'efficienza intrinseca dell'architettura dell'athlon non e' superiore a quella del P4, ma, anzi, viene ad essere inferiore quando, a parita' di tempo, elabora meno operazioni. Il confronto sull'efficienza ha senso solo sull'unita' di tempo, non sul clock, perche' quello che noi percepiamo e' il tempo, e l'unica differenza che vediamo e' che un processore impega 10 secondi e l'altro 12 a fare un rendering, non che uno elabora 1M di dati per clock a 100 Hz e l'altro 200K a 1000Hz.


Ci sono due figure di merito per i processori: le Instruction Per Clock, considerata una misura di efficienza, e le Instruction Per Second, più noto come MIPS, considerata una misura di potenza fuori tutto.


Poi e' sicuro che se si vuole salire in potenza,bisogna salire in consumo, e su questo la frequenza di clock non mi pare abbia un'importanza fondamentale; molto di piu' lo ha la tecnologia utilizzata.

In realtà la potenza dissipata è funzione quasi lineare del numero di transistor e della loro frequenza di lavoro.

Originariamente inviato da lombardp
Nel confronto tra Athlon e P4 c'è (giustamente) la tendenza a confrontare la CPU nel suo complesso. Però nel dare giudizi su "efficienza" e "architettura interna" non mi sembra l'approccio corretto.

Certo, l'Athlon è mediamente meno potente, però si deve tenere conto di diversi fattori. Per esempio il FSB è di gran lunga meno capace, al punto che le architetture a doppio banco di RAM non danno praticamente nessun vantaggio. Poi c'è la questione delle SSE2 del P4, che non presenti nell'Athlon. Altro dettaglio non da poco è la maturità dei processi tecnoligici del silicio, che danno a Intel un vantaggio di 6-9 mesi su AMD.
E' vero che le SSE danno una mano, ma non penso che i videogiochi, se non proprio gliultimi, implementino ottimizzazioni pro-SSE.
Mi sembra tanto anche il ritardo di cui parli, anche considerando che alla fine le fonderie a cui si appoggiano Intel e AMD hanno dimostrato entrambe dia vere difficolta', UMC per alti volumi e TSMC con i noti problemi tecnologici di NV30. 9 mesi mi sembrano tantissimi , e anche 6 non sono affatto pochi. Non ho informazioni di alcun tipo a riguardo, ma non vedo comunque questo ritardo tecnologico. Pensa che Intel e' una realta' industriale molto piu' grande di AMD, e che se da un lato Intel si adopera sul lato sviluppo chipset, piataforma itanium etc, AMD ha speso molte risorse, sia di ricerca e sia, penso di tecnologia in senso stretto, per x86-64.

In un discorso complessivo è corretto trascurare questi fattori, perché si sta confrontando due CPU prese dallo scaffale del rivenditore. Se invece si confrontano le architetture interne per cercare di stabilire quale sia il migliore "core", non mi sembra l'approccio migliore.
Non mi piace vedere la cosa dal punto di vista del miglio core......sono tutti e due ottimi prodotti, quella che ho descritto e' il mio modo di vedere quale sia il miglior approccio all'incremento di potenza in proiezione futura.



Sono d'accordo con il fatto che le rese produttive saranno sempre più basse, ma proprio per questo occorre migliorare i processi già noti con le note tecniche "strained silicon", "matertiali low-k" e SOI.
con quei metodi, piu' che aumentare le rese, almeno, si aumentano, ma indirettamente, si cerca di diminuire le latenze dei transistor e la resistenza dei conduttori utilizzati per collegarli, nonche', se non sbaglio, SOI permette di ridurre le interferenze elettromagnetiche che si generano quando le dimensioni dei transistor e la loro vicinanza arriva ai livelli del futuro prossimo.

Purtroppo la cache non ha alcun impatto sulla riduzione del rischio di stallo, semmai riduce l'entità dello stallo. La previsione dei salti riduce effettivamente il rischio degli stalli, ma preferisco di più l'approccio "predicated execution" usato nella famiglia Itanium.

Inoltre, con l'aumento indiscriminato degli stadi di pipeline, oltre ai noti problemi di consumo e impatto degli stalli, ci sono dei problemi intrinseci che non possono essere trascurati.

http://www.lithium.it/articolo.asp?code=52&pag=7

la cache e' vero che non ha influenza sul verificarsi in senso stretto dello stallo, ma non fino in fondo. Avere piu' cache vuol dire avere piu' dati accessibili direttamente. Questi dati sono recuperati in anticipo mediante opportuni algoritmi, e avere piu' cache significa avere piu' dati. Finorapensavo che gli algoritmi di previsione lavorassero su piu' opzioni, per questo ho scritto che la cache aumentata diminuisce il rischio di stallo, ma leggendo quello che mi rispondi, mi viene un dubbio: in ogni caso viene prelevato un solo "dato", o un ventaglio di dati con simile probabilita' di essere richiesti nei passaggi successivi?
Ci sono due figure di merito per i processori: le Instruction Per Clock, considerata una misura di efficienza, e le Instruction Per Second, più noto come MIPS, considerata una misura di potenza fuori tutto.

d'accordo, ma l'ipc non e' misurabile, perche' si basa sulla statistica.





In realtà la potenza dissipata è funzione quasi lineare del numero di transistor e della loro frequenza di lavoro.

[/quote] a parita' di processo tecnologico?
Mi sembra strano, la potenza dissipata da un P4 3 GHz non mi sembra molto superiore di un AthlonXP 3000+

Infatti l'Athlon e' nel complesso un processore più efficiente, in quanto ha un IPC sensibilmente superiore al P4, che al contrario a causa del clock molto più elevato è il processore più potente nel complesso (la sua versione più potente riesce a compiere la maggioranza dei task in meno tempo rispetto alla versione più potente di AMD). Comunque le potenze termiche dissipate stanno diventando veramente esagerate, già nel caso del nuovo Prescott si parla di oltre 100 W negli esemplari di preserie, e dubito si riuscirà a ridurlo a meno di 90 W. Salendo ulteriormente di clock si avrà sempre più dissipazione, e la transizione a 0.09 micron sarà solo un paliativo temporaneo. Entrambi gli approcci (AMD e Intel) hanno vantaggi e svantaggi, certo è che quando si raggiungeranno i limiti fisici dell'innalzamento di frequenza, Intel sarà forzata ad aumentare l'IPC.
Senza contare che un clock inferiore significa non dover necessariamente fare i salti mortali per ridurre induttanze parassite et similia e poter utilizzare sistemi di raffreddamento più "normali".

Originariamente inviato da +Benito+
E' vero che le SSE danno una mano, ma non penso che i videogiochi, se non proprio gliultimi, implementino ottimizzazioni pro-SSE.

Dal 2002 tutti i giochi hanno ottimizzazioni SSE, senza contare che moltissime implementazioni sono da ricercarsi nelle librerie (Direct X su tutte, dalla versione 8 hanno le ottimizzazioni di cui si parla) e nei drivers.

Mi sembra tanto anche il ritardo di cui parli, anche considerando che alla fine le fonderie a cui si appoggiano Intel e AMD hanno dimostrato entrambe dia vere difficolta', UMC per alti volumi e TSMC con i noti problemi tecnologici di NV30.

? Questa mi è nuova: mai saputo che Intel e AMD facessero produrre i propri processori sa UMC e TSMC. Intel ha diversi stabilimenti in giro per il mondo, e AMD ha la nuovissima fabbrica di Dresda che produce quasi tutti i suoi processori. Al limite AMD può aver dato in subappalto la produzione di Chipset.


Non mi piace vedere la cosa dal punto di vista del miglio core......sono tutti e due ottimi prodotti, quella che ho descritto e' il mio modo di vedere quale sia il miglior approccio all'incremento di potenza in proiezione futura.

Se parliamo dell'Athlon XP, siamo d'accordo. Se parliamo dell'Athlon 64, le cose sono diverse, in quanto il controller integrato elimina moltissime delle latenze presenti in gioco e scala progressivamente con la frequenza del processore (e' l'eliminazione del concetto stesso di FSB). Non a caso gli Opteron, nonostante i loro problemi a salire di frequenza (il che dipende non solo da pipeline, ma anche da un effettiva mancanza di risorse da parte di AMD dedicabili all'ottimizzazione dei layout: per questo AMD ha chiesto l'aiuto di IBM) scala molto meglio dell'Athlon XP all'aumentare del clock.

la cache e' vero che non ha influenza sul verificarsi in senso stretto dello stallo, ma non fino in fondo. Avere piu' cache vuol dire avere piu' dati accessibili direttamente. Questi dati sono recuperati in anticipo mediante opportuni algoritmi, e avere piu' cache significa avere piu' dati. Finorapensavo che gli algoritmi di previsione lavorassero su piu' opzioni, per questo ho scritto che la cache aumentata diminuisce il rischio di stallo, ma leggendo quello che mi rispondi, mi viene un dubbio: in ogni caso viene prelevato un solo "dato", o un ventaglio di dati con simile probabilita' di essere richiesti nei passaggi successivi?

Il problema è che oltre un certo limite si richiederebbero quantitativi di cache inusitati per contrastare l'inefficienza di base.

d'accordo, ma l'ipc non e' misurabile, perche' si basa sulla statistica.

L'IPC medio è misurabile e non è una quantità astratta.

a parita' di processo tecnologico?
Mi sembra strano, la potenza dissipata da un P4 3 GHz non mi sembra molto superiore di un AthlonXP 3000+ [/QUOTE]

Purtroppo lo è, e non di poco: un P4 a 3,2 GHz dissipa da 85 a 100 W, un Barton 3200+ da 60 a 77 W (min-max), il che significa il 30% di meno.

Originariamente inviato da +Benito+
Mi sembra tanto anche il ritardo di cui parli, anche considerando che alla fine le fonderie a cui si appoggiano Intel e AMD hanno dimostrato entrambe dia vere difficolta', UMC per alti volumi e TSMC con i noti problemi tecnologici di NV30. 9 mesi mi sembrano tantissimi , e anche 6 non sono affatto pochi. Non ho informazioni di alcun tipo a riguardo, ma non vedo comunque questo ritardo tecnologico. Pensa che Intel e' una realta' industriale molto piu' grande di AMD, e che se da un lato Intel si adopera sul lato sviluppo chipset, piataforma itanium etc, AMD ha speso molte risorse, sia di ricerca e sia, penso di tecnologia in senso stretto, per x86-64.


Che io sappia, Intel utilizza tutte FAB proprie.

AMD solo recentemente sta facendo produrre gli Athlon XP alla UMC, in modo da tenere nelle proprie FAB i processi più avanzati (SOI, 90nm, etc.).

Il ritardo c'è, se guardi bene il primo processore a 0.13um introdotto, per Intel è il Northwood 1.6GHz di Gennaio 2002, mentre AMD è il Thoroughbred 2000+ di Settembre 2002.


con quei metodi, piu' che aumentare le rese, almeno, si aumentano, ma indirettamente, si cerca di diminuire le latenze dei transistor e la resistenza dei conduttori utilizzati per collegarli, nonche', se non sbaglio, SOI permette di ridurre le interferenze elettromagnetiche che si generano quando le dimensioni dei transistor e la loro vicinanza arriva ai livelli del futuro prossimo.


Si, infatti. Il SOI, proprio per il fatto di sostituire il silicio con un isolante, abbatte la corrente di leakage, che tra l'altro nei transistor a 90nm risulta essere considerevole.


Finorapensavo che gli algoritmi di previsione lavorassero su piu' opzioni, per questo ho scritto che la cache aumentata diminuisce il rischio di stallo, ma leggendo quello che mi rispondi, mi viene un dubbio: in ogni caso viene prelevato un solo "dato", o un ventaglio di dati con simile probabilita' di essere richiesti nei passaggi successivi?


In effetti esistono processori (es: Itanium) che effettuano sistematicamente la così detta "speculative execution", cioè esecuzione di entrambi di rami di un branch, così da annullare l'eventuale stallo.

Pentium 4, Athlon e Opteron non credo abbiano questa caratteristica. Penso che si limitino a determinare il ramo che più probabilmente sarà seguito.


d'accordo, ma l'ipc non e' misurabile, perche' si basa sulla statistica.


Si, è vero.


Mi sembra strano, la potenza dissipata da un P4 3 GHz non mi sembra molto superiore di un AthlonXP 3000+

Si hai ragione, alla fine le potenze sono quasi uguali. Perché pur avendo l'Athlon una minor frequenza, sprecando meno cicli di clock riesce a far lavorare di più i transistor.

Il discorso della "funzione lineare" è comunque valido e dimostrabile.

[/QUOTE]

Si hai ragione, alla fine le potenze sono quasi uguali. Perché pur avendo l'Athlon una minor frequenza, sprecando meno cicli di clock riesce a far lavorare di più i transistor.

Humm.. il 30% di potenza dissipata in più non mi sembra "quasi uguale". Significa dover avere una ventola più grande e rumorosa, un dissipatore di migliore qualità ed una ventilazione migliore del case.

Originariamente inviato da +Benito+
io invece penso che le pipeline aumenteranno ancora, e lo dico perche' e' sancito dai fatti che siamo arrivati ad un punto in cui e' piu' efficiente l'architettura "a bassa latenza" rispetto a quella "a basso impatto degli stalli". Athlon, con le sue pipeline a stadi complessi, non riesce piu' a salire, causa latenze, e sebbene abbia minor danno dallo stallo della pipeline, appunto perche' sono piu' corte e servono meno clock per vuotarle, alla fine il numero di operazoini che riesce a portare a temine a parita' di tempo e' minore di quello dei P4.
Bisogna vedere quali tipi di operazione riesce a portare a termine a parità di tempo. Il P4 va forte quando può sfruttare appieno le SSE/SSE2 e in generale quando deve eseguire codice "multimediale", dove c'è da elaborare uno flusso di dati che, per natura, richiede una catena di operazioni dove la presenza di controlli e salti è ridottissima o addirittura assente.
In queste condizioni gli stalli si verificano molto più raramente, anche perché il sistema di prefetching provvede quasi sempre a recuperare i dati prima della loro richiesta, e nel caso che il processore non trovi i dati l'esecuzione speculativa e fuori ordine delle istruzioni provvede a "congelare" l'istruzione in attesa di dati e a passare le risorse della CPU/ALU a qualche altra istruzione che non sia legata da rapporti di dipendenza o altro, per poi tornare ad eseguirla quando tutte le sue risorse saranno disponibili.
In quest'ottica è chiaro che l'aumento della frequenza di clock è la principale responsabile delle migliori performance di un processore, e in misura MOLTO minore contano la quantità di cache L2 e la frequenza di bus. In particolare, già 512KB di cache L2 "veloce", come quella del P4, offre delle ottime prestazioni nell'esecuzione di codice SIMD; con l'aumento della cache a 1MB non assisteremo sicuramente ad un impatto prestazionale paragonabile a quello dovuto al passaggio dai 256KB del Willamette ai 512KB del Northwood. Stesso discorso per l'FSB: a fronte di un raddoppio dai 400Mhz della sua introduzione agli 800Mhz attuali, non abbiamo assistito a grossi boost prestazionali (lo dimostrano anche i primi test del chipset Via per P4 a singolo canale: prestazioni paragonabili a quelle Intel a doppio canale/banda).
Sarebbe interessante effettuare una bella prova comparativa mettendo in gioco tutti questi fattori: Corsini è in possesso di alcuni engineering sample di P4 con moltiplicatore sbloccato che potrebbero fornire le informazioni di cui sopra. :)
In questo contesto, aumentare il numero degli stadi di pipeline, semplificandoli, quindi riducendo le latenze del singolo stadio e potendo cosi' salire di piu' in frequenza, e' la mossa giusta, perche' grazie ai quantitativi di cache sempre maggiori e ad algoritmi di previsione dei salti (nonche' di programmi scritti apposta) il rischio di stallo della pipeline si sta riducendo moltissimo.
Questo porterebbe però ad un ulteriore sbilanciamento delle prestazioni del processore verso le applicazioni SIMD, riducendo al contempo quelle "generiche": mi piacerebbe, ad esempio, avere dei benchmark con degli emulatori, compilatori, database, operazioni tipiche di applicazioni office (ricerca, ordinamento, calcolo di formule, ecc.).
I quantitivi di cache maggiori possono soltanto lenire gli effetti degli innumerevoli problemi dovuti ai bench miss che si verificano spesso, e gli algoritmi di previsione dei salti non possono certo arrivare a fare miracoli, per quanto elaborati e complessi: al più servono a bilanciare le cadute di performance.
Quanto ai programmi scritti apposta, non credo che si possa pensare di tornare a scrivere codice assembly per una parte consistente del codice: non è economicamente conveniente e a volte la natura stessa del codice non permette di scrivere del codice efficiente. Per questo ormai l'uso dei compilatori è imperativo, ma questi non possono certo fare miracoli. Rimarrebbe la carta di un'architettura che aiuti nella predizione (o sarebbe meglio dire predicazione) dei salti, come quella dell'Itanium, ma anche in questo caso i risultati sono stati, a mio avviso, abbastanza deludenti (basti guardare alle prestazioni interi di questi "mostri", Itanium2 incluso), in quanto ci si affida al compilatore, che può avere soltanto una visione statica del lavoro che dovrebbe essere effttuato dal codice e non dinamica, come avviene invece nella realtà; infatti l'Itanium non è dotato di un'unità di esecuzione fuori ordine, che permetterebbe un notevole boost prestazionale, e difficilmente la implementerà, in quanto l'architettura EPIC su cui è basato di fatto lo obbliga ad eseguire le istruzioni in bundle e secondo certi criteri.
L'efficienza intrinseca dell'architettura dell'athlon non e' superiore a quella del P4, ma, anzi, viene ad essere inferiore quando, a parita' di tempo, elabora meno operazioni. Il confronto sull'efficienza ha senso solo sull'unita' di tempo, non sul clock, perche' quello che noi percepiamo e' il tempo, e l'unica differenza che vediamo e' che un processore impega 10 secondi e l'altro 12 a fare un rendering, non che uno elabora 1M di dati per clock a 100 Hz e l'altro 200K a 1000Hz.
Vedi sopra: dipende dal tipo di codice eseguito. Se guardiamo, ad esempio, al rendering, generalmente le prestazioni degli Athlon sono buone e in linea con quelle dei P4 di pari frequenza. Decadono quando esiste del codice SSE2 che può sfruttare al meglio l'architettura del P4. Se però, andiamo a prendere buona parte dei pacchetti 3D presenti in circolazione ed effettuiamo diversi test, vediamo che rimane abbastanza competitivo, grazie all'FPU più potente e alla migliore esecuzione di codice intero/condizionale, che è abbastanza presente anche nel codice 3D.
E' vero che le SSE danno una mano, ma non penso che i videogiochi, se non proprio gliultimi, implementino ottimizzazioni pro-SSE.
Considera che, appena uscito, già Quake 3 era ottimizzato per le SSE (e forse per le SSE2, ma non ricordo di preciso).
la cache e' vero che non ha influenza sul verificarsi in senso stretto dello stallo, ma non fino in fondo. Avere piu' cache vuol dire avere piu' dati accessibili direttamente.
Anche codice.
Questi dati sono recuperati in anticipo mediante opportuni algoritmi, e avere piu' cache significa avere piu' dati. Finorapensavo che gli algoritmi di previsione lavorassero su piu' opzioni, per questo ho scritto che la cache aumentata diminuisce il rischio di stallo, ma leggendo quello che mi rispondi, mi viene un dubbio: in ogni caso viene prelevato un solo "dato", o un ventaglio di dati con simile probabilita' di essere richiesti nei passaggi successivi?
Per sua natura penso che venga prelevato un dato alla volta, fra quelli che possono essere interessanti. Non sono molto addentrato nella conoscenza delle politiche di data prefetching dei dati, ma le strade percorribili penso che siano due: la classica LRU (si sfruttano gli ultimi indirizzi di memoria utilizzati per generare le successive richieste in anticipo) oppure una più sofisticata analisi delle successive istruzioni che ancora debbono essere elaborate per analizzare, nel caso di accesso alla memoria, il possibile indirizzo e provvedere, se possibile, al caricamento del dato quando ancora l'istruzione non è neppure stata caricata dallo scheduler; o anche una combinazione di queste due tecniche, penso.
Comunque considera che uno stallo si può benissimo verificare anche per il caricamento del codice che dev'essere eseguito, e ciò comporata non pochi problemi, specialmente nel caso del P4. Infatti la trace cache, che contiene le istruzioni decodificate direttamente in formato RISC (ROP), è molto piccola (può contenere circa 12mila istruzioni a 112bit) ed è in grado di analizzare e decodificare al più un'istruzione x86 alla volta (mentre è in grado di spedire al più 3 ROP alle unità di esecuzione), per cui puoi ben immaginare quale impatto prestazionale si può verificare col codice "generico", non SIMD: le applicazioni che ho citato ne risentirebbero veramente moltissimo...
Mi sembra strano, la potenza dissipata da un P4 3 GHz non mi sembra molto superiore di un AthlonXP 3000+
Se vai a guardare le tabelle con i consumi, puoi prenderne atto, come ha già riporato leoneazzurro. Considera, inoltre, che il P4 ha un voltaggio di alimentazione più basso rispetto all'XP3200+...

P.S. P4 e Athlon/Opteron non eseguono speculativamente i due possibili rami di un salto condizionale, come invece fa l'Itanium...

Originariamente inviato da cdimauro
Bisogna vedere quali tipi di operazione riesce a portare a termine a parità di tempo. Il P4 va forte quando può sfruttare appieno le SSE/SSE2 e in generale quando deve eseguire codice "multimediale", dove c'è da elaborare uno flusso di dati che, per natura, richiede una catena di operazioni dove la presenza di controlli e salti è ridottissima o addirittura assente.
In queste condizioni gli stalli si verificano molto più raramente, anche perché il sistema di prefetching provvede quasi sempre a recuperare i dati prima della loro richiesta, e nel caso che il processore non trovi i dati l'esecuzione speculativa e fuori ordine delle istruzioni provvede a "congelare" l'istruzione in attesa di dati e a passare le risorse della CPU/ALU a qualche altra istruzione che non sia legata da rapporti di dipendenza o altro, per poi tornare ad eseguirla quando tutte le sue risorse saranno disponibili.
In quest'ottica è chiaro che l'aumento della frequenza di clock è la principale responsabile delle migliori performance di un processore, e in misura MOLTO minore contano la quantità di cache L2 e la frequenza di bus. In particolare, già 512KB di cache L2 "veloce", come quella del P4, offre delle ottime prestazioni nell'esecuzione di codice SIMD; con l'aumento della cache a 1MB non assisteremo sicuramente ad un impatto prestazionale paragonabile a quello dovuto al passaggio dai 256KB del Willamette ai 512KB del Northwood. Stesso discorso per l'FSB: a fronte di un raddoppio dai 400Mhz della sua introduzione agli 800Mhz attuali, non abbiamo assistito a grossi boost prestazionali (lo dimostrano anche i primi test del chipset Via per P4 a singolo canale: prestazioni paragonabili a quelle Intel a doppio canale/banda).
Sarebbe interessante effettuare una bella prova comparativa mettendo in gioco tutti questi fattori: Corsini è in possesso di alcuni engineering sample di P4 con moltiplicatore sbloccato che potrebbero fornire le informazioni di cui sopra. :)

Questo porterebbe però ad un ulteriore sbilanciamento delle prestazioni del processore verso le applicazioni SIMD, riducendo al contempo quelle "generiche": mi piacerebbe, ad esempio, avere dei benchmark con degli emulatori, compilatori, database, operazioni tipiche di applicazioni office (ricerca, ordinamento, calcolo di formule, ecc.).
I quantitivi di cache maggiori possono soltanto lenire gli effetti degli innumerevoli problemi dovuti ai bench miss che si verificano spesso, e gli algoritmi di previsione dei salti non possono certo arrivare a fare miracoli, per quanto elaborati e complessi: al più servono a bilanciare le cadute di performance.
Quanto ai programmi scritti apposta, non credo che si possa pensare di tornare a scrivere codice assembly per una parte consistente del codice: non è economicamente conveniente e a volte la natura stessa del codice non permette di scrivere del codice efficiente. Per questo ormai l'uso dei compilatori è imperativo, ma questi non possono certo fare miracoli. Rimarrebbe la carta di un'architettura che aiuti nella predizione (o sarebbe meglio dire predicazione) dei salti, come quella dell'Itanium, ma anche in questo caso i risultati sono stati, a mio avviso, abbastanza deludenti (basti guardare alle prestazioni interi di questi "mostri", Itanium2 incluso), in quanto ci si affida al compilatore, che può avere soltanto una visione statica del lavoro che dovrebbe essere effttuato dal codice e non dinamica, come avviene invece nella realtà; infatti l'Itanium non è dotato di un'unità di esecuzione fuori ordine, che permetterebbe un notevole boost prestazionale, e difficilmente la implementerà, in quanto l'architettura EPIC su cui è basato di fatto lo obbliga ad eseguire le istruzioni in bundle e secondo certi criteri.

Vedi sopra: dipende dal tipo di codice eseguito. Se guardiamo, ad esempio, al rendering, generalmente le prestazioni degli Athlon sono buone e in linea con quelle dei P4 di pari frequenza. Decadono quando esiste del codice SSE2 che può sfruttare al meglio l'architettura del P4. Se però, andiamo a prendere buona parte dei pacchetti 3D presenti in circolazione ed effettuiamo diversi test, vediamo che rimane abbastanza competitivo, grazie all'FPU più potente e alla migliore esecuzione di codice intero/condizionale, che è abbastanza presente anche nel codice 3D.

Considera che, appena uscito, già Quake 3 era ottimizzato per le SSE (e forse per le SSE2, ma non ricordo di preciso).

Anche codice.

Per sua natura penso che venga prelevato un dato alla volta, fra quelli che possono essere interessanti. Non sono molto addentrato nella conoscenza delle politiche di data prefetching dei dati, ma le strade percorribili penso che siano due: la classica LRU (si sfruttano gli ultimi indirizzi di memoria utilizzati per generare le successive richieste in anticipo) oppure una più sofisticata analisi delle successive istruzioni che ancora debbono essere elaborate per analizzare, nel caso di accesso alla memoria, il possibile indirizzo e provvedere, se possibile, al caricamento del dato quando ancora l'istruzione non è neppure stata caricata dallo scheduler; o anche una combinazione di queste due tecniche, penso.
Comunque considera che uno stallo si può benissimo verificare anche per il caricamento del codice che dev'essere eseguito, e ciò comporata non pochi problemi, specialmente nel caso del P4. Infatti la trace cache, che contiene le istruzioni decodificate direttamente in formato RISC (ROP), è molto piccola (può contenere circa 12mila istruzioni a 112bit) ed è in grado di analizzare e decodificare al più un'istruzione x86 alla volta (mentre è in grado di spedire al più 3 ROP alle unità di esecuzione), per cui puoi ben immaginare quale impatto prestazionale si può verificare col codice "generico", non SIMD: le applicazioni che ho citato ne risentirebbero veramente moltissimo...

Se vai a guardare le tabelle con i consumi, puoi prenderne atto, come ha già riporato leoneazzurro. Considera, inoltre, che il P4 ha un voltaggio di alimentazione più basso rispetto all'XP3200+...

P.S. P4 e Athlon/Opteron non eseguono speculativamente i due possibili rami di un salto condizionale, come invece fa l'Itanium...


...le tue conoscenze sono "un po' troppo piu'" delle mie per poterti rispondere...:D

Spero almeno di riuscire a ricordare un po' delle cose interessantissime che spesso escono dalla tua tastiera!
;)

Ti ringrazio per l'apprezzamento. Sono felice di poter discutere con delle persone tecnicamente preparate. :)