Nuove informazioni sulle cpu Cedar Mill

[Dreadnought]

Originariamente inviato da Fx

1) non dicevo che consumava di più, dicevo che a parità di clock alcuni dothan hanno un TDP maggiore dei banias, ed è un po' duretta smentirlo (a meno che non vai in intel a cambiare i datasheet)... volevo sapere come mi spiegavi questo

Ok hai ragione, non ci siamo intesi, in effetti hai insisito sul TDP, ma io il TDP non l'ho mai considerato.

2) ancora con 'sto leakage! SPIEGAMI PERCHE' DA 3.2 A 3.8 A PARITA' DI CORE I CONSUMI (quelli RILEVATI SUL CAMPO, non il tdp o il consumo massimo dichiarato da intel) CRESCONO LINEARMENTE, POI TORNAMI A DIRE CHE IL LEAKAGE E' DIPENDENTE DALLA FREQUENZA DI CLOCK

Perchè il leakage dipende dalla C e dalla L del transistor, e fanno aumentare i Watt dissipati al crescere della frequenza

3) si, la cache hai smesso di considerarla solo dopo che te l'ho fatto notare io... basta che fai page up e vedi subito chi è il primo che ha tirato fuori la questione qualitativa dei transistor, e guarda invece chi parla di pentium 4 EE northwood che "pur avendo più transistor" quando in realtà sono tutta cache...

Il problema è che dai l'impressione di scrivere senza sapere quello che scrivi, poi fai "tuoi" dei concetti che non aveiv espresso in precedenza.

4) ma dir balle non è da ban? quoto il mio primo post:

Infatti quello che quoti è errato.

Intel che avrà prodotto i primi sample dei core prescott nel 2000-2001 [stando alle tempistiche di produzione delle CPU che dall'inizio alla fine di un progetto durano dai 5 ai 10 anni), ha ricercato metodi come strained silicon e materiali come i Low-K per portare i consumi dei 90nm sotto a quelli dei 130nm. Che è quello che sto cercando di dire dall'inizio di questo topic, ma che evidentemente ti entra daun orecchio e ti esce dall'altro

5) le percentuali di transistor attivi mi sa che considerava anche la cache, e comunque anche se non la considera il fatto che nel prescott ci siano meno transistor attivi nello stesso momento del northwood è una triste scappatoia per puntellare il castello di carte ma non ha nessun fondamento e tantomeno non ha nessun senso... il dato del 30% mi sembra attendibile ma non mi sembra attendibile che nel northwood sia 30 e nel prescott 12 (per compensare il numero di transistor in più, dovrebbe esser 12)... se cambia, può cambiare di pochi punti percentuali... altrimenti in poche generazione di core avremmo un estinguersi dei transistor attivi? =) ripeto,

Sono d'accordo, ma non mi pare atrettanto normale che il rapporto sia direttamente proporzionale al numero di transistor, del tipo:
- nel northwood (55mtrans) il 30% sono 16milioni
- nel prescott (125mtrans) il 30% sono 37milioni
se guardiamo solo ai core
- nel northwood (31mtrans) il 30% sono 10milioni
- nel prescott (75mtrans) il 30% sono 21milioni


Non penso proprio che nel prescott si arrivi a così tanto, anche perchè
1) la cache del prescott ha latenze più elevate che nel northwood e quindi questo implica che la cache viene indirizzata mediamente qualcosina di meno a parità di tempo.
2) i miglioramenti nell'HT, nel Branch Prediction e l'allungamento della pipe portano si a tanti transistor in più, ma non penso che sia un aumento proporzionale all'aumento di transistor da North a Prescott.
Inoltre l'HT non è migliorato aggungendo transistor ma solo aumentando le cache (è scritto nelle tue note con le novità del prescott)
3) altre aggiunte sono usate "al posto di" vedi:
- 2 Shift Unit
- 1 Imul Unit
- Emt64
- SSE3
Certo queste consumano, ma sono usate solo quando richieste e come ho già detto a cidimauro non è detto che alcune (shift e imul) riducano i consumi leggermente piuttosto che aumentarli.
4) I maggiori Buffer (store load e write) sono aumentati, ma non mi sembra che incidano tantissimo sui consumi
6) Il prefetch HW/SW migliorato bisogna vedere di quanto e come, può essere anche dell'1% perchè hanno ottimizzato un circuito...

Dubito che queste variazioni portino a 21 (o 11 che siano a seconda della interpretazione) milioni di transistor attivi in più, ovvero più di quello che è attivo in un core northwood completo.

basta illazioni: la realtà è che il prescott ha più del doppio di transistor e consuma un po' di più, fai un semplice calcolo e scoprirai che la tecnologia a 90 nm ha OVVIAMENTE consumi più parchi di quella a 130

...come sempre argomenti su quello che scrivo io senza nemmeno sprecarti a cliccare su google e cercare qualcosa.
Probabilmente hai paura ad aggiungere qualcosa di tuo, perchè potresti sbagliare

6) ti spiace leggere anche ciò che ho riportato esser cambiato nel prescott dal northwood? vai a considerare UNICAMENTE ALCUNE COSE, e IGNORI DELIBERATAMENTE LE ALTRE che sai benissimo che aumentano eccome i consumi... a partire dal branch prediction in giù...

Le stesse cose che hai scritto tu sono ripetute nell'articolo che ho postato qualche post prima
http://www.xbitlabs.com/articles/cpu...rescott_5.html
del tuo (dove peraltro nemmeno hai specificato la fonte... )

Veramente ho aperto una discussione su questo nel post 55
http://forum.hwupgrade.it/showpost.p...3&postcount=55
però visto che nessuno ha detto niente ho preso per buono che non vi interessasse.

8) ok ignorare bellamente i valori riscontrati sul campo, dove viene fuori che i watt dissipati dal prescott crescono linearmente con la frequenza (la piccola discrepanza può essere ampiamente giustificata dal fatto che se lavora a temperature superiori consuma anche di più), ma non saper manco leggere ciò che sta scritto nei link che si riporta è grave...

?? LOL ??
Nel prescott (ma anche nel northwood, o altre cpu, ma in forma minore) non è proporzionale al clock (peggio!), ma al clock per un fattore maggiore di 1, per via del leakage e del fatto che il leakage aumenta con la temperatura (quest'ultimo tra l'altro corretto probabilmente dalla discesa del Vcc al salire della I come implementato dal prescott 5x0J).

Normalmente i W sono proporzionalli alla frequenza, ma questo è risaputo dai primi overclock (oppure da una lezione di elettrotecnica/elettronica), con le solite formule.

P(nuovo_clock) = P(vecchio_clock) * nuovo_clock / vecchio_clock
P(nuovo_vcore) = P(vecchio_vcore) * nuovo_vcore^2 / vecchio_vcore^2

Da che si deduce quello che ho scritto tempo fa:

