[Thread Ufficiale] Aspettando Bulldozer *leggere prima pagina con attenzione*

[paolo.oliva2]

@Cionci.

Io ti chiederei una cosa, che ti illustro con parole certamente non tecniche (discorso Magny-C e low-k).

Io avevo fatto un collegamento mio a intuito (senza basi tecniche) sul fatto che i MC sono step D1 (45nm SOI senza low-k).

Le prime versioni del Thuban, avevano un Vcore minimo piuttosto alto, in quanto un 1090T mi sembra non potesse scendere sotto 1,150V, contro 0,8V di un Phenom II C3.

Questo mi ha portato a pensare che i MC non siano stati realizzati con il low-k perché tanto lavoravano a frequenze basse e quindi forse con Vcore 1,1V o addirittura 1V.

In poche parole, un Thuban ha un TDP basso se viene paragonato ad un C3, a patto che lo si faccia lavorare a frequenze alte, perché necessita di un Vcore minore, mentre, al contrario, in teoria, un MC ottiene un TDP inferiore con il 45nm C3 che con un E0 low-k. Tieni presente che all'uscita dei Thuban, il 95W era per frequenze sui 2,6GHz, ed i 125W per i 3,2GHz. A distanza di tempo, i 95W hanno incrementato la frequenza di 300MHz, i 125W solamente di 100MHz, e questo in concomitanza di abbassamento del Vcore minimo (da 1,250V a 1,1V, -0,15V), non tanto di quello massimo, che al più è cambiato di -0,05V.
Ora mi viene un dubbio... riguardo la presenza dell'ULK già allo stadio iniziale del 32nm. O GF ha lavorato bene e ULK/Vcore bassi non sono un problema, oppure forse... ci potrebbe essere un nesso del perché prima desktop e poi server.
Il desktop ha bisogno di frequenze alte, e quindi l'ULK (facendo un parallelo low-k) in ogni caso permetterebbe di più. Il discorso server invece darebbe priorità al TDP per via del numero maggiore di core, quindi, a maggior ragione l'ULK avrebbe bisogno di un processo più rodato.
Per il lato desktop, tra core che si spengono e parti del procio inattive, il discorso TDP minimo in idle non sarebbe un problema anche se il Vcore fosse relativamente più alto. La cosa cambierebbe per un procio server che necessariamente dovesse avere un Vcore più alto (con l'ULK) perché le frequenze sono più basse.

Boh...


l'HKMG abbasserebbe ulteriormente il Vcore... infatti si partirebbe da 0,8V. o AMD realizza il 32nm direttamente con l'ULK avendo risolto tutti i problemi, i casi sarebbero 2.

[capitan_crasy]

Originariamente inviato da Labview

1° Nel bios non è presente alcun OPN
2° Il microcode è lo stesso della 890FX Deluxe4, quindi di deve attndere un upgrade.

Tanto per essere OT...

[IMG]http://www.pctunerup.com/up/results/_201103/20110304220149_Cattura1.JPG[/IMG
[IMG]http://www.pctunerup.com/up/results/_201103/20110304220356_Cattura2.JPG[/IMG

Ciao lab, per cortesia abbassa la risoluzione delle immagini...

Originariamente inviato da capitan_crasy

Chiedi a Labview, ma dubito che i primi BIOS abbiano già il supporto alle CPU Bulldozer...

Se era già presente il supporto a quest'ora l'avrei già sparato su marte

Purtroppo anche dalle mie fonti non scorre una goccia d'acqua...

Originariamente inviato da capitan_crasy

Ciao lab, per cortesia abbassa la risoluzione delle immagini...

è meglio il link

[paolo.oliva2]

Originariamente inviato da xk180j

adesso la scimmia di Paolo si risveglia o almeno fa la sonnambula

.
Le 8+2 fasi le ha anche la CF IV (mi sembra). La dissipazione del socket migliore... io sono a liquido. Di meglio ci sono 8 porte SATA, la CF IV ne ha 6 + 1 e-sata... questo non mi dispiacerebbe , però alla fine è 1 porta.

La scimmia questa mobo non me la fa venire... a parte l'acquolina in bocca perché mi fa assaporare BD più vicino.

Tu aspetta che annuncino BD disponibile, poi vedrai che scimmia.

[paolo.oliva2]

Originariamente inviato da Labview

Se era già presente il supporto a quest'ora l'avrei già sparato su marte

Purtroppo anche dalle mie fonti non scorre una goccia d'acqua...

Mah... secondo me (ho scoperto l'acqua calda) vogliono tenere sotto tomba tutto fino all'ultimo. Dal mio punto di vista, è una certezza che hanno da nascondere cose buone, non certo cattive

[astroimager]

Io sono sempre più convinto che il lancio di Llano è più vicino di BD, dato che l'NDA di quest'ultimo è praticamente caduto, almeno per la parte GPU.

[Athlon 64 3000+]

Originariamente inviato da astroimager

Io sono sempre più convinto che il lancio di Llano è più vicino di BD, dato che l'NDA di quest'ultimo è praticamente caduto, almeno per la parte GPU.

C'è quindi una possibilità che Llano possa essere addirittura essere presentato prima di Buldozer?
Se mai fosse vero sarebbe una cosa fantastica.

[bjt2]

Allora... Due cose... La prima è che nella slide del capitano, si legge in piccolo che Llano va a 1.8GHz più turbo, anche se il BIOS era beta...
La seconda... Non dimentichiamo che un modulo BD ha 30000 clock enable... Che vuol dire? Che c'è una granularità molto spinta nel poter spegnere le unità. Spegnere il clock non azzera il leakage. Ma se in un dato momento ci sono il 10% del modulo attivo (ed è possibile perchè il clock enable puó essere acceso e spento a ogni ciclo, quindi ad ogni ciclo solo i transistors strettamente necessari hanno il clock attivo), abbiamo un 23% di leackage sempre attivo e un altro 10% del restante 67%... Anche ammettendo un 60% per un carico molto pesante, io penso che il turbo entri in funzione quasi sempre... Qui non stiamo parlando di INTEL... Qui abbiamo un leakage molto basso...

[paolo.oliva2]

Originariamente inviato da bjt2

Allora... Due cose... La prima è che nella slide del capitano, si legge in piccolo che Llano va a 1.8GHz più turbo, anche se il BIOS era beta...
La seconda... Non dimentichiamo che un modulo BD ha 30000 clock enable... Che vuol dire? Che c'è una granularità molto spinta nel poter spegnere le unità. Spegnere il clock non azzera il leakage. Ma se in un dato momento ci sono il 10% del modulo attivo (ed è possibile perchè il clock enable puó essere acceso e spento a ogni ciclo, quindi ad ogni ciclo solo i transistors strettamente necessari hanno il clock attivo), abbiamo un 23% di leackage sempre attivo e un altro 10% del restante 67%... Anche ammettendo un 60% per un carico molto pesante, io penso che il turbo entri in funzione quasi sempre... Qui non stiamo parlando di INTEL... Qui abbiamo un leakage molto basso...

Sinceramente... io lo nasavo dall'inizio (ma a livello di intuito, certamente non tecnicamente ).

Non si poteva considerare questo Turbo come uguale a quanto visto sino ad ora, cioé praticamente che il Turbo entrerebbe in funzione solamente quando il 50% dei core è sotto carico o addirittura solo 1, perché appunto in quel momento il TDP reale sarebbe di molto inferiore al TDP nominale.
Annunciare un Turbo di +500MHz su 16 core già sotto carico, di per sè rappresentava più che esplicitamente uno scienario ben differente, perché con i proci "tradizionali", nel momento in cui tutti i core sono sotto carico, il TDP reale dovrebbe essere uguale al TDP nominale, quindi senza alcun W di margine per il Turbo.
I 30.000 clock enable a modulo, in un modo o nell'altro, anche se si parla di Turbo deterministico, rifletterebbero la condizione a priori che architetturalmente un modulo BD sotto carico non sfrutti l'intero TDP nominale, e di qui lo spazio per il turbo è implicito. Questo si collega ampiamente al rumors del 63% del TDP utilizzato da BD sotto carico, che mano a mano che passa il tempo, prende sempre più sostanza.

Io mi sto convincendo che se le innovazioni dell'architettura BD fossero state implementate anche su un procio su base 45nm, tralasciando eventuali limitazioni del 45nm, porterebbero agli stessi guadagni di frequenza che invece noi stiamo attribuendo ad un BD sul 32nm, valutando quindi le frequenze possibili di un'architettura BD + il 32nm inferiori a quanto si potrebbe delineare.
Sarebbe come dire che se noi abbiamo previsto +20% di clock, la cosa andrebbe vista forse come +30% o anche +40%. In questo scenario, prendendo come paragone un Phenom II a 125W a 3,6GHz, veramente i 4,5GHz per un BD X4 95W a frequenza def non sarebbero da considerare ottimistici, ma quasi pessimistici.

[Caterpillar86]

Previsioni di cali di prezzi dei Phenom II X6 per quando uscirà Buldozer?

[Heimdallr]

Originariamente inviato da Caterpillar86

Previsioni di cali di prezzi dei Phenom II X6 per quando uscirà Buldozer?

Se calano ancora li regaleranno coi punti delle merendine

[cionci]

Originariamente inviato da bjt2

Allora... Due cose... La prima è che nella slide del capitano, si legge in piccolo che Llano va a 1.8GHz più turbo, anche se il BIOS era beta...
La seconda... Non dimentichiamo che un modulo BD ha 30000 clock enable... Che vuol dire? Che c'è una granularità molto spinta nel poter spegnere le unità. Spegnere il clock non azzera il leakage. Ma se in un dato momento ci sono il 10% del modulo attivo (ed è possibile perchè il clock enable puó essere acceso e spento a ogni ciclo, quindi ad ogni ciclo solo i transistors strettamente necessari hanno il clock attivo), abbiamo un 23% di leackage sempre attivo e un altro 10% del restante 67%... Anche ammettendo un 60% per un carico molto pesante, io penso che il turbo entri in funzione quasi sempre... Qui non stiamo parlando di INTEL... Qui abbiamo un leakage molto basso...

Io credo che il Turbo sia sempre in funzione con carichi esclusivamente INT. Dall'altro lato credo che non sia mai in funzione in un uso FP estremo, però FP legacy misto a SIMD. In questo caso ci sarebbe anche un fortissimo uso dell'unità INT (come si vede dalla slide, l'unità INT ricopre comunque una buona percentuale che non credo sia attribuibile al caso di uso di sole istruzioni SIMD).
Per il calcolo del Turbo al 100% di utilizzo (dubito che i due core del modulo siano indipendenti in frequenza) bisogna però tenere conto anche di quello che fa il core accanto. Se i due core hanno un carico come quello descritto sopra è chiaro che il Turbo non potrà essere inserito, ma anche se il carico di uno solo dei due core sarà come quello sopra è palese che non potrà essere inserito. Questo perché l'unità FP verrebbe sfruttata al 100% delle proprie possibilità (e quindi max TDP) anche solo da un thread.
Anzi, credo che questo sia esattamente il worst case: un core INT al 100% e un workload come quello descritto sopra sull'altro core.

Originariamente inviato da paolo.oliva2

Ma anche no. Io credo, ma vado ad intuito, che sia sempre la stessa cosa o comunque cambi poco.
Cioè... se a livello di 1 core/1 TH, dicendola breve, o si esegue un INT o un FP, a livello di 2 core o si eseguirebbero 2 INT o 2 FP (o 1 doppio) o 1 INT e 1 FP, ma nella logica, rimarrebbe invariato l'utilizzo a core, nel senso che se parliamo a core sarebbe il 63%, se parliamo a modulo, dovremmo essere comunque sempre al 63%. D'altronde, quando si parla di TDP usato, si parla sempre del 63% sul nominale, quindi, a maggior ragione, con numero di TH uguale al numero massimo di core fisici.

Leggi sopra

Originariamente inviato da paolo.oliva2

Scusa, se fosse come dici tu, un BD X16 tra avere 4 core in più (+33%) e l'IPC in più (+20%), perché un BD ottenesse solamente +50% rispetto a MC... avrebbe bisogno anche di una frequenza maggiore di clock? Anche perché, se AMD ha utilizzato quel valore, certamente avrà usato software che scalino bene all'aumentare dei core, e visto che il discorso è il confronto tra un X12 e X16, ipotizzare che non l'abbia fatto è utopistico.
Diversamente, come fai a confrontare 2 proci diversi per capirne la potenzialità se le frequenze operative fossero diverse? E' come se dicessi che un Thuban va di più di un SB, perché io farei girare il Thuban a 4,5GHz e poi mi prendo un SB mobile come confronto a 2GHz...
E nemmeno a parità di TDP, perché comunque BD ha un TDP/frequenza nettamente migliore di MC.
Comunque se il discorso si fosse basato su un sistema equipaggiato con MC ed un altro con BD, la cosa sarebbe dubbia, perché in quel senso si parlerebbe più di prestazioni sistema (e frequenza superiore, TDP/frequenza, IPC, farebbero parte del brodo), diverso invece come ha intavolato il discorso JF, parlando unicamente di BD rispetto a MC, nel qual caso, il confronto per forza di cose va interpretato a IPC e numero dei core ma a frequenza chiaramente uguale, altrimenti sarebbe un confronto tra pere e mele.

In poche parole, JF non ha assolutamente specificato che le frequenze erano uguali ma nemmeno ha specificato che i TDP erano uguali e tantomeno che le frequenze erano diverse. Ma mi sembra chiaro... come poteva parlare di frequenze ufficiali con un Interlagos BD X16 a dicembre 2010 con la commercializzazione 9 mesi dopo?

Vedi, il fatto è che nei server si ha proprio come unità di misura della validi di un server il ratio prestazioni/potenza assorbita.
Quindi già è poco probabile fare una sostituzione di CPU in un server, nei casi in cui verrà fatta è chiaro che si andrà a massimizzare il ratio prestazioni/potenza. Quindi si andrà a mettere una CPU con TDP (o addirittura potenza massima vera e propria) identica alla CPU originale.
Questo è dovuto anche a al fatto che alcuni server nascono dimensionati proprio per quella data potenza della CPU.
Quello del non conoscere la frequenza è un falso problema. Sono sicuro che la frequenza target, a meno di 100 Mhz, la conoscono già dal primo sample, quindi anche a luglio, dopo il primo tape out.

[gi0v3]

Originariamente inviato da cionci

Vedi, il fatto è che nei server si ha proprio come unità di misura della validi di un server il ratio prestazioni/potenza assorbita.
Quindi già è poco probabile fare una sostituzione di CPU in un server, nei casi in cui verrà fatta è chiaro che si andrà a massimizzare il ratio prestazioni/potenza. Quindi si andrà a mettere una CPU con TDP (o addirittura potenza massima vera e propria) identica alla CPU originale.
Questo è dovuto anche a al fatto che alcuni server nascono dimensionati proprio per quella data potenza della CPU.
Quello del non conoscere la frequenza è un falso problema. Sono sicuro che la frequenza target, a meno di 100 Mhz, la conoscono già dal primo sample, quindi anche a luglio, dopo il primo tape out.

sulla frequenza esatta dubito, anche perchè per come vanno gli step di silicio le differenze potrebbero essere notevoli, dal primo tape out allo step in vendita... sul tdp quotissimo, più macchine hai più il sistema di raffreddamento è tarato al millimetro (cubo, di aria spostata ), quindi l'importante è che non si superi il tdp della generazione prima, e visto che nella stragrande maggioranza dei casi una diminuzione del calore da dissipare non porta alcun beneficio economico all'azienda (leggi: le ventole non girano a minori rpm, le pompe non spostano meno liquido, i condizionatori non battono ciglio) a quel punto la soluzione ideale è una cpu che consumi esattamente come la precedente, aumentando le prestazioni... una cpu che abbia le stesse prestazioni con meno watt diventa economicamente sconveniente

[cionci]

Originariamente inviato da gi0v3

sulla frequenza esatta dubito, anche perchè per come vanno gli step di silicio le differenze potrebbero essere notevoli, dal primo tape out allo step in vendita...

Non ho detto che il primo tape out avesse quella frequenza, ma che potessero tranquillamente determinare in base a calcoli statistici o fisici la frequenza di commercializzazione senza particolari problemi.

[bjt2]

Originariamente inviato da cionci

Io credo che il Turbo sia sempre in funzione con carichi esclusivamente INT. Dall'altro lato credo che non sia mai in funzione in un uso FP estremo, però FP legacy misto a SIMD. In questo caso ci sarebbe anche un fortissimo uso dell'unità INT (come si vede dalla slide, l'unità INT ricopre comunque una buona percentuale che non credo sia attribuibile al caso di uso di sole istruzioni SIMD).
Per il calcolo del Turbo al 100% di utilizzo (dubito che i due core del modulo siano indipendenti in frequenza) bisogna però tenere conto anche di quello che fa il core accanto. Se i due core hanno un carico come quello descritto sopra è chiaro che il Turbo non potrà essere inserito, ma anche se il carico di uno solo dei due core sarà come quello sopra è palese che non potrà essere inserito. Questo perché l'unità FP verrebbe sfruttata al 100% delle proprie possibilità (e quindi max TDP) anche solo da un thread.
Anzi, credo che questo sia esattamente il worst case: un core INT al 100% e un workload come quello descritto sopra sull'altro core.

Leggi sopra

Vedi, il fatto è che nei server si ha proprio come unità di misura della validi di un server il ratio prestazioni/potenza assorbita.
Quindi già è poco probabile fare una sostituzione di CPU in un server, nei casi in cui verrà fatta è chiaro che si andrà a massimizzare il ratio prestazioni/potenza. Quindi si andrà a mettere una CPU con TDP (o addirittura potenza massima vera e propria) identica alla CPU originale.
Questo è dovuto anche a al fatto che alcuni server nascono dimensionati proprio per quella data potenza della CPU.
Quello del non conoscere la frequenza è un falso problema. Sono sicuro che la frequenza target, a meno di 100 Mhz, la conoscono già dal primo sample, quindi anche a luglio, dopo il primo tape out.

Io penso che durante l'intervallo di tempo di cambio clock, che penso sia sui 100ms, a meno di codice patologico, ci saranno momenti di stallo di pipeline, per tanti motivi: branch miss prediction, cache miss, interdipendenze tra istruzioni... Anche esagerando e considerando un IPC medio di 2, un core int ha 4 pipeline di calcolo e 3 di memoria. Questo vuol dire che in un dato intervallo, in media, meno del 50% dei transistors sono usati... E ho considerato solo codice intero... Mettiamo 2 thread con IPC 2. Abbiamo in media 4 istruzioni per clock, quando un modulo ne puó fare 8 intere, 6 di memoria e 4 FP... Secondo te che percentuale di transistors sono attivi in media?
Per il fatto di un core int occupato al 100%: di nuovo anche considerando un codice con ipc 2, molto alto, vediamo che comunque non si usano neanche il 50% dei transistors del modulo int, che comunque è solo il 12% dell'intero modulo... Quindi di margine ce n'è se considerano come TDP massimo quello con tutti i transistors attivi...
Per la questione clock: con le varie code c'è la possibilità teorica di avere clock separati per i due core int, il core fp e il resto... Ma credo se ne parli almeno con il BD 2... Hanno dichiarato miglioramenti... Questo è l'unico rimasto...

[astroimager]

Originariamente inviato da Athlon 64 3000+

C'è quindi una possibilità che Llano possa essere addirittura essere presentato prima di Buldozer?
Se mai fosse vero sarebbe una cosa fantastica.

Se non ci sono bug gravi o problemi di resa... dopo quello che abbiamo visto... perché aspettare ulteriormente?
Il discorso è semplice: o cominciano la distribuzione ai partner entro qualche settimana, cercando di contrastare SB fin dalla tarda primavera - estate, o proseguono con lo sviluppo, invadendo il mercato da fine agosto.

[capitan_crasy]

Aggiornamento sulle slide di Llano!

[astroimager]

Direi che sono molto fiduciosi sull'appetibilità di Llano rispetto alla concorrenza.

Peccato veramente per il ritardo, se i primi portatili fossero usciti in Q1 - considerando il problema ai chipset SB - avrebbero fatto furore!

[astroimager]

Slide della nuova roadmap mobile?



Non sembra previsto nulla sotto i 35W, per subnote di un certo livello insomma... settore che così sarà monopolizzato dagli SB da 17W...

Fonte:
http://translate.google.it/translate...n&hl=&ie=UTF-8