Alcune informazioni su Tejas e Prescott

[leoneazzurro]

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

[leoneazzurro]

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.

[lombardp]

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.

[leoneazzurro]

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

[cdimauro]

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

[+Benito+]

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

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

[cdimauro]

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