P proporzionale al Clock (o meglo alla corrente) e al quadrato della Vcc (che riassunsi con ---> P=V^2*I*Clock e che un utente interpreto' male pensando che era una formula)

Questo perchè al salire del clock aumentano gli Ampere assorbiti (è elettronica di base eh... ) basta integrare i segnali nel periodo.

e finiscila lì al posto che scrivere papiri su papiri per difendere l'indifendibile... sei veramente pedante... ma tu in vita tua hai mai detto: "mi sono sbagliato"

Con te penso mai, infatti come al punto [8] dimostri di non conoscere nemmeno i fondamentali dell'argomento.

Inoltre dicevi lo stesso quando affermavi che le GF6800 consumavano 120W (lol!!! con quei sistemi di raffreddamento esigui alcune si sarebbero fuse in 2 minuti e questo lo si può valutare ad occhio) e io con insistenza ti dicevo che massimo potevano farne 70...

[Fx]

io trovo a pagina 2:

Originariamente inviato da Fx

... e non me ne puoi ignorare un altro: I FENOMENI DI LEAKAGE CI SONO ANCHE A 130 NM... a 90 nm semplicemente AUMENTANO, ma nel contempo STAI PASSANDO ALLO STEP SUCCESSIVO, che ti dà un vantaggio in termini di consumi imho ben più ampio, e non mi puoi dire che gli stessi 90 nm di intel sul dothan in effetti comportano un consumo inferiore ma nel prescott no perchè a 2.1 ghz il leakage non c'è e a 2.4 si... non si regge in piedi dai. come non si regge in piedi la storiella che il leakage aumenta così tanto con il salire della frequenza, tant'è che un 540 (3.2) full load consuma 87.8 watt e un 570 (3.8) 104.5... guarda qua:

http://www6.tomshardware.com/cpu/200...m4_570-20.html

se il leakage fosse così dipendente dalla frequenza, ciao... schizzerebbe su come una saponetta. e invece sono solo poco più di 16 watt... basta fare una DIVISIONE: per il 540 si parla di 27,43 watt per ghz e per il 570 si parla di... 27.5! cazzo, quanto influisce eh?

ora... sei d'accordo con me che il leakage dovrebbe influire molto ma molto di più?

in conclusione:
- sappiamo che aumentando la frequenza la potenza consumata cresce in modo quasi lineare, quando i fenomeni di leakage dovrebbero farla crescere molto più velocemente
- sappiamo che al di là della cache il core del prescott è molto più grosso (più del doppio) di quello del northwood
- sappiamo che con lo stesso processo produttivo da 90 nm laddove il core è rimasto pressochè invariato (leggasi dothan, se togli la cache è grosso poco più del banias, ma è pressochè identico) il consumo SCENDE

io concludo che IL PROCESSO A 90 NM DI PER SE CONSUMA DI MENO DI QUELLO A 130, e che la conclusione contraria perchè un prescott consuma di più di un northwood è determinata unicamente da un calcolo che non tiene in considerazione un fattore: come è cambiato il core.

fammi indovinare: di fronte a queste argomentazioni ferree e semplici, scriverai un papiro di 40 righe arrampicandoti sugli specchi, riportando datasheet e facendo illazioni a tutto spiano per giustificare la tua tesi.

prova una sensazione nuova: prova per un attimo ad ascoltare

ho indovinato, che dici?

[cdimauro]

Originariamente inviato da Dreadnought

Quindi tornando al discorso da cui è scaturito il thread è che a 90nm senza strained silicon, senza SOI e senza Low-K si consuma comunque meno che a 130nm?

Dipende. Finora è ciò che si è sempre verificato. Arrivando ai 90nm i problemi di leakage sono diventati rilevanti, a seconda dei casi...

Scusa ma ci sono 8 tipi di moltiplicatori integrabili in una CPU, tutti molto differenti in precisione velocità e complessità (e quindi consumi), mi spieghi ora come fai a sapere quale tipo sia?

Non sono tutti uguali: quanti sono quelli che si possono permettere di tirare fuori un risultato con una latenza di 10 cicli di clock e un throughput di 1?

Il concetto era chiaro inutile puntualizzare se tanto non era quello che volevo esprimere, se vuoi posso mettertela giù così:

imul ebx, ebx, 24453
add ebx, 5

Che poi sinceramente puntualizzare su queste cose denota un po' di incapacità nel reggere il discorso...

Scusa, ma se vuoi fare un esempio, quanto meno devi scriverne uno giusto: ricordare la sintassi precisa di un'istruzione può essere difficile quando il set d'istruzioni è molto ampio, ma dimenticare cosa è possibile fare e cosa no con un'unità di elaborazione non è ammissibile.

Più che altro hai appena scritto tu quali sono le modifiche al core del prescott però non hai fatto nessuna ipotesi su quanto possano influire nei consumi, il che è come dire tutto e niente.

Io ti ho appena fatto un esempio: nelle due ALU netburst sono state aggiunte due unità per effettuare gli shiftL e shiftR, ma ti pare possibile che in quelle unità circoli corrente durante un JMP, un ADD o altro? (e non è una domanda retorica, ti sto chiedendo una opinione)

Dipende dall'implementazione.

[cdimauro]

Originariamente inviato da Dreadnought

[1]A parte che qui c'era chi affermava che il dothan consumasse più del banias...

Capita quando è in idle o il carico di lavoro è molto basso: Intel ha stranamente scelto valori di v-core e di moltiplicatore più elevati rispetto al Banias nelle stesse condizioni...

Cque come ho già scritto (ma non hai detto che leggevi i thread? ) il prescott e il dothan usano comunque:
- Strained silicon per diminuire la resistività e velocizzare la commutazione
- il Low-K per il medesimo uso dell'ST
http://nepp.nasa.gov/index_nasa.cfm/934/

Certo che leggo: infatti quello era un banale riepilogo dei concetti...

Visto che il dothan consuma in ogni caso POCO meno del banias, non è difficile immaginare che senza St e Low-K il Vcc sarebbe stato un bel 10-15% più alto a parità di clock, con un aumento dei consumi attorno al 20-30%. Portando il dothan a consumi superiori o pari al banias.

Per me è difficile pensarlo senza dati certi e/o formule che permettano di dedurre questi valori.
Comunque, come dicevo nel messaggio precedente, finora il passaggio a tecnologie più raffinate ha sempre comportato una riduzione di consumi: arrivando ai 90nm le correnti di leakage sono diventati rilevanti, a seconda dei contesti (quindi non sempre).

[2]dimentichi che il leakage aumenta con l'aumentare del clock e così le capacità parassite che a 90nm sono molto più significative, soprattutto per la miniaturizzazione che c'è nei core a 90nm (vedi prescott che con il doppio di transistor sta ugualmente in meno superficia del northwood)

Indubbiamente: e chi l'ha mai negato questo? Il problema è che difficile stabilire quale sia la causa preponderante nel caso del Prescott, perché ha subito troppi cambiamenti rispetto al Northwood.

[3]Appunto è quello che scrivo da un po' mi pare... in una CPU non ci sono mai tutti i transistor attivi, altrimenti la temperatura in IDLE e in BURN sarebbe uguale, e così i consumi.
Per di più non ho detto che ca cache non consuma, semplicemente che ha consumi trascurabili.
Anche questo mi pare di averlo scritto più volte.

Infatti quella era un puntualizzazione. Come dire: la cache non incide in maniera rilevante nel discorso che stiamo affrontando...

[4]In realtà qualcuno all'inizi ha semplicemente detto "il P4 consuma di più perchè ha più transistor" e "il p4 consuma di più perchè ha un core diverso" che da quello che stai scrivendo sono affermazioni perfettamente opinabili.

Se messe assieme no, IMHO.

Da una lezione di calcolatori elettronici circa 4 anni fa, mi rimase impressa perchè uno studente aveva tirato su una interessante discussione (su chip dedicati e cpu general purpose) con l'esercitatore che era un ing. che lavorava in ST. (la frase era tipo "in una CPU moderna come un Pentium4 o un Athlon non troverete mai più del 30% dei transistor attivi nello stesso istante")
Che poi è un dato perfettamente plausibile, vista la differenza di consumi in Idle e Burn di una CPU, oppure ragionando sul consumo di un singolo transistor e facendo un calcolo, anche se in questo caso i tempi di commutazione possono farti variare la stima di molto.

Non metto in dubbio le considerazioni e la ragionevolezza di quanto hai scritto: mi riferivo al dato del 30%. Se, cioé, derivasse da uno studio preciso che lo dimostrasse.

Quindi è anche poco plausibile che le percentuali di transistor attivi nel prescott sia simile a quelle in un northwood, proprio perchè ha subito delle modifiche finalizzate al velocizzare delle singole operazioni.

Dimentichi che il P4 arriva ad avere fino a 120 istruzioni "in volo", che prima o poi devono essere servite: il fatto di avere più unità dedicate / specializzate permette di smistare e quindi portare a termine un maggior numero di istruzioni rispetto al Northwood.

[5]In realtà sarebbe bastato dire che i 90nm senza nessuna tecnologia di contorno non bastano a diminuire i consumi.

Non è detto, come ho già scritto.

Quote mio:

Cos'è che non consideravo?

Il come fossero stati impiegati quei transistor in più: tu sei rimasto sostanzialmente ancorato al fatto che gli stadi della pipeline siano arrivati a 31, e che quindi che il maggior numero di transisor fosse impiegato per questo motivo. Ciò non è affatto vero.

[6]- Ho ben detto che ci sono delle differenze nella gestione della pipe (avendo anche 30 e passa stadi invece che 20), ma quanto queste influiscono nei consumi? Non l'hai ancora detto.

Secondo me poco, se in un core è cambiato solamente il numero di stadi di pipeline. Questo perché si è soltanto distribuito il lavoro in maniera più "fine", ma la sostanza non cambia: il lavoro è sempre lo stesso.
Se, invece, in mezzo ci sono altre variazioni, il discorso cambia. Ovviamente.

- Come hai detto tu, puoi aggiungere transistor per delle unità che poi non sono utilizzate sempre, vedi EMT64, vedi IMUL aggiunto nella ALU complessa, vedi ShiftUnits aggiunte nelle ALU netburst. Tanti transistor in più che non fanno certo aumentare i consumi, anzi, avendo unità dedicate li fan diminuire O vorrai mica dirmi che fare una moltiplicazione intera interpellando la FPU consumi di meno che aggiungendo una IMUL alla ALU...

Vedi sopra: il lavoro semmai aumenta, perché si riesce a smistare e portare a termine più lavoro rispetto a prima...

- Ci sono anche le SSE3, ma quanto queste sono utilizzate?

Poco. E comunque non è che cambia più di tanto la situazione: si tratta di istruzioni aggiunte all'unità SIMD, non di unità di elaborazione.

[7]Non sono d'accordo, AMD ha aggiunto nel Thoro-B 1 layer (passando da 8 a 9) per salire di clock, intel ha invece creato vari stepping soprattutto per consumare mediamente meno, abilitando appunto il controllo delle tensioni in base agli ampere assorbiti e altro.
IMHO le finalità sono differenti.

Le finalità mi sembrano simili (entrambi avevano problemi di consumo eccessivo, di conseguenza impossibilità a salire di clock).
Comunque in entrambi i casi ripeto: non sono stati effettuati cambiamenti al core (parlo di modifiche alle unità di esecuzione, ai buffer, alla logica di prefetch, ecc.).

Si è un sito interessante e mi sono anche guardato le foto linkate tempo fa sui forum di anandtech. Se noti nel Prescott ci sono alcune zone che non sono state identificate, tanto per dirne una.

Se leggi bene si tratta molto probabilmente di Palladium / LaGrande.

Inoltre hai notato che quelle foto sono del 2003? In quel periodo non si sapeva nemmeno se il prescott avesse o no le istruzioni a 64bit, erano solo ipotesi.

Ma il bello è proprio questo: reverse engineer di quel tipo lo fanno come lavoro quello di capire a che servono i trasistor. Infatti se ti leggi bene quegli articoli capisci che sono arrivati alla conclusione che le estensioni a 64 bit erano già presenti, ed è anche sottolineato dove e come sono state implementate.

Sinceramente parlando avrei preferito il flow chart delle varie unità, tipo questo: http://www.xbitlabs.com/images/cpu/prescott/diagram.jpg
pero' anche qua siamo troppo a grandi linee, ci vorrebbe qualcosa di più preciso.

Quelle analisi sono MOLTO, ma MOLTO più precise del diagramma di flusso che hai postato: non solo si ricava quel disegnino, ma è anche tanti altri dettagli implementativi che altrimenti non conosceresti...

[8]Non mi viene da dirti che "stai sbagliando" ma piuttosto che non consideri che il leakage dipende dal clock.
http://arstechnica.com/articles/paed...prescott.ars/2

Infatti non ho sbagliato: citando la "frequenza", mi riferivo proprio al clock...

Sono perfettamente d'accordo con te, ma rispondi a questa domanda: secondo te un prescott prodotto con la tecnologia dell'A64 consumerebbe uguale?

Probabilmente qualcosa meno, grazie al SOI, ma non credo che la situazione cambierebbe radicamente: il Prescott è stato progettato per funzionare a frequenze elevate, ma la sua complessità è anche il suo tallone d'Achille.

Vedi punto 6

Idem.

Non ho link però se vuoi ho un libro, l'hennesy-patterson, cap 6. Ci sono varie versioni, l'ultima è aggiornata al 2000, un po' datata ma non ci sono certo scritte stronzate.

E chi lo nega? E' un ottimo libro, un prestigioso testo di riferimento, e per questo credo che quelle conclusioni che hai riportato, se effettivamente sono le stesse, probabilmente sono legate a un contesto e a delle precise considerazioni.
Se, invece, sono delle conclusioni "sui generis", allora mi spiace: proprio gli esempi che ho portato le confutano inequivocabilmente.

Verissimo, anche le SSE-2 fanno lo stesso, ma appunto per quello che le hanno introdotte: un IPC alto non ti serve per usare office o per navigare, piuttosto per encodare o giocare, e visto che l'IPC di un P4EE nel benchmark Drystone SSE-2 è 3,6 (le SSE-2 dovrebbero fare 8 operazioni a 16 bit in una volta sul singolo registro MMX) puoi immaginare cosa sia l'IPC senza.

Certo che lo immagino: non trascuro mai niente quando faccio delle considerazioni... Ma anche le SSE e le SIMD in generale non sempre si possono impiegare, per cui hanno un peso rilevante esclusivamente nel dominio d'utilizzo...

Se ti interessa posso sempre dare un occhio.

Se hai qualche informazione, sarebbe interessante.

Cque è facile calcolare l'IPC basta fare un programma in assembler che fa un ciclo ripetuto qualche miliardo di volte e calcolare il tempo impiegato, si potrebbe fare qualche prova, però serve un sistema operativo tipo DOS e da qui mi viene da pensare che è più la spesa che l'impresa :/

Se è solo questo ciò che chiedi, te lo dico io al volo e senza bisogno di fare delle prove: l'IPC risulterebbe quasi 4...
Però ti lascio sbatterci un po' la testa per capire da dove viene fuori, se ne hai voglia...

Su questo hai ragione: ho sicuramente sbagliato le mie ipotesi visto che intel vuole puntare ancora sulla tecnologia netburst.

OK.

[cdimauro]

Originariamente inviato da cionci

Boh...io è la prima volta che vedo una mul con tre parametri...

Io da quasi vent'anni: da quando Intel ha introdotto il 386...

[cdimauro]

Originariamente inviato da Dreadnought

2) i miglioramenti nell'HT, nel Branch Prediction e l'allungamento della pipe portano si a tanti transistor in più, ma non penso che sia un aumento proporzionale all'aumento di transistor da North a Prescott.

Nemmeno io lo credo.

Inoltre l'HT non è migliorato aggungendo transistor ma solo aumentando le cache (è scritto nelle tue note con le novità del prescott)

No, Intel ha migliorato anche l'HT. Ai tempi dell'introduzione del Prescott l'ho letto in qualche documento ufficiale...

Dubito che queste variazioni portino a 21 (o 11 che siano a seconda della interpretazione) milioni di transistor attivi in più, ovvero più di quello che è attivo in un core northwood completo.

Tutti attivi no, certo, ma penso che una buona parte dei transistor in più siano stati spesi proprio per tutte le novità elencate...

Veramente ho aperto una discussione su questo nel post 55
http://forum.hwupgrade.it/showpost.p...3&postcount=55
però visto che nessuno ha detto niente ho preso per buono che non vi interessasse.

Ehm: io qualcosa l'ho detta...

[Dreadnought]

Ti riassumo un po' quello che ho da dire, per il resto se non dico niente fai che concordo.

Originariamente inviato da cdimauro

Dipende. Finora è ciò che si è sempre verificato. Arrivando ai 90nm i problemi di leakage sono diventati rilevanti, a seconda dei casi...

Scusa eh... dove trovi cpu prodotte a 90nm senza strained silicon e/o low-k?

Originariamente inviato da cidimauro

Non sono tutti uguali: quanti sono quelli che si possono permettere di tirare fuori un risultato con una latenza di 10 cicli di clock e un throughput di 1?

Mi viene di pensare a quelli con tabella di lookup, che potrebbero avere una palata di transistor ma che effettivamente non consumano praticamente niente

No, Intel ha migliorato anche l'HT. Ai tempi dell'introduzione del Prescott l'ho letto in qualche documento ufficiale...

Sei sicuro che non sia conseguenza di altre migliorie apportate qua e là su prediction, prefetch e varie cache TLB aumentate di dimensioni?

Per me è difficile pensarlo senza dati certi e/o formule che permettano di dedurre questi valori.
Comunque, come dicevo nel messaggio precedente, finora il passaggio a tecnologie più raffinate ha sempre comportato una riduzione di consumi: arrivando ai 90nm le correnti di leakage sono diventati rilevanti, a seconda dei contesti (quindi non sempre).

Vero, però se ravani sul sito intel cercando Strained silicon 90nm su google trovi:

Intel's implementation of strained silicon devices improves drive current about a 25 percent in PMOS and about 10 percent in NMOS in silicon manufactured with it 90nm process. This gives a substantial gain over existing 0.13 micron processes while only increasing the manufacturing cost by two percent.
http://www.intel.com/technology/silicon/si12031.htm
e
http://www.intel.com/research/downlo...con-120403.pdf
http://www.eetimes.com/story/OEG20031024S0038

Da quello che ho capito con lo SS abbassi la R, aumenti la I e il transistor commuta più in fretta, quindi puoi portare la I più in là rispetto al valore iniziale senza SS e consumare uguale.

Se messe assieme no, IMHO.

Considerando che chi ha scritto quelle affermazioni ha ampliamente dimostrato di non conoscere bene nemmeno le poche leggi fondamentali sui consumi (che si possono apprendere da qualsiasi articolo tecnico con 3 click su google), non hanno senso nemmeno se messe assieme.
Sempre IMHO ovviamente

Non metto in dubbio le considerazioni e la ragionevolezza di quanto hai scritto: mi riferivo al dato del 30%. Se, cioé, derivasse da uno studio preciso che lo dimostrasse.

...penso fosse una affermazione di quelle che ti vengono dalle esperienze sul campo.
Sarà stata una stima, che poi sicuramente detta tipo nel 2001-2002 ha un senso, nel 2005 ne ha un'altro.

Dimentichi che il P4 arriva ad avere fino a 120 istruzioni "in volo", che prima o poi devono essere servite: il fatto di avere più unità dedicate / specializzate permette di smistare e quindi portare a termine un maggior numero di istruzioni rispetto al Northwood.

Beh perchè mai il doppio (dovrebbe essere il rapport tra northwood e prescott) di istruzini "on the fly" dovrebbe consumare di più visto che le unità di esecuzione sono le medesime e che il prescott ha un IPC minore dle northwood (e quindi un throughput minore)?

Infatti non ho sbagliato: citando la "frequenza", mi riferivo proprio al clock...

Eh ok, ma non mi puoi dire che il leakage è uguale, perchè il prescott arriva a 3.8GHz e il Dothan a 2.2
Un po' come dire che una BMW 550d ha lo stesso consumo di un 530d, puo' anche essere che il gasolio che entra per ogni cilindro è uguale, ma dovresti anche considerare che il numero e la grandezza dei cilindri

Se è solo questo ciò che chiedi, te lo dico io al volo e senza bisogno di fare delle prove: l'IPC risulterebbe quasi 4...
Però ti lascio sbatterci un po' la testa per capire da dove viene fuori, se ne hai voglia...

Come fa l'IPC ad essere così tanto maggiore di 1? Un A64 dovrebbe avere IPc di 6 visti i bench... e come farebbe? (soprattutto con istruzioni che impiegano tipo 10-20 clock per essere eseguite)
Poi c'è da aggiungere che tipo di istruzioni e registri considerare, se a 16, 8 o 32 bit, l'IPC è un dato di merda in ogni caso, dice tutto e il cotnrario di tutto.

[cdimauro]

Originariamente inviato da Dreadnought

Ti riassumo un po' quello che ho da dire, per il resto se non dico niente fai che concordo.

Idem: ormai c'è ben poco da discutere e sostanzialmente la discussione mi sembra ormai chiara...

Scusa eh... dove trovi cpu prodotte a 90nm senza strained silicon e/o low-k?

Non ne trovi, infatti, e purtroppo non è possibile fare dei confronti.
Rimane però la storia: finora, come dicevo, si è sempre provveduto ad effettuare un die shrink senza modificare la tecnologia utilizza, ma semplicemente riducendo le dimensioni dei transistor (che ha comporato una diminuzione dei consumi).
E' il passaggio dai 130nm ai 90nm che ha messo in risalto i problemi di leakage, in particolare per i processori che operano a frequenze elevate.

Mi viene di pensare a quelli con tabella di lookup, che potrebbero avere una palata di transistor ma che effettivamente non consumano praticamente niente

Infatti si usano proprio delle lut (più di una, a seconda della dimensione dei dati da trattare e degli obiettivi in termini di latenza e througput) da 8x8 -> 16 bit per implementare la moltiplicazione.
Perché dici che non consumano niente?

Sei sicuro che non sia conseguenza di altre migliorie apportate qua e là su prediction, prefetch e varie cache TLB aumentate di dimensioni?

No no: ricordo proprio che è stata migliorata la logica (i circuiti dedicati) del'HyperThreading.

Beh perchè mai il doppio (dovrebbe essere il rapport tra northwood e prescott) di istruzini "on the fly"

Può essere che mi sbagli, ma non ricordo che il numero di istruzioni "on the fly" sia cambiato fra i due processori.

dovrebbe consumare di più visto che le unità di esecuzione sono le medesime

Infatti non sono le stesse: ne abbiamo già parlato.

e che il prescott ha un IPC minore dle northwood (e quindi un throughput minore)?

Questo è un altro discorso: l'IPC minore del Prescott è dovuto all'elevato numero di stadi di pipeline, per cui uno stallo provoca maggiori perdite dal punto di vista prestazionale.
Le perdite sono contenute proprio grazie al fatto che Prescott esegue "più lavoro", perché l'efficienza "interna" è migliorata rispetto al Northwood.
Immagina cosa sarebbe potuto essere un Northwood con 31 stadi di pipeline e soltanto la cache L2 aumentata: un disastro!
Fare "più lavoro" chiaramente produce dei consumi maggiori. Tutto questo lavoro viene buttato a mare quando la pipeline si deve svuotare, ma l'energia ormai consumata non viene mica recuperata...

Eh ok, ma non mi puoi dire che il leakage è uguale, perchè il prescott arriva a 3.8GHz e il Dothan a 2.2

Appunto, ma quei processori utilizzano comunque lo stesso processo produttivo.
Il contesto d'utilizzo chiaramente è diverso, perché lavorano a frequenze diverse e hanno un core diverso. Un Prescott a 2,2Ghz certamente non consumerebbe tutta quella corrente che consuma a 3,8Ghz, sia per il minor clock sia per la minor tensione di lavoro che richiederebbe.

Non è in discussione che le correnti di leakage si facciano sentire maggiormente a frequenze più elevate: ci mancherebbe! Anzi da questo punto di vista il Prescott è messo anche peggio, visto che le due ALU lavorano a frequenza doppia rispetto agli altri circuiti, e sono le unità che lavorano di più (normalmente).

Però, come già detto, il processo produttivo è lo stesso.

Come fa l'IPC ad essere così tanto maggiore di 1? Un A64 dovrebbe avere IPc di 6 visti i bench...

Al più un A64 si avvicinerebbe a 3...

e come farebbe? (soprattutto con istruzioni che impiegano tipo 10-20 clock per essere eseguite)

Appunto. L'esempio che hai fatto non considerava il caso medio: realizzare un programma in assembly (non assembler: questo è il compilatore ) che esegua un ciclo con qualche istruzione in mezzo mette il processore in grado di lavorare in un contesto estremamente favorevole, e quindi lontano dalla realtà.
Nel caso del P4, potendo spedire / eseguire 4 istruzioni per ciclo di clock, arriveresti vicino a 4, appunto. Per lo stesso motivo, arriveresti a 3 con gli A64 (sempre se non ricordo male... )

Poi c'è da aggiungere che tipo di istruzioni e registri considerare, se a 16, 8 o 32 bit, l'IPC è un dato di merda in ogni caso, dice tutto e il cotnrario di tutto.

Esatto. L'IPC medio non lo si calcola con un loop con qualche istruzione, ma simulando l'esecuzione di codice estremamente diverso, relativo quindi ad ambiti applicativi diversi, e in condizioni varie (es: non tutte le pagine di dati/codice/stack sono presenti in memoria, o con gli indirizzi "cachati" nelle TLB, ecc. ecc. ecc.).

[Dreadnought]

Originariamente inviato da cdimauro

Infatti si usano proprio delle lut (più di una, a seconda della dimensione dei dati da trattare e degli obiettivi in termini di latenza e througput) da 8x8 -> 16 bit per implementare la moltiplicazione.
Perché dici che non consumano niente?

Conosci dei multiplier che consumano di meno a parità di bit?

Può essere che mi sbagli, ma non ricordo che il numero di istruzioni "on the fly" sia cambiato fra i due processori.

Non stavo confutando, dovevo esprimermi meglio: ho visto che è cambiato il numero di istruzioni in volo, ma non mi spiego perchè di così tanto...
Tempo fa lessi ingiro commenti tipo questo da geek.com:

http://www.geek.com/news/geeknews/20...0122023559.htm
The current p4 can only have 128 instructions issued at any one time - given that the 20 stage pipeline can have almost 100 instructions currently on the fly it is clear that the second thread can get very short changed.

Prescott (we think) can have up to 256 instructions issued at one time - if indeed the prescott pipeline is 30 stages, well over 100 could be on the fly however...

Capisco che è superscalare, ma con una pipe da 30-36 stadi, come fai ad avere 256 istruzioni in coda? Condisera forse la branch prediction? Oppure il prefetch? Oppure le istruzioni impacchettate tipo SIMD?

Infatti non sono le stesse: ne abbiamo già parlato.

Scusa è vero qua bisogna precisare:
Sono cambiate le unità nel senso che han subito modifiche e aggiunte, ma il numero delle unità è sempre quello di prima, vedo sempre 3 ALU (2 netburst e 1 complex), 2 FP (simple e complex), 1 Branch prediction....

Pero' c'è da dire che essendo aumentati i buffer e gli stage effettivamente si potrebbe dire dire che c'è un throughput maggiore, ma allora perchè il prescott a parità di clock viaggia meno del northwood?

[quote]Questo è un altro discorso: l'IPC minore del Prescott è dovuto all'elevato numero di stadi di pipeline, per cui uno stallo provoca maggiori perdite dal punto di vista prestazionale.
Le perdite sono contenute proprio grazie al fatto che Prescott esegue "più lavoro", perché l'efficienza "interna" è migliorata rispetto al Northwood.
Immagina cosa sarebbe potuto essere un Northwood con 31 stadi di pipeline e soltanto la cache L2 aumentata: un disastro!
Fare "più lavoro" chiaramente produce dei consumi maggiori. Tutto questo lavoro viene buttato a mare quando la pipeline si deve svuotare, ma l'energia ormai consumata non viene mica recuperata...

Non è in discussione che le correnti di leakage si facciano sentire maggiormente a frequenze più elevate: ci mancherebbe! Anzi da questo punto di vista il Prescott è messo anche peggio, visto che le due ALU lavorano a frequenza doppia rispetto agli altri circuiti, e sono le unità che lavorano di più (normalmente).

Esatto, appunto per quello che ho affermato che i 90nm non bastano per abbassare i consumi

Al più un A64 si avvicinerebbe a 3...

come fa ad andare di più con meno clock allora?

Appunto. L'esempio che hai fatto non considerava il caso medio: realizzare un programma in assembly (non assembler: questo è il compilatore ) che esegua un ciclo con qualche istruzione in mezzo mette il processore in grado di lavorare in un contesto estremamente favorevole, e quindi lontano dalla realtà.
Nel caso del P4, potendo spedire / eseguire 4 istruzioni per ciclo di clock, arriveresti vicino a 4, appunto. Per lo stesso motivo, arriveresti a 3 con gli A64 (sempre se non ricordo male... )

[Premettendo di ignorare l'unita SIMD]
Non è che mi convince molto questa tua spiegazione.
Se fosse così semplice aumentare il numero di istruzioni eseguite al secondo allora uno fa una cpu superpipelined e supescalare con 5 ALU per ogni core come un P4 ed è tutto fatto: SBAMMM! ed ecco che ci sono le nostre 5 istruzioni per ciclo di clock, basta che siano 4 semplici ed una complessa da distribuire nel caso ottimo sulle 5 alu che ci sono all'interno.

Ma le code? Le dipendenze tra le istruzioni? I registri non sono infiniti e le ram e le cache hanno latenza di 1-10-100 cicli; le istruzioni non devi solo eseguirle, devi anche farne il fetch e lo store e il numero dei registri non è fatto per 4 pipeline, ma per una, e così la pipeline è unica, non è il caso di una Scheda video che quando ha finito di processare i dati sono subito a video, una CPU poi i dati li deve rimandare in ram o da qualche altra parte.
Forse con dei NOP in serie ad un IPC di 4 ci arrivi facilmente, ma con altre istruzioni non penso

P.S: Assembler è anche il linguaggio, la tua definizione "assembly" è semplicemente uno slang usato da molti e reso famoso per le manifestazioni che si tengono nel nord europa, per altro una figata: vorrei essere stato là nel '93 quando vinse Second Reality! (la prima demo dell'assembly che mi diede un amico che masterizzava CD warez tirati giù dalle BBS)
L'anno dopo mi ero messo ad imparare l'assembler x86 comprandomi un bellissimo libro della mcgraw hill e il MASM... bei tempi... non avevo mai un cazzo da fare quando andavo al liceo

Esatto. L'IPC medio non lo si calcola con un loop con qualche istruzione, ma simulando l'esecuzione di codice estremamente diverso, relativo quindi ad ambiti applicativi diversi, e in condizioni varie (es: non tutte le pagine di dati/codice/stack sono presenti in memoria, o con gli indirizzi "cachati" nelle TLB, ecc. ecc. ecc.).

Si ok, ma da qui a dire che arrivi a 4 di IPC è diverso
Cque un IPC di 4 lo dici perchè hai provato oppure perchè ipotizzi? Fammi capire.

[Fx]

Originariamente inviato da Dreadnought

Scusa è vero qua bisogna precisare:
Sono cambiate le unità nel senso che han subito modifiche e aggiunte, ma il numero delle unità è sempre quello di prima, vedo sempre 3 ALU (2 netburst e 1 complex), 2 FP (simple e complex), 1 Branch prediction....

te lo stiamo dicendo da 4 pagine, hanno subito modifiche e aggiunte. non potrebbe essere altrimenti, dato che c'è più del doppio dei transistor e le unità sono bene o male le stesse.

Originariamente inviato da Dreadnought

Pero' c'è da dire che essendo aumentati i buffer e gli stage effettivamente si potrebbe dire dire che c'è un throughput maggiore, ma allora perchè il prescott a parità di clock viaggia meno del northwood?

perchè tutte le belle cose che si sono fatte per migliorare l'efficienza sono bastate a malapena per compensare un incremento di oltre il 50% della lunghezza della pipeline?

Originariamente inviato da Dreadnought

Esatto, appunto per quello che ho affermato che i 90nm non bastano per abbassare i consumi

aaaaaaaaaa e che palle che sei... il sottoscritto, che ha dato il via all'argomento, ha detto che "le cpu a 90 nm [a parità di core] consumano di meno", senza dire se questo fosse legato alla dimensione dei transistor o perchè tutti i processi produttivi a 90 nm hanno caratteristiche migliori.

in ogni caso, senza girarci intorno, sappiamo:
- che a 90 nm ci sono fenomeni di leakage
- che a 130 nm ci sono ANCHE LI' fenomeni di leakage, anche se in misura inferiore

premesso questo, ti giro la domanda:
producendo un prescott a 130 nm con low-k e strained silicon secondo te consumerebbe di meno di un prescott a 90 nm con low-k e strained silicon?

Originariamente inviato da Dreadnought

P.S: Assembler è anche il linguaggio, la tua definizione "assembly" è semplicemente uno slang usato da molti e reso famoso per le manifestazioni che si tengono nel nord europa, per altro una figata: vorrei essere stato là nel '93 quando vinse Second Reality! (la prima demo dell'assembly che mi diede un amico che masterizzava CD warez tirati giù dalle BBS)
L'anno dopo mi ero messo ad imparare l'assembler x86 comprandomi un bellissimo libro della mcgraw hill e il MASM... bei tempi... non avevo mai un cazzo da fare quando andavo al liceo

se vuoi ho fatto un paio di intro da pochi byte, te le posso passare =)

ps: cmq il mio testo di riferimento si chiamava opcodes.txt (quello del PCGPE, si)... ho anche un volumazzo della wrox fatto decisamente bene, ma non l'ho mai consultato più di tanto

[Fx]

comunque io aspetto ancora una spiegazione del come mai nello stesso core (stessa cpu, stesso core, stesso stepping) i consumi (quelli reali) crescano linearmente con la frequenza, e non da 20 a 30 mhz, ma da 3.2 a 3.8 ghz

[Dreadnought]

aaaaaaaaaa e che palle che sei... il sottoscritto, che ha dato il via all'argomento, ha detto che "le cpu a 90 nm [a parità di core] consumano di meno", senza dire se questo fosse legato alla dimensione dei transistor o perchè tutti i processi produttivi a 90 nm hanno caratteristiche migliori.

humm... non hai detto proprio così, hai detto che a 90nm abbassi il Vcc e consumi meno, ma non hai considerato che nei processi produttivi a 90nm che conosci o hanno usato SS+Low-K oppure SOI. Perchè se andiamo a guardare altri produttori che non hanno usato nessuno di questi, tipo samsung o toshiba nelle RAM i consumi sono in alcuni casi aumentati, anche se poi non gliene frega a nessuno perchè tanto un modulo di ram fa 8-10W.

in ogni caso, senza girarci intorno, sappiamo:
- che a 90 nm ci sono fenomeni di leakage
- che a 130 nm ci sono ANCHE LI' fenomeni di leakage, anche se in misura inferiore

I fenomeni di leakage nei 130nm sono trascurabili, nei 90nm sono rilevanti, la differenza è ampia, non poca. Da un articolo che ho postato un po' più indietro si leggeva che la potenza dissipata per il fenomeno del leakage a 90nm iniziava ad essere una percentuale consistente del totale.

Tra l'altro leggo ora qual'è l'arcano: il leakage non avviene a transistor attivo, ma a transistor spento. Quindi a 90nm se non riduci il leakage pure la cache tende ad aumentare i consumi, e ancor di più tendono a prendere importanza tutte le metodologie per ridurlo.

premesso questo, ti giro la domanda: producendo un prescott a 130 nm con low-k e strained silicon secondo te consumerebbe di meno di un prescott a 90 nm con low-k e strained silicon?

No, perchè fondamentalmente lo strained silicon e il Low-K servono solo per diminuire il leak della corrente, e a 130nm non ce n'è più di tanto.
Lo vedi anche tu no? Il prescott ha 125M di transistor in 112mm^2, il northwood ne ha 55M in 131mm^2 i fenomeni di capacità parassite con così tanti transistor impacchettati sono molto ma molto più consistenti.
http://www.hardware4you.it/recension...id_r=273&pag=7

tipo qua (banias -140M trans- e dothan -77M trans- a confronto)
http://www.hardware4you.it/recension...id_r=273&pag=5

...tra l'altro questo articolo di Hardware4you è molto interessante, sembra ben fatto.

se vuoi ho fatto un paio di intro da pochi byte, te le posso passare =)

ps: cmq il mio testo di riferimento si chiamava opcodes.txt (quello del PCGPE, si)... ho anche un volumazzo della wrox fatto decisamente bene, ma non l'ho mai consultato più di tanto

Io vorrei tanto racimulare ed archiviare tutti i vari programmi fatti negli assembly, con tutte le demo e relativi gruppi che le han fatte, con le sorgenti dove possibile

Le demo se me le vuoi passare le accetto volentieri

comunque io aspetto ancora una spiegazione del come mai nello stesso core (stessa cpu, stesso core, stesso stepping) i consumi (quelli reali) crescano linearmente con la frequenza, e non da 20 a 30 mhz, ma da 3.2 a 3.8 ghz

Si che te l'ho spiegato.


Cque stando in topic ma aggiungendo solo info ecco qua una img che mostra quanta attività c'è in una CPU, in questo caso un banias:

[cdimauro]

Originariamente inviato da Dreadnought

Conosci dei multiplier che consumano di meno a parità di bit?

Non sono un ingegnere elettronico...

Non stavo confutando, dovevo esprimermi meglio: ho visto che è cambiato il numero di istruzioni in volo, ma non mi spiego perchè di così tanto...
[...]
Capisco che è superscalare, ma con una pipe da 30-36 stadi, come fai ad avere 256 istruzioni in coda? Condisera forse la branch prediction? Oppure il prefetch? Oppure le istruzioni impacchettate tipo SIMD?

E' un discorso generale: il numero di istruzioni in volo è aumentato perché ci sono più unità di esecuzione in grado di potersene fare carico, oltre al fatto che il processore è superscalare ed è di tipo OOOE (quindi è molto facile trovare delle istruzioni che aspettano di essere eseguite per mancanza di unità disponibili oppure a causa di una dipendenza).

Scusa è vero qua bisogna precisare:
Sono cambiate le unità nel senso che han subito modifiche e aggiunte, ma il numero delle unità è sempre quello di prima, vedo sempre 3 ALU (2 netburst e 1 complex), 2 FP (simple e complex), 1 Branch prediction....

Macroscopicamente sì, ma il fatto, ad esempio, di avere l'ALU "complessa" che permette di eseguire finalmente una moltiplicazione intera senza ricorrere alla FPU è un cambiamento notevole. E' in questo senso che bisogna considerare per unità di esecuzione quella parte di un'ALU, FPU (o altro) che è in grado di portare a termine un ben preciso compito.

Pero' c'è da dire che essendo aumentati i buffer e gli stage effettivamente si potrebbe dire dire che c'è un throughput maggiore, ma allora perchè il prescott a parità di clock viaggia meno del northwood?

Per la lunghezza della pipeline. Ed è una conseguenza logica della strategia di Intel:
1) innalzamento della frequenza di clock del processore -> aumento del numero di stadi di pipeline;
2) aumento del numero di stadi di pipeline -> decadimento delle prestazioni;
3) aumento delle prestazioni -> aumento dell'efficienza del processore.

Esatto, appunto per quello che ho affermato che i 90nm non bastano per abbassare i consumi

Infatti sulla carta li abbasserebbero... solo che Prescott e Northwood sono due "bestie" diverse, ed è difficile fare paragoni (com'è, invece, possibile fare con Banias e Dothan): manca un Prescott a 130nm o un Northwood a 90nm...

come fa ad andare di più con meno clock allora?

Perché sono due processori completamente diversi: l'Athlon64, come l'Athlon, è stato progettato per essere più efficiente del P4.
Prova a dare un'occhiata ai tempi di esecuzione di una LEA EAX,[EBX + ESI * 4 + 1234567890] per entrambi i processori...

[Premettendo di ignorare l'unita SIMD]
Non è che mi convince molto questa tua spiegazione.
Se fosse così semplice aumentare il numero di istruzioni eseguite al secondo allora uno fa una cpu superpipelined e supescalare con 5 ALU per ogni core come un P4 ed è tutto fatto: SBAMMM! ed ecco che ci sono le nostre 5 istruzioni per ciclo di clock, basta che siano 4 semplici ed una complessa da distribuire nel caso ottimo sulle 5 alu che ci sono all'interno.

Ma le code? Le dipendenze tra le istruzioni? I registri non sono infiniti e le ram e le cache hanno latenza di 1-10-100 cicli; le istruzioni non devi solo eseguirle, devi anche farne il fetch e lo store e il numero dei registri non è fatto per 4 pipeline, ma per una, e così la pipeline è unica, non è il caso di una Scheda video che quando ha finito di processare i dati sono subito a video, una CPU poi i dati li deve rimandare in ram o da qualche altra parte.
Forse con dei NOP in serie ad un IPC di 4 ci arrivi facilmente, ma con altre istruzioni non penso

Ma è proprio questo dove volevo arrivare io...
Eseguire un loop con delle istruzioni qualche miliardo di volte per calcolare l'IPC non ha senso, perché non tiene conto della diversità del tipo di codice e del contesto di esecuzione. L'IPC medio viene calcolato tenendo conto di queste variabili, e in ogni caso rimane un dato che ha una valenza relativa e non assoluta...

P.S: Assembler è anche il linguaggio, la tua definizione "assembly" è semplicemente uno slang usato da molti e reso famoso per le manifestazioni che si tengono nel nord europa,

Ti assicuro che uso la parola "assembly" quando ancora non esisteva ancora nessuna manifestazione del genere.
Comunque per "assembler" s'intende il compilatore ("assembler" è un particolare "compiler") e non il linguaggio, anche se da anni ormai il termine viene usato anche per quest'ultimo.

per altro una figata: vorrei essere stato là nel '93 quando vinse Second Reality! (la prima demo dell'assembly che mi diede un amico che masterizzava CD warez tirati giù dalle BBS)

Purtroppo non posso condividere la tua gioia: ho sempre visto in malo modo le demo e chi le realizzava.

L'anno dopo mi ero messo ad imparare l'assembler x86 comprandomi un bellissimo libro della mcgraw hill e il MASM... bei tempi... non avevo mai un cazzo da fare quando andavo al liceo

A chi lo dici... Però è stata un'esperienza formativa...

Si ok, ma da qui a dire che arrivi a 4 di IPC è diverso

Vedi sopra: l'ho detto perché il contesto me lo permetteva...

Cque un IPC di 4 lo dici perchè hai provato oppure perchè ipotizzi? Fammi capire.

La trace cache del Prescott è in grado di spedire fino a quattro microistruzioni (il Northwood fino a tre) all'unità RISC86, che le esegue. Nella migliore delle ipotesi, quindi, verrano eseguite quattro istruzioni (supponendo, ovviamente, che ogni istruzione venga rimappata in una sola microistruzione). Il contesto mi permetteva di fare qualunque assunzione, da cui IPC = 4...

[Fx]

Originariamente inviato da Dreadnought

I fenomeni di leakage nei 130nm sono trascurabili, nei 90nm sono rilevanti, la differenza è ampia, non poca. Da un articolo che ho postato un po' più indietro si leggeva che la potenza dissipata per il fenomeno del leakage a 90nm iniziava ad essere una percentuale consistente del totale.

eh, porta numeri... scoprirai che anche a 130 nm non sono così trascurabili... certo, a 90 nm sono decisamente più importanti, ma anche a 130 nm non sono affatto trascurabili

Originariamente inviato da Dreadnought

Tra l'altro leggo ora qual'è l'arcano: il leakage non avviene a transistor attivo, ma a transistor spento. Quindi a 90nm se non riduci il leakage pure la cache tende ad aumentare i consumi, e ancor di più tendono a prendere importanza tutte le metodologie per ridurlo.

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

ce l'ha fatta...

Originariamente inviato da Dreadnought

Io vorrei tanto racimulare ed archiviare tutti i vari programmi fatti negli assembly, con tutte le demo e relativi gruppi che le han fatte, con le sorgenti dove possibile

Le demo se me le vuoi passare le accetto volentieri

sono due intro (quelle piiiiiiiiccole piccole), le recupero e te le mando... anche se sotto xp che mi ricordi una si impasta (nel senso che termina poco dopo la metà)... probabilmente un baco che sotto dos o sotto i vari win senza modalità protetta rimaneva nascosto

Originariamente inviato da Dreadnought

Si che te l'ho spiegato.

Originariamente inviato da Dreadnought

Cque stando in topic ma aggiungendo solo info ecco qua una img che mostra quanta attività c'è in una CPU, in questo caso un banias:

come era lecito aspettarsi


cidimauro: hai parlato del tempo che ci impiegano pentium 4 e athlon 64 a fare quella LEA (tra le altre cose sembra incasinata ma in realtà è abbastanza tipica... tra l'altro cmq a memoria una cosa del genere già ai tempi dei 386/486 consumava pochissimo, forse 2/3 cicli di clock)... dimmi che hai una bella tabella con tutti gli opcode (magari anche quelli specifici per le varie cpu) e i cicli di clock... io non ne trovo più una così dal 486 cazzo =)

[leoneazzurro]

Originariamente inviato da Dreadnought

No, perchè fondamentalmente lo strained silicon e il Low-K servono solo per diminuire il leak della corrente, e a 130nm non ce n'è più di tanto. ]

No per lo strained silicon (forse volevi dire SOI) che in realtà viene usato per aumentare la mobilità degli elettroni nel materiale e quindi abbassare la resistenza elettrica del mezzo (e quindi i consumi, ma non quelli legati al leakage) e consente inoltre di aumentare la velocità di switching dei transistor e no per il low-K che ha il compito invece di limitare le capacità parassite e quindi di migliorare l'integrità dei segnali elettrici. E' altresì vero che in questo modo si riducono anche le correnti parassite, tuttavia queste correnti non sono quelle di leakage propriamente dette.

[cdimauro]

Originariamente inviato da Fx

hai parlato del tempo che ci impiegano pentium 4 e athlon 64 a fare quella LEA (tra le altre cose sembra incasinata ma in realtà è abbastanza tipica...

E' una delle istruzioni più utili e usate dai programmatori più esperti...

tra l'altro cmq a memoria una cosa del genere già ai tempi dei 386/486 consumava pochissimo, forse 2/3 cicli di clock)...

Per il 386 il tempo di esecuzione era di almeno 3 cicli di clock.
Un 486 dovrebbe impiegare 1 ciclo di clock.
Sempre se la memoria non m'inganna...

dimmi che hai una bella tabella con tutti gli opcode (magari anche quelli specifici per le varie cpu) e i cicli di clock... io non ne trovo più una così dal 486 cazzo =)

Li trovi sui manuali di Intel e AMD.

Per il resto sono fermo a quasi una decina d'anni fa, con la tabella presente nella famosa Interrupt List di Ralph Brown, che riportava per ogni istruzione i processori che la implementevano e il loro tempo d'esecuzione. Si fermava al Pentium, se non erro.

[Fx]

Originariamente inviato da cdimauro

E' una delle istruzioni più utili e usate dai programmatori più esperti...

si, dato che è altamente ottimizzata si usa anche a "sproposito", nel senso che la sua finalità è quella di calcolare un offset, ma se ti serve fare ad es. "y = x*4 + a" la usi lo stesso che è molto più rapida di fare una mul (o se sei sgamato uno shift) e un add...

Originariamente inviato da cdimauro

Per il 386 il tempo di esecuzione era di almeno 3 cicli di clock.
Un 486 dovrebbe impiegare 1 ciclo di clock.
Sempre se la memoria non m'inganna...

ci inganna ad entrambi

LEA - Load Effective Address

Usage: LEA dest,src
Modifies flags: None

Transfers offset address of "src" to the destination register.

Clocks Size
Operands 808x 286 386 486 Bytes

reg,mem 2+EA 3 2 1 2-4

- the MOV instruction can often save clock cycles when used in
place of LEA on 8088 processors

Originariamente inviato da cdimauro

Li trovi sui manuali di Intel e AMD.

io ho ritrovato la pcgpe online... guardati "Intel opcodes"... i manuali di intel e amd li avevo guardati ma a quanto mi ricordo (era successo parecchio tempo fa) sono organizzati peggio... cmq me li andrò a rivedere =)

http://www.qzx.com/pc-gpe/

Originariamente inviato da cdimauro

Per il resto sono fermo a quasi una decina d'anni fa, con la tabella presente nella famosa Interrupt List di Ralph Brown, che riportava per ogni istruzione i processori che la implementevano e il loro tempo d'esecuzione. Si fermava al Pentium, se non erro.

minchia era enorme... c'erano pure gli INT usati dai virus... c'è da farsi venire il mal di testa solo a pensarci

[cdimauro]

Originariamente inviato da Fx

si, dato che è altamente ottimizzata si usa anche a "sproposito", nel senso che la sua finalità è quella di calcolare un offset, ma se ti serve fare ad es. "y = x*4 + a" la usi lo stesso che è molto più rapida di fare una mul (o se sei sgamato uno shift) e un add...

Esattamente. Occhio però a non usarla su un P4...

ci inganna ad entrambi

Ho cannato quello del 386: ricordavo peggio...

io ho ritrovato la pcgpe online...

"Bookmarkata"

guardati "Intel opcodes"...

Vecchiotta come tabella, però...

i manuali di intel e amd li avevo guardati ma a quanto mi ricordo (era successo parecchio tempo fa) sono organizzati peggio... cmq me li andrò a rivedere =)

Meglio, perché almeno sono aggiornati. Dopo passa ai manuali sulle ottimizzazioni...

minchia era enorme... c'erano pure gli INT usati dai virus... c'è da farsi venire il mal di testa solo a pensarci

Ai tempi erano molto interessanti...

[Dreadnought]

Originariamente inviato da Fx

eh, porta numeri... scoprirai che anche a 130 nm non sono così trascurabili... certo, a 90 nm sono decisamente più importanti, ma anche a 130 nm non sono affatto trascurabili

Oh sempre io devo portare i numeri?

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

ce l'ha fatta...

aa cosa?
ma se non lo sapevi nemmeno.

Tra l'altro questo implica che un dothan che ha 140M di transistor dovrebbe consumare di più di un banias che ne ha 77, rispetto ad un prescott e un northwood.

Perchè a questo punto la cache non ha più un consumo idle trascurabile, ma probabilmente il dothan e il prescott non hanno lo stesso processo produttivo.

cidimauro: hai parlato del tempo che ci impiegano pentium 4 e athlon 64 a fare quella LEA (tra le altre cose sembra incasinata ma in realtà è abbastanza tipica... tra l'altro cmq a memoria una cosa del genere già ai tempi dei 386/486 consumava pochissimo, forse 2/3 cicli di clock)... dimmi che hai una bella tabella con tutti gli opcode (magari anche quelli specifici per le varie cpu) e i cicli di clock... io non ne trovo più una così dal 486 cazzo =)

su google l'avevo trovata tempo fa, una tabellona con tutte le istruzioni e i tempi di exec di tutti i 5/6/786

[Dreadnought]

Originariamente inviato da Fx

http://eetimes.com/news/design/showA...leID=159902216

P = KCV2F

where

K is toggle rate (the fraction of time that transistors are switching)
C is circuit capacitance, including interconnect and transistor capacitance
V is supply voltage to transistors
F is operating frequency

No per lo strained silicon (forse volevi dire SOI) che in realtà viene usato per aumentare la mobilità degli elettroni nel materiale e quindi abbassare la resistenza elettrica del mezzo (e quindi i consumi, ma non quelli legati al leakage) e consente inoltre di aumentare la velocità di switching dei transistor e no per il low-K che ha il compito invece di limitare le capacità parassite e quindi di migliorare l'integrità dei segnali elettrici. E' altresì vero che in questo modo si riducono anche le correnti parassite, tuttavia queste correnti non sono quelle di leakage propriamente dette.

Per il leakage di specifico c'è il SOI

Rimane il fatto che riducendo la R dei transistor P e dei transistor N, le commutazioni sono più rapide e si puo' abbassare la Vcc mantenendo clock superiori. Abbassando il Vcc consumi meno e riduci il problema del leak, indirettamente, ma lo argini in qualche modo.

Penso che il goal finale sia la stabilità delle commutazioni e la riduzione dei Watt.