View Full Version : [Thread Ufficiale] Aspettando Bulldozer *leggere prima pagina con attenzione*
paolo.oliva2
02-10-2010, 22:21
Questa riflessione in effetti mi fa vedere la cosa in maniera molto più positiva:
Facendo lavorare fino a metà dei core (uno per modulo) BD non sarebbe penalizzato dagli elementi condivisi (anzi, elementi come la L2 di grandi dimensioni potrebbe avvantaggiarlo), e in caso servano più core, il maggior numero di questi dovuto all'architettura condivisa supplirà adeguatamente al calo.
Infatti credo che anche io facevo lo stesso sbaglio.
Ho letto più volte attentamente quello che postava Bjt2, ma non riuscivo ad assimilarlo perché rimanevo ancorato al discorso di condivisione di parti del modulo...
La riflessione di Ares17 invece mi ha fatto capire di colpo quello che intendeva Bjt2, ed a tutti gli effetti il modulo BD, se fatto lavorare con solo 1 core sotto carico, si ritroverebbe, rispetto al core Phenom II:
+ 1 INT
+ raddoppio FP
+ 1,5MB di cache L2 (2MB totali)
+ 2MB di L3 (8MB totali).
Ora mi torna tutto il po' po' di roba scritto da Bjt2... :sofico: .
paolo.oliva2
02-10-2010, 22:26
Questa cosa mi balena dalla mente da un bel po.
Quando qualcuno all'interno di AMD dichiarò che mai ci sarebbe stato un SMT logico-virtuale, ma che anzi ci sarebbe stato un smt fisico (dove intel proporra 8 core logici noi ne proporremi 8 fisici) indicava la capacità di bd nel ripartire i th nei singoli moduli, e solo all'esaurimento di questi si sarebbe passato ad assegnare i th ai rimanti core.
Sono sicuro anche che utilizzando un test come il superpi si avrà un'evidente differenza di risultato quando si passa da un numero di istanze pari ai moduli ad una pari al numero dei core.
Verosimilmente credo che bd abbia le carte in regola per sbaragliare sb nel rapporto costo produzione-prestazioni
Però ora tu mi apri una finestra... grande come un'autostrada a 5 corsie per ogni senso di marcia :)
Supponiamo che un programma preveda al max 4 TH e che BD (X8) abbia la "logica" di far funzionare 1 core (o TH) a modulo... a quel punto l'IPC svetterebbe, perché avremmo la logica di 2 core dedicata solo ad 1 core...
Perché la frase di AMD, quella che noi daremo 2 TH fisici al posto di 2 logici, non avrebbe senso con 2 TH nello stesso modulo, ma avrebbe molto senso in caso di 2TH su 2 moduli.
Però... non ci sono BD X12... peccato :)
Sarebbe possibile?
paolo.oliva2
02-10-2010, 22:32
Faccio l'avvocato del diavolo :), non voglio stare li a difendere Paolo perchè è ingrado di difendersi da solo, però mi sembra che si stia giocando a smontare ogni cosa che dica, è da c.a. un paio di anni che lo seguo e devo dire che in mezzo a tante cose buttate li a naso ci sia sempre arrivato con piccolissimi margini di errore è vero non parla con dati alla mano ma dobbiamo dare atto che le sue sensazioni non sono poi così campate in aria, le sue sensazioni derivano da un'uso fatto di piccole e grandi esperienze sul campo, sono daccordo che sia a volte un pò troppo ottimista ma chi non lo è in questo thread e spera in una rivincità, se lo seguiamo leggendo pagina per pagina in fin dei conti un pò di parte lo siamo, forse perchè ci piace stare dalla parte dei più deboli e anche meno prepotenti?
Volevo poi aggiungere una cosa, ma chi se ne frega se in mono core la controparte va di più, visto che oramai i software nuovi saranno sempre più rivolti verso il multi thread e per quelli vecchi c'è ne in abbondanza di potenza, io vi dico che sono contento che AMD guarda avanti se no a quest'ora altro che proci con la potenza di adesso!!! In fin dei conti bisogna prendere atto che AMD nel "suo piccolo" dà filo da torcere ad'un colosso e meno male che lo fà.
Fare paragoni adesso con due architetture completamente diverse di cui una è una vera e propria novità lo trovo ASSURDO, senza dati alla mano alla fine ci rimangono le sensazioni di PAOLO, e meno male che c'è lui se no di cosa si discuteva? :D
Edit: chiedo scusa per lo sfogo ma è da un paio di pagine che leggo solo pessimismo contro tutto quello che dice Paolo, un pessimismo avvolte anche cercato nonostante si discuta di un'architettura che alla fine si sa ben poco... in poche parole, se Paolo non può essere Ottimista, non vedo perchè altri possono essere pessimisti!!!
Troppo buono.
Da parte mia c'è anche troppa impulsività... e questo genera anche antipatia.
Ma io non lo faccio per dire "io ho sempre ragione", ma perché sono della bilancia e quando faccio un ragionamento di cui ne sono convinto, mi infervorisco perché sento come se fosse attaccata la verità...
Comunque scrivo ciò che penso, se non fossi convinto di BD, non lo scriverei per difendere AMD.
Però ora tu mi apri una finestra... grande come un'autostrada a 5 corsie per ogni senso di marcia :)
Supponiamo che un programma preveda al max 4 TH e che BD (X8) abbia la "logica" di far funzionare 1 core (o TH) a modulo... a quel punto l'IPC svetterebbe, perché avremmo la logica di 2 core dedicata solo ad 1 core...
Perché la frase di AMD, quella che noi daremo 2 TH fisici al posto di 2 logici, non avrebbe senso con 2 TH nello stesso modulo, ma avrebbe molto senso in caso di 2TH su 2 moduli.
Però... non ci sono BD X12... peccato :)
Sarebbe possibile?
un modulo e da vedere come un super core con 1 Th
e 2 th li AMD non si smentisce mette 2 core reali visto che il core viene inteso L'Int. "e vero che magari hanno meno prestazioni di due core completi ma è stato creato per contrastare un SMT che funziona in modo virtuale quindi dovrebbe bastare a contrastarlo "intel sfrutta la Logica, AMD usa la Forza bruta, da li il nome Buldozer, Mentre Intel punta su come sfruttare al meglio un core, direi che sarebbe il max unire le due filosofie"
adesso l'utente che nelle precedenti pagine pensava di essere truffato con la storia dei numeri di core e perchè come me, presumo, piaccia Pensare un Modulo=a 1 super Core, ora se amd ha detto che affronterà SMT con pari core reali, hai dodici thread Intel la risposta di AMD dovrebbe essere un 6 Moduli!!! Nel mio Ottimismo piace pensare che sarà dove AMD ci sorprenderà, quello che veramente tengono più di tutto a nascondere, non a breve ma neanche molto distante.
un modulo e da vedere come un super core con 1 Th
e 2 th li AMD non si smentisce mette 2 core reali visto che il core viene inteso L'Int. "e vero che magari hanno meno prestazioni di due core completi ma è stato creato per contrastare un SMT che funziona in modo virtuale quindi dovrebbe bastare a contrastarlo "intel sfrutta la Logica, AMD usa la Forza bruta, da li il nome Buldozer, Mentre Intel punta su come sfruttare al meglio un core, direi che sarebbe il max unire le due filosofie"
adesso l'utente che nelle precedenti pagine pensava di essere truffato con la storia dei numeri di core e perchè come me, presumo, piaccia Pensare un Modulo=a 1 super Core, ora se amd ha detto che affronterà SMT con pari core reali, hai dodici thread Intel la risposta di AMD dovrebbe essere un 6 Moduli!!! Nel mio Ottimismo piace pensare che sarà dove AMD ci sorprenderà, quello che veramente tengono più di tutto a nascondere, non a breve ma neanche molto distante.
ma infatti: anche io ho sempre pensato questo fin dall'inizio!
AMD disse che contrasteranno i core logici con quelli fisici. Per dare veridicità a questa affermazione dovremmo ragionare a moduli, e non a cores!!!
Io non solo spero, ma mi aspetto proprio un BD ad 8 moduli per contrastare SB x8 con SMT, altrimenti cio' che e' stato detto piu' volte in maniera ufficiale non avrebbe alcun senso. Se cosi' fosse veramente penso che AMD avrebbe indubbiamente lo scettro prestazionale nel multicore, distanziando (e di molto) la scorretta rivale Intel.
Si, anche io sono molto ottimista, e spero sicneramente che una volta tanto (e dopo tanto tempo) la "piccola" AMD dopo le odiose ingiustizie subite, possa davvero superare il colosso Intel. Vedremo chi avra' ragione! :rolleyes:
paolo.oliva2
03-10-2010, 00:35
un modulo e da vedere come un super core con 1 Th
e 2 th li AMD non si smentisce mette 2 core reali visto che il core viene inteso L'Int. "e vero che magari hanno meno prestazioni di due core completi ma è stato creato per contrastare un SMT che funziona in modo virtuale quindi dovrebbe bastare a contrastarlo "intel sfrutta la Logica, AMD usa la Forza bruta, da li il nome Buldozer, Mentre Intel punta su come sfruttare al meglio un core, direi che sarebbe il max unire le due filosofie"
adesso l'utente che nelle precedenti pagine pensava di essere truffato con la storia dei numeri di core e perchè come me, presumo, piaccia Pensare un Modulo=a 1 super Core, ora se amd ha detto che affronterà SMT con pari core reali, hai dodici thread Intel la risposta di AMD dovrebbe essere un 6 Moduli!!! Nel mio Ottimismo piace pensare che sarà dove AMD ci sorprenderà, quello che veramente tengono più di tutto a nascondere, non a breve ma neanche molto distante.
Guarda...
Sappiamo che a parità di frequenza AMD ha dichiarato un 40 o 50% in meno di TDP, e fino a qui ci siamo.
Sappiamo che le frequenze sono aumentate (attorno ai 4GHz su tutti i core) e contemporaneamente è aumentato anche il numero dei core (+2).
Sappiamo inoltre che il TDP è basso, perché comunque AMD dichiara l'intenzione di non superare i 125W TDP.
In ogni caso la superficie di BD, nonostante la L3 + grande e la L2 pure, ha la L1 più piccola e condivisioni all'interno del modulo che comportano una diminuzione di superficie, forse tali, da portare il die di un BD X8 alle stesse grandezze di un die Thuban (se fosse realizzato sempre sul 45nm).
Ma BD è realizzato sul 32nm... quindi... teoricamente un X12 potrebbe ancora risultare suppergiù simile.
Cerco di inquadrare la superficie perché comunque AMD supporrei che debba guardare il lato costo produzione molto di più del lato TDP, questo perché, teorizzerei io, visto che BD ha controlli evoluti sul lato clock/Turbo/TDP, nel caso di un X12 AMD potrebbe sempre far intervenire un "limitatore" di frequenza nel caso i moduli vengano sfruttati come 2 core.
Per il momento è troppo fantascientifico come pensiero... però... far lavorare 6 moduli come X6 darebbe un incremento non indifferente nell'IPC.
Fare lavorare invece 6 moduli come X12, si avrebbe un calo di IPC, chiaramente, si dovrebbe intervenire con un calo di frequenza perché altrimenti si sforerebbe il TDP, ma con la risultante che comunque si avrebbe più potenza.
Però... la cosa non mi sembra proprio fantascientifica intesa come funzionamento logico, che poi sia un 4 moduli e non un 5 o 6, questo sarebbe da verificare... però, indubbiamente, sarebbe un salto non da poco inteso come sfruttabilità del procio, perché darebbe il max IPC in qualsiasi condizione possibile, sia con programmi monocore che con programmi che supportino 2-4-8 TH. Come logica, sarebbe un procio da desktop IDEALE.
paolo.oliva2
03-10-2010, 00:43
ma infatti: anche io ho sempre pensato questo fin dall'inizio!
AMD disse che contrasteranno i core logici con quelli fisici. Per dare veridicità a questa affermazione dovremmo ragionare a moduli, e non a cores!!!
Io non solo spero, ma mi aspetto proprio un BD ad 8 moduli per contrastare SB x8 con SMT, altrimenti cio' che e' stato detto piu' volte in maniera ufficiale non avrebbe alcun senso. Se cosi' fosse veramente penso che AMD avrebbe indubbiamente lo scettro prestazionale nel multicore, distanziando (e di molto) la scorretta rivale Intel.
Si, anche io sono molto ottimista, e spero sicneramente che una volta tanto (e dopo tanto tempo) la "piccola" AMD dopo le odiose ingiustizie subite, possa davvero superare il colosso Intel. Vedremo chi avra' ragione! :rolleyes:
Se AMD ha tolto dal cilindro il jolly, come fece a sua volta con il K8, ed il silicio dasse una mano per il TDP/numero dei core (meglio moduli :)), sarebbe un'architettura in grado di stare sul mercato TRANQUILLAMENTE sino all'arrivo di Fusion2... e... sarebbe contrastabile, a questo punto, da Intel, solamente da un'architettura completamente nuova (SB non farebbe nulla) o da un silicio che permetta frequenze e numero di core almeno vicino ad AMD (probabilmente non basterebbe il 22nm). Significherebbe uno stallo per Intel di almeno 2 anni... tra rimboccarsi le maniche per il 16nm e per una nuova architettura.
Però ora tu mi apri una finestra... grande come un'autostrada a 5 corsie per ogni senso di marcia :)
Supponiamo che un programma preveda al max 4 TH e che BD (X8) abbia la "logica" di far funzionare 1 core (o TH) a modulo... a quel punto l'IPC svetterebbe, perché avremmo la logica di 2 core dedicata solo ad 1 core...
Perché la frase di AMD, quella che noi daremo 2 TH fisici al posto di 2 logici, non avrebbe senso con 2 TH nello stesso modulo, ma avrebbe molto senso in caso di 2TH su 2 moduli.
Però... non ci sono BD X12... peccato :)
Sarebbe possibile?
per sfruttare appieno bd credo che bisogna usare win7 o linux, sia xp che (credo) vista non hanno la capacità di assegnare un th ad un core fisico (il modulo amd) distinguendolo da quello logico (smt di intel e 2 core del modulo di bd).
Con i molti ed i voltaggi indipendenti per modulo di bd credo che le frequenze saranno belle alte anche nel caso di th superiori al numero di core.
Possiamo avere per esempio due moduli che lavorano a 4,5 ghz (un solo core attivo) ed altri due che lavorano a 3 ghz (4 th poco esigenti) mantenendo al contempo basso il tpd.
ma per fare cio credo che il codice del programma debba essere ottimizzato per bd altrimenti ci possiamo ritrovare con un modulo a clock def con due th attivi ed altri 3 moduli con un solo th attivo e clock più basso (nel caso di th più parchi di gigaflop).
quindi possiamo ritrovarci con programmi multi th che mostrano capacità di calcolo diversi a secondo dell'assegnazione di th
carlottoIIx6
03-10-2010, 01:20
ma infatti: anche io ho sempre pensato questo fin dall'inizio!
AMD disse che contrasteranno i core logici con quelli fisici. Per dare veridicità a questa affermazione dovremmo ragionare a moduli, e non a cores!!!
Io non solo spero, ma mi aspetto proprio un BD ad 8 moduli per contrastare SB x8 con SMT, altrimenti cio' che e' stato detto piu' volte in maniera ufficiale non avrebbe alcun senso. Se cosi' fosse veramente penso che AMD avrebbe indubbiamente lo scettro prestazionale nel multicore, distanziando (e di molto) la scorretta rivale Intel.
Si, anche io sono molto ottimista, e spero sicneramente che una volta tanto (e dopo tanto tempo) la "piccola" AMD dopo le odiose ingiustizie subite, possa davvero superare il colosso Intel. Vedremo chi avra' ragione! :rolleyes:
c'è un problema non da poco
un 8 moduli amd andrà molto più veloce di un x8 classico intel con 16 thrend
se costassero uguali, intel andrebbe in fallimento
Se AMD ha tolto dal cilindro il jolly, come fece a sua volta con il K8, ed il silicio dasse una mano per il TDP/numero dei core (meglio moduli :)), sarebbe un'architettura in grado di stare sul mercato TRANQUILLAMENTE sino all'arrivo di Fusion2... e... sarebbe contrastabile, a questo punto, da Intel, solamente da un'architettura completamente nuova (SB non farebbe nulla) o da un silicio che permetta frequenze e numero di core almeno vicino ad AMD (probabilmente non basterebbe il 22nm). Significherebbe uno stallo per Intel di almeno 2 anni... tra rimboccarsi le maniche per il 16nm e per una nuova architettura.
Non credo che Sb possa essere di molto inferiore a BD.
Piuttosto credo che avremo scenari di volta in volta favorevoli adesso ad un architettura adesso ad un'altra.
Credo anche che Bd 2 moduli abbia poca capacità di competere con Sb 4 core smt off in muli th, invece lo vedo sopra in single th.
Invece un 2/4 intel sb avrà da competere con Llano (bd 2 moduli completamente fuori portata)
c'è un problema non da poco
un 8 moduli amd andrà molto più veloce di un x8 classico intel con 16 thrend
se costassero uguali, intel andrebbe in fallimento
Ma difatti bd è destinato a primeggiare sui server, vero cavallo di battaglia di amd dai primi opteron e quello è un mercato che anche a vendere a basso costo non credo che si possa andare in perdita (ma nemmeno in pareggio).
c'è un problema non da poco
un 8 moduli amd andrà molto più veloce di un x8 classico intel con 16 thrend
se costassero uguali, intel andrebbe in fallimento
ti sbagli: molta pubblicità, "qualche accordo" con i partners, una ritoccata ai compilatori.. e passa la paura! XD
A parte gli scherzi: io fin dall'inizio sostengo l'idea che i moduli AMD vadano intesi un pò come dei cores "tradizionali" con pero' una sorta di smt "fisico". D'altra parte la stessa AMD ha dichiarato cose di questo tipo, mica io! XD
Tutto combacerebbe infatti con le affermazioni fatte, ed una prima possibilità di riscontro la avremmo a partire dalla tipologia di architettura, particolarmente integrata nei moduli, caratterizzata da molte risorse condivise. La possibilità proposta da JDM70 è a mio parere da prendere in seria considerazione: se si avesse un singolo Thread si potrebbero usare tutte le risorse per un solo core INT; quando si eseguono programmi pesantemente multitasking il processore potrebbe entrare in modalità "SMT FISICO", in modo da gestire il doppio dei threads con conseguente consistente guadagno prestazionale.
La effettiva realizzabilità di queste mie personali ipotesi alla fine dipendera' completamente dalla bontà del silicio di GF, ma se fate 2 calcoli in termini di superficie occupata e pensando che ci sara' un nuovo processo produttivo.. beh, vi renderete conto che le possibilità di una mossa (per nulla sorprendente, a dire la verità) in questo senso da parte di AMD ci potrebbe stare tutta.. :)
Magari un 8 Moduli-16Thread sarebbe per ora troppo.. ma un 6 moduli 12 thread (in ambito desktop) ci sta eccome, cosi' come invece per ambito server potrebbe starci il 6+6moduli, al pari di come fatto finora.
Io ci spero davvero, ma come gia' detto sono piuttosto fiducioso ;)
paolo.oliva2
03-10-2010, 05:13
ti sbagli: molta pubblicità, "qualche accordo" con i partners, una ritoccata ai compilatori.. e passa la paura! XD
A parte gli scherzi: io fin dall'inizio sostengo l'idea che i moduli AMD vadano intesi un pò come dei cores "tradizionali" con pero' una sorta di smt "fisico". D'altra parte la stessa AMD ha dichiarato cose di questo tipo, mica io! XD
Tutto combacerebbe infatti con le affermazioni fatte, ed una prima possibilità di riscontro la avremmo a partire dalla tipologia di architettura, particolarmente integrata nei moduli, caratterizzata da molte risorse condivise. La possibilità proposta da JDM70 è a mio parere da prendere in seria considerazione: se si avesse un singolo Thread si potrebbero usare tutte le risorse per un solo core INT; quando si eseguono programmi pesantemente multitasking il processore potrebbe entrare in modalità "SMT FISICO", in modo da gestire il doppio dei threads con conseguente consistente guadagno prestazionale.
La effettiva realizzabilità di queste mie personali ipotesi alla fine dipendera' completamente dalla bontà del silicio di GF, ma se fate 2 calcoli in termini di superficie occupata e pensando che ci sara' un nuovo processo produttivo.. beh, vi renderete conto che le possibilità di una mossa (per nulla sorprendente, a dire la verità) in questo senso da parte di AMD ci potrebbe stare tutta.. :)
Magari un 8 Moduli-16Thread sarebbe per ora troppo.. ma un 6 moduli 12 thread (in ambito desktop) ci sta eccome, cosi' come invece per ambito server potrebbe starci il 6+6moduli, al pari di come fatto finora.
Io ci spero davvero, ma come gia' detto sono piuttosto fiducioso ;)
Comunque, se vi ricordate, non dovrebbe uscire windows 8 nel 2011?
Secondo me non esisterebbe un problema di TDP vero e proprio... e quindi sarebbe fattibile.
In pratica, spegnendo i moduli non attivi, un BD X8 o X16 non cambia di una virgola nella frequenza di 1 core attivo o 2... Nel caso di utilizzo di tutti i core, si può sempre applicare una frequenza idonea al TDP, abbassandola all'occorrenza.
Il problema di gestire più core non implicherebbe di per sé un aumento di L3. Che 8 core vadano a 5GHz o 16 core a 2,5GHz di per sé non cambierebbe nulla sulla banda dati.
Tra l'altro, se vogliamo puntualizzare, AMD passa dalle DDR3 1333 alle DDR3 1850 e la seconda release del Vcore RAM, 1,4V. Già questo innalzerebbe del 50% la banda. Ma le ultime voci non davano anche un potenziamento ulteriore dell'MC? Non sentite puzza di bruciato? Perché tutto questo potenziamento se già per un X8 basterebbe unicamente il supporto a DDR3 più veloce? Ma se i core aumentano.... :)
Il problema, che vedrei, è nella dimensione del die e relativo costo produzione e vendita.
Ma questo in un certo senso combacerebbe con il fatto di rendere BD il più piccolo possibile... più è piccolo, più moduli in teoria si potrebbero aggiungere contenendo la grandezza del die.
Il nesso sarebbe che se le dimensioni di un BD X12 o X16 fossero vicine a quelle del Thuban, tra processo forse più costoso e innalzamento di die fallati, un prezzo comunque doppio (ma anche triplo) rispetto al Thuban sarebbe proponibile.
Secondo me... all'uscita ci sarà comunque solo BD X8, perché comunque basterebbe a contrastare tranquillamente un SB X4 e i990 X6.
Visto che gli SB X6 e X8 li vedremo a fine 2011, la catena BD sarebbe già in funzione da 6 mesi, con tutti i vantaggi del caso, in primis, massima resa e implementazione low-k se non già disponibile all'uscita.
In fin dei conti, Intel a che prezzo commercializzerà gli SB X8? Con un X6 odierno quasi a 1000€, già sarebbe un miracolo vedere un SB X8 a 800€. Se BD X8 potrebbe avere un prezzo onesto sui 400€, un BD X16 potrebbe costare in linea a SB X8... ma comunque risultare NETTAMENTE più veloce, sia in monocore ed ancor più in multicore... praticamente quasi doppiandolo.
bicchiere
03-10-2010, 07:44
Comunque, se vi ricordate, non dovrebbe uscire windows 8 nel 2011?
Direi di no.
Ciclo di sviluppo di tre anni.
Seven è uscito a ottobre 2009,
Windows 8 uscità attorno a ottobre 2012.
<<hacker>>
03-10-2010, 09:39
qualcuno mi sa dare un link oppure info per il nuovo x6 a 3.3 ghz?
:help:
dark.halo
03-10-2010, 10:31
Io invece spero in qualche iniziativa dei produttori di mobo, di far uscire anche per il mercato desktop un dual socket su piattaforma g34.
immaginatevi adesso se un bd x12 3ghz costasse 600€, mettetene 2 dentro e sono 1200€,facciamo 400€ per la mobo,più 160€ x2 4 moduli di ram 1866 per socket.
insomma si andrebbe a spendere 200/300€ euro in più di una piattaforma intel extreme,ma con il doppio delle prestazioni,ne venderebbero a bizzeffe.:D
paolo.oliva2
03-10-2010, 13:24
Io invece spero in qualche iniziativa dei produttori di mobo, di far uscire anche per il mercato desktop un dual socket su piattaforma g34.
immaginatevi adesso se un bd x12 3ghz costasse 600€, mettetene 2 dentro e sono 1200€,facciamo 400€ per la mobo,più 160€ x2 4 moduli di ram 1866 per socket.
insomma si andrebbe a spendere 200/300€ euro in più di una piattaforma intel extreme,ma con il doppio delle prestazioni,ne venderebbero a bizzeffe.:D
Allucinante...
Prevederei portaceneri stracolmi, notti insonni e internet sovraccarica a postare i bench :doh: ... ma sai che libidine... :sofico:
greeneye
03-10-2010, 14:17
Io invece spero in qualche iniziativa dei produttori di mobo, di far uscire anche per il mercato desktop un dual socket su piattaforma g34.
immaginatevi adesso se un bd x12 3ghz costasse 600€, mettetene 2 dentro e sono 1200€,facciamo 400€ per la mobo,più 160€ x2 4 moduli di ram 1866 per socket.
insomma si andrebbe a spendere 200/300€ euro in più di una piattaforma intel extreme,ma con il doppio delle prestazioni,ne venderebbero a bizzeffe.:D
Per le dual socket c'e' il C32.
dark.halo
03-10-2010, 14:29
Allucinante...
Prevederei portaceneri stracolmi, notti insonni e internet sovraccarica a postare i bench :doh: ... ma sai che libidine... :sofico:
:sofico: :sofico: :sofico:
questo video mostra Zacate alle prese con una demo in directcompute del motore fisico Bullet Physics.
http://www.youtube.com/watch?v=SnEERBcTqok
Secondo me in futuro,le apu in presenza di una vga discreta accelereranno la fisica nei giochi che adotteranno il motore fisico AMD.
EDIT:
@greeneye
io mi riferivo proprio all'adozione del socket g32 con chipset desktop (ovviamente con le modifiche del caso al bus hypertransport per supportare il dual cpu).
più o meno come ha fatto intel con la piattaforma skulltraill
Comunque, se vi ricordate, non dovrebbe uscire windows 8 nel 2011?
Secondo me non esisterebbe un problema di TDP vero e proprio... e quindi sarebbe fattibile.
In pratica, spegnendo i moduli non attivi, un BD X8 o X16 non cambia di una virgola nella frequenza di 1 core attivo o 2... Nel caso di utilizzo di tutti i core, si può sempre applicare una frequenza idonea al TDP, abbassandola all'occorrenza.
Il problema di gestire più core non implicherebbe di per sé un aumento di L3. Che 8 core vadano a 5GHz o 16 core a 2,5GHz di per sé non cambierebbe nulla sulla banda dati.
Tra l'altro, se vogliamo puntualizzare, AMD passa dalle DDR3 1333 alle DDR3 1850 e la seconda release del Vcore RAM, 1,4V. Già questo innalzerebbe del 50% la banda. Ma le ultime voci non davano anche un potenziamento ulteriore dell'MC? Non sentite puzza di bruciato? Perché tutto questo potenziamento se già per un X8 basterebbe unicamente il supporto a DDR3 più veloce? Ma se i core aumentano.... :)
Il problema, che vedrei, è nella dimensione del die e relativo costo produzione e vendita.
Ma questo in un certo senso combacerebbe con il fatto di rendere BD il più piccolo possibile... più è piccolo, più moduli in teoria si potrebbero aggiungere contenendo la grandezza del die.
Il nesso sarebbe che se le dimensioni di un BD X12 o X16 fossero vicine a quelle del Thuban, tra processo forse più costoso e innalzamento di die fallati, un prezzo comunque doppio (ma anche triplo) rispetto al Thuban sarebbe proponibile.
Secondo me... all'uscita ci sarà comunque solo BD X8, perché comunque basterebbe a contrastare tranquillamente un SB X4 e i990 X6.
Visto che gli SB X6 e X8 li vedremo a fine 2011, la catena BD sarebbe già in funzione da 6 mesi, con tutti i vantaggi del caso, in primis, massima resa e implementazione low-k se non già disponibile all'uscita.
In fin dei conti, Intel a che prezzo commercializzerà gli SB X8? Con un X6 odierno quasi a 1000€, già sarebbe un miracolo vedere un SB X8 a 800€. Se BD X8 potrebbe avere un prezzo onesto sui 400€, un BD X16 potrebbe costare in linea a SB X8... ma comunque risultare NETTAMENTE più veloce, sia in monocore ed ancor più in multicore... praticamente quasi doppiandolo.
Mi stavo rileggendo la spiegazione da me fatta a Carlotto riguardante l'architettura di BD descritta in un ottimo articolo da lui segnalato.
http://www.hwupgrade.it/forum/showpost.php?p=33085038&postcount=3254
Mi azzardero' a dirti di piu': la storia annunciata anni fa da AMD riguardante la teoria del "Reverse Hyper-threading" e di cui ora si sono perse le voci e le speranze potrebbe essere a mio parere il possibile vero segreto relativo a questi misteriosi "moduli".
So che farò un discorso piuttosto ipotetico, ma d'altra parte questo e' il thread apposito, no? :D
Per chi non lo sapesse il reverse Hyper-threading molto in breve è tecnologia (per ora esistente solo su carta) atta a eseguire un programma tipicamente "mono-thread" su piu' cores del processore.
Ipotesi: in ottica "modulo" sarebbe possibile eseguire un programma monothread, smistando i calcoli su due unità INT in maniera parallela? Se cosi' fosse sarebbe DAVVERO un SMT FISICO, e non semplicemente due cores con unità in condivisione, non credete?
Ovviamente per poter fare questo servirebbero degli algoritmi di decode e branch prediction davvero sofisticati, ma se guardate l'architettura di BD nel dettaglio (anche solo rileggendo il link della spiegazione riguardante l'articolo sopra descritto), vedrete che qualcosa di strano effettivamente c'e':
1)l'unità di fetch e' UNA SOLA per modulo. Una cosa davvero strana se si ragionasse in termini di cores indipendenti e quindi operanti in maniera "classica": perche' "raccogliere le informazioni" da elaborare per un solo Thread, quando si hanno a disposizione 2 moduli INT?
2)Se c'e' una cosa che AMD sta nascondendo piu' di tutte e' tutto quello che riguarda gli algoritmi di Branch Prediction. Perche'? Potrebbe essere che ragionino in un'ottica di smistamento delle elaborazioni su 2 cores int? Sappiamo solo per ora che il BTB e' grosso LA META' dell'attuale k10. Possibile che BD sia in grado di prevedere meta' dei salti? ..oppure semplicemente e' in grado di "elaborarli" piu' velocemente (al doppio della velocita', avendo appunto il doppio dei cores INT per modulo)?
3)Di questo non sono sicuro, ma nel k10 le unita' di decode da quello che ho letto sono "esclusive", ovvero possono decodificare solamente una alla volta, e non simultaneamente. In ogni modulo BD abbiamo 4 unità di decode (da quanto ho capito) indipendenti, ed in grado di codificare simultaneamente. Possibile che tutta questa potenza di decode sia solo fine a se' stessa, avendo oltretutto per ogni unità INT meno risorse di memoria rispetto a quelle che aveva l'architettura k10 per ogni unita' INT? ..anche qui c'e' qualcosa che non torna, a mio parere.
L'unica cosa che in tutto questo ragionamento non quadra riguarda la "retire unit". Abbiamo visto dagli schemi che abbiamo una retire per ogni core INT. Se ragionassero in un'ottica di SMT Hardware suppongo l'unita' di retire debba essere unica per modulo, e non per core! Vedremo, perche' a mio parere negli schemi che abbiamo visto fin'ora c'e' qualcosa che non quadra..
Insomma: il mio sospetto e' che ci sia la possibilità di vedere davvero qualcosa che qui nessuno si sta nemmeno immaginando. Attenzione, non voglio dire che SICURAMENTE sara' cosi', ma il fatto di non ammettere questa possibilità, arrivati a questo punto, vedendo certe "stranezze" architetturali, ricordando cio' che AMD disse ufficialmente piu' e piu' volte riguardo al suo SMT hardware, ricordando cio' che disse riguardo sl confronto "cores fisici / cores logici", facendo dei semplici calcoli relativi alla superficie di silicio occupata dai moduli (nascosta anch'essa da AMD), osservando la tipologia di risorse condivise nel modulo dai cores INT e, perchè no, ricordando le vecchie dicerie su un "reverse Hyperthreading".. sarebbe quantomeno limitante.
Se davvero cosi' fosse ecco spiegato il vero motivo dei moduli: Creare degli algoritmi di reverse Hyperthreading relativi a TUTTI i cores sarebbe dispendiosissimo, infatti non si potrebbero riutilizzare i proci con moduli fallati, ed ogni tipologia di processore andrebbe riprogrammata in base al numero dei cores. Con i moduli diventa tutto piu' semplice e si abbattono i costi, pur avendo teoricamente meno prestazione assoluta nell'ambito del singolo thread.
Sono ipotesi fantasiose, me ne rendo conto.. ma detto cio', che ne pensate? :sofico:
paolo.oliva2
03-10-2010, 15:56
Mi stavo rileggendo la spiegazione da me fatta a Carlotto riguardante l'architettura di BD descritta in un ottimo articolo da lui segnalato.
http://www.hwupgrade.it/forum/showpost.php?p=33085038&postcount=3254
Mi azzardero' a dirti di piu': la storia annunciata anni fa da AMD riguardante la teoria del "Reverse Hyper-threading" e di cui ora si sono perse le voci e le speranze potrebbe essere a mio parere il possibile vero segreto relativo a questi misteriosi "moduli".
So che farò un discorso piuttosto ipotetico, ma d'altra parte questo e' il thread apposito, no? :D
Per chi non lo sapesse il reverse Hyper-threading molto in breve è tecnologia (per ora esistente solo su carta) atta a eseguire un programma tipicamente "mono-thread" su piu' cores del processore.
Ipotesi: in ottica "modulo" sarebbe possibile eseguire un programma monothread, smistando i calcoli su due unità INT in maniera parallela? Se cosi' fosse sarebbe DAVVERO un SMT FISICO, e non semplicemente due cores con unità in condivisione, non credete?
Ovviamente per poter fare questo servirebbero degli algoritmi di decode e branch prediction davvero sofisticati, ma se guardate l'architettura di BD nel dettaglio (anche solo rileggendo il link della spiegazione riguardante l'articolo sopra descritto), vedrete che qualcosa di strano effettivamente c'e':
1)l'unità di fetch e' UNA SOLA per modulo. Una cosa davvero strana se si ragionasse in termini di cores indipendenti e quindi operanti in maniera "classica": perche' "raccogliere le informazioni" da elaborare per un solo Thread, quando si hanno a disposizione 2 moduli INT?
2)Se c'e' una cosa che AMD sta nascondendo piu' di tutte e' tutto quello che riguarda gli algoritmi di Branch Prediction. Perche'? Potrebbe essere che ragionino in un'ottica di smistamento delle elaborazioni su 2 cores int? Sappiamo solo per ora che il BTB e' grosso LA META' dell'attuale k10. Possibile che BD sia in grado di prevedere meta' dei salti? ..oppure semplicemente e' in grado di "elaborarli" piu' velocemente (al doppio della velocita', avendo appunto il doppio dei cores INT per modulo)?
3)Di questo non sono sicuro, ma nel k10 le unita' di decode da quello che ho letto sono "esclusive", ovvero possono decodificare solamente una alla volta, e non simultaneamente. In ogni modulo BD abbiamo 4 unità di decode (da quanto ho capito) indipendenti, ed in grado di codificare simultaneamente. Possibile che tutta questa potenza di decode sia solo fine a se' stessa, avendo oltretutto per ogni unità INT meno risorse di memoria rispetto a quelle che aveva l'architettura k10 per ogni unita' INT? ..anche qui c'e' qualcosa che non torna, a mio parere.
L'unica cosa che in tutto questo ragionamento non quadra riguarda la "retire unit". Abbiamo visto dagli schemi che abbiamo una retire per ogni core INT. Se ragionassero in un'ottica di SMT Hardware suppongo l'unita' di retire debba essere unica per modulo, e non per core! Vedremo, perche' a mio parere negli schemi che abbiamo visto fin'ora c'e' qualcosa che non quadra..
Insomma: il mio sospetto e' che ci sia la possibilità di vedere davvero qualcosa che qui nessuno si sta nemmeno immaginando. Attenzione, non voglio dire che SICURAMENTE sara' cosi', ma il fatto di non ammettere questa possibilità, arrivati a questo punto, vedendo certe "stranezze" architetturali, ricordando cio' che AMD disse ufficialmente piu' e piu' volte riguardo al suo SMT hardware, ricordando cio' che disse riguardo sl confronto "cores fisici / cores logici", facendo dei semplici calcoli relativi alla superficie di silicio occupata dai moduli (nascosta anch'essa da AMD), osservando la tipologia di risorse condivise nel modulo dai cores INT e, perchè no, ricordando le vecchie dicerie su un "reverse Hyperthreading".. sarebbe quantomeno limitante.
Se davvero cosi' fosse ecco spiegato il vero motivo dei moduli: Creare degli algoritmi di reverse Hyperthreading relativi a TUTTI i cores sarebbe dispendiosissimo, infatti non si potrebbero riutilizzare i proci con moduli fallati, ed ogni tipologia di processore andrebbe riprogrammata in base al numero dei cores. Con i moduli diventa tutto piu' semplice e si abbattono i costi, pur avendo teoricamente meno prestazione assoluta nell'ambito del singolo thread.
Sono ipotesi fantasiose, me ne rendo conto.. ma detto cio', che ne pensate? :sofico:
Secondo me AMD si sta muovendo in quella direzione che tu hai descritto, che poi, se vogliamo, sarebbe né più né meno obbligato, visto che comunque Fusion2 dovrebbe essere con delle differenze, certamente, ma nella logica simile.
Per il discorso fantasia... beh, è impossibile non mettercela con l'NDA. Ma non dobbiamo confondere la fantasia con la fantascienza, che è tutta un'altra cosa. La fantasia è riuscire a riunire tutte le piccole informazioni e trovare una correlazione, per poi avanzare delle ipotesi.
Non dobbiamo dimenticare, poi, che il post ad esempio di quel manager software, che attribuisce a BD praticamente potenze simili a SB. Guardate che è sottile... a quei livelli, affermazioni simili mettono in gioco la reputazione della persona, oltre poi che il comportamento è più "politico", nel senso che si maschera un pochino la propria idea con la prerogativa di non calpestare i piedi a nessuno. Poi le affermazioni AMD, le contro-informazioni Intel, contratti importanti con aziende produttrici di hardware, possono essere possibili unicamente nel caso che la sostanza ci sia, eccome.
Pensare ad un BD come a Thuban con 2 core in più e clock più alti, non può ASSOLUTAMENTE avere questo effetto.
Inoltre, AMD non ha un budget alla Intel, nel senso che, come più volte molti hanno postato, BD dovrebbe rimanere sul campo almeno 3 anni... Non può assolutamente essere un Phenom II più veloce.
Secondo me AMD si sta muovendo in quella direzione che tu hai descritto, che poi, se vogliamo, sarebbe né più né meno obbligato, visto che comunque Fusion2 dovrebbe essere con delle differenze, certamente, ma nella logica simile.
Per il discorso fantasia... beh, è impossibile non mettercela con l'NDA. Ma non dobbiamo confondere la fantasia con la fantascienza, che è tutta un'altra cosa. La fantasia è riuscire a riunire tutte le piccole informazioni e trovare una correlazione, per poi avanzare delle ipotesi.
Non dobbiamo dimenticare, poi, che il post ad esempio di quel manager software, che attribuisce a BD praticamente potenze simili a SB. Guardate che è sottile... a quei livelli, affermazioni simili mettono in gioco la reputazione della persona, oltre poi che il comportamento è più "politico", nel senso che si maschera un pochino la propria idea con la prerogativa di non calpestare i piedi a nessuno. Poi le affermazioni AMD, le contro-informazioni Intel, contratti importanti con aziende produttrici di hardware, possono essere possibili unicamente nel caso che la sostanza ci sia, eccome.
Pensare ad un BD come a Thuban con 2 core in più e clock più alti, non può ASSOLUTAMENTE avere questo effetto.
Inoltre, AMD non ha un budget alla Intel, nel senso che, come più volte molti hanno postato, BD dovrebbe rimanere sul campo almeno 3 anni... Non può assolutamente essere un Phenom II più veloce.
Sul reverse HT avrei i miei dubbi (splittare un th mono su due core mi pare molto improbabile).
L'unico uso potrebbe essere quello di fare eseguire al secondo core una diramazione meno probabile del codice rispetto a quella che viene elaborata nel primo, ed in caso di mancato Hit avere gia l'elaborazione pronta.
Ma credo che un approcio simile, anche se possibile, porta pochi benefici, anche se considerando il clock vincolato per il momento al modulo e non al singolo core in termini di tdp non dovrebbe essere troppo penalizzante, anche a fronte di un aumento dell'ipc del modulo in single th tra il 5 ed il 15%
Sarei curioso di leggere cosa ne pensa Bjt su questa mia ipotesi.
io penso una cosa ,per non essere troppo convergente(o insistente),che siamo di fronte ad una serie di novità che ,per non essere troppo fantascientifico(come dice giustamente paolo),se analizzate combaciano in alcuni punti
è chiaro che stiamo ai confini di questa ''terra promessa'',in cui prima di entrare si assiste a queste nuove architetture,ma infondo una parola li accomuna:la ''compartimentazione''
se guardiamo bene ,tanto per essere increduli,la filosofia è sempre quella.Da un lato bulldozer con il mistero modulo, dall'altro apu,e se fate caso al caso(discutibile) ,anche i chip della serie 4 rispetto alla serie 5 delle schede grafiche presentano una certa compartimentazione hardware(rv770&rv870,che ''dimostrano''che la strada sia buona)).......il tutto(anche di sola fantasia) sembra combaciare
dovranno prima o poi far intravedere cosa sarà una miscela di tutti questi ''comparti miscelati'' insieme, di natura diversa ma costruiti per essere una cosa sola
non desisto di ammettere che gia solo immaginarle gli uni accanto agli altri in maniera quasi indistinguibile questi comparti:Prrr: ,mi basta già...figuriamoci vederli in azione
ci sarà certamente ancora del tempo,ma le padelle avrebbero gli anni contati ed il loro destino neanche sarà rimpianto :eek:
Secondo me AMD si sta muovendo in quella direzione che tu hai descritto, che poi, se vogliamo, sarebbe né più né meno obbligato, visto che comunque Fusion2 dovrebbe essere con delle differenze, certamente, ma nella logica simile.
Per il discorso fantasia... beh, è impossibile non mettercela con l'NDA. Ma non dobbiamo confondere la fantasia con la fantascienza, che è tutta un'altra cosa. La fantasia è riuscire a riunire tutte le piccole informazioni e trovare una correlazione, per poi avanzare delle ipotesi.
Non dobbiamo dimenticare, poi, che il post ad esempio di quel manager software, che attribuisce a BD praticamente potenze simili a SB. Guardate che è sottile... a quei livelli, affermazioni simili mettono in gioco la reputazione della persona, oltre poi che il comportamento è più "politico", nel senso che si maschera un pochino la propria idea con la prerogativa di non calpestare i piedi a nessuno. Poi le affermazioni AMD, le contro-informazioni Intel, contratti importanti con aziende produttrici di hardware, possono essere possibili unicamente nel caso che la sostanza ci sia, eccome.
Pensare ad un BD come a Thuban con 2 core in più e clock più alti, non può ASSOLUTAMENTE avere questo effetto.
Inoltre, AMD non ha un budget alla Intel, nel senso che, come più volte molti hanno postato, BD dovrebbe rimanere sul campo almeno 3 anni... Non può assolutamente essere un Phenom II più veloce.
hehe, che vuoi farci: mi piace fantasticare! :cool:
che poi a ben pensarci questo sarebbe a mio parere l'uso piu' logico per una architettura modulare di questo tipo, anche se ovviamente sarebbe di difficilissima implementazione. Il discorso del risparmio di silicio (per produrre al max dei 4 moduli, poi) a mio parere da solo non regge e non giustifica un cambiamento cosi' radicale di architettura.
Magari Bulldozer sara' anche in questo una fase embrionale per fusion2, dove oltre alla GPU al posto della FPU ci sara' magari davvero un reverse Hyperthreading.. Basterebbe (detto cosi' sembra semplice) lavorare "a monte" per quanto riguarda gli algoritmi di smistamento delle singole istruzioni ed a valle per unificare le retire units.. (altra ipotesi!)
Non voglio fare fantascienza, comunque.. volevo solo porre dei quesiti interessanti per vedere se ci sarebbe oggettivamente spazio per ipotizzare "fantasticherie" di questo tipo, pur sapendo che oggettivamente sarebbe molto difficile vedere tutto in BD (anche se ammetto di non escludere nulla a priori).
Volevo farvi notare una cosa. Tempo fa avevo provato a ricostruire (sulla base di ipotesi fatte da un altro sito con il quale però non concordavo sulla ricostruzione finale) le unità di esecuzione del BD dall'immagine camuffata rilasciata da AMD e questo era il risultato:
http://www.mediafire.com/imgbnc.php/5b716c3626ffe4a12e8fea77842f2d5d6g.jpg
Oggi mi è venuto in mente che AMD aveva dichiarato che l'aggiunta di un core int provocava un aumento di solamente il 12% dell'area occupata dal modulo. Ebbene...ho verificato e l'area occupata da LD/ST Unit, Int Core, relativa L1 dati e Int Scheduler è esattamente il 12% del modulo :eek:
paolo.oliva2
03-10-2010, 19:49
hehe, che vuoi farci: mi piace fantasticare! :cool:
che poi a ben pensarci questo sarebbe a mio parere l'uso piu' logico per una architettura modulare di questo tipo, anche se ovviamente sarebbe di difficilissima implementazione. Il discorso del risparmio di silicio (per produrre al max dei 4 moduli, poi) a mio parere da solo non regge e non giustifica un cambiamento cosi' radicale di architettura.
Magari Bulldozer sara' anche in questo una fase embrionale per fusion2, dove oltre alla GPU al posto della FPU ci sara' magari davvero un reverse Hyperthreading.. Basterebbe (detto cosi' sembra semplice) lavorare "a monte" per quanto riguarda gli algoritmi di smistamento delle singole istruzioni ed a valle per unificare le retire units.. (altra ipotesi!)
Non voglio fare fantascienza, comunque.. volevo solo porre dei quesiti interessanti per vedere se ci sarebbe oggettivamente spazio per ipotizzare "fantasticherie" di questo tipo, pur sapendo che oggettivamente sarebbe molto difficile vedere tutto in BD (anche se ammetto di non escludere nulla a priori).
Io veramente avevo scritto che tu avevi fantasia a collegare il tutto, :D ma che assolutamente non avevi scritto fantascienza. :sofico:
paolo.oliva2
03-10-2010, 19:51
Volevo farvi notare una cosa. Tempo fa avevo provato a ricostruire (sulla base di ipotesi fatte da un altro sito con il quale però non concordavo sulla ricostruzione finale) le unità di esecuzione del BD dall'immagine camuffata rilasciata da AMD e questo era il risultato:
http://www.mediafire.com/imgbnc.php/5b716c3626ffe4a12e8fea77842f2d5d6g.jpg
Oggi mi è venuto in mente che AMD aveva dichiarato che l'aggiunta di un core int provocava un aumento di solamente il 12% dell'area occupata dal modulo. Ebbene...ho verificato e l'area occupata da LD/ST Unit, Int Core, relativa L1 dati e Int Scheduler è esattamente il 12% del modulo :eek:
Ma, alla fine... contando la diminuzione della superficie del modulo rispetto ai 2 core Phenom II classici, e valutando anche la diminuzione nel passaggio dal 45nm al 32nm... un BD X12 starebbe dentro alla superficie di un die Thuban X6? (secondo te)
Io veramente avevo scritto che tu avevi fantasia a collegare il tutto, :D ma che assolutamente non avevi scritto fantascienza. :sofico:
ops, allora scusa :eek: : avevo capito sinceramente il contrario! :mc:
Beh, allora sentiamo i piu' esperti (bjt2 in primis) cosa ne pensano di un'ipotesi del genere! :D
Sul reverse HT avrei i miei dubbi (splittare un th mono su due core mi pare molto improbabile).
L'unico uso potrebbe essere quello di fare eseguire al secondo core una diramazione meno probabile del codice rispetto a quella che viene elaborata nel primo, ed in caso di mancato Hit avere gia l'elaborazione pronta.
Ma credo che un approcio simile, anche se possibile, porta pochi benefici, anche se considerando il clock vincolato per il momento al modulo e non al singolo core in termini di tdp non dovrebbe essere troppo penalizzante, anche a fronte di un aumento dell'ipc del modulo in single th tra il 5 ed il 15%
Sarei curioso di leggere cosa ne pensa Bjt su questa mia ipotesi.
si, ma immagina ad esempio di splittare magari solo le "micro-op INT" gia' codificate dalla fase di decode (ricordo che BD avra' BEN 4 decoder).. Il Fetch e' unificato, quindi i moduli tra loro devono avere una qualche correlazione biunivoca! non sarebbe cosi' assurda come ipotesi, vista l'architettura del modulo!
esempio di flusso della esecuzione di un programma mono-thread (semplifico al max):
1)Fetch modulare (unico per i due cores int) che cerca e seleziona le informazioni da eseguire del programma mono-thread. Fino ad ora sappiamo che questa fase sara' gestita a livello di modulo e non a lv di core, quindi ci potrebbe stare.
2)Il decoder che creerà le micro-ops da eseguire sarà anch'esso condiviso dai cores INT. Per ora sappiamo che ci saranno 4 unità decoder per modulo che agiscono per entrambi i cores INT in maniera NON indipendente, quindi sarebbe possibile. La cosa si farebbe davvero delicata (a livello implementativo) per quanto riguarda il branch prediction, ma immaginiamo per un attimo un algoritmo funzionante in grado di gestire le micro-ops, i salti e tutto quanto su appunto 2 moduli di exec INT. In un caso del genere la memoria di buffer dei branch potrebbe teoricamente essere diciamo la meta' di quella del K10, in quanto si avrebbe una esecuzione parallela e potenzialmente quindi "doppia". Magari è un caso, ma fino ad ora sappiamo che questa memoria di Buffer e' esattamente grande la meta' di quella del k10.. (ho fatto delle ricerche al riguardo, ma spero di non aver detto una idiozia XD )
guardate bene questa immagine:
http://www.hardwaresecrets.com/fullimage.php?image=28025
Fino a qui tutto potrebbe essere possibile (difficoltà implementative a parte), ma l'unica cosa che davvero non quadra in tutto questo fanta-ragionamento sono quelle retire units separate, a meno che non esista una ulteriore "retire-module" (assente in quella figura) che metta insieme le operazioni ricomposte dalle 2 retire units (fantascienza? uhm.. forse si, ma chissà.. :fagiano: )
d'altra parte se davvero fossero totalmente indipendenti questi benedetti Cores INT non dovrebbero avere decoders e fetches anch'essi indipendenti?
E se fosse cosi', allora come si potrebbe mettere un'unica FPU al servizio di due moduli INT?
Insomma, non sono un vero esperto (invoco bjt2 per smentirmi o supportarmi al riguardo) ma a mio modesto parere c'e' assolutamente qualcosa che non va in quelle immagini che finora abbiamo visto. AMD sta nascondendo qualcosa, questo ormai secondo me e' sicuro. Molto difficile che sia un "reverse Hyperthreading" in "piccolo" (solo su due cores INT), ma -ripeto- secondo me le possibilità potrebbero anche esserci.
si, ma immagina ad esempio di splittare magari solo le "micro-op INT" gia' codificate dalla fase di decode (ricordo che DB avra' BEN 4 decoder).. Il Fetch e' unificato, quindi i moduli tra loro devono avere una qualche correlazione biunivoca! non sarebbe cosi' assurda come ipotesi, vista l'architettura del modulo!
esempio di flusso della esecuzione di un programma mono-thread (semplifico al max):
1)Fetch modulare (unico per i due cores int) che cerca e seleziona le informazioni da eseguire del programma mono-thread. Fino ad ora sappiamo che questa fase sara' gestita a livello di modulo e non a lv di core, quindi ci potrebbe stare.
2)Il decoder che creerà le micro-ops da eseguire sarà anch'esso condiviso dai cores INT. Per ora sappiamo che ci saranno 4 unità decoder per modulo che agiscono per entrambi i cores INT in maniera NON indipendente, quindi sarebbe possibile. La cosa si farebbe davvero delicata (a livello implementativo) per quanto riguarda il branch prediction, ma immaginiamo per un attimo un algoritmo funzionante in grado di gestire le micro-ops, i salti e tutto quanto su appunto 2 moduli di exec INT. In un caso del genere la memoria di buffer dei branch potrebbe teoricamente essere diciamo la meta' di quella del K10, in quanto si avrebbe una esecuzione parallela e potenzialmente quindi "doppia". Magari è un caso, ma fino ad ora sappiamo che questa memoria di Buffer e' esattamente grande la meta' di quella del k10.. (ho fatto delle ricerche al riguardo, ma spero di non aver detto una idiozia XD )
guardate bene questa immagine:
http://www.hardwaresecrets.com/fullimage.php?image=28025
Fino a qui tutto potrebbe essere possibile (difficoltà implementative a parte), ma l'unica cosa che davvero non quadra in tutto questo fanta-ragionamento sono quelle retire units separate, a meno che non esista una ulteriore "retire-module" (assente in quella figura) che metta insieme le operazioni ricomposte dalle 2 retire units (fantascienza? uhm.. forse si, ma chissà.. :fagiano: )
d'altra parte se davvero fossero totalmente indipendenti questi benedetti Cores INT non dovrebbero avere decoders e fetches anch'essi indipendenti?
E se fosse cosi', allora come si potrebbe mettere un'unica FPU al servizio di due moduli INT?
Insomma, non sono un vero esperto (invoco bjt2 per smentirmi o supportarmi al riguardo) ma a mio modesto parere c'e' assolutamente qualcosa che non va in quelle immagini che finora abbiamo visto. AMD sta nascondendo qualcosa, questo ormai secondo me e' sicuro. Molto difficile che sia un "reverse Hyperthreading" in "piccolo" (solo su due cores INT), ma -ripeto- secondo me le possibilità potrebbero anche esserci.
Ci ho pensato durante tutto il pomerigio:
Per aumentare l'ipc in monoth basterebbe che in caso di prediction fault invece di attendere lo svuotamento delle pipeline prima di inserire altri dati da elaborare si manda il tutto in esecuzione sull'altro core (abbassando di molto le latenze).
Questo potrebbe permettere un doppio vantaggio:
utilizzare algoritmi di prefech più spinti e al tempo stesso riddurre di molto i cicli di attesa in caso di fetch fault.
Questo porterebbe il guadagno di ipc ad una notevole impennata (tra un fetch aggressivo ed una notevole tolleranza all'errore, senza peraltro innalzare di un solo watt il tdp del singolo modulo.
Potrebbe sembrare FS, ma credo che con una struttura logica come quella imputata a Bd sia più che possibile e senza le controindicazioni dei processi multith che generalmente sono abbastanza prevedibili limitando le latenze dovute a fetch fault.
Se ho detto una cassanata scusatemi. :rolleyes:
paolo.oliva2
03-10-2010, 21:35
Facciamo un attimo di riflessione:
Comunque, non c'è correlazione tra la frase di AMD "proporremo TH fisici a TH logici" in un procio che con 4 moduli può gestire al max 8 TH contro già un i7 980X che ne può gestire 12.
Le uniche uscite da questo ragionamento che vedrei sono 2:
1a
-------------------------------------------------------------------
che l'affermazione sia per l'ambito server: SB X8 con 16 TH = BD X16.
Per il desktop rimane solo BD X8, magari reputandolo già sufficiente almeno sino all'arrivo di SB X8 previsto sul finire anno prox.
Nel momento in cui Intel proporrà un X10, tra affinamenti e quant'altro, penso probabile che AMD proporrà un BD X10 e a quel punto non credo problematica l'"emigrazione" pure nel desktop.
--------------------------------------------------------------------
2a.
Il desktop, ha altre prerogative.
E' importante l'IPC del singolo core (ed in questo l'esempio è l'i7 e successivamente SB, in questo Intel al momento è nettamente prima).
Se BD incrementa l'IPC singolo core, facendo lavorare il modulo come X1, risolve ampiamente il problema, aiutato inoltre dal clock di per sé almeno del 25-30% superiore a quello Intel.
Il numero di TH è secondario... e comunque, diciamo che AMD anche con un numero di TH inferiore, essendo i TH fisici, non ha problemi a contrastare un numero di TH superiore da parte di Intel, visto che sono logici ma che si basano su n core logici/2 = core fisici, quindi anche in caso di SB X6 e X8, che comunque arriveranno sul finire anno prox., AMD avrebbe tutto il tempo sia per un nuovo step di silicio, sia per aggiungere il low-k se non presente all'uscita, e, tra CTI e processo a regime, miglioramenti di TDP tali da permettere l'aggiunta di 2 core non vedrei il tutto problematico.
Inoltre, il desktop può contare su clock sicuramente più alti che nel server, può contare su proci B.E. per la gioia di tutti.... ci mancherebbe solo un listino alla Thuban e vivremmo tutti felici e contenti.
paolo.oliva2
03-10-2010, 21:44
Ci ho pensato durante tutto il pomerigio:
Per aumentare l'ipc in monoth basterebbe che in caso di prediction fault invece di attendere lo svuotamento delle pipeline prima di inserire altri dati da elaborare si manda il tutto in esecuzione sull'altro core (abbassando di molto le latenze).
Questo potrebbe permettere un doppio vantaggio:
utilizzare algoritmi di prefech più spinti e al tempo stesso riddurre di molto i cicli di attesa in caso di fetch fault.
Questo porterebbe il guadagno di ipc ad una notevole impennata (tra un fetch aggressivo ed una notevole tolleranza all'errore, senza peraltro innalzare di un solo watt il tdp del singolo modulo.
Potrebbe sembrare FS, ma credo che con una struttura logica come quella imputata a Bd sia più che possibile e senza le controindicazioni dei processi multith che generalmente sono abbastanza prevedibili limitando le latenze dovute a fetch fault.
Se ho detto una cassanata scusatemi. :rolleyes:
Per me siamo nella strada giusta e l'abbiamo nasata molto bene... In fin dei conti il TH del Capitano è sempre stato nelle prime posizioni in fatto di nasate :) Vi ricordate quella dell'E0 del Thuban?
Inoltre... JF con quel 13% in più... non è attendibile nel desktop, perché lui parlava di server, quindi tutto il "nostro" discorso che si basa sul modulo inteso come X1 esula dalla sua affermazione.
Per finire... se cominciano ad essere sempre di più chi afferma che a parità di clock BD sarà sotto ma di poco a SB, ciò è ottenibile unicamente con sopra il 30% di IPC, cosa che mi sembra non sia giustificata da un INT in più e una doppia FP e L2 da 2MB. Un qualche cosa ci deve essere, e penso sia quella che abbiamo nasato....
Megakirops
03-10-2010, 21:45
Appoggio Gigamez, infatti l'argomento non è nuovo ma ne parlammo già nel mese di luglio, e fui proprio io ad avanzarla :D
Sono ancora convinto che ci sarà la sorpresa dei BD X4/4moduli/8thread fisici ed X8/8moduli/16thread fisici che però all'occorrenza possono lavorare solo su 4 ed 8 thread rispettivamente nel caso di programmi poco propensi al multi-thread in modo da ottimizzare le risorse.
Heimdallr
03-10-2010, 21:56
comunque i SB di fascia alta su lga 2011 sono previsti per il Q3 2011, quindi BD dovrà fronteggiarli ben presto dopo la sua uscita.
Ci ho pensato durante tutto il pomerigio:
Per aumentare l'ipc in monoth basterebbe che in caso di prediction fault invece di attendere lo svuotamento delle pipeline prima di inserire altri dati da elaborare si manda il tutto in esecuzione sull'altro core (abbassando di molto le latenze).
Questo potrebbe permettere un doppio vantaggio:
utilizzare algoritmi di prefech più spinti e al tempo stesso riddurre di molto i cicli di attesa in caso di fetch fault.
Questo porterebbe il guadagno di ipc ad una notevole impennata (tra un fetch aggressivo ed una notevole tolleranza all'errore, senza peraltro innalzare di un solo watt il tdp del singolo modulo.
Potrebbe sembrare FS, ma credo che con una struttura logica come quella imputata a Bd sia più che possibile e senza le controindicazioni dei processi multith che generalmente sono abbastanza prevedibili limitando le latenze dovute a fetch fault.
Se ho detto una cassanata scusatemi. :rolleyes:
In linea teorica potrebbe funzionare.. ma non hai tenuto conto di una cosa: quando le pipeline vanno in prediction fault la vera perdita di tempo sta nel ricercare il dato o il salto che non era stato predetto. Pur avendo due cores INT questa ricerca deve comunque essere effettuata! Una volta trovata una soluzione che tu risolva l'istruzione sul core 0 (con pipelines in stallo) o sul core 1 (totalmente in idle), non cambia molto a parte appunto el latenze.. un po' poco per giustificare un CORE aggiuntivo, non credi? Insomma: il guadagno prestazionale in un'ipotesi di questo tipo sarebbe davvero molto limitato.. a meno che non si ragioni in un'ottica SMT tipo Intel HT, dove una volta che si raggiunge una condizione di stallo lo scheduler "passa la palla" direttamente su un altro thread (il famoso thread "logico") per tenere comunque impegnate le pipelines e le executions durante l'attesa dovuta a cercare il "pezzo mancante".
Effettivamente funzionerebbe un pò meglio in un'ottica "intel HT", "saltando" sul secondo core solamente quando il primo core attende qualcosa e va in stallo. Sarebbe tuttavia estremamente poco efficiente avere un core FISICO chiamato in causa solamente nelle situazioni di fallimento, e quindi con un utilizzo molto distante dal massimo teorico (100%), non credi?
Sarebbe di certo piu' conveniente a livello di ottimizzazione ed utilizzo delle risorse (avendo due veri e propri cores FISICI) creare due threads (permettetemi il gioco di parole) "logici" partendo da un unico "thread fisico"!
Mi spiego: intendo "threads logici" in quanto a partire da un'unico thread "fisico" (il vero e proprio programma "monocore") si dovrebbero creare due percorsi logici di micro-ops da eseguire simultaneamente nei due cores INT.
Ecco che pero' arriviamo alla mia precedente ipotesi, non credi? :eek:
il prediction fault si avvera quando una istruzione condizionale ha un risultato diverso da quello predetto.
Di norma questo avviene all' uscita dai loop , se ho un loop che per 100 volte ha continuato a girare la branch prediction prevedera' che anche alla 101 esecuzione dopo l'istruzione condizionale vennga eseguita una determinata istruzione e quindi manda in pipeline questa istruzione prima ancora che venga completata l'esecuzione dell' istruzione condizionale.
L'idea proposta e' che nel caso di istruzioni condizionali un core int eseguirebe il ramo (true) mentre l'altro il ramo (false) , in questo modo indipendentemente dal risultato della condizionale ci sarebbe comunque un core gia' pronto con i dati correti in pipeline.
A mio parere pero' questa soluzione sebbene permetta di migliorare le performance non e' una risposta intelligente perche' raddoppia il consumo elettrico e perche' impedisce ad un unita' Int di occuparsi di altro ( o di stare spenta in idle)
Mi spiego: intendo "threads logici" in quanto a partire da un'unico thread "fisico" (il vero e proprio programma "monocore") si dovrebbero creare due percorsi logici di micro-ops da eseguire simultaneamente nei due cores INT.
Ecco che pero' arriviamo alla mia precedente ipotesi, non credi? :eek:
mi quoto per semplificare AL MASSIMO cosa intendo con la mia ipotesi (permettetemi qualche licenza tecnica, hehe):
immaginate una sorta di "SLI/crossfire" tra due unità INT: nel multi GPU, la scena da renderizzare e' la stessa, ma un frame viene dato in pasto alla prima GPU, e durante l'esecuzione di questi calcoli viene dato il frame successivo alla seconda GPU, avvicinandosi ad un guadagno vicino a quello teorico, nel migliore dei casi.
Ora.. immaginate la stessa cosa, ma tra le due unità INT: Il thread da eseguire e' lo stesso, ma una micro-op viene data in pasto alla prima unità INT, e durante l'esecuzione dei calcoli viene data la micro-op successiva alla seconda unità INT. Molto semplice, ma potrebbe anche funzionare, no? Magari si spiegano anche quelle 4 unita' di decode ed il fetch unificato nei moduli.. :fagiano:
Tutte ipotesi, ehhhh :sofico: XD
il prediction fault si avvera quando una istruzione condizionale ha un risultato diverso da quello predetto.
Di norma questo avviene all' uscita dai loop , se ho un loop che per 100 volte ha continuato a girare la branch prediction prevedera' che anche alla 101 esecuzione dopo l'istruzione condizionale vennga eseguita una determinata istruzione e quindi manda in pipeline questa istruzione prima ancora che venga completata l'esecuzione dell' istruzione condizionale.
L'idea proposta e' che nel caso di istruzioni condizionali un core int eseguirebe il ramo (true) mentre l'altro il ramo (false) , in questo modo indipendentemente dal risultato della condizionale ci sarebbe comunque un core gia' pronto con i dati correti in pipeline.
A mio parere pero' questa soluzione sebbene permetta di migliorare le performance non e' una risposta intelligente perche' raddoppia il consumo elettrico e perche' impedisce ad un unita' Int di occuparsi di altro ( o di stare spenta in idle)
infatti: potrebbe avere senso, ma ricadremmo comunque nel caso di uno spreco di risorse davvero notevole, distanziando di troppo il massimo teorico ottenibile da due cores INT (ovvero il doppio di prestazione sugli interi). Secondo me un'ottica di questo tipo e' quasi inutile e porterebbe infatti piu' svantaggi (consumo e calore maggiori) che vantaggi (limitatissimi al solo caso di appunto fallimento)
In linea teorica potrebbe funzionare.. ma non hai tenuto conto di una cosa: quando le pipeline vanno in prediction fault la vera perdita di tempo sta nel ricercare il dato o il salto che non era stato predetto. Pur avendo due cores INT questa ricerca deve comunque essere effettuata! Una volta trovata una soluzione che tu risolva l'istruzione sul core 0 (con pipelines in stallo) o sul core 1 (totalmente in idle), non cambia molto a parte appunto el latenze.. un po' poco per giustificare un CORE aggiuntivo, non credi? Insomma: il guadagno prestazionale in un'ipotesi di questo tipo sarebbe davvero molto limitato.. a meno che non si ragioni in un'ottica SMT tipo Intel HT, dove una volta che si raggiunge una condizione di stallo lo scheduler "passa la palla" direttamente su un altro thread (il famoso thread "logico") per tenere comunque impegnate le pipelines e le executions durante l'attesa dovuta a cercare il "pezzo mancante".
Effettivamente funzionerebbe un pò meglio in un'ottica "intel HT", "saltando" sul secondo core solamente quando il primo core attende qualcosa e va in stallo. Sarebbe tuttavia estremamente poco efficiente avere un core FISICO chiamato in causa solamente nelle situazioni di fallimento, e quindi con un utilizzo molto distante dal massimo teorico (100%), non credi?
Sarebbe di certo piu' conveniente a livello di ottimizzazione ed utilizzo delle risorse (avendo due veri e propri cores FISICI) creare due threads (permettetemi il gioco di parole) "logici" partendo da un unico "thread fisico"!
Mi spiego: intendo "threads logici" in quanto a partire da un'unico thread "fisico" (il vero e proprio programma "monocore") si dovrebbero creare due percorsi logici di micro-ops da eseguire simultaneamente nei due cores INT.
Ecco che pero' arriviamo alla mia precedente ipotesi, non credi? :eek:
Attenzione tutto quello che ho ipotizzato prima dovrebbe corrispondere ad un + 5-7% sul totale dovuto sopratutto ad un prefech più aggressivo scortato da una bassa latenza ( all'incirca 4 cicli contro i 7, in media) in monoth.
Se ho abbastanza thread da riempire i singoli core questo reverseht non avrebbe luogo, mentre in caso di inattività innalzerebbe l'ipc del singolo th perchè eseguito alternativamente sui due core.
Sul discorso delle micro-ops credo che si avrebbero problemi di latenza nel gestire la cache L1 del singolo core (che anche se in presenza di cache esclusiva porterebbe danno il non utilizzarla)
infatti: potrebbe avere senso, ma ricadremmo comunque nel caso di uno spreco di risorse davvero notevole, distanziando di troppo il massimo teorico ottenibile da due cores INT (ovvero il doppio di prestazione sugli interi). Secondo me un'ottica di questo tipo e' quasi inutile e porterebbe infatti piu' svantaggi (consumo e calore maggiori) che vantaggi (limitatissimi al solo caso di appunto fallimento)
e se le prediction fault fossero il 30% sul totale?
Attenzione tutto quello che ho ipotizzato prima dovrebbe corrispondere ad un + 5-7% sul totale dovuto sopratutto ad un prefech più aggressivo scortato da una bassa latenza ( all'incirca 4 cicli contro i 7, in media) in monoth.
Se ho abbastanza thread da riempire i singoli core questo reverseht non avrebbe luogo, mentre in caso di inattività innalzerebbe l'ipc del singolo th perchè eseguito alternativamente sui due core.
Sul discorso delle micro-ops credo che si avrebbero problemi di latenza nel gestire la cache L1 del singolo core (che anche se in presenza di cache esclusiva porterebbe danno il non utilizzarla)
uhm.. allora mi sa che non ho capito bene cosa intendi: praticamente la tua ipotesi si basa su un qualcosa di "misto" ed alternativo tra un SMT ed un vero modulo "dualcore"? :)
No, perche' se fosse solamente come SMT avresti appunto un guadagno molto piccolo, e se fosse un vero dualcore penso proprio non dovresti avere unita' come fetch e branch prediction in comune.. :help:
e se le prediction fault fossero il 30% sul totale?
Teoricamente pensando al solo branch prediction avresti comunque un guadagno prestazionale <= al 30% rispetto alla singola unità int, quindi comunque troppo distante da quello teorico che l'unità aggiuntiva potrebbe darti (100%, appunto). E quando invece hai dei successi? Lasci il secondo core in idle o lo fai comunque lavorare inutilmente per qualcosa che poi non servirà (consumando comunque e producendo calore)? Gli daresti in pasto qualcos'altro quando non ci sono dei "trees" da gestire? in questo caso con quali unità di fetch e decode potresti fare una cosa simile, visto che quelle condivise starebbero gia' lavorando per il primo core? :S
uhm.. allora mi sa che non ho capito bene cosa intendi: praticamente la tua ipotesi si basa su un qualcosa di "misto" ed alternativo tra un SMT ed un vero modulo "dualcore"? :)
No, perche' se fosse solamente come SMT avresti appunto un guadagno molto piccolo, e se fosse un vero dualcore penso proprio non dovresti avere unita' come fetch e branch prediction in comune.. :help:
Teoricamente pensando al solo branch prediction avresti comunque un guadagno prestazionale <= al 30% rispetto alla singola unità int, quindi comunque troppo distante da quello teorico che l'unità aggiuntiva potrebbe darti (100%, appunto). E quando invece hai dei successi? Lasci il secondo core in idle o lo fai comunque lavorare inutilmente per qualcosa che poi non servirà (consumando comunque e producendo calore)? Gli daresti in pasto qualcos'altro quando non ci sono dei "trees" da gestire? in questo caso con quali unità di fetch e decode potresti fare una cosa simile, visto che quelle condivise starebbero gia' lavorando per il primo core? :S
onestamente preferisco avere un +5% ipc in mono th usando i core alternandoli nei calcoli (solo nel caso il numero di th in esecuzione siano inferiori al numero dei core) con peso 0 watt che +20% di ipc con peso di 5W (non dimentichiamoci che un core int è solo il 12% di un modulo, quindi l'utilizzarlo porta ad al massimo + 8% di W in più, considerando che per la struttura del modulo il singolo core non viene spento e nemmeno rallentato
ma semplicemente lasciato in c1 state)
onestamente preferisco avere un +5% ipc in mono th usando i core alternandoli nei calcoli (solo nel caso il numero di th in esecuzione siano inferiori al numero dei core) con peso 0 watt che +20% di ipc con peso di 5W (non dimentichiamoci che un core int è solo il 12% di un modulo, quindi l'utilizzarlo porta ad al massimo + 8% di W in più, considerando che per la struttura del modulo il singolo core non viene spento e nemmeno rallentato
ma semplicemente lasciato in c1 state)
vabbe', ma allora perche' fare un core fisico quando usando un SMT si potrebbe avere una prestazione aggiunta a volte anche molto maggiore dell'8% (senza nemmeno avere quel seppur piccolo 8% di consumo in +)? :O
vabbe', ma allora perche' fare un core fisico quando usando un SMT si potrebbe avere una prestazione aggiunta a volte anche molto maggiore dell'8% (senza nemmeno avere quel seppur piccolo 8% di consumo in +)? :O
ecco dove sbagli.
Io non faccio un core fisico in più per avere un 8% in più di ipc.
Io faccio un core in più per avere un thread reale in più, ma che quando questo sta a rigirarsi i pollici lo uso per avere un ipc maggiore del 5-8-20% (quello che sia insomma) prendendolo in prestito.
4 moduli possono essere visti come 8 core reali in ambito multi th o come 4 supercore in ambito single th.
L'SMT di intel dal canto suo utilizza i tempi morti dovuti a codice malamente ottimizzato per poter raddoppiare i th logici.
Per curiosità domani provo a lanciare un cinebench su i7 975 senza smt attivo (con smt on ho 6,02) per vedere la perdita di performance in sua assenza.
ecco dove sbagli.
Io non faccio un core fisico in più per avere un 8% in più di ipc.
Io faccio un core in più per avere un thread reale in più, ma che quando questo sta a rigirarsi i pollici lo uso per avere un ipc maggiore del 5-8-20% (quello che sia insomma) prendendolo in prestito.
4 moduli possono essere visti come 8 core reali in ambito multi th o come 4 supercore in ambito single th.
L'SMT di intel dal canto suo utilizza i tempi morti dovuti a codice malamente ottimizzato per poter raddoppiare i th logici.
Per curiosità domani provo a lanciare un cinebench su i7 975 senza smt attivo (con smt on ho 6,02) per vedere la perdita di performance in sua assenza.
ecco allora che ho capito cosa intendevi: una sorta di "misto" tra le due cose, appunto.
Ma come faresti a gestire un modulo come 2 cores reali (nel caso tu non debba gestire dei prediction), sapendo di avere moltissime unità condivise tra cui appunto fetch e decode? :O
Inoltre: ogni volta che avresti una "biforcazione" del tuo programma dovresti gestire simultaneamente le due possibili soluzioni, cosi' come faceva notare Athlon. Sarebbe veramente la cosa piu' ottimizzata, al livello di prestazioni? Non sarebbe allora piu' facile fare come ha fatto Intel, ovvero un modulo con un solo core molto potente in grado di implementare un SMT? avresti sicuramente consumi minori, costi minori, tdp minore ed ottimizzazione delle risorse hardware maggiore!
Secondo me non puo' essere questa l'ipotesi su cui si basa un modulo BD..
capitan_crasy
04-10-2010, 00:55
Ho ricevuto una notizia da confermare.
E' sotto esame il nuovo step produttivo di Llano cioè lo step B0 (quello che in pratica ha portato il posticipo a quest'estate); il primo step funzionante di Llano è stato A0....
ecco allora che ho capito cosa intendevi: una sorta di "misto" tra le due cose, appunto.
Ma come faresti a gestire un modulo come 2 cores reali (nel caso tu non debba gestire dei prediction), sapendo di avere moltissime unità condivise tra cui appunto fetch e decode? :O
Inoltre: ogni volta che avresti una "biforcazione" del tuo programma dovresti gestire simultaneamente le due possibili soluzioni, cosi' come faceva notare Athlon. Sarebbe veramente la cosa piu' ottimizzata, al livello di prestazioni? Non sarebbe allora piu' facile fare come ha fatto Intel, ovvero un modulo con un solo core molto potente in grado di implementare un SMT? avresti sicuramente consumi minori, costi minori, tdp minore ed ottimizzazione delle risorse hardware maggiore!
Secondo me non puo' essere questa l'ipotesi su cui si basa un modulo BD..
Bd è indirizzato al mercato server (quindi niente smt attivo su intel).
Bd è massimizzato per avere le massime prestazioni in multith.
L'smt di intel occupa diciamo il 3% di superfice in relazione al core.
il 2 core occupa il 12% in relazione al modulo.
Adesso cosa ti faccia pensare che un core + smt sia più efficente in multith di un modulo?
la densita di core per superfice è nettamente a favore di bd e presumibilmente dove SB avrà 8 core reali Bd avrà almeno 6 moduli (ma forse ci sarebbe lo spazio anche per 7)
Il modulo di amd serve ad aumentare la densità dei core.
Tutto il discorso sul reverse HTT sono solo speculazioni e se questo fosse reale sarebbe solo un opzional (che peraltro sarebbe del tutto inutile in ambito server)
paolo.oliva2
04-10-2010, 01:30
Ho ricevuto una notizia da confermare.
E' sotto esame il nuovo step produttivo di Llano cioè lo step B0 (quello che in pratica ha portato il posticipo a quest'estate); il primo step funzionante di Llano è stato A0....
Mi sa proprio che sia il... low-k.
Se fosse il 32nm liscio, da A0 dovrebbe passare ad A1.
B0, cioè cambiare la lettera iniziale, dovrebbe essere un cambio radicale di trattamento, cioé... dovrebbe equivalere all'introduzione low-k.
(vedi Soi 45nm C2, C3... altro trattamento D0 D1, introduzione low-k E0).
Se proprio non fosse il low-k, comunque dovrebbe essere qualche cosa di importante, visto il posticipo.
Bd è indirizzato al mercato server (quindi niente smt attivo su intel).
Bd è massimizzato per avere le massime prestazioni in multith.
L'smt di intel occupa diciamo il 3% di superfice in relazione al core.
il 2 core occupa il 12% in relazione al modulo.
Adesso cosa ti faccia pensare che un core + smt sia più efficente in multith di un modulo?
la densita di core per superfice è nettamente a favore di bd e presumibilmente dove SB avrà 8 core reali Bd avrà almeno 6 moduli (ma forse ci sarebbe lo spazio anche per 7)
Il modulo di amd serve ad aumentare la densità dei core.
Tutto il discorso sul reverse HTT sono solo speculazioni e se questo fosse reale sarebbe solo un opzional (che peraltro sarebbe del tutto inutile in ambito server)
uhm.. mi sa che ora sei tu a non aver capito cosa intendo io.. ma te lo spiego bene domani: ora vado a dormire! XD
paolo.oliva2
04-10-2010, 01:47
Bd è indirizzato al mercato server (quindi niente smt attivo su intel).
Bd è massimizzato per avere le massime prestazioni in multith.
L'smt di intel occupa diciamo il 3% di superfice in relazione al core.
il 2 core occupa il 12% in relazione al modulo.
Adesso cosa ti faccia pensare che un core + smt sia più efficente in multith di un modulo?
la densita di core per superfice è nettamente a favore di bd e presumibilmente dove SB avrà 8 core reali Bd avrà almeno 6 moduli (ma forse ci sarebbe lo spazio anche per 7)
Il modulo di amd serve ad aumentare la densità dei core.
Tutto il discorso sul reverse HTT sono solo speculazioni e se questo fosse reale sarebbe solo un opzional (che peraltro sarebbe del tutto inutile in ambito server)
Quoto.
Il problema di AMD è quello di recuperare IPC nel monocore in desktop.
Nell'ambito server praticamente sarebbe bastato portare un Magny-C sul 32nm per guadagnare quei 0.5-1GHz di clock.
BD diciamo che sarebbe ottimizzato per sfruttare il 32nm sia sul lato clock (con pipeline idonee) che sul lato monocore inteso come IPC.
Inoltre aggiungerei una cosa... da notare che il livello di spegnimento core è inteso a livello di modulo. Quindi viene da sé che coinciderebbe con l'ipotesi di modulo visto come 1 super-core nel caso il modulo non debba servire 2 TH ma 1 TH.
E poi, semplificando, abbiamo visto che il modulo con sia l'INT in più che la FP raddoppiata sono un'ottimizzazione per ridurre la superficie del die ed ottimizzare il TDP/IPC al massimo.
Ma questo non toglie che se il modulo lavora con 1 singolo TH, praticamente avrebbe a quel punto un raddoppio di INT ed una FP doppia.
Il TDP non importerebbe, perché comunque non può arrivare al livello di 2 core che funziano.
Insomma, anche senza complicarci la vita con 2 pipeline simultanee o qualsivoglia, mi pare innegabile che un modulo fatto lavorare con 1 TH sarebbe un super-core.
Oltretutto, riducendo lo spazio a modulo (per 2 core), la potenza del multicore si troverebbe sempre e ugualmente semplicemente perché con meno TDP e con meno spazio a die, aggiungere più moduli risulterebbe comunque cosa facile.
Con questo non è che dico che Gigamez abbia torto... cerco soltanto di semplificare il concetto.
Nell'ambito server praticamente sarebbe bastato portare un Magny-C sul 32nm per guadagnare quei 0.5-1GHz di clock.
Assolutamente imho è troppo ;) 0.4-0.5 Ghz a dire tanto.
Ma, alla fine... contando la diminuzione della superficie del modulo rispetto ai 2 core Phenom II classici, e valutando anche la diminuzione nel passaggio dal 45nm al 32nm... un BD X12 starebbe dentro alla superficie di un die Thuban X6? (secondo te)
A parità di processo produttivo dubito che un BD x8 possa stare nell'area di un Thuban x6. Non tanto per i core, quanto per l'area della cache che è di fatto più che raddoppiata.
Facendo una valutazione spannometrica a parità di processo produttivo:
- l'area di 4 moduli BD potrebbe essere di circa il 35% superiore a quella di 6 core Thuban
- l'area della cache circa raddoppiata
Considerando l'area occupata da cache e core in Thuban corrisponde a circa l'11% per la cache e il 29% per i core e considerando circa costante tutto quello che gli sta intorno: il BD X8 avrebbe un'area maggiore di un Thuban X6 del 20%.
Contando che il die-shrink potrebbe portare ad una diminuzione del 50% dell'area, un BD X8 a 32 nm occuperebbe circa il 60% dell'area di un Thuban X6. Stiamo larghi e consideriamo il 70% (visto che alcune componenti della geometria non scalano linearmente).
Il BD X12 invece potrebbe stare nell'area di un Thuban 45nm.
paolo.oliva2
04-10-2010, 10:27
A parità di processo produttivo dubito che un BD x8 possa stare nell'area di un Thuban x6. Non tanto per i core, quanto per l'area della cache che è di fatto più che raddoppiata.
Facendo una valutazione spannometrica a parità di processo produttivo:
- l'area di 4 moduli BD potrebbe essere di circa il 35% superiore a quella di 6 core Thuban
- l'area della cache circa raddoppiata
Considerando l'area occupata da cache e core in Thuban corrisponde a circa l'11% per la cache e il 29% per i core e considerando circa costante tutto quello che gli sta intorno: il BD X8 avrebbe un'area maggiore di un Thuban X6 del 20%.
Contando che il die-shrink potrebbe portare ad una diminuzione del 50% dell'area, un BD X8 a 32 nm occuperebbe circa il 60% dell'area di un Thuban X6. Stiamo larghi e consideriamo il 70% (visto che alcune componenti della geometria non scalano linearmente).
Il BD X12 invece potrebbe stare nell'area di un Thuban 45nm.
Allora rimane da constatare il TDP del 32nm, perché come costo produzione sarebbe proponibile.
Assolutamente imho è troppo ;) 0.4-0.5 Ghz a dire tanto.
Considera questo:
Il D0 (il primo Opteron 6 core) era 2,8GHz 140W.
Il D1 (seconda release silicio) permette un X12 a 2,4GHz sempre a 140W (raddoppio dei core con perdita 400MHz a parità di TDP)
Già comunque si parlava di un +100MHz (2,5GHz) rimanendo sullo stesso TDP
Già se fosse fatto con il low-k (E0) sarei dell'idea di un incremento di almeno 200-300MHz (suppongo che non sia stato fatto perché il low-k rende di più a frequenze medio-alte, ma non nelle basse... Ad esempio il Vcore in idle è 1,15V con l'E0 mentre con il C2-C3 arriva a 0,8V. Probabilmente il leakage non è così alto nel D1 da permettere guadagni notevoli sull'E0, per via di Vcore particolarmente bassi)
Passando al 32nm, con un 40% in meno di TDP, un Magny-C X12 potrebbe arrivare addirittura a 85W a 2,5GHz...
Considera questo:
Il D0 (il primo Opteron 6 core) era 2,8GHz 140W.
Il D1 (seconda release silicio) è 2,5GHz 140W X12 (raddoppio dei core con perdita 300MHz)
Già se fosse fatto con il low-k (E0) sarei dell'idea di un incremento di almeno 200-300MHz.
Passando al 32nm, con in 40% in meno di TDP, un Magny-C X12 sarebbe 85W a 2,5GHz...
Confronta almeno processori con lo stesso TDP e lo stesso numero di core ;)
Opteron 2435: 6 core, TDP 115W, frequenza 2600 Mhz
Opteron 4184: 6 core, TDP 115W, frequenza 2800 Mhz
Quindi con uno step si sono guadagnati 200 Mhz.
Primo devi contare che una CPU non esce sul mercato subito con il secondo step. Secondo è possibile che da uno step all'altro si facciano modifiche non radicali che portino ad avvantaggiarsi sul TDP. E non è detto che ogni step porti equivalenti vantaggi in termine di TDP, ma è possibile anche che non portino alcun vantaggio e si vada ad intervenire su altro.
Terzo il 45nm Low-k non viene implementato per ora sui 32nm.
Queste cose non c'entrano niente con il die-shrink... Ed in ogni caso questi possibili vantaggi si avrebbero nel tempo e non immediatamente (anche 12 mesi). Quindi rimango dell'idea che dal semplice passaggio da 45 nm low-k al 32 nm si otterrebbero circa 400 Mhz in più a parità di processore.
paolo.oliva2
04-10-2010, 11:33
Comunque, dando per scontato che un Magny-C non lo vedremmo mai sul desktop, considera le differenze sul Thuban.
Incremento IPC nel singolo core nullo, solamente incremento di frequenza (dando per scontato che le frequenze almeno in turbo si alzerebbero).
Incremento di IPC nel multicore elevato.
Ma infatti analizzando questo si riesce a inquadrare molto meglio il perché di BD ed i requisiti con cui è stato creato BD, passando già nell'evoluzione del Phenom II nel Thuban.
In fin dei conti il Thuban cosa ha fatto? Maggior frequenza in monocore (Turbo) per alzare la potenza nel monocore e innalzamento IPC del multicore per i 2 core aggiuntivi.
Un Magny-C X12 avrebbe tranquillamente contrastato un i7 X6 e probabilmente pure X8 con l'aumento di clock, ma non sarebbe stato competitivo in termini di IPC monocore.
Per questo reputo MOLTO fondate il discorso del modulo che possa lavorare con 1 TH come fosse un super-core, lasciando pressoché invariato l'IPC del multicore perché anche considerando una relativa perdita di prestazioni in multicore (comunque intesa nella condivisione, perché a tutti gli effetti bisogna anche valutare le differenze se non porterebbero comunque vantaggi) e comunque sarebbero compensate dal notevole aumento di frequenza, di per sé anche ammettendo solamente un + 30% (3,2GHz --> 4GHz) molto più consistente di qualsiasi calo derivante dall'IPC multicore.
AMD non può aver progettato un Buldozer in 5 anni senza tenere conto di tutto questo, e comunque seguendo la strada intrapresa dal primpo Phenom II/Opteron X4.
Bd è indirizzato al mercato server (quindi niente smt attivo su intel).
Bd è massimizzato per avere le massime prestazioni in multith.
L'smt di intel occupa diciamo il 3% di superfice in relazione al core.
il 2 core occupa il 12% in relazione al modulo.
Adesso cosa ti faccia pensare che un core + smt sia più efficente in multith di un modulo?
la densita di core per superfice è nettamente a favore di bd e presumibilmente dove SB avrà 8 core reali Bd avrà almeno 6 moduli (ma forse ci sarebbe lo spazio anche per 7)
Il modulo di amd serve ad aumentare la densità dei core.
Tutto il discorso sul reverse HTT sono solo speculazioni e se questo fosse reale sarebbe solo un opzional (che peraltro sarebbe del tutto inutile in ambito server)
ok, sono d'accordo :)
Ma quello che intendevo dire io non era che un core + SMT fosse piu' prestante di un modulo in maniera assoluta.. Intendevo dire che se usassi un modulo come un dual core dove all'occorrenza (programmi monoth) il secondo core fa da "supporto SMT fisico" al primo core vorrebbe dire che ogni core dovrebbe necessariamente avere anche il suo fetch ed il suo decode autonomo ed asclusivo, in modo da poter essere all'occorrenza totalmente indipendente. Se fosse davvero cosi', dunque, allora perche' non proporre 2 cores veramente separati (perche' sarebbero "separati" comunque, secondo la tua ipotesi visto che nell'utilizzo multith a parte alcune memorie interne agirebbero in maniera totalmente autonoma) con l'aggiunta di un SMT, cosi' come appunto ha gia' fatto Intel da un pezzo? Si risparmierebbe in progettazione, si massimerebbero le prestazioni e si consumerebbe anche di meno! Intel ha dei cores piu' estesi a livello di silicio, vero, ma sono anche decisamente piu' potenti.. quindi anche il discorso sul risparmio del silicio da solo non basterebbe, secondo me. E conta anche che per quello che vediamo se i due cores fossero davvero separati, SULLA CARTA avrebbero, presi singolarmente, un IPC addirittura inferiore di quello di un singolo core k10 (presi da soli, hanno meno risorse da poter usare). Conta inoltre che le circuitazioni e gli algoritmi necessari a gestire i trees nel caso dei prediction sarebbero dispensdiose in termini di silicio e di progettazione.. per avere un guadagno praticamente simile a quello che ha Intel con il suo SMT..
La logica del modulo penso sia quella dell'integrare alcune componenti per i due core (e non solo le memorie, come proporresti tu). E' questa integrazione che non puo' permettere una completa autonomia di questi due cores, che devono essere PER FORZA legati tra di loro in fase esecutiva (hanno ad esempio fetch e decode in comune, almeno stando ai disegni finora visti)! Ecco perche' sto cercando di fare queste speculazioni, proprio perche' per quello che ora si e' visto dai grafici architetturali una ipotesi come la tua dovrebbe partire da una architettura piuttosto diversa, ed a mio parere non sarebbe per nulla conveniente..
Per quanto riguarda i vantaggi nel mercato server.. Una fantasiosa ipotesi come la mia (quella che ho semplificato al massimo come un "SLI" tra unità int XD) porterebbe vantaggi in qualunque caso.. qualunque! Praticamente potrebbe quasi raddoppiare le prestazioni INT, avendo nel modulo in comune praticamente tutto il resto (fetch, decode, memorie, retires, ecc.). A mio parere sarebbe un esempio di integrazione decisamente piu' spinta, tale da giustificare una nuova architettura, invece ad esempio di prendere quella gia' esistente ed aggiungerci un SMT per avere vantaggi simili rispetto a quello che proponi tu.
AceGranger
04-10-2010, 12:16
Un Magny-C X12 avrebbe tranquillamente contrastato un i7 X6 e probabilmente pure X8 con l'aumento di clock, ma non sarebbe stato competitivo in termini di IPC monocore.
tranquillamente mica tanto, arranca un pochino contro i 6+6
http://www.anandtech.com/show/2978/amd-s-12-core-magny-cours-opteron-6174-vs-intel-s-6-core-xeon
i test sono stai effettuati con questi proci
6174 80/115W 2.2 GHz
X5670 95W 2.93 GHz equivalente i7 970
sono entrambi i secondi proci piu veloci, i TOP gamma sono
6176 SE 105/137W 2.3 GHz + 100 MHz
W5680 130W 3.30 GHz + 370 MHz equivalente i7 980X
l'aumento di clock servirebbe per contrastare sempre i 6+6, gli 8+8 mi sa che stanno fuori portata
george_p
04-10-2010, 12:20
Ma visto che BD ragiona per moduli e l'inserimento di un core Int. rappresenta solo 12% dell'area dell'intero modulo, potrebbe, AMD, aver progettato questa architettura prevedendo l'inserimento di più Int. per ogni modulo così da aumentare significativamente l'elaborazione simultanea di più threads?
In questo modo aumenterebbe di poco l'area occupata a tutto vantaggio in termini di tdp e roba varia.
Fantascienza?
Sarebbe molto auspicabile :sofico:
Ma visto che BD ragiona per moduli e l'inserimento di un core Int. rappresenta solo 12% dell'area dell'intero modulo, potrebbe, AMD, aver progettato questa architettura prevedendo l'inserimento di più Int. per ogni modulo così da aumentare significativamente l'elaborazione simultanea di più threads?
In questo modo aumenterebbe di poco l'area occupata a tutto vantaggio in termini di tdp e roba varia.
Fantascienza?
Sarebbe molto auspicabile :sofico:
No, assolutamente. Chiaramente non è una cosa possibile nell'immediato. I core interi non possono essere aggiunti come le figurine all'album, perché tutti gli stage precedenti e successivi all'esecuzione devono essere dimensionati in modo da poter gestire in modo efficiente una quantità contemporanea di istruzioni tale da lasciare il meno possibile inoperosi i vari core int. Quindi aggiungere core int senza riprogettare backend e frontend è impossibile.
Il vantaggio è che questo ridimensionamento non porta ad un raddoppio di ogni risorsa ;)
ok, sono d'accordo :)
Ma quello che intendevo dire io non era che un core + SMT fosse piu' prestante di un modulo in maniera assoluta.. Intendevo dire che se usassi un modulo come un dual core dove all'occorrenza (programmi monoth) il secondo core fa da "supporto SMT fisico" al primo core vorrebbe dire che ogni core dovrebbe necessariamente avere anche il suo fetch ed il suo decode autonomo ed asclusivo, in modo da poter essere all'occorrenza totalmente indipendente. Se fosse davvero cosi', dunque, allora perche' non proporre 2 cores veramente separati (perche' sarebbero "separati" comunque, secondo la tua ipotesi visto che nell'utilizzo multith a parte alcune memorie interne agirebbero in maniera totalmente autonoma) con l'aggiunta di un SMT, cosi' come appunto ha gia' fatto Intel da un pezzo? Si risparmierebbe in progettazione, si massimerebbero le prestazioni e si consumerebbe anche di meno!
Non ci sarebbe alcuno dei vantaggi che hai descritto.
Prima di tutto con un SMT classico è stato dimostrato che l'aumento di prestazioni è bassissimo in ogni situazione, tranne in quelle fortemente parallelizzabile (si arriva ad un massimo del 33% di efficienza in più in rarissimi casi, ma con medie intorno al 7% ed occupando il 5% in più di area).
L'area di due core (con singolo core int) senza SMT sarebbe pari al 178% di quella di un modulo. Le prestazioni (teoriche) sarebbero pari al 200% di quelle di un single core così come l'area occupata.
Le prestazioni di un modulo con due core int sono l'80% di quelle del dual core occupando il 56% dell'area.
Le prestazioni / area occupata sarebbero nettamente a favore del modulo ;)
Per rendersi conto:
- prestazioni / area singole/dual core con solamente un core int: 100%
- prestazioni / area occupata modulo: 143%
Supponendo di avere un SMT sui core con singolo core int, in situazione di efficienza massima (33%) e con area occupata del 5% in più.
Le prestazioni rispetto al core senza SMT sarebbero il 133% con un'area del 105%.
Le prestazioni del singolo modulo rispetto al dual core SMT sarebbero del 60%. L'area occupata sarebbe il 53%.
Vediamo l'efficienza prestazioni / area occupata:
- per il single/dual core: 100%
- per il single/dual core SMT: 127%
- per il modulo: 143%
Quindi anche considerando un dual core SMT, le prestazioni sarebbero nettamente superiori rispetto all'area occupata per il modulo con due core int ;) E considera che ho preso le prestazioni massime ottenibili con l'SMT. Se prendevo il 7% le cose sarebbero andate ancora peggio.
george_p
04-10-2010, 13:33
Capisco :)
Grazie della risposta cionci.
Aspettiamo e vediamo l'arrivo di bulldozer, sarà molto atteso per applicazioni 3D su desktop :cool:
paolo.oliva2
04-10-2010, 14:14
tranquillamente mica tanto, arranca un pochino contro i 6+6
http://www.anandtech.com/show/2978/amd-s-12-core-magny-cours-opteron-6174-vs-intel-s-6-core-xeon
i test sono stai effettuati con questi proci
6174 80/115W 2.2 GHz
X5670 95W 2.93 GHz equivalente i7 970
sono entrambi i secondi proci piu veloci, i TOP gamma sono
6176 SE 105/137W 2.3 GHz + 100 MHz
W5680 130W 3.30 GHz + 370 MHz equivalente i7 980X
l'aumento di clock servirebbe per contrastare sempre i 6+6, gli 8+8 mi sa che stanno fuori portata
Prova a guardare i test su linux... :).
In ambito Windows, senza sollevare polemiche, le piattaforme Intel rendono sempre di più, ma le cose cambieranno, perché con le AVX non potranno esistere compilatori "partigiani", e poi perché Intel non può risciare altre sanzioni perché è già stata avvisata e nell'accordo di "liquidazione" vecchio ha messo su carta che deve cambiare.
In ambito Linux le differenze tra un Magny-C ed un X6 Intel sono esigue, ma conta il fatto che il Magny-C "gira" a 2,4GHz-2,5GHz e l'Intel gira a 3,333GHz.
Con base SB Intel avrà suppergiù gli stessi clock, mentre un Magny-C, anche consideranto (per me) il sottostimato di Cionci a +500MHz, cosa otterremo?
SB un incremento di IPC, ma se un SB X4 mostra un +12% di media.... SB X6 potrebbe averlo inferiore, ma sicuramente NON maggiore.
AMD Da 2,5GHz a 3GHz si tratterebbe di +20%.
Ai bench visti, ammettendo per SB +10% e per Magny-C +20%, la risultante è che uscirebbe un +10% a favore di AMD rispetto all'attuale, non briciole, considerando per Magny-C solo 3GHz su 32nm...
Però, se vogliamo considerare per SB un +10% di IPC e pure un +10% sul clock, con risultante di un incremento maggiore del 20%, con la stessa manica larga non possiamo considerare solo un 20% per Magny-C, allo stesso modo, dovremmo considerare almeno un 40-50% che sarebbe equivalente alla stessa diminuzione di TDP dichiarata da AMD.
Se vogliamo fare i confronti, dobbiamo utilizzare lo stesso metro. E' inutile fare confronti aumentando le aspettive sull'Intel ed abbassando nettamente sul concreto quelle AMD... che confronto verrebbe fuori?
ok, sono d'accordo :)
Ma quello che intendevo dire io non era che un core + SMT fosse piu' prestante di un modulo in maniera assoluta.. Intendevo dire che se usassi un modulo come un dual core dove all'occorrenza (programmi monoth) il secondo core fa da "supporto SMT fisico" al primo core vorrebbe dire che ogni core dovrebbe necessariamente avere anche il suo fetch ed il suo decode autonomo ed asclusivo, in modo da poter essere all'occorrenza totalmente indipendente. Se fosse davvero cosi', dunque, allora perche' non proporre 2 cores veramente separati (perche' sarebbero "separati" comunque, secondo la tua ipotesi visto che nell'utilizzo multith a parte alcune memorie interne agirebbero in maniera totalmente autonoma) con l'aggiunta di un SMT, cosi' come appunto ha gia' fatto Intel da un pezzo? Si risparmierebbe in progettazione, si massimerebbero le prestazioni e si consumerebbe anche di meno! Intel ha dei cores piu' estesi a livello di silicio, vero, ma sono anche decisamente piu' potenti.. quindi anche il discorso sul risparmio del silicio da solo non basterebbe, secondo me. E conta anche che per quello che vediamo se i due cores fossero davvero separati, SULLA CARTA avrebbero, presi singolarmente, un IPC addirittura inferiore di quello di un singolo core k10 (presi da soli, hanno meno risorse da poter usare). Conta inoltre che le circuitazioni e gli algoritmi necessari a gestire i trees nel caso dei prediction sarebbero dispensdiose in termini di silicio e di progettazione.. per avere un guadagno praticamente simile a quello che ha Intel con il suo SMT..
La logica del modulo penso sia quella dell'integrare alcune componenti per i due core (e non solo le memorie, come proporresti tu). E' questa integrazione che non puo' permettere una completa autonomia di questi due cores, che devono essere PER FORZA legati tra di loro in fase esecutiva (hanno ad esempio fetch e decode in comune, almeno stando ai disegni finora visti)! Ecco perche' sto cercando di fare queste speculazioni, proprio perche' per quello che ora si e' visto dai grafici architetturali una ipotesi come la tua dovrebbe partire da una architettura piuttosto diversa, ed a mio parere non sarebbe per nulla conveniente..
Per quanto riguarda i vantaggi nel mercato server.. Una fantasiosa ipotesi come la mia (quella che ho semplificato al massimo come un "SLI" tra unità int XD) porterebbe vantaggi in qualunque caso.. qualunque! Praticamente potrebbe quasi raddoppiare le prestazioni INT, avendo nel modulo in comune praticamente tutto il resto (fetch, decode, memorie, retires, ecc.). A mio parere sarebbe un esempio di integrazione decisamente piu' spinta, tale da giustificare una nuova architettura, invece ad esempio di prendere quella gia' esistente ed aggiungerci un SMT per avere vantaggi simili rispetto a quello che proponi tu.
edit: abbiamo una gran confusione in mente
L'SMT serve ad utilizzare le unità di calcolo inoperose durante un thread per indirizzare ed eseguirne un'altro.
Risultato di ipc al massimo uguale in single Th con un verosibilmente calo dell'ipc nel caso si utilizzi il core virtuale per l'esecuzione di un'altro th ( a causa delle risorse comuni contese dai due Th e conseguente decadimento dell'ipc)
Reverse htt:
Un core lavora al 100% delle sue possibilità sia in ambiente single th che multi.
Se il secondo core (stiamo parlando dell'unità di esecuzione int) del modulo è inattivo ed è possibile swichtando il thread tra un core e l'altro un aumento dell'ipc di solo il 5% abbiamo come risultato:
2 core 2 th ipc 80
2 core 1 th ipc 50 Rev off
2 core 1 th ipc 52.5 rev on
Con smt abbiamo:
2 core 4 th ipc 120
2 core 2 th ipc 100
2 core 1 th ipc 50 smt off
2 core 1 th ipc =< 50 smt on
Adesso ragioniamo per superfice (valuteremo il tdp uguale nel caso di superfice uguale, tralasciando la superfice occupata dalle l3 ipotizzata idendica per le due architetture)
1 core smt 105
10 core smt 1050
2 core modulo 120
9 moduli 1080
Quindi a parità di superfice avremo 10 core smt contrapposti a 9 moduli.
totale ipc in multi (ipotizzando una scalabilità perfetta) avremo
60 ipc x 10 core = 600 per architettura smt
40 ipc x 18 core = 720 per architettura a modulo
Analizzaziamo l'ipc in single th
Architettura smt =<50
architettura smt off 50
modulo 50
modulo rev htt 52.5
All'aumentare dei th avremo fino a 9 th:
architettura smt 450
architettura modulo 472,5
questa è la massimizzazione delle prestazioni a modulo per singolo th.
Qualora i th siano 10 avremo una rivalsa dell'architettura smt:
architettura smt 500
architettura moduli 420 (4 moduli in modalità rev htt) + 80 (un modulo in modalità dual)
Da adesso in poi all'aumentare dei th un'architettura smt viene sempre superata da una a moduli.
Integrando un smt nel modulo avremo due controindicazioni:
Aumento della superfice del 20-30% a modulo.
abbattimento dell'ipc in multi a causa della contesa di risorse comuni da parte non più di 2 th, bensi 4 .
Quindi ragionando a moduli l'ipc aumenta in maniera maggiore all'aumentare della superfice in multi th e rimane costante sul singolo th.
D'accordo che il singolo core di intel ha un ipc maggiore in single th.
Ma verosimilmente questo avviene perchè si utilizza più superfice per singolo core dei canonici 105 ipotizzati prima (probabilmente avremo un rapporto di 230 a 120 a parità di processo produttivo e questo implica che l'ipc debba essere almeno il doppio per poter competere a livello di superfice
AceGranger
04-10-2010, 14:29
Prova a guardare i test su linux... :)
te lo scrivono pure, l'engine di blender su linux non sfrutta nel modo corretto l'HT dei nuovi 6 core, è programmato male, contando che è pure una Alpha....
paolo.oliva2
04-10-2010, 14:50
te lo scrivono pure, l'engine di blender su linux non sfrutta nel modo corretto l'HT dei nuovi 6 core, è programmato male, contando che è pure una Alpha....
Però, non è che voglio arrivare ad avere ragione e non voglio andare OT.
Se guardi l'i980X, da un TDP dichiarato di 130W, sono stati ipotizzati perfino 157W TDP sotto carico (ci sono parecchi articoli a riguardo). Tu stai partendo come di fatto che a +333MHz rimarrebbero 130W TDP reali con un i990X.
Ora, ripeto senza polemizzare, io reputo molto difficile aumentare di un 10% il clock e nello stesso tempo abbassare di un 20% il TDP, rispetto ad un Magny-C che con un 32nm avrebbe il TDP abbassato dal 40-50% ma lo si vuole vedere solo con un +20% di clock.
Il 990X lo si può considerare come un affinamento del silicio e relativa selezione. Quanto può incidere? il 5%?
Poi se consideri che Intel dal suo primo 45nm HKMG su base 1366 a 3,333GHz quanto è potuto crescere in 2 anni? ZERO. E' migliorata solo nel socket "inferiore". Ma l'i990X non va nel socket inferiore.
edit: abbiamo una gran confusione in mente
L'SMT serve ad utilizzare le unità di calcolo inoperose durante un thread per indirizzare ed eseguirne un'altro.
Risultato di ipc al massimo uguale in single Th con un verosibilmente calo dell'ipc nel caso si utilizzi il core virtuale per l'esecuzione di un'altro th ( a causa delle risorse comuni contese dai due Th e conseguente decadimento dell'ipc)
Reverse htt:
Un core lavora al 100% delle sue possibilità sia in ambiente single th che multi.
Se il secondo core (stiamo parlando dell'unità di esecuzione int) del modulo è inattivo ed è possibile swichtando il thread tra un core e l'altro un aumento dell'ipc di solo il 5% abbiamo come risultato:
2 core 2 th ipc 80
2 core 1 th ipc 50 Rev off
2 core 1 th ipc 52.5 rev on
Con smt abbiamo:
2 core 4 th ipc 120
2 core 2 th ipc 100
2 core 1 th ipc 50 smt off
2 core 1 th ipc =< 50 smt on
Adesso ragioniamo per superfice (valuteremo il tdp uguale nel caso di superfice uguale, tralasciando la superfice occupata dalle l3 ipotizzata idendica per le due architetture)
1 core smt 105
10 core smt 1050
2 core modulo 120
9 moduli 1080
Quindi a parità di superfice avremo 10 core smt contrapposti a 9 moduli.
totale ipc in multi (ipotizzando una scalabilità perfetta) avremo
60 ipc x 10 core = 600 per architettura smt
40 ipc x 18 core = 720 per architettura a modulo
Analizzaziamo l'ipc in single th
Architettura smt =<50
architettura smt off 50
modulo 50
modulo rev htt 52.5
All'aumentare dei th avremo fino a 9 th:
architettura smt 450
architettura modulo 472,5
questa è la massimizzazione delle prestazioni a modulo per singolo th.
Qualora i th siano 10 avremo una rivalsa dell'architettura smt:
architettura smt 500
architettura moduli 420 (4 moduli in modalità rev htt) + 80 (un modulo in modalità dual)
Da adesso in poi all'aumentare dei th un'architettura smt viene sempre superata da una a moduli.
Integrando un smt nel modulo avremo due controindicazioni:
Aumento della superfice del 20-30% a modulo.
abbattimento dell'ipc in multi a causa della contesa di risorse comuni da parte non più di 2 th, bensi 4 .
Quindi ragionando a moduli l'ipc aumenta in maniera maggiore all'aumentare della superfice in multi th e rimane costante sul singolo th.
D'accordo che il singolo core di intel ha un ipc maggiore in single th.
Ma verosimilmente questo avviene perchè si utilizza più superfice per singolo core dei canonici 105 ipotizzati prima (probabilmente avremo un rapporto di 230 a 120 a parità di processo produttivo e questo implica che l'ipc debba essere almeno il doppio per poter competere a livello di superfice
:S mi sa che nessuno dei due sta capendo quello che dice l'altro.. :cry:
Le differenze tra SMT e Reverse Hyperthreading le conosco bene, tant'e' che se leggi vari post addietro vedrai che addirittura ne parlai in lungo ed in largo.
Il mio era semplicemente un discorso ipotetico di come poter fare ad aumentare la capacità di calcolo Intera in single-TH avendo a disposizione una architettura simile a quella che circola nelle varie figure relative a bulldozer.
Basandomi su cio' che amd disse e soprattutto basandomi sulle figure che abbiamo visto ho semplicemente espresso una teoria. Non ho mai detto che sara' sicuramente cosi', ma secondo me potrebbe essere una soluzione davvero interessante, tutto qui.
Io pero' vorrei capire come secondo te (e secondo la tua rispettabilissima teoria) in una architettura modulare quale quella di BD verrebbero gestite in maneira separata per le due unità int le fasi di fetch e decode, basandoti sui disegni architetturali che circolano relativi a BD. Vorrei inoltre capire sempre secondo la tua teoria un'approssimazione dei vantaggi prestazionali che ci sarebbero (oltre ovviamente al silicio "risparmiato"). Secondo te l'ipc in mono-th sarebbe davvero superiore anche solo rispetto a quello del K10?
concordo in pieno comunque con il tuo ragionamento sull'area del silicio. Ma io non stavo mettendo in dubbio nulla di cio'! Capisci che o AMD ci mette davvero il doppio dei cores (cores Intel con SMT Vs. Modulo BD), oppure sarebbe una partita (prestazionalmente parlando) gia' persa in partenza? ..E se fosse cosi', allora perche' la mia ipotesi di un core con una doppia INT unit gestita alternativamente per lo stesso thread sarebbe cosi' impossibile? (visto ceh ripeto, abbiamo UN SOLO FETCH ed un solo DECODE unificato per i due core nello stesso modulo?)
Abbiamo però due int scheduler e questo fa capire che i due core non possono eseguire lo stesso thread. Altrimenti lo scheduler avrebbe dovuto essere uno solo. A quel punto di fatto si sarebbe semplicemente avuta una sola ALU SMT con il doppio delle unità di calcolo.
:S mi sa che nessuno dei due sta capendo quello che dice l'altro.. :cry:
Le differenze tra SMT e Reverse Hyperthreading le conosco bene, tant'e' che se leggi vari post addietro vedrai che addirittura ne parlai in lungo ed in largo.
Il mio era semplicemente un discorso ipotetico di come poter fare ad aumentare la capacità di calcolo Intera in single-TH avendo a disposizione una architettura simile a quella che circola nelle varie figure relative a bulldozer.
Basandomi su cio' che amd disse e soprattutto basandomi sulle figure che abbiamo visto ho semplicemente espresso una teoria. Non ho mai detto che sara' sicuramente cosi', ma secondo me potrebbe essere una soluzione davvero interessante, tutto qui.
Io pero' vorrei capire come secondo te (e secondo la tua rispettabilissima teoria) in una architettura modulare quale quella di BD verrebbero gestite in maneira separata per le due unità int le fasi di fetch e decode, basandoti sui disegni architetturali che circolano relativi a BD. Vorrei inoltre capire sempre secondo la tua teoria un'approssimazione dei vantaggi prestazionali che ci sarebbero (oltre ovviamente al silicio "risparmiato"). Secondo te l'ipc in mono-th sarebbe davvero superiore anche solo rispetto a quello del K10?
concordo in pieno comunque con il tuo ragionamento sull'area del silicio. Ma io non stavo mettendo in dubbio nulla di cio'! Capisci che o AMD ci mette davvero il doppio dei cores (cores Intel con SMT Vs. Modulo BD), oppure sarebbe una partita (prestazionalmente parlando) gia' persa in partenza? ..E se fosse cosi', allora perche' la mia ipotesi di un core con una doppia INT unit gestita alternativamente per lo stesso thread sarebbe cosi' impossibile? (visto ceh ripeto, abbiamo UN SOLO FETCH ed un solo DECODE unificato per i due core nello stesso modulo?)
Le risorse condivise nel modulo derivano dalla teoria della coda unica , cioe' e' piu' efficiente utilizzare delle risorse condivise rispetto ad una duplicazione totale delle unita'.
Se un core INT ha bisogno ad esempio di 3 unita' decode quando metto 2 core INT non ho bisogno del doppio delle unita' decode perche' statisticamente e' molto imporbabile che entrambi i core abbiano bisogno contemporaneamente di tutte le potenzialita' della sezione decode , quindi se con un core INT ho 3 unita' quando ho 2 core INT 5 unita' decode possono svolgere tranqullamente il lavoro.
L'accorpamento in moduli permette appunto di sharare tra due core INT molte unita' senza ricorrere al raddoppio secco , risparmiando cosi' silicio e energia
paolo.oliva2
04-10-2010, 16:47
Abbiamo però due int scheduler e questo fa capire che i due core non possono eseguire lo stesso thread. Altrimenti lo scheduler avrebbe dovuto essere uno solo. A quel punto di fatto si sarebbe semplicemente avuta una sola ALU SMT con il doppio delle unità di calcolo.
Però fammi capire una cosa...
L'INT in più che è condiviso nel modulo deve comunque consentire l'accesso sia dallo scheduler INT A che dallo scheduler INT B.
Nel caso che il modulo debba eseguire 1 TH, ci troveremmo nella condizione che il core A avrebbe a disposizione 2 INT, cioè il doppio della condizione di un core Phenom II, con il core B in "parcheggio".
Se il procio, gestisse gli HT con una logica del tipo 1 HT = 1 modulo per n HT = a n moduli e solo nella condizione n HT > n moduli passerebbe a gestire 1 HT a core e non a modulo, avremmo la seguente condizione:
Il modulo sarebbe come un super-core, quindi con possibilità di incremento IPC. Tra la condizione SMT che sfrutta i tempi "morti" per aumentare l'IPC e la condizione che il modulo offrirebbe più unità di calcolo e quindi più IPC che cambierebbe?
Da una condizione che l'SMT porta da un teorico 95% al 100% di sfruttamento del core, un INT in più io lo vedrei come raddoppio di capacità di calcolo, semplicemente perché l'SMT deve comunque ritornare nello stesso INT, perché di fisico rimane quello, mentre con 2 INT può trovare la pappa pronta perché può saltare da uno all'altro...
Se l'INT in più a modulo non potesse essere utilizzato in parallelo né in logica 1TH e né in logica 2 TH a modulo, AMD che cacchio lo avrebbe messo a fare? Mi pare ovvio che sia in un modo che nell'altro è lì per permettere di risolvere 2 elaborazioni contemporanee con lo scopo di aumentare l'IPC.
A spanna, direi che con 1 TH a modulo le istruzioni INT potrebbero aumentare del 100% (teorico) la velocità di elaborazione, mentre con 2 TH a modulo l'incremento calerebbe al 50%, sempre teorico.
Però fammi capire una cosa...
L'INT in più che è condiviso nel modulo deve comunque consentire l'accesso sia dallo scheduler INT A che dallo scheduler INT B.
Assolutamente no. Due thread possono comunicare tra loro soltanto attraverso la memoria.
Nel caso che il modulo debba eseguire 1 TH, ci troveremmo nella condizione che il core A avrebbe a disposizione 2 INT, cioè il doppio della condizione di un core Phenom II, con il core B in "parcheggio".
No, solo uno per thread. C'è uno scheduler dedicato per ogni core int e quindi per ognuno dei due thread.
paolo.oliva2
04-10-2010, 17:02
Le risorse condivise nel modulo derivano dalla teoria della coda unica , cioe' e' piu' efficiente utilizzare delle risorse condivise rispetto ad una duplicazione totale delle unita'.
Se un core INT ha bisogno ad esempio di 3 unita' decode quando metto 2 core INT non ho bisogno del doppio delle unita' decode perche' statisticamente e' molto imporbabile che entrambi i core abbiano bisogno contemporaneamente di tutte le potenzialita' della sezione decode , quindi se con un core INT ho 3 unita' quando ho 2 core INT 5 unita' decode possono svolgere tranqullamente il lavoro.
L'accorpamento in moduli permette appunto di sharare tra due core INT molte unita' senza ricorrere al raddoppio secco , risparmiando cosi' silicio e energia
Quindi collegando il tuo post con il mio post precedente questo...
Un INT in più condiviso potrebbe in media incrementare del 25% la velocità di calcolo INT in caso di 2 TH a modulo, e del 50% nel caso di 1 TH.
Chiaramente potrebbe andare anche da 0% al 50%-100%, a seconda che vi sia la condizione di 2 INT possano essere eseguiti parallelamente o, caso contrario, 1 ciclo "morto".
Però... tra l'SMT software (Intel) e l'SMT (chiamiamolo così) AMD, la differenza è che comunque, allacciandoci ai post di BJT2, la condizione di più calcoli in contemporanea sarebbe nettamente a favore di AMD.
paolo.oliva2
04-10-2010, 17:03
Assolutamente no. Due thread possono comunicare tra loro soltanto attraverso la memoria.
No, solo uno per thread. C'è uno scheduler dedicato per ogni core int e quindi per ognuno dei due thread.
Non mi torna... :confused: All'ora per te quell'INT in più che ci fosse o meno sarebbe uguale.
Ma se nel modulo ci sono 1 INT a core (2 totali) + 1 INT condiviso... gli scheduler rimangono 2 o sono 3?
Se sono 2... lo scheduler potrebbe gestire 2 INT, oppure se sono 3 comunque 2 scheduler dovrebbero o dialogare o essere parallelizzati.
Se AMD lo ha messo, una funzione in più la deve comunque fare.
Non mi torna... :confused: All'ora per te quell'INT in più che ci fosse o meno sarebbe uguale.
E perché ? Non capisco cosa intendi. A livello di singolo thread uno dei due core INT è come se non esistesse. Con due thread un core INT processa un thread e un altro core INT processa un secondo thread. Se non ci fosse come potrebbe processare il secondo thread ?
Le risorse condivise nel modulo derivano dalla teoria della coda unica , cioe' e' piu' efficiente utilizzare delle risorse condivise rispetto ad una duplicazione totale delle unita'.
Se un core INT ha bisogno ad esempio di 3 unita' decode quando metto 2 core INT non ho bisogno del doppio delle unita' decode perche' statisticamente e' molto imporbabile che entrambi i core abbiano bisogno contemporaneamente di tutte le potenzialita' della sezione decode , quindi se con un core INT ho 3 unita' quando ho 2 core INT 5 unita' decode possono svolgere tranqullamente il lavoro.
L'accorpamento in moduli permette appunto di sharare tra due core INT molte unita' senza ricorrere al raddoppio secco , risparmiando cosi' silicio e energia
beh si.. e' sicuramente tutto vero per quanto riguarda il risparmio di silicio e di energia.. ma per quanto riguarda le prestazioni, se cosi' fosse, dove sarebbe l'aumento di IPC? Vedendo i grafici architetturali si potrebbe supporre addirittura un ipc inferiore per core rispetto al k10! Figuriamoci un BDx8 (4moduli) cosi' strutturato quante ne prenderebbe sempre e comunque rispetto ad un SB x10!!! Sarebbe una situazione catastroficamente impari, talmente drammatica che quella attuale sarebbe fantastica, in confronto!
Ci DEVE essere qualcos'altro sotto, ne sono convinto.
Conta poi che se avessi un fetch e ed un decode "comune" tra i due core ma in grado di "servire" entrambi i cores contemporaneamente avresti da gestire gli indirizzi ed i threads in maniera separata, il che vorrebbe dire avere una complessita' architetturale ed algoritmica notevole. Non sarebbe allora piu' facile (a livello di implementazione) fare un singolo core con un unico scheduler ma con 2 unita' intere a cui smistare alternativamente le micro-ops, per poi mettere tutto insieme in un'unica retire-unit? Si avrebbe IL DOPPIO di prestazione intera in mono-th, si avrebbe una superficie del modulo ancora piu' piccola (sarebbe praticamente tutto condiviso), e quindi si potrebbe senza problemi fare ALMENO un 6 moduli desktop, no?
Non mi quadra: c'e' assolutamente qualcosa che non va nelle info che abbiamo, secondo me.
Abbiamo però due int scheduler e questo fa capire che i due core non possono eseguire lo stesso thread. Altrimenti lo scheduler avrebbe dovuto essere uno solo. A quel punto di fatto si sarebbe semplicemente avuta una sola ALU SMT con il doppio delle unità di calcolo.
beh, sugli scheduler hai ragione, cosi' come le retire che anch'esse sono separate (come avevo gia' notato)..
vabbe' tutta questa nuova architettura "solamente" (si fa per dire, eh..) per risparmiare silicio e rischiare di avere prestazioni addirittura peggiori del k10 in monocore? bah, vedremo.. :confused:
Io rimango della duplice teoria che o AMD confrontera' core vs modulo (prendendole ancora di piu' in mono-TH ma rischiando di essere forse leggermente superiore in multi), oppure ogni modulo sara' di fatto un core con una doppia unita' int operativa in grado quindi di processare un solo thread alla volta (potendo virtualmente essere superiore in ogni ambito), oppure.. se non fosse nessuno dei due casi praticamente avrebbe gia' virtualmente perso in partenza, in ogni ambito prestazionale, secondo me. Visto che non penso che i loro progettisti siano assolutamente degli sprovveduti, deve sicuramente esserci qualcosa sotto.
ok, mi zittisco qui. :fagiano:
vedremo.. :oink:
vabbe' tutta questa nuova architettura "solamente" (si fa per dire, eh..) per risparmiare silicio e rischiare di avere prestazioni addirittura peggiori del k10 in monocore? bah, vedremo.. :confused:
Come farebbero ad essere peggiori con 400-600 Mhz in più a parità di processo produttivo e TDP ?
vabbe' tutta questa nuova architettura "solamente" (si fa per dire, eh..) per risparmiare silicio e rischiare di avere prestazioni addirittura peggiori del k10 in monocore? bah, vedremo..
Secondo quanto emerso finora, dovrebbero essere superiori anche senza considerare la differenza di frequenza, perchè nonostante la condivisione, le migliorie architetturali ci sono e sono evidenti.
Se poi come ipotizzato BD dovesse usare, nel caso di pochi thread (intendendo per pochi, non più del numero dei moduli) ogni modulo per processare un singolo thread, allora anche il problema del mono-thread non sussisterebbe, dato che ogni core non dovrebbe condividere più le risorse del modulo ma averle tutte a disposizione (oltretutto sovrabbondanti, dato che pensate per gestire due core int).
Come farebbero ad essere peggiori con 400-600 Mhz in più a parità di processo produttivo e TDP ?
non saprei, davvero.. Progettare una architettura nuova partendo da zero non è uno scherzo: servono risorse, SOLDI, tempo (amd ci lavora da tanti anni a bulldozer). Tutto cio' per avere una architettura potenzialmente con MENO ipc della precedente (a parità di clock) che pero' "recupera" un po' per quei 600Mhz in piu'?
Bd 4Moduli (8cores) Vs SB 10 Cores + ht?
Sinceramente spero davvero non sia cosi', altrimenti vorrebbe dire senza ombra di dubbio che AMD si sarebbe definitivamente rassegnata ad essere eterna seconda (e che perde pure terreno di generazione in generazione) per quello che riguarda la battaglia prestazionale con Intel.. :muro:
:S mi sa che nessuno dei due sta capendo quello che dice l'altro.. :cry:
Le differenze tra SMT e Reverse Hyperthreading le conosco bene, tant'e' che se leggi vari post addietro vedrai che addirittura ne parlai in lungo ed in largo.
Il mio era semplicemente un discorso ipotetico di come poter fare ad aumentare la capacità di calcolo Intera in single-TH avendo a disposizione una architettura simile a quella che circola nelle varie figure relative a bulldozer.
Basandomi su cio' che amd disse e soprattutto basandomi sulle figure che abbiamo visto ho semplicemente espresso una teoria. Non ho mai detto che sara' sicuramente cosi', ma secondo me potrebbe essere una soluzione davvero interessante, tutto qui.
Io pero' vorrei capire come secondo te (e secondo la tua rispettabilissima teoria) in una architettura modulare quale quella di BD verrebbero gestite in maneira separata per le due unità int le fasi di fetch e decode, basandoti sui disegni architetturali che circolano relativi a BD. Vorrei inoltre capire sempre secondo la tua teoria un'approssimazione dei vantaggi prestazionali che ci sarebbero (oltre ovviamente al silicio "risparmiato"). Secondo te l'ipc in mono-th sarebbe davvero superiore anche solo rispetto a quello del K10?
concordo in pieno comunque con il tuo ragionamento sull'area del silicio. Ma io non stavo mettendo in dubbio nulla di cio'! Capisci che o AMD ci mette davvero il doppio dei cores (cores Intel con SMT Vs. Modulo BD), oppure sarebbe una partita (prestazionalmente parlando) gia' persa in partenza? ..E se fosse cosi', allora perche' la mia ipotesi di un core con una doppia INT unit gestita alternativamente per lo stesso thread sarebbe cosi' impossibile? (visto ceh ripeto, abbiamo UN SOLO FETCH ed un solo DECODE unificato per i due core nello stesso modulo?)
Partendo dal presupposto che l'ipc su singolo core sia almeno uguale a quello del k10 (ma come spiegato da bjt2 dovrebbe essere superiore) la mia ipotesi non è basata su come aumentare l'ipc potendo processare più dati contemporaneamente, semplicemente ipotizzo la possibilità di poter traslare l'indirizzo logico sul core inattivo nel momento che il core che stia eseguendo il th abbia bisogno di svuotare le pipeline e la cache l1 in caso di salto di codice errato.
Praticamente il thread rimane sempre uno solo e dato che Fech e Decode possono accedere indistintamente ad una qualsiasi delle due int passare i dati da elaborare all'unità che sta a spasso senza attendere che scuoti la cache e le pipeline, di conseguenza si ridurrebbero i cicli a vuoto in alcune condizioni.
Che questo possa essere realizzabile (come spero) o che tipo di incremento porti in single th (1, oppure il 20%) non importa, nel caso fosse possibile si risparmierebbe comunque sui cicli a vuoto aumentando i cicli utili e di conseguenza l'ipc.
non saprei, davvero.. Progettare una architettura nuova partendo da zero non è uno scherzo: servono risorse, SOLDI, tempo (amd ci lavora da tanti anni a bulldozer). Tutto cio' per avere una architettura potenzialmente con MENO ipc della precedente (a parità di clock) che pero' "recupera" un po' per quei 600Mhz in piu'?
Bd 4Moduli (8cores) Vs SB 10 Cores + ht?
Sinceramente spero davvero non sia cosi', altrimenti vorrebbe dire senza ombra di dubbio che AMD si sarebbe definitivamente rassegnata ad essere eterna seconda (e che perde pure terreno di generazione in generazione) per quello che riguarda la battaglia prestazionale con Intel.. :muro:
Credo che AMD abbia maggior possibilità di produrre per prima un 8 moduli che intel un decacore.
non saprei, davvero.. Progettare una architettura nuova partendo da zero non è uno scherzo: servono risorse, SOLDI, tempo (amd ci lavora da tanti anni a bulldozer). Tutto cio' per avere una architettura potenzialmente con MENO ipc della precedente (a parità di clock) che pero' "recupera" un po' per quei 600Mhz in piu'?
L'IPC non è il solo parametro per valutare le prestazioni, ma conta anche la frequenza a parità di TDP. Fermo restando che credo che l'IPC sarà maggiore.
L'IPC non è il solo parametro per valutare le prestazioni, ma conta anche la frequenza a parità di TDP. Fermo restando che credo che l'IPC sarà maggiore.
Protremmo parlare di IPS per la valutazione prestazionale ed IPC per valutare l'efficenza architetturale (anche se quest'ultima andrebbe misurata in gflop/watt)
Partendo dal presupposto che l'ipc su singolo core sia almeno uguale a quello del k10 (ma come spiegato da bjt2 dovrebbe essere superiore) la mia ipotesi non è basata su come aumentare l'ipc potendo processare più dati contemporaneamente, semplicemente ipotizzo la possibilità di poter traslare l'indirizzo logico sul core inattivo nel momento che il core che stia eseguendo il th abbia bisogno di svuotare le pipeline e la cache l1 in caso di salto di codice errato.
Praticamente il thread rimane sempre uno solo e dato che Fech e Decode possono accedere indistintamente ad una qualsiasi delle due int passare i dati da elaborare all'unità che sta a spasso senza attendere che scuoti la cache e le pipeline, di conseguenza si ridurrebbero i cicli a vuoto in alcune condizioni.
Che questo possa essere realizzabile (come spero) o che tipo di incremento porti in single th (1, oppure il 20%) non importa, nel caso fosse possibile si risparmierebbe comunque sui cicli a vuoto aumentando i cicli utili e di conseguenza l'ipc.
Questo credo che si possa fare senza problemi, ma non capisco quali vantaggi possa portare iniziare a processare le nuove istruzioni sul core libero o su quello appena stallato. La cache dL1 deve comunque ricaricare i dati, visto che non è condivisa. La pipeline stallata implica alcuni cicli di attesa prima della terminazione della prima istruzione del nuovo ramo, ma comporterebbe la stessa identica attesa sull'altro core.
L'unica operazione da fare in più sarebbe quella di invalidare la dL1, ma non mi sembra un così grande spreco. Dopo tutto ci sarà un circuito per invalidare tutti i bit V contemporaneamente.
Secondo quanto emerso finora, dovrebbero essere superiori anche senza considerare la differenza di frequenza, perchè nonostante la condivisione, le migliorie architetturali ci sono e sono evidenti.
Se poi come ipotizzato BD dovesse usare, nel caso di pochi thread (intendendo per pochi, non più del numero dei moduli) ogni modulo per processare un singolo thread, allora anche il problema del mono-thread non sussisterebbe, dato che ogni core non dovrebbe condividere più le risorse del modulo ma averle tutte a disposizione (oltretutto sovrabbondanti, dato che pensate per gestire due core int).
si ma nel caso usasse un modulo (quindi 2 cores) per processare un SINGOLO thread.. si tratterebbe di un qualcosa paragonabile proprio ad un reverse Hyperthreading!!!.. ed e' quello che sto cercando di dire da 12 post a questa parte! XD
Poi che lo faccia usando il secondo core per calcolarsi i branch, che lo faccia secondo uno schema "simil-SLI" o che lo faccia secondo qualunque altra tecnica al livello sostanziale non cambia la storia (ed e' qui che volevo arrivare.. il resto erano solo ipotesi riguardanti il fatto di come sarebbe stato meglio prestazionalmente parlando gestire un reverse-HT).
AMD deve avere qualcosa in serbo, questo e' sicuro! La architettura cosi' come e' stata presentata fino ad ora da sola non sembrerebbe prestazionalmente parlando nulla di rilevante, eppure Intel sta addirittura avendo un certo timore e cerca di anticipare i 22nm, annunciando gia' un SB x10.
C'e' sicuramente qualcosa di piu': LARGO ALLE IPOTESI! :cool:
Ora ritorno con le mie domande (e lasciate perdere le ipotesi che fino ad ora ho fatto estendendo questa possibilità). Un reverse-HT come risposta prestazionale si tratterebbe di fantascienza? Se cosi' non fosse come si potrebbe immaginare una implementazione di reverse-HT partendo da una architettura modulare di questo tipo? quale sarebbe secondo voi la modalità piu' efficiente da ogni punto di vista (prestazione, silicio, consumi)?
Fin'ora ho solo espresso appunto la mia personale ipotesi (basata appunto sulla ripartizione alternata delle micro-ops sui due moduli INT) riguardo a quella che sarebbe a mio parere l'implementazione migliore per un reverse-HT, tutto qui! ;)
I discorsi sull'SMT e sul silicio sono tutti giusti, ma molto poco inerenti rispetto a quello di cui stavo parlando, ovvero quale sia il "possibile segreto" che AMD sta celando dietro a tutto cio'.. :S (e qualcosa deve esserci per forza)
O.T. Azz, non solo non ho rispettato la mia promessa del post precedente, ma mi sa che sto scrivendo pure troppo :doh:
Questo credo che si possa fare senza problemi, ma non capisco quali vantaggi possa portare iniziare a processare le nuove istruzioni sul core libero o su quello appena stallato. La cache dL1 deve comunque ricaricare i dati, visto che non è condivisa. La pipeline stallata implica alcuni cicli di attesa prima della terminazione della prima istruzione del nuovo ramo, ma comporterebbe la stessa identica attesa sull'altro core.
L'unica operazione da fare in più sarebbe quella di invalidare la dL1, ma non mi sembra un così grande spreco. Dopo tutto ci sarà un circuito per invalidare tutti i bit V contemporaneamente.
Ho scritto che non so che tipo di guadagno ci possa essere, ma essendo la cache esclusiva l'unità accederebbe direttamente alla l2.
La l1 data con il core in idle dovrebbe gia essere vuota.
Se tutta questa manovra porterebbe ad abbassare il peso di un prefetch fault da 20 a 19 cicli non credi che sia tutto grasso che cola?
si ma nel caso usasse un modulo (quindi 2 cores) per processare un SINGOLO thread.. si tratterebbe di un qualcosa paragonabile proprio ad un reverse Hyperthreading!!!.. ed e' quello che sto cercando di dire da 12 post a questa parte! XD
Oddio... per me quanto emerso finora per BD promette molto bene, altro che "prestazionalmente parlando nulla di rilevante".
Ma tornando al discorso del "reverse HT", anche io qualche tempo fa mi ero chiesto se il modulo fosse in grado di usare le "alu" (in senso generale) di entrambe le unità int per generare un "super core" da 8 alu (le 4 del primo core int e le 4 del secondo core int).
La risposta era stata abbastanza precisa: inutile fare un core con millemila alu, perchè statisticamente se ne sfruttano insieme al più 3 o 4.
Scartiamo quindi l'ipotesi del "supercore", scartiamo quella dello "sli", dato che nelle GPU il codice è altamente parallelo mentre quello di un'elaborazione monothread no, scartiamo l'ipotesi dell'uso del secondo core in caso di predizione sbagliata per quanto elencato da Cionci qui sopra.
Morale della favola: se il codice è poco parallelizzabile, c'è poco da fare: aggiungere potenza bruta non aiuta, ma bisogna muoversi in altre direzioni.
paolo.oliva2
04-10-2010, 19:40
E perché ? Non capisco cosa intendi. A livello di singolo thread uno dei due core INT è come se non esistesse.
Scusa... sarò duro ma non capisco.
1 core = 1 INT (ottica Phenom II)
Modulo = 2 core = 3 INT (BD).
Mi sembra chiaro che non sto parlando dell'INT dedicato esclusivamente all'altro core, ma dell'INT condiviso.
Con due thread un core INT processa un thread e un altro core INT processa un secondo thread. Se non ci fosse come potrebbe processare il secondo thread ?
E il 3° INT, il modulo processa 3 TH?
Quindi se riporti "A livello di singolo thread uno dei due core INT è come se non esistesse" è la stessa cosa che a livello di 2TH il 3° INT è come se non esistesse.
Se con 2 TH il 3° INT viene usato (altrimenti cosa le metterebbero a fare?) non capisco la diffrerenza.
Con la stessa logica con la quale in base a 2 TH viene usato il 3° INT, non vedo il perché con 1 TH dovrebbe essere usato solo 1 INT e non utilizzato l'INT condiviso...
Rifacendomi a quanto postato da Bjt2, il 3° INT dovrebbe essere sfruttato sia che il modulo sia con 1 TH che con 2 TH (come posta Bjt2, infatti, le operazioni eseguite a parità di clock sarebbero superiori sia nei confronti di un Phenom II che nei confronti dell'i7).
Se il 3° incrementa la velocità di esecuzione, tale incremento lo si avrebbe maggiore in modalità 1 TH, perché con 2 TH sarebbe condiviso e potrebbe essere "occupato".
E il 3° INT, mica ha 3 TH.
3° ? Quale ?
paolo.oliva2
04-10-2010, 20:00
3° ? Quale ?
Il Modulo BD ha 3 INT?
1 per core (esclusivo) = 2 core = 2 INT
+ un 3° INT condiviso.
Il Modulo BD ha 3 INT?
1 per core (esclusivo) = 2 core = 2 INT
+ un 3° INT condiviso.
Non ha 3 core int...
paolo.oliva2
04-10-2010, 20:06
Grrrr... allora ho preso un abbaglio.... :doh: .
Ma non si diceva all'inizio che c'era un'unità INT condivisa in più tra i 2 core?
Grrrr... allora ho preso un abbaglio.... :doh: .
Ma non si diceva all'inizio che c'era un'unità INT condivisa in più tra i 2 core?
No, c'è l'unità per le istruzioni vettoriali sugli interi, ma è nella FPU.
non saprei, davvero.. Progettare una architettura nuova partendo da zero non è uno scherzo: servono risorse, SOLDI, tempo (amd ci lavora da tanti anni a bulldozer). Tutto cio' per avere una architettura potenzialmente con MENO ipc della precedente (a parità di clock) che pero' "recupera" un po' per quei 600Mhz in piu'?
Bd 4Moduli (8cores) Vs SB 10 Cores + ht?
Sinceramente spero davvero non sia cosi', altrimenti vorrebbe dire senza ombra di dubbio che AMD si sarebbe definitivamente rassegnata ad essere eterna seconda (e che perde pure terreno di generazione in generazione) per quello che riguarda la battaglia prestazionale con Intel.. :muro:
Ciao
Dunque posto una frase di un ing amd:
http://www.semiaccurate.com/forums/showthread.php?t=3443&page=2
What you're looking at today is at a processor through a terrible telescope and trying to make determinations on how it might perform. Obviously, you can tell that the planet is red and several obvious other cues, but often times the little details are what is required to make a proper performance determination.
As JF as already pointed out, you only see the big picture. The little details are extremely important, and IMHO, the most important.
There's several big big cards not shown yet
Dunque ti faccio un esempio terra terra poichè io non sono esperto in queste due cose:
I c2q hanno 4 alu , i PhII ne hanno 3, hai mai visto un c2q che vada il 33% in più rispetto ad un phII? Io dico che hanno lo stesso ipc in molte applicazioni con alcune che privilegiano i c2q ed altre i PhII. BD avrà il 33% in meno di alu del k10, andrà meno?
No, ci sono svariati motivi:
K10 retirement buffer di 3mop, BD 4 mop, 33% teorico di vantaggio sulle mop ritirate (mop= uop matematico\logico più op di memoria o load\store)
Inoltre il 60% di istruzioni x86 contiene op load e store nel rapporto di 2:1 tra di loro, il k10 può eseguire queste istruzioni in modo quasi in order, ovvero con poche possibilità di esecuzione OoO, ad es dopo 3 cicli la alu 0 è pronta a sfornare un Imul, toh, manca l'operando, pipeline stallata poichè il processore non ha precaricato gli operandi ma ha eseguito le op di memoria quasi in ordine del codice che ha eseguito. Con Bd le memory pipelines sono completamente OoO
ed altri ancora di cui alcuni postati nelle varie slides. come prefetcher migliorati ed aggressivi nuovi branch predictors, scheduler più efficiente, caches più efficienti (si spera)
comunque io non sto parlando di unita' ALU.. la mia ipotesi si basa su una logica di parallellizzazione delle micro-ops (chiamiamoli "pacchetti di micro-ops, se preferite) sulle due unità INT (quindi sulle alu della unità).. proprio come in un crossfire o in un SLI. Il discorso delle istruzioni parallelizzate non c'entra:
se do ad una sola unita' l'istruzione 1, poi la 2, poi la 3 e poi la 4.. teoricamente ricevero' in output le istruzioni in questo ordine (al max le riordino).
Se do alla prima unita' l'istruzione 1, e mentre questa elabora grazie al fetch potente ed al decode potente riesco ad avere gia' pronta l'istruzione 2, potro' darla alla seconda unità. quando la prima unita' sara' pronta a ricevere un'altra istruzione io la avro' pronta, per poi dare nel mentre dell'elaborazione l'istruzione 4 alla seconda unità.
Supponendo le unita' di eguale potenza elaborativa, allora l'ordine di output della seconda opzione sarebbe lo stesso della pirma, con pero' la particolarità di poter eseguire le 4 istruzioni in un tempo minore.
E' per questo che mi veniva in mente l'esempio dell'SLI.
Ovviamente lo scheduler e la retire dovrebbero essere unificate..
Magari sono stupidate, ma secondo me potrebbe essere possibile.. Potrebbe essere una soluzione per aumentare di molto la potenza sugli interi, no?
vabbe', in fondo e' solamente una ipotesi probabilmente strampalata, quindi vedremo quando avremo qualcosa di piu' certo riguardante l'architettura! :)
comunque io non sto parlando di unita' ALU.. la mia ipotesi si basa su una logica di parallellizzazione delle micro-ops (chiamiamoli "pacchetti di micro-ops, se preferite) sulle due unità INT (quindi sulle alu della unità).. proprio come in un crossfire o in un SLI. Il discorso delle istruzioni parallelizzate non c'entra:
se do ad una sola unita' l'istruzione 1, poi la 2, poi la 3 e poi la 4.. teoricamente ricevero' in output le istruzioni in questo ordine (al max le riordino).
Se do alla prima unita' l'istruzione 1, e mentre questa elabora grazie al fetch potente ed al decode potente riesco ad avere gia' pronta l'istruzione 2, potro' darla alla seconda unità. quando la prima unita' sara' pronta a ricevere un'altra istruzione io la avro' pronta, per poi dare nel mentre dell'elaborazione l'istruzione 4 alla seconda unità.
Supponendo le unita' di eguale potenza elaborativa, allora l'ordine di output della seconda opzione sarebbe lo stesso della pirma, con pero' la particolarità di poter eseguire le 4 istruzioni in un tempo minore.
E' per questo che mi veniva in mente l'esempio dell'SLI.
Ovviamente lo scheduler e la retire dovrebbero essere unificate..
Magari sono stupidate, ma secondo me potrebbe essere possibile.. Potrebbe essere una soluzione per aumentare di molto la potenza sugli interi, no?
vabbe', in fondo e' solamente una ipotesi probabilmente strampalata, quindi vedremo quando avremo qualcosa di piu' certo riguardante l'architettura! :)
Ciao
Scusami se non potrò dare una risposta esaustiva, ma il mio schifobook con atom ha finito la batteria.
Stai facendo un pò di confusione, quello che descrivi gia avviene dai tempi del Pii\p pro con la logica OoO e la fowarding network
Ciao
Scusami se non potrò dare una risposta esaustiva, ma il mio schifobook con atom ha finito la batteria.
Stai facendo un pò di confusione, quello che descrivi gia avviene dai tempi del Pii\p pro con la logica OoO e la fowarding network
no, ma io non intendo tirare in ballo i discorsi della logica di tipo Out of order.. So che normalmente le istruzioni vengono eseguite in maniera "disordinata", so la funzione delle pipelines.. poi parlavo appunto prima della retire units. Ma non volevo tirare in mezzo la logica OoO, ormai scontata nei moderni processori: il mio esempio serviva solamente a far capire che una esecuzione di questo tipo non presenterebbe difficolta' e dipendenze superiori a quelle relative ad una esecuzione sempre OoO ma fatta con solamente una unità intera (e le sue relative ALU).
Intendevo dire che il flusso di dati sarebbe in entrambi i casi il medesimo, semplicemente raddoppiato, a patto che i decoders riescano ad essere veloci abbastanza per "dare da mangiare" ad entrambe le unità. Il vero problema infatti sarebbe proprio li': bisognerebbe decodificare al doppio della velocità, altrimenti sarebbe appunto totalmente inutile..
vabbe', mi fermo qui, sto andando forse troppo oltre con queste appunto fantasiose ipotesi, e sicuramente sto sbagliando qualcosa :)
Se do alla prima unita' l'istruzione 1, e mentre questa elabora grazie al fetch potente ed al decode potente riesco ad avere gia' pronta l'istruzione 2, potro' darla alla seconda unità. quando la prima unita' sara' pronta a ricevere un'altra istruzione io la avro' pronta, per poi dare nel mentre dell'elaborazione l'istruzione 4 alla seconda unità.
Supponendo le unita' di eguale potenza elaborativa, allora l'ordine di output della seconda opzione sarebbe lo stesso della pirma, con pero' la particolarità di poter eseguire le 4 istruzioni in un tempo minore.
E' per questo che mi veniva in mente l'esempio dell'SLI.
Ovviamente lo scheduler e la retire dovrebbero essere unificate..
E' quello che fanno dal momento in cui ci sono unità di esecuzione multiple all'interno della stessa FPU o ALU. Quindi questo avviene già. Ed è proprio lo scheduler a gestire l'allocazione delle unità di esecuzione in modo da ottenere un throughput più alto possibile. Per questo prima ti dicevo che se i due core int avessero avuto lo stesso scheduler allora sarebbe stata come una grande ALU con il doppio delle unità di esecuzione.
Certo, sarebbe bello ma...lo scheduler avrebbe dovuto gestire due thread contemporaneamente in SMT (possibile, ma non è certo agevole visto l'instruction set), la cache dL1 avrebbe dovuto essere unificata (con tutti i problemi che ne conseguono in caso di stallo di un solo thread), il retirement sarebbe dovuto essere unificato.
Senza contare che se non aumentano ulteriormente le unità di esecuzione della ALU evidentemente c'è un limite pratico al numero di unità che possono essere sfruttate contemporaneamente con istruzioni x86. Quindi probabilmente questa ALU non porterebbe ad effettivi miglioramenti rispetto alle due separate.
no, ma io non intendo tirare in ballo i discorsi della logica di tipo Out of order.. So che normalmente le istruzioni vengono eseguite in maniera "disordinata", so la funzione delle pipelines.. poi parlavo appunto prima della retire units. Ma non volevo tirare in mezzo la logica OoO, ormai scontata nei moderni processori: il mio esempio serviva solamente a far capire che una esecuzione di questo tipo non presenterebbe difficolta' e dipendenze superiori a quelle relative ad una esecuzione sempre OoO ma fatta con solamente una unità intera (e le sue relative ALU).
Intendevo dire che il flusso di dati sarebbe in entrambi i casi il medesimo, semplicemente raddoppiato, a patto che i decoders riescano ad essere veloci abbastanza per "dare da mangiare" ad entrambe le unità. Il vero problema infatti sarebbe proprio li': bisognerebbe decodificare al doppio della velocità, altrimenti sarebbe appunto totalmente inutile..
vabbe', mi fermo qui, sto andando forse troppo oltre con queste appunto fantasiose ipotesi, e sicuramente sto sbagliando qualcosa :)
I decoders credo che ce la possano fare.
Quello che mi sembra "strano" è:
Un th è codificato per avere un flusso dati ottimizzato per 2-3 pipeline.
Ammettendo che la logica interna possa far vedere il secondo int come un'estensione del primo l'ipc si può migliore utilizzando questa capacità di calcolo, oppure rimarrebbe inoperoso?
Il guadagno derivante dall'utilizzare due unità di calcolo separate basterebbe a compensare l'innalzamento della latenza derivante dalla necessità di leggere e scrivere nella L2?
Certo che se la fpu possa operare sia in modalità 1x256, 2x128 e 4x64 non vedo perchè gli int (se opportunamente strutturati) non possano venire usati in parallelo.
Certo che se la fpu possa operare sia in modalità 1x256, 2x128 e 4x64 non vedo perchè gli int (se opportunamente strutturati) non possano venire usati in parallelo.
Per la FPU la cosa è molto diversa. Questo perché opera su istruzioni vettoriali. Quindi su una sequenza di dati (solitamente maggiore di 4) a 64, 128 o 256 bit. Non c'è alcun conflitto da risolvere fra le varie unità di calcolo sulle istruzioni SIMD, quindi è molto più semplice: si allocano quante più unità possibili e si cerca di terminare l'istruzione vettoriale nel minor tempo possibile. Ovviamente nel caso di un solo thread. Tra l'altro le unità FMAC sono appunto solo per istruzioni SIMD. Le istruzioni FP legacy sono eseguite dalle altre unità.
Nel caso di due thread in SMT è la politica dello scheduler a decidere come assegnare le unità di calcolo fra i vari thread.
E' quello che fanno dal momento in cui ci sono unità di esecuzione multiple all'interno della stessa FPU o ALU. Quindi questo avviene già. Ed è proprio lo scheduler a gestire l'allocazione delle unità di esecuzione in modo da ottenere un throughput più alto possibile. Per questo prima ti dicevo che se i due core int avessero avuto lo stesso scheduler allora sarebbe stata come una grande ALU con il doppio delle unità di esecuzione.
Certo, sarebbe bello ma...lo scheduler avrebbe dovuto gestire due thread contemporaneamente in SMT (possibile, ma non è certo agevole visto l'instruction set), la cache dL1 avrebbe dovuto essere unificata (con tutti i problemi che ne conseguono in caso di stallo di un solo thread), il retirement sarebbe dovuto essere unificato.
Senza contare che se non aumentano ulteriormente le unità di esecuzione della ALU evidentemente c'è un limite pratico al numero di unità che possono essere sfruttate contemporaneamente con istruzioni x86. Quindi probabilmente questa ALU non porterebbe ad effettivi miglioramenti rispetto alle due separate.
esatto! infatti e' quello che intendevo quando dicevo che con un'ipotesi del genere sarebbe davvero tutto condiviso (e dai grafici infatti non dovrebbe essere cosi', in quanto gia' solo gli scheduler e le retire sono separate, ma il fatto che il fetch ed il decode sia unico non quadra comunque)!
Riguardo a quello che gia' succede, sono d'accordo nel senso che ogni INT unit avendo a disposizione varie ALU lavora gia' in modo parallelizzato.. ma immagina delle sorte di "pacchetti" di istruzioni mandate in maniera alternata.. pensi davvero in un caso del genere non possa essere possibile un guadagno prestazionale?
esatto! infatti e' quello che intendevo quando dicevo che con un'ipotesi del genere sarebbe davvero tutto condiviso (e dai grafici infatti non dovrebbe essere cosi', in quanto gia' solo gli scheduler e le retire sono separate, ma il fatto che il fetch ed il decode sia unico non quadra comunque)!
Riguardo a quello che gia' succede, sono d'accordo nel senso che ogni INT unit avendo a disposizione varie ALU lavora gia' in modo parallelizzato.. ma immagina delle sorte di "pacchetti" di istruzioni mandate in maniera alternata.. pensi davvero in un caso del genere non possa essere possibile un guadagno prestazionale?
Ragionando sul raddoppio delle pipeline:
Se fosse bastato raddoppiare le pipeline dell'alu (con tutto quello che c'è dietro) avremo un aumento della superfice per core al massimo del 20% con un ipc teorico del doppio.
Consideriamo anche il raddoppio delle cache L1 e L2 sarebbe stato, per i produttori di cpu, più agevole questa operazione che puntare al multi core per avere un raddoppio dell'ipc con un risparmio della superfice di almeno il 60% rispetto ad un dual.
Ma se così non è significa che oltre un certo numero di pipeline (3) il guadagno di ipc non è proporzionale al costo su silicio.
Io continuo a rimanere dell'idea che il massimo che si possa fare per aumentare l'ipc del singolo th in un modulo sia quello di poter ridurre (se possibile) i cicli di attesa in caso di stallo delle pipeline swichando l'alu (e credo che al massimo si possa raggiungere il 5%)
Ragionando sul raddoppio delle pipeline:
Se fosse bastato raddoppiare le pipeline dell'alu (con tutto quello che c'è dietro) avremo un aumento della superfice per core al massimo del 20% con un ipc teorico del doppio.
Consideriamo anche il raddoppio delle cache L1 e L2 sarebbe stato, per i produttori di cpu, più agevole questa operazione che puntare al multi core per avere un raddoppio dell'ipc con un risparmio della superfice di almeno il 60% rispetto ad un dual.
Ma se così non è significa che oltre un certo numero di pipeline (3) il guadagno di ipc non è proporzionale al costo su silicio.
Io continuo a rimanere dell'idea che il massimo che si possa fare per aumentare l'ipc del singolo th in un modulo sia quello di poter ridurre (se possibile) i cicli di attesa in caso di stallo delle pipeline swichando l'alu (e credo che al massimo si possa raggiungere il 5%)
Beh, ma allora come giustifichi ad esempio una differenza sul calcolo intero cosi' marcata tra Intel ed AMD? Secondo il tuo ragionamento dovrebbero essere pressocchè identiche in termini di potenza di calcolo..
Comunque, in effetti non sarebbe proprio tutto "rosa e fiori".. Si risparmierebbe tantissimo silicio e si avrebbero prestazioni teoricamente doppie sugli interi, ma una architettura di questo tipo sarebbe piuttosto complessa da gestire, soprattutto nella fase di decode. Bisogna creare due veri e propri "flussi" di pacchetti di istruzioni cercando di far si che i pacchetti del primo flusso non siano in dipendenza sequenziale rispetto ai pacchetti del secondo flusso. Praticamente bisognerebbe avere una sorta di secondo branch prediction sui due rami, oltre che quello "classico" sulle istruzioni ed quindi un ulteriore algoritmo di ordinamento in base alle dipendenze sui flussi di pacchetti.. non sarebbe uno scherzo, senza contare che servirebbero logiche di fetch, decode, scheduling e retire che siano decisamente piu' veloci (e magari complesse) del normale.. o sbaglio? :O
Beh, ma allora come giustifichi ad esempio una differenza sul calcolo intero cosi' marcata tra Intel ed AMD? Secondo il tuo ragionamento dovrebbero essere pressocchè identiche in termini di potenza di calcolo..
edit
per la parte editata questo gia avviene con il multicore.
Sulla prima parte piuttosto come giustifichi l'aumento di ipc in s-th passando da 4 pipeline del c2d alle 3 di I7 (oltretutto contese tra due th con l'smt attivo)?
Beh, ma allora come giustifichi ad esempio una differenza sul calcolo intero cosi' marcata tra Intel ed AMD? Secondo il tuo ragionamento dovrebbero essere pressocchè identiche in termini di potenza di calcolo..
Le solite cose per cui intel si avvantaggia, ossia algoritmi di predizione migliore, scheduler unificati e compilatori ottimizzati...
per la parte editata questo gia avviene con il multicore.
Sulla prima parte piuttosto come giustifichi l'aumento di ipc in s-th passando da 4 pipeline del c2d alle 3 di I7 (oltretutto contese tra due th con l'smt attivo)?
beh, il discorso dell'HT non pregiudica l'efficienza dei calcoli INT su un singolo thread, perche' pur essendo risorse "condivise", il secondo thread viene elaborato solamente durante le fasi di "stallo" del primo, quindi possiamo dire che le risorse vengono condivise in mutua esclusione..
Per quanto riguarda il numero di ALU penso che vada considerato non solo il loro numero, ma anche la loro effettiva efficienza prestazionale, legata sia ai branch prediction, sia al numero ci cicli relativo alle tipologie di micro-ops eseguibili, sbaglio?
Ma secondo me (ed e' un discorso che penso sia a prescindere dall'architettura OoO) in qualunque caso se ad esempio una unità INT di potenza elaborativa data e composta ad esempio da 3 alu è in grado di processarmi un "pacchetto di istruzioni" composto da "X" micro-ops in "Y" tempo.. nello stesso intervallo di tempo "Y" secondo uno schema di distribuzione alternata su due unità intere identiche alla prima data (ammesso non si siano errori di predizione) potremo processare due pacchetti di di istruzioni di eguale complessità, quindi 2X micro-ops. il flusso di output sarebbe identico, quindi anche gli algoritmi di ri-ordinamento sarebbero i medesimi.
ammettendo un caso del genere con "pacchetti" di operazioni.. secondo voi servirebbero due scheduler? (uno per modulo)
Penso sicuramente almeno una memoria di bufferizzazione per i pachetti di istruzioni per ogni modulo, sbaglio?
ditelo se sto divagando troppo, ehh? :D mi piace chiaccherare su cose tecniche, anche perche' oltre alla curiosità imparo sempre qualcosa di nuovo dai piu' esperti di me :)
beh, il discorso dell'HT non pregiudica l'efficienza dei calcoli INT su un singolo thread, perche' pur essendo risorse "condivise", il secondo thread viene elaborato solamente durante le fasi di "stallo" del primo, quindi possiamo dire che le risorse vengono condivise in mutua esclusione..
Non funziona proprio così. Il due thread vengono eseguiti contemporaneamente, mescolati tra loro. In modo da cercare di allocare in ogni istante il maggior numero di unità di esecuzione possibile. Se c'è "spazio" per l'HyperThreading (se due thread senza HyperThreading vanno più lenti di due thread con HyperThreading) significa che con un solo thread non si riescono ad allocare molto spesso tutte le unità di esecuzione ;)
dark.halo
05-10-2010, 16:35
Per quanto riguarda il discorso dell 80% di prestazioni del modulo rispetto un design classico,JF ha escluso tutto.
Dal blog AMD, JF risponde ad uno che gli chiedeva informazioni a riguardo...
TIPO:u said many times..your bulldozer core will be better than one curent core..other times bulldozer core will have 80% perfformance from a current core.what is right version,make it clear please?
JF:We have never said that Bulldozer would be 80% of the performance of current cores. This was a different statement about a different product.
http://blogs.amd.com/work/2010/10/04/20-questions-part-4/
Per quanto riguarda il discorso dell 80% di prestazioni del modulo rispetto un design classico,JF ha escluso tutto.
Dal blog AMD, JF risponde ad uno che gli chiedeva informazioni a riguardo...
TIPO:u said many times..your bulldozer core will be better than one curent core..other times bulldozer core will have 80% perfformance from a current core.what is right version,make it clear please?
JF:We have never said that Bulldozer would be 80% of the performance of current cores. This was a different statement about a different product.
http://blogs.amd.com/work/2010/10/04/20-questions-part-4/
In quella pagina c'è scritto che la cache istruction (l1 ?) è di 64k ed è condivisa tra le due unità int, mentre la cache data è di 16k per ogni int.
Che le speculazioni fatte prima su un possibile supercore (sia le mie che quelle di Gigamez) non siano davvero implementate in qualche modo?
E' normale che la iL1 sia condivisa, visto che i primi stage sono in comune fra i due thread. Era una cosa nota tra l'altro.
capitan_crasy
05-10-2010, 17:28
Per quanto riguarda il discorso dell 80% di prestazioni del modulo rispetto un design classico,JF ha escluso tutto.
Dal blog AMD, JF risponde ad uno che gli chiedeva informazioni a riguardo...
TIPO:u said many times..your bulldozer core will be better than one curent core..other times bulldozer core will have 80% perfformance from a current core.what is right version,make it clear please?
JF:We have never said that Bulldozer would be 80% of the performance of current cores. This was a different statement about a different product.
http://blogs.amd.com/work/2010/10/04/20-questions-part-4/
E' da mesi ormai che dico di non basarsi sulle percentuali rilasciate da AMD per stabilire le prestazioni di Bulldozer....:muro:
E' da mesi ormai che dico di non basarsi sulle percentuali rilasciate da AMD per stabilire le prestazioni di Bulldozer....:muro:
Comunque ha risposto in quel modo perché non è quello che hanno detto. Le percentuali erano riferite ad un ipotetico dual core con un solo int per core. Quindi a parità di architettura.
Inutile quindi usare quel 80% per cercare di capire le prestazioni, visto che si riferisce a se stesso ;)
Comunque ha risposto in quel modo perché non è quello che hanno detto. Le percentuali erano riferite ad un ipotetico dual core con un solo int per core. Quindi a parità di architettura.
Inutile quindi usare quel 80% per cercare di capire le prestazioni, visto che si riferisce a se stesso ;)
Difatti serve solo a valutare a spanne il rapporto superfice-modulo/ipc,
superfice-dualcore/ipc
capitan_crasy
05-10-2010, 19:14
:DEcco finalmente la conferma ufficiale!:D
Come più volte ipotizzato sul thread del K10 il progetto originale di Bulldozer prevedeva l'utilizzo dei 45nm SOI; l'uscita era prevista per fine 2009 e doveva scontrarsi con le CPU Nehalem di Intel.
Durante lo sviluppo il progetto Bulldozer a 45nm fu abbandonato e rivisto (aggiunta delle istruzioni AVX e abbandono delle SSE5) per i 32nm SOI.
AMD non specifica cosa andò storto e se il vecchio Bulldozer era uguale al nuovo come concetto architetturale, tuttavia nei mesi che seguirono su intrapresa la configurazione di tipo MCM per le CPU Opteron a 8/12 core e l'utilizzo del Low-k sulle CPU Six core Thuban destinate al mercato Desktop.
“How much resemblance does your today’s Bulldozer architecture have to the original design?” – Tye
As you are aware, when we initially designed “Bulldozer,” we were working with a more modular processor design. The original “Bulldozer” design was 45nm. But as development progressed, it became clear that the 45nm design that we had been working on was not going to be as competitive as we would have liked.
With the world watching your every move, all product decisions become very public (how many articles have you seen about “Bulldozer” in the press?) It is never an easy decision to make substantial changes to your product roadmap, but sometimes you have to make the tough call because it is the right thing to do. It helps when your partners are behind you and agree with the changes – sometimes a little short-term pain is necessary for a long-term gain.
We obviously aren’t going to get into specific design changes, but we think that the 32nm “Bulldozer” can bring a lot of benefit to our product due to smaller transistor size (which can help drive down the power envelope). By going for lower power, we hope to give you more room for compute cores, FP capabilities and more.
In addition, bringing the AMD Opteron™ 6100 Series processors to market allowed us to deliver an MCM design to market, which validated that technology. Having the SR5600 series chipsets, with more than a year under their belt, means that platform validation should be much easier for our partners. One of the biggest beneficiaries of a 32nm design is not necessarily a new technology added to the processor as much as it is the socket, chipset and platform work that happened ahead of the “Bulldozer” release.
Clicca qui... (http://blogs.amd.com/work/2010/10/04/20-questions-part-4/)
In quella pagina c'è scritto che la cache istruction (l1 ?) è di 64k ed è condivisa tra le due unità int, mentre la cache data è di 16k per ogni int.
Che le speculazioni fatte prima su un possibile supercore (sia le mie che quelle di Gigamez) non siano davvero implementate in qualche modo?
vero (e me ne ero sinceramente dimenticato), lo avevo letto e fatto notare anche io qualche settimana fa..
dai che magari ci scappa il sorpresone XD!
Si, ma se poi ci abbiamo azzeccato il capitano deve come minimo offrire da bere a tutti, :sofico:
hehe
Le solite cose per cui intel si avvantaggia, ossia algoritmi di predizione migliore, scheduler unificati e compilatori ottimizzati...
Ciao
Appunto, oltre a un sistema di caches più efficiente di quello di amd ed i migliori prefetchers sino ad ora in circolazione, (che fanno grandi cose nei c2q e nei nehalem) Oltre ad avere con nehalem un memory controller che ti da più banda e meno latenza di quello dei k10, e non è da poco.
Cut
Bisogna creare due veri e propri "flussi" di pacchetti di istruzioni cercando di far si che i pacchetti del primo flusso non siano in dipendenza sequenziale rispetto ai pacchetti del secondo flusso. Praticamente bisognerebbe avere una sorta di secondo branch prediction sui due rami, oltre che quello "classico" sulle istruzioni ed quindi un ulteriore algoritmo di ordinamento in base alle dipendenze sui flussi di pacchetti.. non sarebbe uno scherzo, senza contare che servirebbero logiche di fetch, decode, scheduling e retire che siano decisamente piu' veloci (e magari complesse) del normale.. o sbaglio? :O
Ciao.
Guarda purtroppo l'isa x86 contiene istruzioni tra loro non ortagonali, ovvero di lunghezza in n di bit differenti tra loro, perciò una bella fase di tempo viene spesa nello scanning delle istruzioni, ovvero, esempio, fetch di 32 bytes quante istruzioni in essi? 15, bene il procio decodifichera tranquillamente fino a quando non trova una istruzione di branch, si perde un ciclo, si rifectha il codice giusto (se hai preso la diramazione giusta e se hai gli operandi caricati ) e si ricontinua.
Ovviamente non sono un tecnico e nelle cose soprascritte c'è di vero assumo il 10%, però come puoi ben vedere predire le dipendenze di due flussi "pachetti" è abbastanza difficile.
paolo.oliva2
05-10-2010, 19:51
Capitano... c'è una cosa che non mi è chiara.
Praticamente nell'intervista AMD riporta che hanno tralasciato Buldozer sul 45nm perché sarebbe stato meno competitivo, e modificato per sfruttare al meglio il 32nm perché con la riduzione di TDP avrebbe garantito più spazio per i core e FPU. By going for lower power, we hope to give you more room for compute cores, FP capabilities and more
Ora... c'è qualche cosa che non mi torna.
BD può contare su un'ottimizzazione migliore per quello che riguarda IPC/W.
Quindi, se fosse realizzato ancora sul 45nm, potrebbe garantire 8 core suppergiù al TDP del Thuban, ad essere pessimisti, diciamo 140W.
A questo si aggiunge il 32nm che a parità di potenza produrrebbe il 40-50% in meno di TDP.
Insomma... su questa base, un BD X8 a 3,2GHz sul 32nm dovrebbe essere dai 70W ai 94W...
Per arrivare ai 125W... c'è un margine pazzesco... dai 31W ai 55W.
Praticamente se un BD "lavorasse" a frequenze del Thuban avrebbe un margine tale nel TDP da poter garantire da un +40% a un + 80% dei core.
Riportando quello in neretto... possibile che AMD si fermi a solo 2 core in più? Mi suona strano che 800MHz di clock stock maggiore possano assorbire da soli 50W, quando un Thuban già sull'E0 45nm per i 4GHz X6 si ferma ad un TDP maggiore sotto i 30W, considerando poi pure il fatto che teorizzando 1GHz di Turbo, mi pare chiaro che il Vcore non può arrivare alle stelle...
Probabilmente il progetto non era quello che vediamo oggi.
Inoltre pare evidente che fosse il processo produttivo stesso a limitare la possibilità di salire in frequenza, quindi di fatto castrando il progetto.
paolo.oliva2
05-10-2010, 20:11
Probabilmente il progetto non era quello che vediamo oggi.
Inoltre pare evidente che fosse il processo produttivo stesso a limitare la possibilità di salire in frequenza, quindi di fatto castrando il progetto.
Probabile.
Però non mi torna che un BD 32nm odierno possa avere il limite di 8 core per restare dentro i 125W.
Con un 50% in meno di TDP a parità di frequenza per il silicio e con un 10-20% a parità di architettura per le migliorie, un BD alle frequenze del Thuban (3,2GHz) dovrebbe consentire almeno un 65-80% in più di core del Thuban.
Thuban X6, BD X10-X11... X8 è un totale sotto...
Forse AMD ha voluto evitare che il progetto BullDozer subisse la sorte del progetto Phenom: un processore troppo complesso per il processo produttivo per cui è stato pensato.
Così, anzichè rischiare di perdere tempo a rappezzare un eventuale Bulldozer inadatto al processo produttivo, hanno deciso di saltare a pie pari i 45nm migliorando ulteriormente il progetto, ed evitando così di perdere altra strada nei confronti di Intel.
Scelta abbastanza condivisibile, direi, se i risultati non sono stati da subito quelli sperati.
Ciao.
Guarda purtroppo l'isa x86 contiene istruzioni tra loro non ortagonali, ovvero di lunghezza in n di bit differenti tra loro, perciò una bella fase di tempo viene spesa nello scanning delle istruzioni, ovvero, esempio, fetch di 32 bytes quante istruzioni in essi? 15, bene il procio decodifichera tranquillamente fino a quando non trova una istruzione di branch, si perde un ciclo, si rifectha il codice giusto (se hai preso la diramazione giusta e se hai gli operandi caricati ) e si ricontinua.
Ovviamente non sono un tecnico e nelle cose soprascritte c'è di vero assumo il 10%, però come puoi ben vedere predire le dipendenze di due flussi "pachetti" è abbastanza difficile.
allora, ragioniamo nella "pratica" impropriamente con una logica di "pacchetti" considerando l'assenza di ogni ulteriore algoritmo di ordinamento rispetto a quelli gia' classici che ci sono..
Ragioniamo inizialmente nel caso di un solo core. Mando in sequenza i pacchetti A,C,B,D alle mie alu. Sappiamo che i nostri algoritmi "classici" li hanno cosi' ordinati in quanto il pacchetto "B" dipende dal risultato del pacchetto "C". L'esecuzione sarà dunque lineare in quanto l'ordine di invio scelto e' ottimale per non avere interruzioni di flusso.
In ordine possiamo schematizzare in questo modo:
core0
1)loading A
2)return A
3)loading C
4)return C
5)loading B
6)return B
7)loading D
8)return D
abbiamo eseguito 8 ipotetici cicli di clock.
Ora ragioniamo secondo la stessa logica e secondo LO STESSO algoritmo di ordinamento usato nel primo esempio. Abbiamo il pacchetto A che viene mandato al core0. Quando il core0 mi dara' il risultato di A, allora caricherò il pacchetto C sul core1. Mentre il core1 mi da il risultato di C, carichero' sul core0 B. Non avro' comunque problemi di esecuzione riguardo al pacchetto B, perche' il risultato di C da cui dipende, io ce l'ho gia'!
Vediamo uno schema semplificato al massimo come il precedente:
Core0 | Core1
1) Loading A | IDLE
2) Return A | Loading C
3) Loading B | Return C
4) Return B | Loading D
5) IDLE | Return D
abbiamo eseguito solamente 5 ipotetici cicli di clock, senza nemmeno aver dovuto modificare il nostro algoritmo (perche' non ci sarebbe nulla da modificare). Ovviamente il guadagno e' minore per frammenti di codice tanto piu' piccoli in quanto i due idle di inizio e di coda di uno dei due core incidono in percentuale in maniera inversamente proporzionale al numero di pacchetti. Se invece di avere 4 pacchetti ne avessimo avuti ad esempio 4000, il guadagno sarebbe stato sempre piu' vicino al teorico 50%.
dove sto sbagliando? XD
B|4KWH|T3
05-10-2010, 20:22
Prova a guardare i test su linux... :).
In ambito Windows, senza sollevare polemiche, le piattaforme Intel rendono sempre di più, ma le cose cambieranno, perché con le AVX non potranno esistere compilatori "partigiani", e poi perché Intel non può risciare altre sanzioni perché è già stata avvisata e nell'accordo di "liquidazione" vecchio ha messo su carta che deve cambiare.
In ambito Linux le differenze tra un Magny-C ed un X6 Intel sono esigue, ma conta il fatto che il Magny-C "gira" a 2,4GHz-2,5GHz e l'Intel gira a 3,333GHz.
Con base SB Intel avrà suppergiù gli stessi clock, mentre un Magny-C, anche consideranto (per me) il sottostimato di Cionci a +500MHz, cosa otterremo?
SB un incremento di IPC, ma se un SB X4 mostra un +12% di media.... SB X6 potrebbe averlo inferiore, ma sicuramente NON maggiore.
AMD Da 2,5GHz a 3GHz si tratterebbe di +20%.
Ai bench visti, ammettendo per SB +10% e per Magny-C +20%, la risultante è che uscirebbe un +10% a favore di AMD rispetto all'attuale, non briciole, considerando per Magny-C solo 3GHz su 32nm...
Però, se vogliamo considerare per SB un +10% di IPC e pure un +10% sul clock, con risultante di un incremento maggiore del 20%, con la stessa manica larga non possiamo considerare solo un 20% per Magny-C, allo stesso modo, dovremmo considerare almeno un 40-50% che sarebbe equivalente alla stessa diminuzione di TDP dichiarata da AMD.
Se vogliamo fare i confronti, dobbiamo utilizzare lo stesso metro. E' inutile fare confronti aumentando le aspettive sull'Intel ed abbassando nettamente sul concreto quelle AMD... che confronto verrebbe fuori?
Per ora con il compilatore non è cambiato ancora nulla e dubito fortemente che cambierà.
Con l'ultimo uscito Intel ha messo un disclaimer e basta
La cosa di cui si parla poco sono queste:
http://software.intel.com/en-us/intel-mkl/
Anche queste sono ottimizzate per modello di processore e non per verifica della presenza del set di istruzioni corretto (ovvero, abilitano il corretto path di codice verificando il modello). Ciò porta ad un degrado per i processori non Intel.
Il vero problema è che quelle librerie sono le migliori disponibili e usandone altre le prestazioni non arrivano a quelle che si hanno usando le librerie Intel. Anche se non viene abilitato il path più ottimizzato.
AMD deve darsi una seria svegliata sotto questo punto di vista e assumere un po' di sviluppatori. Addirittura le stesse ottimizzazione pro intel sono state trovate anche nella AML (AMD Math Library).
Qui puoi seguire tutta la storia: http://software.intel.com/en-us/intel-mkl/
paolo.oliva2
05-10-2010, 20:53
Per ora con il compilatore non è cambiato ancora nulla e dubito fortemente che cambierà.
Con l'ultimo uscito Intel ha messo un disclaimer e basta
La cosa di cui si parla poco sono queste:
http://software.intel.com/en-us/intel-mkl/
Anche queste sono ottimizzate per modello di processore e non per verifica della presenza del set di istruzioni corretto (ovvero, abilitano il corretto path di codice verificando il modello). Ciò porta ad un degrado per i processori non Intel.
Il vero problema è che quelle librerie sono le migliori disponibili e usandone altre le prestazioni non arrivano a quelle che si hanno usando le librerie Intel. Anche se non viene abilitato il path più ottimizzato.
AMD deve darsi una seria svegliata sotto questo punto di vista e assumere un po' di sviluppatori. Addirittura le stesse ottimizzazione pro intel sono state trovate anche nella AML (AMD Math Library).
Qui puoi seguire tutta la storia: http://software.intel.com/en-us/intel-mkl/
Ma il discorso non riguardava o meno le librerie più ottimizzate... il discorso era incentrato sul fatto "IF not genuine cpu Intel Then...." che è ben altro.
Una cosa è che AMD utilizzi librerie fatte da Intel per CPU Intel, e qui certamente AMD non può obbligare Intel a ottimizzarle per proci AMD, un altro che le stesse librerie in caso di una CPU NON Intel, di proposito instaura loop assurdi e non ottimizzati, giustificati da Intel come "realizzati per assicurare una piena compatibilità"... :mc: . L'intento con cui è stato fatto, come ben sappiamo, è tutt'altro.
Infatti nessuno ha chiesto che Intel realizzasse qualche cosa ad hoc per AMD, ma solamente che Intel togliesse le discriminazioni.
Poi è chiaro che se andiamo a vedere la spiegazione ufficiale sul sito Intel, tutto scriveranno tranne che l'hanno fatto per far andare più piano la concorrenza e far apparire i propri proci più veloci. :boh:
Probabile.
Però non mi torna che un BD 32nm odierno possa avere il limite di 8 core per restare dentro i 125W.
Con un 50% in meno di TDP a parità di frequenza per il silicio e con un 10-20% a parità di architettura per le migliorie, un BD alle frequenze del Thuban (3,2GHz) dovrebbe consentire almeno un 65-80% in più di core del Thuban.
Thuban X6, BD X10-X11... X8 è un totale sotto...
il controller di memoria di bulldozer è diverso dal k10 e non solo per la frequenza,anche se dual .dovrà resistere a stress di overclock spinti e deve tenere a bada 2 o 4 moduli a 5 o piu gigahertz
questo significa che per essere all'altezza deve pompare parecchio perche deve tenere a bada il lavoro di un bulldozer x8 a 5 ghz + 8/16 giga di ram a 2500 mghz (o su di li )
Vediamo uno schema semplificato al massimo come il precedente:
Core0 | Core1
1) Loading A | IDLE
2) Return A | Loading C
3) Loading B | Return C
4) Return B | Loading D
5) IDLE | Return D
Questa cosa si fa sfruttando le varie unità di esecuzione della stesso core INT. Lo scheduler riordina le istruzioni a seconda delle dipendenze e le smista in modo da svolgere il più possibile dei compiti in parallelo. I pacchetti di istruzioni non esistono, le dipendenze possono anche esistere a centinaia di istruzioni di distanza.
Questa cosa si fa sfruttando le varie unità di esecuzione della stesso core INT. Lo scheduler riordina le istruzioni a seconda delle dipendenze e le smista in modo da svolgere il più possibile dei compiti in parallelo. I pacchetti di istruzioni non esistono, le dipendenze possono anche esistere a centinaia di istruzioni di distanza.
infatti, so che non esistono per i pacchetti ma solo per le singole micro-op, per quello parlavo di pacchetti in maniera ipotetica.. ma se si usasse lo stesso algoritmo invece che sulle singole micro-ops, direttamente su dei "pacchetti", allora il risultato sarebbe questo, o sbaglio?
Teoricamente non dovrebbe essere molto piu' dispendioso calcolare il tutto secondo lo stesso algoritmo non per l'istruzione ma per il pacchetto (anche inteso come un array di 4 micro istruzioni, tante quante sono le alu nella singola unità INT).
Se poi le dipendenze fossero molto distanti tra loro, magari distanti piu' dell'intervallo di tempo necessario a processare cio' che ci sta in mezzo diviso il numero di istruzioni per pacchetto, non servirebbe nemmeno calcolarle, sbaglio? :fagiano:
infatti, so che non esistono per i pacchetti ma solo per le singole micro-op, per quello parlavo di pacchetti in maniera ipotetica.. ma se si usasse lo stesso algoritmo invece che sulle singole micro-ops, direttamente su dei "pacchetti", allora il risultato sarebbe questo, o sbaglio?
Teoricamente non dovrebbe essere molto piu' dispendioso calcolare il tutto secondo lo stesso algoritmo non per l'istruzione ma per il pacchetto (anche inteso come un array di 4 micro istruzioni, tante quante sono le alu nella singola unità INT).
Se poi le dipendenze fossero molto distanti tra loro, magari distanti piu' dell'intervallo di tempo necessario a processare cio' che ci sta in mezzo diviso il numero di istruzioni per pacchetto, non servirebbe nemmeno calcolarle, sbaglio? :fagiano:
Ciao
Dunque, premetto che le dipendenze non esistono solo sulle istruzioni, ma anche sui dati. Detto ciò, se calcoli come dici in maniera OoO, devi poi comunque riordinare per ritirare come il programma richiede. Quindi, scusami se ancora non ho abbastanza vita da sto schifobook, le istruzioni in mezzo le devi comunque calcolare.
Cosa succederebbe ad esempio nel caso di un salto indiretto (ovvero memory address non conosciuto) ?
carlottoIIx6
05-10-2010, 23:49
Ciao
Dunque, premetto che le dipendenze non esistono solo sulle istruzioni, ma anche sui dati. Detto ciò, se calcoli come dici in maniera OoO, devi poi comunque riordinare per ritirare come il programma richiede. Quindi, scusami se ancora non ho abbastanza vita da sto schifobook, le istruzioni in mezzo le devi comunque calcolare.
Cosa succederebbe ad esempio nel caso di un salto indiretto (ovvero memory address non conosciuto) ?
non sputiamo, plese, nel piatto in vui mangiamo :)
secondo me bulldozer nasconde un segreto
chi lo capisce è bravo :D
Ciao
Dunque, premetto che le dipendenze non esistono solo sulle istruzioni, ma anche sui dati. Detto ciò, se calcoli come dici in maniera OoO, devi poi comunque riordinare per ritirare come il programma richiede. Quindi, scusami se ancora non ho abbastanza vita da sto schifobook, le istruzioni in mezzo le devi comunque calcolare.
Cosa succederebbe ad esempio nel caso di un salto indiretto (ovvero memory address non conosciuto) ?
certo, ragionando in ottica OoO la retire-unit dovrebbe essere unificata per i due core. Gli algoritmi di "riordino" sarebbero esattamente i medesimi di quelli tradizionali in quanto il flusso di output sarebbe appunto esattamente il medesimo con pero' una portata doppia. Il riordino pertanto dovrebbe essere eseguito ovviamente anch'esso al doppio della velocità.
Anche se penso la cosa migliore sia avere un'unica retire (era questo appunto l'unico "neo" che dai grafici visti non quadrerebbe nel mio ragionamento, come appunto piu' volte ho detto), volendo si potrebbero anche avere due retire core più una retire unificata a livello modulo, in modo da frammentare il carico di lavoro relativo a riordinamento per magari cercare di avere una implementazione piu' semplice.
Per quanto invece riguarda i vari algoritmi di predizione sarebbero tali e quali a quelli normalmente usati. Secondo me l'unico problema aggiuntivo come ho già detto in una logica di questo tipo sarebbe il far fronte alle dipendeze di flusso tra pacchetti..
Il consumo di Bulldozer DEVE essere molto basso perche' non dobbiao dimenticare che a breve all' interno del Chip verra' integrata una scheda video completa e che al giorno d'oggi una scheda video assorbe anche 200W.
sicuramente in futuro i TDP delle CPU verranno alzati di molto perche' dovranno includere quello che e' oggi consumato da una schda video.
Sicuramente ci saranno un po' di ottimizzazioni dovute al fatto che la FPU tradizionale verra' eliminata e verranno usate le pipeline grafiche , pero' si tratta comunque di circa 200W che si aggiungono all' attuale TDP.
Per come la vedo io con Fusion2 il TDP di una CPU viaggera' intorno ai 200-250W e nelle maniboard Gaming sara' possibile montare una seconda CPU per avere piu' potenza grafica
Questo vuol dire che OGGI l'architettura Buldozzer deve consumare veramente poco per potersi adattare in futuro a questa nuova e grande inclusione.
Personalmente ritengo che da parte di AMD non ci sarebbero problemi tecnicamente a proporre fin da subito un bulldozer 16x , pero' se si giocano subito tutte le carte poi si resta senza risorse ;)
Se invece di avere 4 pacchetti ne avessimo avuti ad esempio 4000, il guadagno sarebbe stato sempre piu' vicino al teorico 50%.
dove sto sbagliando? XD
beh, un errore l'ho gia' trovato.. il guadagno TEORICO sarebbe del doppio (sugli INT), quindi del 100% :sofico:
certo, ragionando in ottica OoO la retire-unit dovrebbe essere unificata per i due core. Gli algoritmi di "riordino" sarebbero esattamente i medesimi di quelli tradizionali in quanto il flusso di output sarebbe appunto esattamente il medesimo con pero' una portata doppia. Il riordino pertanto dovrebbe essere eseguito ovviamente anch'esso al doppio della velocità.
Secondo me il problema continua ad essere quello di cui avevamo parlato all'inizio di questa discussione:
inutile mettere a disposizione di un singolo thread il doppio delle pipeline int, perchè a causa delle dipendenze non è mai possibile sfruttarne più di tre o quattro insieme.
Le unità int attuali sono cioè già ben dimensionate per gestire un unico flusso, e per poter avere prestazioni superiori ci sono solo due strade:
- dividere questo "flusso" in due, ossia avere due thread distinti (e quindi lavorare sulla parallelizzazione del codice)
- lavorare su ciò che sta intorno alle unità int in maniera tale da sfruttarle al meglio (con decoder migliori, algoritmi di branch prediction migliori, occupazione delle pipeline tramite SMT, ecc...)
paolo.oliva2
06-10-2010, 01:29
Io aspetto altre dichiarazioni da parte di AMD, che dovrebbero arrivare entro i primi di novembre.
Non mi posso addentrare "dentro" al funzionamento del procio perché non ne ho le basi.
Però, a intuito, BD è un po' "strano" al suo interno... e non credo sia uno step di architettura che non avrà nulla a che fare con Fusion2.
Secondo me, rimango dell'idea che ci sfugge qualche cosa nell'ottica di funzionamento di BD.
Tra l'altro... trovo molto strano che BD si limiti ad un X8 per i 125W.
E trovo alquanto strano che in caso di IPC non superiore al 15% del Phenom II non si faccia ricorso ad aumentare i core sfruttando il clock del Turbo che secondo me da un X4 ad un X8 non dovrebbe praticamente cambiare.
Tanto le caratteristiche del silicio sono simili... se si dovesse portare un BD X8 a 4GHz stock per ottenere potenza (IPC x Core), tralasciando il Turbo che non dovrebbe cambiare da X4/X8 per via dello spegnimento dei moduli se non attivi, si otterrebbero più benefici in caso di frequenze minori ma con aumento dei core.
Io supporrei che se AMD così non ha fatto, vuol dire che X8 ha un sufficiente IPC e che non si ricerca il clock massimo per compensarlo.
In vista di Fusion2, questa architettura dovrebbe avere i requisiti trasformarsi in una APU... e con la coesione con le unità di calcolo VGA, se proprio non è presente in questa release, perlomeno l'0architettura di sé per sé dev'essere comunque idonea.
Su queste basi... nel modulo c'è certamente almeno un approccio, e secondo me è quello che sfugge per inquadrare l'IPC che dovrebbe essere anche più del 15%... BD è nato per contrastare SB... e se l'SB tra 1 anno lo vedremo come X8, se l'IPC fosse basso, BD sarebbe nato almeno come X10.
Scusate... partendo da un dato di fatto che il silicio AMD 32nm HKMG (forse pure low-k dall'inizio) sarà indubbiamente migliore di quello Intel... che vie può attuare AMD? TUTTE.
- aumento dei core, stile Thuban X6 vs X4.
- aumento del clock
- aumento dell'IPC
Ora... 8 core al posto di 6 del 45nm... a me sembra scarso... avrebbe potuto realizzare almeno un X10 e pure un X12 (se colleghiamo strategia Turbo clock alto per il monocore e clock relativamente più basso di un X8 ma con più core).
Il clock sarà certamente alto... però riflettiamo un attimo: una frequenza turbo ipotizzata a +1GH, non è di per sé la conferma che il clock per tutti i core sia "limitato" dal TDP?
Faccio un esempio: Thuban X6 3,2GHz... X4 3,6GHz.
Questo perché? Perché oltre i 3,6GHz ci vogliono più di 1,3-1,35V che, ipotizzo io, comincia nell'aumento di W rispetto a clock*IPC.
Ma il Turbo di +800MHz-1GHz, per me rendono l'idea che ancora non ci sia l'impennata dei consumi rispetto alla potenza.
Quindi cosa vorrebbe dire? Che gli 8 core lavorano pienamente a frequenze quasi di "riposo".
Con frequenze così "relativamente" basse, che aumento di TDP si avrebbe ad avere 10 core o 12? Guardiamo il Magny-C, ha 700MHz in meno con 12 core rispetto ad un Thuban che è a 3,2GHz ma come X6 e per giunta con il low-k. E' così assurdo pensare che un X12 BD sul 32nm "pagherebbe" una diminuzione di frequenza ridicola? Probabilmente almeno 3GHz.
Ma... ci facciamo un'idea che già di per sé potremmo parlare di 12 core sui 3GHz? Se il Turbo potesse da solo permettere i 5GHz, l'IPC monocore non avrebbe di per sé problemi.
Vediamo il multicore... Un Thuban @4,5GHz corrisponderebbe ad un Thuban X8 a 3,4GHz scarsi... e ad un X10 a 2,7GHz, addirittura un X12 a 2,250GHz (almeno con Cinebench, pov-ray, H-264 e similari). Un 12 core a 3GHz sarebbero tanto quanto un Thuban a 6GHz. Un Thuban a 6GHz se lo pappa un I7 X6 a 3,3GHz, in qualsiasi condizione, pure nella versione SB.
Allora... la risposta si deve trovare nella semplice equazione X12=X8.
P.S.
Che vi devo dire? Ho fatto il mio classico poema... :)
Secondo me il problema continua ad essere quello di cui avevamo parlato all'inizio di questa discussione:
inutile mettere a disposizione di un singolo thread il doppio delle pipeline int, perchè a causa delle dipendenze non è mai possibile sfruttarne più di tre o quattro insieme.
Le unità int attuali sono cioè già ben dimensionate per gestire un unico flusso, e per poter avere prestazioni superiori ci sono solo due strade:
- dividere questo "flusso" in due, ossia avere due thread distinti (e quindi lavorare sulla parallelizzazione del codice)
- lavorare su ciò che sta intorno alle unità int in maniera tale da sfruttarle al meglio (con decoder migliori, algoritmi di branch prediction migliori, occupazione delle pipeline tramite SMT, ecc...)
L'unico modo per aumentare l'ipc in mono th a parità di algoritmo di predizione è:
1 Avere pipeline veloci (freq elevate oppure pochi stadi ad alta capacità)
2 Ridurre i cicli di stallo delle pipeline in caso di predizione di salto errata (credo intorno al 30% delle predizioni totali).
capitan_crasy
06-10-2010, 11:39
Capitano... c'è una cosa che non mi è chiara.
Praticamente nell'intervista AMD riporta che hanno tralasciato Buldozer sul 45nm perché sarebbe stato meno competitivo, e modificato per sfruttare al meglio il 32nm perché con la riduzione di TDP avrebbe garantito più spazio per i core e FPU. By going for lower power, we hope to give you more room for compute cores, FP capabilities and more
Ora... c'è qualche cosa che non mi torna.
BD può contare su un'ottimizzazione migliore per quello che riguarda IPC/W.
Quindi, se fosse realizzato ancora sul 45nm, potrebbe garantire 8 core suppergiù al TDP del Thuban, ad essere pessimisti, diciamo 140W.
A questo si aggiunge il 32nm che a parità di potenza produrrebbe il 40-50% in meno di TDP.
Insomma... su questa base, un BD X8 a 3,2GHz sul 32nm dovrebbe essere dai 70W ai 94W...
Per arrivare ai 125W... c'è un margine pazzesco... dai 31W ai 55W.
Praticamente se un BD "lavorasse" a frequenze del Thuban avrebbe un margine tale nel TDP da poter garantire da un +40% a un + 80% dei core.
Riportando quello in neretto... possibile che AMD si fermi a solo 2 core in più? Mi suona strano che 800MHz di clock stock maggiore possano assorbire da soli 50W, quando un Thuban già sull'E0 45nm per i 4GHz X6 si ferma ad un TDP maggiore sotto i 30W, considerando poi pure il fatto che teorizzando 1GHz di Turbo, mi pare chiaro che il Vcore non può arrivare alle stelle...
Non sapremo mai come e perchè AMD abbia prima cancellato poi modificato il progetto Bulldozer a 45nm; tuttavia il primo annuncio della nuova architettura fu data sotto l'egemonia di RUIZ.
Quindi mi dispiace solo in parte che Bulldozer non si sia visto a 45nm, anche perchè intanto AMD ha modificato il suo assetto societario e certe cassate fatte con i 65nm devono restare solo un brutto ricordo (tremo solo all'idea di un fiasco costruttivo con un Bulldozer a 45nm stile K10 a 65nm)...
Il consumo di Bulldozer DEVE essere molto basso perche' non dobbiao dimenticare che a breve all' interno del Chip verra' integrata una scheda video completa e che al giorno d'oggi una scheda video assorbe anche 200W.
sicuramente in futuro i TDP delle CPU verranno alzati di molto perche' dovranno includere quello che e' oggi consumato da una schda video.
Sicuramente ci saranno un po' di ottimizzazioni dovute al fatto che la FPU tradizionale verra' eliminata e verranno usate le pipeline grafiche , pero' si tratta comunque di circa 200W che si aggiungono all' attuale TDP.
Non ci saranno mai GPU integrate con core X86 con quel TDP, sarebbe totalmente fuori mercato anche sul lato produttivo.
Guardando al futuro Llano saranno utilizzati GPU mainstream e non Top level; inoltre il passaggio dei core Bulldozer con core GPU verrà con tutta probabilità con i 22nm SOI quindi si avranno nuove GPU e nuovi parametri non confrontabili direttamente con le produzioni attuali...
Per come la vedo io con Fusion2 il TDP di una CPU viaggera' intorno ai 200-250W e nelle maniboard Gaming sara' possibile montare una seconda CPU per avere piu' potenza grafica
Questo vuol dire che OGGI l'architettura Buldozzer deve consumare veramente poco per potersi adattare in futuro a questa nuova e grande inclusione.
Personalmente ritengo che da parte di AMD non ci sarebbero problemi tecnicamente a proporre fin da subito un bulldozer 16x , pero' se si giocano subito tutte le carte poi si resta senza risorse ;)
Fusion2 sarà l'ibrido tra i core X86 e le GPU, cioè un unico elemento dove le due tecnologie non saranno più distinguibili.
Ciò significa una sola frequenza, una sola cache e un solo TDP che sarà a livello di quelli attuali...
Probabile.
Però non mi torna che un BD 32nm odierno possa avere il limite di 8 core per restare dentro i 125W.
Con un 50% in meno di TDP a parità di frequenza per il silicio e con un 10-20% a parità di architettura per le migliorie, un BD alle frequenze del Thuban (3,2GHz) dovrebbe consentire almeno un 65-80% in più di core del Thuban.
Thuban X6, BD X10-X11... X8 è un totale sotto...
Ti sei dimenticato l'area che occuperebbe e quindi il costo, dato anche il basso yield iniziale... :D Forse tra un anno, a processo 32nm maturo e sopratutto se il settore server richiederà più di 16 core per socket (attuale limite dell'MCM di 2 Bulldozer)...
Per ora un X8 a 4GHz stock lo vedo un sogno forse non così irrealizzabile...
Non sapremo mai come e perchè AMD abbia prima cancellato poi modificato il progetto Bulldozer a 45nm; tuttavia il primo annuncio della nuova architettura fu data sotto l'egemonia di RUIZ.
Quindi mi dispiace solo in parte che Bulldozer non si sia visto a 45nm, anche perchè intanto AMD ha modificato il suo assetto societario e certe cassate fatte con i 65nm devono restare solo un brutto ricordo (tremo solo all'idea di un fiasco costruttivo con un Bulldozer a 45nm stile K10 a 65nm)...
Non ci saranno mai GPU integrate con core X86 con quel TDP, sarebbe totalmente fuori mercato anche sul lato produttivo.
Guardando al futuro Llano saranno utilizzati GPU mainstream e non Top level; inoltre il passaggio dei core Bulldozer con core GPU verrà con tutta probabilità con i 22nm SOI quindi si avranno nuove GPU e nuovi parametri non confrontabili direttamente con le produzioni attuali...
Fusion2 sarà l'ibrido tra i core X86 e le GPU, cioè un unico elemento dove le due tecnologie non saranno più distinguibili.
Ciò significa una sola frequenza, una sola cache e un solo TDP che sarà a livello di quelli attuali...
Non necessariamente una sola frequenza... ;) Già con questo bulldozer e date le code che separano i vari stadi non mi stupirei se ogni stadio (i due int core, la FPU, load/store/L2, L3 e controller e il feth/decode/dispatch/retire) abbiano frequenze diverse e indipendenti... E' forse per questo che JF-AMD ha la bocca cucita sul turbocore 2.0...
Anzi: avevo una mezza idea di suggerirlo a JF-AMD...
La mia idea era questa:
Ogni stadio in bulldozer è accoppiato al successivo tramite una coda e anche piuttosto generosa. Già nel K10 esistono dei contatori di prestazione che consentono di sapere l'occupazione media delle code interne e ritengo molto probabile che anche bulldozer le abbia. Posto che teoricamente ogni stadio può essere cloccato indipendentemente (sarebbe facile da implementare) e posto che esistano questi contatori di prestazioni, se non fosse implementato già in hardware io farei la seguente implementazione software (magari con AOD o K10-stat):
Per ogni stadio si monitorizza il riempimento medio della coda. Ogni tot millisecondi si calcola l'utilizzo medio delle code. Se la coda è vuota in media (esempio: occupazione sotto il 10-20%), allora scendi di un moltiplicatore il clock dello stadio a valle della coda, se non è già al minimo, impostabile per esempio da BIOS o come parametro ausiliario (es: FPU sottoutilizzata? Scendo il clock).
Se la coda è piena (es: utilizzazione sopra il 60-70%), se il budget di TDP e corrente dei VRM lo consente, se la temperatura è sotto un tot, se il moltiplicatore non è già al massimo consentito dal modello (o impostato nel BIOS a rischio e pericolo dell'utente per i modelli Black edition) allora sali di uno il moltiplicatore dello stadio a valle. Questo per tutti gli stadi che ho elencato sopra. Ogni tot millisecondi. E come parametri di configurazione ci sono le percentuali delle code: in modalità aggressiva, si possono mettere percentuali del tipo 10-50 per le due soglie. Così da avere le massime prestazioni in monothread. In modalità conservativa si possono mettere percentuali del tipo 20-80 per le due soglie, così da avere il miglior rapporto prestazioni/W in multicore, sacrificando un po' il monocore...
Cut
Per quanto invece riguarda i vari algoritmi di predizione sarebbero tali e quali a quelli normalmente usati. Secondo me l'unico problema aggiuntivo come ho già detto in una logica di questo tipo sarebbe il far fronte alle dipendeze di flusso tra pacchetti..
Ciao.
Dunque è qusto il problema, dovresti ridisegnare tutti i predictors, come detto prima le dipendenze esistono anche tra dati non solo tra istruzioni dunque i predictors dovrebbero oltre che prevedere le diramazioni, prevedere che tutti e i due cores seguano la direzione giusta, metti caso che nelle istruzioni decodificate ed inviate al core B vi sia una branch che invalida tutto il codice nel core A. Che si farebbe?
Preciso che probabilmente ho scritto cazzate ma penso di aver reso il concetto. :D
paolo.oliva2
06-10-2010, 19:05
Ti sei dimenticato l'area che occuperebbe e quindi il costo, dato anche il basso yield iniziale... :D Forse tra un anno, a processo 32nm maturo e sopratutto se il settore server richiederà più di 16 core per socket (attuale limite dell'MCM di 2 Bulldozer)...
Per ora un X8 a 4GHz stock lo vedo un sogno forse non così irrealizzabile...
Si, si, certamente.
Ma la mia non era tanto un'idea all'uscita, perché tanto chi si ritroverebbe di fronte? SB X4 e i7 9XX X6.
In Monocore BD avrebbe almeno 1,2GHz in più...
In Multicore... con il doppio dei core rispetto ad un SB e con 2 core in più rispetto ad un i7 9XX, e su entrambi almeno 500MHz in più di clock def... basta ed avanza un X8.
Le cose cambieranno, al limite, verso la fine del 2012... con SB X8 e inizio 2013 con forse un X10 Intel... ma per quelle date è più che presumibile uno step ulteriore sul silicio, il low-k se non presente al debutto ci sarà sicuramente (anche perchè... nel 2013 dovrebbe subentrare il 22nm...), insomma, se ci sarà la necessità e spazio commerciale per un X10/X12, il TDP lo vedrei l'ultimo dei prb.
Ciao.
Dunque è qusto il problema, dovresti ridisegnare tutti i predictors, come detto prima le dipendenze esistono anche tra dati non solo tra istruzioni dunque i predictors dovrebbero oltre che prevedere le diramazioni, prevedere che tutti e i due cores seguano la direzione giusta, metti caso che nelle istruzioni decodificate ed inviate al core B vi sia una branch che invalida tutto il codice nel core A. Che si farebbe?
Preciso che probabilmente ho scritto cazzate ma penso di aver reso il concetto. :D
Infatti: non devono esserci dipendenze di alcun genere ne' tra singole micro-ops "parallele" (come già è), ne' tra pacchetti su due rami diversi (cosa invece da aggiungere al possibile algoritmo di smistamento).
Quello che pero' riguarda l'ordine delle predizioni sui possibili risultati riguardanti cicli, controlli ecc.ecc. non cambierebbe rispetto ad ora in quanto il flusso di input ed il flusso di output a/dalle unità intere sarebbe il medesimo rispetto ad un processore classico. Il fallimento o il successo non dipenderrebbero in ogni caso dalla architettura, ma solamente dalla bontà dell'algoritmo.. sbaglio?
dark.halo
06-10-2010, 19:53
Non necessariamente una sola frequenza... ;) Già con questo bulldozer e date le code che separano i vari stadi non mi stupirei se ogni stadio (i due int core, la FPU, load/store/L2, L3 e controller e il feth/decode/dispatch/retire) abbiano frequenze diverse e indipendenti... E' forse per questo che JF-AMD ha la bocca cucita sul turbocore 2.0...
Anzi: avevo una mezza idea di suggerirlo a JF-AMD...
La mia idea era questa:
Ogni stadio in bulldozer è accoppiato al successivo tramite una coda e anche piuttosto generosa. Già nel K10 esistono dei contatori di prestazione che consentono di sapere l'occupazione media delle code interne e ritengo molto probabile che anche bulldozer le abbia. Posto che teoricamente ogni stadio può essere cloccato indipendentemente (sarebbe facile da implementare) e posto che esistano questi contatori di prestazioni, se non fosse implementato già in hardware io farei la seguente implementazione software (magari con AOD o K10-stat):
Per ogni stadio si monitorizza il riempimento medio della coda. Ogni tot millisecondi si calcola l'utilizzo medio delle code. Se la coda è vuota in media (esempio: occupazione sotto il 10-20%), allora scendi di un moltiplicatore il clock dello stadio a valle della coda, se non è già al minimo, impostabile per esempio da BIOS o come parametro ausiliario (es: FPU sottoutilizzata? Scendo il clock).
Se la coda è piena (es: utilizzazione sopra il 60-70%), se il budget di TDP e corrente dei VRM lo consente, se la temperatura è sotto un tot, se il moltiplicatore non è già al massimo consentito dal modello (o impostato nel BIOS a rischio e pericolo dell'utente per i modelli Black edition) allora sali di uno il moltiplicatore dello stadio a valle. Questo per tutti gli stadi che ho elencato sopra. Ogni tot millisecondi. E come parametri di configurazione ci sono le percentuali delle code: in modalità aggressiva, si possono mettere percentuali del tipo 10-50 per le due soglie. Così da avere le massime prestazioni in monothread. In modalità conservativa si possono mettere percentuali del tipo 20-80 per le due soglie, così da avere il miglior rapporto prestazioni/W in multicore, sacrificando un po' il monocore...
qualcosa di simile non c'è anche in moorestrown/medfield ???
Infatti: non devono esserci dipendenze di alcun genere ne' tra singole micro-ops "parallele" (come già è), ne' tra pacchetti su due rami diversi (cosa invece da aggiungere al possibile algoritmo di smistamento).
Quello che pero' riguarda l'ordine delle predizioni sui possibili risultati riguardanti cicli, controlli ecc.ecc. non cambierebbe rispetto ad ora in quanto il flusso di input ed il flusso di output a/dalle unità intere sarebbe il medesimo rispetto ad un processore classico. Il fallimento o il successo non dipenderrebbero in ogni caso dalla architettura, ma solamente dalla bontà dell'algoritmo.. sbaglio?
Ciao
Però permettimi di farti notare una cosa, il codice parallelo per eccellenza è quello di tipo vettoriale (quindi calcoli simd e fp) mentre quello x86-64 è molto seriale, quindi se si implementasse, un meccanismo di pachetti di dati paralleli, i vantaggi in campo int (escludendo vettori int) sarebbe basso. Cosa diversa invece se i due core su un modulo agissero in maniera concertata, ovvero core A esegue il codice, core b uno scout thread che esplora il codice, risolve le branch ecc ecc.
Si, si, certamente.
Ma la mia non era tanto un'idea all'uscita, perché tanto chi si ritroverebbe di fronte? SB X4 e i7 9XX X6.
In Monocore BD avrebbe almeno 1,2GHz in più...
In Multicore... con il doppio dei core rispetto ad un SB e con 2 core in più rispetto ad un i7 9XX, e su entrambi almeno 500MHz in più di clock def... basta ed avanza un X8.
Le cose cambieranno, al limite, verso la fine del 2012... con SB X8 e inizio 2013 con forse un X10 Intel... ma per quelle date è più che presumibile uno step ulteriore sul silicio, il low-k se non presente al debutto ci sarà sicuramente (anche perchè... nel 2013 dovrebbe subentrare il 22nm...), insomma, se ci sarà la necessità e spazio commerciale per un X10/X12, il TDP lo vedrei l'ultimo dei prb.
anche uno zambezi x8 concepito a 22 nm ed alla frequenza di un altro 1 giga hertz in piu sarebbe piu consono;in fondo piu si ''potrebbe'' accelerare bulldozer è meglio è, anche a 6 ghz a 22 nm(per questioni di fantasia,se forse gia non lo vedremo a 32nm) 8 core bulldozer si farebbero sentire lo stesso
in ogni caso ,dopo bulldozer 32nm, per i 22 nm si dovrebbe cominciare a delinearsi sempre più lo sposalizio finale ,tra i core 22 nm ed le gpu a 28 nm(vicine al 22)
ben presto anche bulldozer si allontanera dal senso di ''spoglio'' e solo;ripeterei sempre le stesse cose ,ma il fidanzamento forse lo vedremo a 22nm a cui seguiranno le nozze di questi ''promessi fusi''
ma APU family....è già una ineluttabile meta scritta;se dopo devo essere felice dovrei ammettere che 2/4 gpu piccoline a 16 nm ,con potenze simili ad esempio ad una 5870 non mi dispiacerebbero e tutto il frullato in una parola sola:
''all(il max di cpu e gpu) on the same die!'':read:
Ciao
Però permettimi di farti notare una cosa, il codice parallelo per eccellenza è quello di tipo vettoriale (quindi calcoli simd e fp) mentre quello x86-64 è molto seriale, quindi se si implementasse, un meccanismo di pachetti di dati paralleli, i vantaggi in campo int (escludendo vettori int) sarebbe basso. Cosa diversa invece se i due core su un modulo agissero in maniera concertata, ovvero core A esegue il codice, core b uno scout thread che esplora il codice, risolve le branch ecc ecc.
ragionando in termini di flusso di dati le unità fpu lavorano in superscalare, mentre una architettura ad unita' alternate lavorerebbe comunque con un flusso seriale, pur avendo appunto due unità..
ragionando in termini di flusso di dati le unità fpu lavorano in superscalare, mentre una architettura ad unita' alternate lavorerebbe comunque con un flusso seriale, pur avendo appunto due unità..
Ciao
Scusami, non ti seguo, superscalari lo possono esse le fpu come le alu, a seconda dell'algoritmo che sta alla base dello scheduling della cpu.
Le fpu simd lavorano in genere su un flusso di dati del tipi x,y,z e su questi dati devono eseguire le operazioni.
B|4KWH|T3
06-10-2010, 22:14
Ma il discorso non riguardava o meno le librerie più ottimizzate... il discorso era incentrato sul fatto "IF not genuine cpu Intel Then...." che è ben altro.
Una cosa è che AMD utilizzi librerie fatte da Intel per CPU Intel, e qui certamente AMD non può obbligare Intel a ottimizzarle per proci AMD, un altro che le stesse librerie in caso di una CPU NON Intel, di proposito instaura loop assurdi e non ottimizzati, giustificati da Intel come "realizzati per assicurare una piena compatibilità"... :mc: . L'intento con cui è stato fatto, come ben sappiamo, è tutt'altro.
Infatti nessuno ha chiesto che Intel realizzasse qualche cosa ad hoc per AMD, ma solamente che Intel togliesse le discriminazioni.
Poi è chiaro che se andiamo a vedere la spiegazione ufficiale sul sito Intel, tutto scriveranno tranne che l'hanno fatto per far andare più piano la concorrenza e far apparire i propri proci più veloci. :boh:
Ma infatti la mia è una critica ad AMD che non si sveglia dal punto di vista software
Ciao
Scusami, non ti seguo, superscalari lo possono esse le fpu come le alu, a seconda dell'algoritmo che sta alla base dello scheduling della cpu.
Le fpu simd lavorano in genere su un flusso di dati del tipi x,y,z e su questi dati devono eseguire le operazioni.
si, ma penso (magari mi sbaglio, ehh! XD) che nelle INT il flusso di macro ops (scomposte in micro-ops dal decoder e ricomposte in macro-risultati dalle retire) sia seriale (anche nella mia ipotesi), nella fpu questo livello è assente, quindi e' realmente superscalare anche a livello trasparente verso il programma, sia in input che in output, e non solo durante la fase computazionale..
Dimmi se sto sbagliando di brutto, come ho detto ipotizzo, ma sicuramente ne sai tu molto piu' di me! :)
qualcosa di simile non c'è anche in moorestrown/medfield ???
Non ne ho idea... Non seguo molto le architetture INTEL... Se hai qualche link però lo leggo con piacere... :)
ragazzi vorrei cambiare pc e passare ad un quad o al massimo a un six core..... secondo voi posso tranquillamente buttarmi su un 955 o al massimo su un 1050t, oppure è meglio aspettare i bulldozer (che se non ho capito male dovrebbero uscire verso primavera)? C sarà così tanta differenza d prestazioni ?:fagiano:
grazie in anticipo
Fabiano 82
07-10-2010, 13:51
con il sistema che hai in firma, potresti tranquillamente ( a meno di esigenze particolari) aspettare bulldozer, che dovrebbe uscire verso l'estate se non sbaglio(anche se non ci sono conferme)
Heimdallr
07-10-2010, 13:54
Beh dipende ovviamente se puoi aspettare, BD dovrebbe scire in primavera per cui l'uscita è vicina in termini 'informatici' ma aspettare 6 mesi o più per cambiare pc se ne hai bisogno è un tempo parecchio lungo imho.
In caso d cambio una configurazione del genere sarebbe ottimale ?
AMD AM3 Phenom II X4 955 Bl.Ed. Box - C3- 3,2GHz - 8MB Cache - 125W € 120
Gigabyte GA-890GPA-UD3H (890GX,AM3,ATX,DDR3,VGA,AMD) € 105,50
Kingston DDR3 4GB 1333Mhz HyperX KIT (2x2) CL7 XMP (KHX1333C7D3K2/4GX) € 89,00
CORSAIR 550W CMPSU-550VXEU € 64,00
o sarebbe meglio andare sul
AMD PHENOM II X6 1055T Soket AM3 2,8GHz - 9MB Cache - 125W Box 157,00 €
pensando anche al futuro
calcolando che prevalentemente gioco (la vga resterebbe qualla in firma)
Heimdallr
07-10-2010, 14:13
va bene l'X4 per giocare, chiudiamo l'OT comunque, se ti servono consigli ti conviene aprire un topic a parte ;)
capitan_crasy
07-10-2010, 14:13
Ragazzi, per cortesia niente consiglio per gli acquisti...
Bulldozer uscirà tra il secondo e il terzo trimestre 2011...
paolo.oliva2
07-10-2010, 14:46
Ragazzi, per cortesia niente consiglio per gli acquisti...
Bulldozer uscirà tra il secondo e il terzo trimestre 2011...
Per me la toto-scommessa è dal 15 aprile in poi...
(visto le analogie con il Thuban).
Comunque... :mad: certo che commercializzare un procio con l'inizio delle temp calde... I Thuban hanno guadagnato 100MHz in OC con le temp odierne.
somethingstrangeinyourmind
07-10-2010, 14:57
Ma si sa quando usciranno le prime mb con socket AM3+?
Heimdallr
07-10-2010, 15:29
Ma si sa quando usciranno le prime mb con socket AM3+?
L'hanno scorso il nuovo chipset era in giro mi pare a fine marzo/aprile, penso sarà la stessa cosa anche per il 990FX.
Io per Natale volevo finalmente far ripartire il mio pc desktop con una nuova mobo e cpu.. non ci sarà quindi il socket AM3+ ancora..:cry:
si, ma penso (magari mi sbaglio, ehh! XD) che nelle INT il flusso di macro ops (scomposte in micro-ops dal decoder e ricomposte in macro-risultati dalle retire) sia seriale (anche nella mia ipotesi), nella fpu questo livello è assente, quindi e' realmente superscalare anche a livello trasparente verso il programma, sia in input che in output, e non solo durante la fase computazionale..
Dimmi se sto sbagliando di brutto, come ho detto ipotizzo, ma sicuramente ne sai tu molto piu' di me! :)
Ciao
forse ho capito cosa intendi :)
Dunque a meno di non aver cannato completamente l'articolo http://www.agner.org/optimize/microarchitecture.pdf
I decoder generano le macro ops, lo scomponimento in micro ops avviene quando entrano negli issue slot, e poi ricomposti, questo succede sia per istruzioni Int che fpu ,ovvero il retirement buffer è condiviso tra alu e fp unit.
paolo.oliva2
07-10-2010, 19:21
Io per Natale volevo finalmente far ripartire il mio pc desktop con una nuova mobo e cpu.. non ci sarà quindi il socket AM3+ ancora..:cry:
Dai, a parte io che ero super-ottimista per un BD prima di Natale :D , le road-map AMD lo davano sempre per inizio 2011.
Questo era già stato postato ?
http://www.youtube.com/watch?v=VIs1CxuUrpc&feature=player_embedded
Questo era già stato postato ?
http://www.youtube.com/watch?v=VIs1CxuUrpc&feature=player_embedded
Sbaglio o li' compara esplicitamente il singolo core "classico", direttamente con il modulo bulldozer? Se fosse cosi' dovrebbe davvero essere core vs modulo..
Sbaglio o li' compara esplicitamente il singolo core "classico", direttamente con il modulo bulldozer? Se fosse cosi' dovrebbe davvero essere core vs modulo..
A che secondo ?
A che secondo ?
dall'1.28 in poi..
Parla di multithreading su singolo core, VS multithreading su modulo.. Sarebbe sciocco e contraddittorio partendo da questo paragone fare un 4 moduli vs 8 cores, no? :)
A che secondo ?
All'inizio, quando compare l'smt con il modulo.
Che poi la tecnologia smt di intel non la si dovrebbe nemmeno far rientrare tra i core "classici"
paolo.oliva2
07-10-2010, 22:34
Scusate... non vorrei dire baggianate, perché io mi perdo nell'architettura interna dei proci... però, da nubbio, vi pongo delle semplici domande:
Quando gli è stato chiesto ad AMD come intendeva il modulo, ha risposto che il modulo è inteso come un 2 core... o meglio 2 TH.
Mi dite dove cacchio riscontriamo la frase AMD "noi offriremo 2 TH fisici contro i 2 TH logici di Intel".
Mi pare LOGICO che a sto punto, un BD X8 o X4 moduli, sia l'antagonista di SB X4.
Fino a questo punto, se la massima espressione di Intel fosse un X4 + SMT, direi che non sorgerebbe nessun dubbio.
Ma siccome Intel ha già in commercio un X6 12TH, mi pare più che logico che i dubbi ci siano.
Ora, io non voglio mettere in campo che AMD possa fare X12 nativi... però ci potrebbe essere un'altra via di uscita, che comunque combacerebbe con quanto anticipato da AMD, cioé BD X8 in campo desktop e fino a BD X16 in campo server.
Vediamo di analizzare bene se questa condizione soddisferebbe le esigenze di AMD per contrastare Intel.
Partiamo dal campo server, in quanto dovrebbe essere più facile.
Io penso probabile che un BD X16 riuscirà a contrastare un SB X8, perché il 32nm AMD potrà consentire clock simili ad un SB X8, e pensare a 16 TH su 16 core, SB potrà avere l'incremento che si vuole, ma potrà offrire 16 TH su 8 core fisici, e se il clock in ambedue è simile, io penso che non ci sarebbe storia.
Campo desktop. Qui la cosa è più complessa... e andrebbe vista nell'insieme.
BD X8 vs SB X4, AMD più potente.
E qui rispecchierebbe la frase "offriremo TH fisici contro Intel a TH logici".
Attribuendo a BD X8 una potenza superiore di un i980X Intel, vediamo già che BD sarà certamente più "tuttofare" rispetto ai 12 TH logici Intel, e anche se un SB X8 potesse offrire di più in specifici campi, BD soddisferà molto meglio su tutta la rosa di programmi del desktop... senza contare che un SB X8 non potrà MAI avere un prezzo di produzione inferiore a BD X8, già solo considerando la grandezza del die, quindi un SB X8 verrà proposto ad un prezzo più alto di un BD X8... su questo non credo ci possano essere dubbi.
Quello che voglio dire è che nel desktop, un BD X8 dovrebbe soddisfare meglio l'utente finale sul discorso "tuttofare" e dovrebbe avere un rapporto prezzo/prestazioni più che soddisfacente, quindi, come prodotto, non dovrebbe avere nulla di meno di un SB X8.
SB X10 sarà a regime nel 2012... BD uscirà ai primi del 2011, quindi AMD avrebbe tutto il tempo per step ulteriori e quant'altro, e pure per aumentare il numero dei core.
Scusate... non vorrei dire baggianate, perché io mi perdo nell'architettura interna dei proci... però, da nubbio, vi pongo delle semplici domande:
Quando gli è stato chiesto ad AMD come intendeva il modulo, ha risposto che il modulo è inteso come un 2 core... o meglio 2 TH.
Mi dite dove cacchio riscontriamo la frase AMD "noi offriremo 2 TH fisici contro i 2 TH logici di Intel".
Mi pare LOGICO che a sto punto, un BD X8 o X4 moduli, sia l'antagonista di SB X4.
Fino a questo punto, se la massima espressione di Intel fosse un X4 + SMT, direi che non sorgerebbe nessun dubbio.
Ma siccome Intel ha già in commercio un X6 12TH, mi pare più che logico che i dubbi ci siano.
Ora, io non voglio mettere in campo che AMD possa fare X12 nativi... però ci potrebbe essere un'altra via di uscita, che comunque combacerebbe con quanto anticipato da AMD, cioé BD X8 in campo desktop e fino a BD X16 in campo server.
Vediamo di analizzare bene se questa condizione soddisferebbe le esigenze di AMD per contrastare Intel.
Partiamo dal campo server, in quanto dovrebbe essere più facile.
Io penso probabile che un BD X16 riuscirà a contrastare un SB X8, perché il 32nm AMD potrà consentire clock simili ad un SB X8, e pensare a 16 TH su 16 core, SB potrà avere l'incremento che si vuole, ma potrà offrire 16 TH su 8 core fisici, e se il clock in ambedue è simile, io penso che non ci sarebbe storia.
Campo desktop. Qui la cosa è più complessa... e andrebbe vista nell'insieme.
BD X8 vs SB X4, AMD più potente.
E qui rispecchierebbe la frase "offriremo TH fisici contro Intel a TH logici".
Attribuendo a BD X8 una potenza superiore di un i980X Intel, vediamo già che BD sarà certamente più "tuttofare" rispetto ai 12 TH logici Intel, e anche se un SB X8 potesse offrire di più in specifici campi, BD soddisferà molto meglio su tutta la rosa di programmi del desktop... senza contare che un SB X8 non potrà MAI avere un prezzo di produzione inferiore a BD X8, già solo considerando la grandezza del die, quindi un SB X8 verrà proposto ad un prezzo più alto di un BD X8... su questo non credo ci possano essere dubbi.
Quello che voglio dire è che nel desktop, un BD X8 dovrebbe soddisfare meglio l'utente finale sul discorso "tuttofare" e dovrebbe avere un rapporto prezzo/prestazioni più che soddisfacente, quindi, come prodotto, non dovrebbe avere nulla di meno di un SB X8.
SB X10 sarà a regime nel 2012... BD uscirà ai primi del 2011, quindi AMD avrebbe tutto il tempo per step ulteriori e quant'altro, e pure per aumentare il numero dei core.
Paolo due piccole considerazioni
1) Nella maggiorparte degli utilizzi server (sopratutto quando ci sono molte richieste di dati da client) l'smt intel è preferibile disattivarlo poichè peggiora le prestazioni della macchina quindi in alcuni utilizzi potrebbe essere preferibile SB con smt attivo, mentre in altri sb con smt disattivo.
Qui entra in gioco BD: se le prestazioni di bd saranno elevate SB server rischia di rimanere appetibile in una piccola tipologia di macchine.
Se invece bd ha prestazioni inferiori il mercato server verrà spartito a causa del prezzo più competitivo di bd (per tipologia e costo di produzione).
2) In ambito desktop vedo inutile gia un 980 six, figurarsi un octacore+smt.
Dal suo, qualsiasi siano le prestazioni, l'elevata frequenza di bd lo rende molto più appetibile di sb, tranne che nell WS di fascia medio-bassa dove l'ipc in multi core è fondamentale (ma anche questa è una piccola percentuale del mercato con cpu di fascia medio-alta).
Nella fascia intermedia credo che ci sarà un equilibro per prezzo.
La fascia bassa invece credo che sarà dominata da amd (tranne che per quei grossi brand che hanno contratti di acquisti annuali per num di cpu con intel)
carlottoIIx6
08-10-2010, 00:22
Paolo due piccole considerazioni
1) Nella maggiorparte degli utilizzi server (sopratutto quando ci sono molte richieste di dati da client) l'smt intel è preferibile disattivarlo poichè peggiora le prestazioni della macchina quindi in alcuni utilizzi potrebbe essere preferibile SB con smt attivo, mentre in altri sb con smt disattivo.
Qui entra in gioco BD: se le prestazioni di bd saranno elevate SB server rischia di rimanere appetibile in una piccola tipologia di macchine.
Se invece bd ha prestazioni inferiori il mercato server verrà spartito a causa del prezzo più competitivo di bd (per tipologia e costo di produzione).
2) In ambito desktop vedo inutile gia un 980 six, figurarsi un octacore+smt.
Dal suo, qualsiasi siano le prestazioni, l'elevata frequenza di bd lo rende molto più appetibile di sb, tranne che nell WS di fascia medio-bassa dove l'ipc in multi core è fondamentale (ma anche questa è una piccola percentuale del mercato con cpu di fascia medio-alta).
Nella fascia intermedia credo che ci sarà un equilibro per prezzo.
La fascia bassa invece credo che sarà dominata da amd (tranne che per quei grossi brand che hanno contratti di acquisti annuali per num di cpu con intel)
molto dipenderà dalle prestazioni in single
come ora, dove amd ha un netto vantaggio in multi perchè offre due core in più, e perde questo vantaggio per la marea di test che sfruttano solo i single
anche con buldozer la posizione sul mercato dipenderà ca come questo processore va in single, poichè in multi, secondo me non c'è storia
paolo.oliva2
08-10-2010, 00:37
Paolo due piccole considerazioni
1) Nella maggiorparte degli utilizzi server (sopratutto quando ci sono molte richieste di dati da client) l'smt intel è preferibile disattivarlo poichè peggiora le prestazioni della macchina quindi in alcuni utilizzi potrebbe essere preferibile SB con smt attivo, mentre in altri sb con smt disattivo.
Qui entra in gioco BD: se le prestazioni di bd saranno elevate SB server rischia di rimanere appetibile in una piccola tipologia di macchine.
Se invece bd ha prestazioni inferiori il mercato server verrà spartito a causa del prezzo più competitivo di bd (per tipologia e costo di produzione).
2) In ambito desktop vedo inutile gia un 980 six, figurarsi un octacore+smt.
Dal suo, qualsiasi siano le prestazioni, l'elevata frequenza di bd lo rende molto più appetibile di sb, tranne che nell WS di fascia medio-bassa dove l'ipc in multi core è fondamentale (ma anche questa è una piccola percentuale del mercato con cpu di fascia medio-alta).
Nella fascia intermedia credo che ci sarà un equilibro per prezzo.
La fascia bassa invece credo che sarà dominata da amd (tranne che per quei grossi brand che hanno contratti di acquisti annuali per num di cpu con intel)
Mi sembra che abbiamo la stessa idea...
Per assurdo, a me sembra molto più vincente il passaggio da i7 X4 a SB X4 che da i7 X4 a i7 X6, perché anche se SB ha indubbiamente un guadagno inferiore (12%), però lo dovrebbe avere praticamente sia in monocore che multicore, e l'SMT a 8 TH verrebbe sfruttato nei più dei casi.
Contrariamente, un i7 980X, in IPC monocore non offre di più di un i7 X4 (e quindi meno di SB), l'SMT 12 TH e più invasivo e da' fastidio nei giochi, ha un TDP ben più alto, l'OC è più limitato, e costa anche un totale di più.
paolo.oliva2
08-10-2010, 00:53
molto dipenderà dalle prestazioni in single
come ora, dove amd ha un netto vantaggio in multi perchè offre due core in più, e perde questo vantaggio per la marea di test che sfruttano solo i single
anche con buldozer la posizione sul mercato dipenderà ca come questo processore va in single, poichè in multi, secondo me non c'è storia
Il grandissimo vantaggio di AMD è che l'aumento del numero dei core non avrà MAI un aspetto negativo... al più, se non sfruttato, semplicemente non verrà utilizzato. Dov'è che un Thuban va "peggio" di un Phenom II X4?
Tanto la similitudine lampante l'abbiamo tra un 975C3 ed un 1090T.
Il 975C3 è un 3,5GHz X4.
il 1090T E0 come X4 è un 3,6GHz, è un X6 a 3,2GHz, si overclocca molto di più e scalda/consuma uguale ed anche meno ad un X4 C3.
Se facciamo una correlazione tra BD ed il Thuban, ritroviamo gli stessi vantaggi ma amplificati.
BD in monocore non avrà 200MHz in più (come da 1090T a 965C3), ma con tutta probabilità avrà almeno + di 1GHz di clock.
BD in multicore non c'è storia... passare da X6 a 3,2GHz ad un X8 a 4GHz, c'è un oceano.
Io arrivo a 4,5GHz in OC con il Thuban X6, a liquido. se BD X8 verrà commercializzato ad almeno 4GHz stock, i 4,5GHz sarebbero una frequenza ottenibile ad aria e con dissi stock, magari senza neppure overvoltare... :)
Comunque il confronto fra monocore e modulo mi sembra solo messo lì per spiegare i vantaggi del multi threading di AMD rispetto al SMT di Intel.
Secondo me poi non ha senso dire: il modulo verrà messo in concorrenza con il dual o il single core Intel... La posizione nel mercato di una CPU la fanno le prestazioni. Se il BD X4 andrà meno di un SB X4 con SMT (dubito) verrà posizionato sotto. Se il BD X4 andrà di più di un SB X4 allora si posizionerà fra SB X4 e SB X6 (e secondo me sarà così).
paolo.oliva2
08-10-2010, 10:19
Comunque il confronto fra monocore e modulo mi sembra solo messo lì per spiegare i vantaggi del multi threading di AMD rispetto al SMT di Intel.
Secondo me poi non ha senso dire: il modulo verrà messo in concorrenza con il dual o il single core Intel... La posizione nel mercato di una CPU la fanno le prestazioni. Se il BD X4 andrà meno di un SB X4 con SMT (dubito) verrà posizionato sotto. Se il BD X4 andrà di più di un SB X4 allora si posizionerà fra SB X4 e SB X6 (e secondo me sarà così).
Se BD X4 si posizionasse tra SB X4 e SB X6, probabilmente un BD X8 potrebbe contrastare un SB X10.
Heimdallr
08-10-2010, 10:52
Comunque se BD X8 avesse prestazioni simili a SB X8 sarebbe da :sbav:
Ciao
forse ho capito cosa intendi :)
Dunque a meno di non aver cannato completamente l'articolo http://www.agner.org/optimize/microarchitecture.pdf
I decoder generano le macro ops, lo scomponimento in micro ops avviene quando entrano negli issue slot, e poi ricomposti, questo succede sia per istruzioni Int che fpu ,ovvero il retirement buffer è condiviso tra alu e fp unit.
http://www.hwupgrade.it/forum/showpost.php?p=33085038&postcount=3254
Io la sapevo cosi' (dimmi se penso male!):
le macro-operazioni sono le operazioni richieste dal programma in esecuzione. Le macro operazioni sono le operazioni complesse relative in questo caso all'ISA x86, un ISA CISC, appunto (quindi in grado di supportare operazioni complesse).
I processori per poter eseguire queste macro-ops devono prima scomporle in micro-ops (RISC) , attraverso la fase di decode, e poi eseguire queste singole micro-ops (fase execute), per poi ricomporle nei risultati "complessi" che il programma si sarebbe aspettato (quello che fanno le retire units), e quindi renderle disponibili al programma stesso, scrivendone i risultati in memoria (fase di write-back).
Ad esempio (esempio stupido) se esegui una potenza sara' una operazione intera, ma a livello di unità intere non hai la possibilità di eseguirla direttamente. Userai quindi le alu (parallelizzando i calcoli) per eseguire n volte la moltiplicazione come se fosse un albero, utilizzando tanti figli quante unità ALU avrai nella tua INT unit. Moltiplicherai tra loro i risultati di ogni "foglia" componendo il risultato finale nelle retire units. Una volta avrai il tuo "macro" risultato potrai restituirlo al programma che te lo ha chiesto, rendendoglielo disponibile in memoria (fase di writeback).
ora da queste mie "nozioni" (che ripeto, potrebbero essere sbagliate) guarda questa figura:
http://www.techreport.com/r.x/bulldozer-uarch/bulldozer-frontend.jpg
Come vedi le due unità intere (cores) hanno un solo fetch ed un solo decoder, pur avendo ognuno la sua retire. Sappiamo inoltre che la cache l1 relativa alle istruzioni è UNIFICATA per entrambi. La mia ipotesi parte appunto da queste considerazioni, ed in effetti non sarebbe un vero e proprio "reverse hyperthreading" (lo sarebbe forse a livello di "micro-istruzioni"), in quanto agirebbe alternativamente su due unità intere senza creare un vero e proprio altro thread, ma gestendo l'unico esistente in maniera alternata e potenzialmente doppia. L'output sarebbe comunque seriale ed identico a quello di processori con singolo core.
Il paragone con l'SLI calza a pennello:
Preso da wikipedia (http://it.wikipedia.org/wiki/Scalable_Link_Interface):
Dal driver della scheda video è possibile selezionare 2 criteri differenti di ripartizione del carico di lavoro tra le schede video operanti in parallelo:
* Alternate Frame Rendering (AFR): il rendering della scena viene eseguito in modo sequenziale, con la prima scheda che renderizza i frames pari e l'altra quelli dispari.
* Split Frame Rendering (SFR): con questa tecnica il rendering di ogni frame viene diviso tra le due schede. La percentuale di rendering può essere 50-50, ma anche divisa dinamicamente tra le due schede a seconda del tipo di applicazione che viene eseguita.
Considera appunto il primo caso, ed immagina l'output seriale come la sequenza di frame che vedi su schermo.
Ogni frame e' la tua MACRO istruzione, composta da tantissime micro-istruzioni (calcoli sui vertici, effetti, ecc.ecc.)
Hai 2 GPU, ed ognuna di loro si alterna nei calcoli relativi ad una Macro-istruzione (frame), restituendoti una sequenza seriale (la visione di una schena 3d) potenzialmente al doppio della velocità.
Io ragiono in macro-istruzioni. Che poi vengano scomposte e gestite da N alu dove ognuna lavorerà ad una singola micro-istruzione non mi importa, perche' dovresti comunque ragionare come se la loro portata (in input ed in output) fosse virtualmente "doppia", capisci cosa intendevo? :)
Se BD X4 si posizionasse tra SB X4 e SB X6, probabilmente un BD X8 potrebbe contrastare un SB X10.
Secondo me questa affermazione va oltre ogni ragionevole ottimismo. :p
Si è passati da un "speriamo che BD x6 competa con SB x4" al capovolgimento completo di fronte.
A mio parere BD andrà meno di SB a parità di core fisici, per tanti motivi:
- i core di BD condividono risorse, quindi se usati entrambi i core in un solo modulo, ci sarà un calo di prestazioni (quello famoso stimato intorno al 20%).
- i core SB potranno processare ognuno due thread, in certi ambiti i migliramenti prestazionali sono sensibili.
- codice ottimizzato intel
Questo naturalmente non è di per se un male: strutturare BD in quel modo è una scelta architetturale che si spera porti nel complesso vantaggi rispetto a SB.
Ma in un raffronto core-to-core dubito che SB finirà in svantaggio.
Se poi dovesse succedere, tanto meglio per AMD! ;)
Già altri siti hanno detto che a parità di frequenza e core BD andrà meno di SB. Probabilmente avrà un IPC maggiore di Phenom II, ma sicuramente minore di SB. E questo mi pare assodato.
Però se si ragionasse a parità di core e di TDP invece la situazione probabilmente cambierebbe ;)
capitan_crasy
08-10-2010, 19:56
Già altri siti hanno detto che a parità di frequenza e core BD andrà meno di SB. Probabilmente avrà un IPC maggiore di Phenom II, ma sicuramente minore di SB. E questo mi pare assodato.
Però se si ragionasse a parità di core e di TDP invece la situazione probabilmente cambierebbe ;)
Ma anche no, caro cionci...;)
Ma anche no, caro cionci...;)
Secondo me è così, c'è poco da fare. Si parla del 10-15% di IPC in più rispetto ad un Phenom II, quindi è impossibile che abbia un IPC maggiore del SB. Dovrebbe avere un IPC superiore almeno del 20-25% rispetto ad un Phenom II...
capitan_crasy
08-10-2010, 21:05
Secondo me è così, c'è poco da fare. Si parla del 10-15% di IPC in più rispetto ad un Phenom II, quindi è impossibile che abbia un IPC maggiore del SB. Dovrebbe avere un IPC superiore almeno del 20-25% rispetto ad un Phenom II...
Ma il problema è chi parla del 15% o del 10% o qualsiasi altra percentuale sono solo voci o rumors, non esiste nessuna conferma del IPC di bulldozer sul K10 ne su SB.
La verità è che nessuno di noi, nelle nostre personali teorie, può dare o quantificare in modo esatto le prestazioni di BD...
Ma il problema è chi parla del 15% o del 10% o qualsiasi altra percentuale sono solo voci o rumors, non esiste nessuna conferma del IPC di bulldozer sul K10 ne su SB.
La verità è che nessuno di noi, nelle nostre personali teorie, può dare o quantificare in modo esatto le prestazioni di BD...
In modo esatto è impossibile, ma non c'è un sito o forum fra tutti quelli che hanno analizzato a fondo l'architettura che assegna un aumento di IPC maggiore del 15%. Questo credo che qualcosa voglia dire. Ben venga se fosse superiore, ma al momento attuale, viste le caratteristiche del progetto, nessuno pensa o spera che lo sia.
capitan_crasy
08-10-2010, 21:30
In modo esatto è impossibile, ma non c'è un sito o forum fra tutti quelli che hanno analizzato a fondo l'architettura che assegna un aumento di IPC maggiore del 15%. Questo credo che qualcosa voglia dire. Ben venga se fosse superiore, ma al momento attuale, viste le caratteristiche del progetto, nessuno pensa o spera che lo sia.
Vuol dire che ci sono rumors non confermati che parlano di un IPC del 15% ma niente di sicuro o di certo, inoltre ragionare sulla carta è un conto ma i numeri reali sul campo sono tutt'altra cosa e questo vale anche in caso di risultati negativi...;)
Vuol dire che ci sono rumors non confermati che parlano di un IPC del 15% ma niente di sicuro o di certo, inoltre ragionare sulla carta è un conto ma i numeri reali sul campo sono tutt'altra cosa e questo vale anche in caso di risultati negativi...;)
Allora chiudiamo il thread ed aspettiamo che esca :D
Non esiste solo l'IPC... :D
Esiste anche la frequenza... :D
E le latenze delle caches, le promesse di global foundries, le voci sul FO4 minore (che sarebbero confermate dalle latenze delle caches maggiori) fanno supporre che saranno moooolto alte. :D
Anche ammesso che l'IPC del BD non arrivi a quella del SB, ci sono buone speranze di clock di base del 30% superiori e di clock turbo anche oltre il 30% superiori... :D
Se il TDP e sopratutto il consumo reale (in idle e full load) sono comparabili, chi se ne frega se per avere le stesse prestazioni (o superiori) BD deve avere un GHZ in più... :D
Anche ammesso che l'IPC del BD non arrivi a quella del SB, ci sono buone speranze di clock di base del 30% superiori e di clock turbo anche oltre il 30% superiori... :D
Se il TDP e sopratutto il consumo reale (in idle e full load) sono comparabili, chi se ne frega se per avere le stesse prestazioni (o superiori) BD deve avere un GHZ in più... :D
Appunto, è esattamente quello che intendevo io...
paolo.oliva2
08-10-2010, 23:03
Secondo me questa affermazione va oltre ogni ragionevole ottimismo. :p
Si è passati da un "speriamo che BD x6 competa con SB x4" al capovolgimento completo di fronte.
A mio parere BD andrà meno di SB a parità di core fisici, per tanti motivi:
- i core di BD condividono risorse, quindi se usati entrambi i core in un solo modulo, ci sarà un calo di prestazioni (quello famoso stimato intorno al 20%).
- i core SB potranno processare ognuno due thread, in certi ambiti i migliramenti prestazionali sono sensibili.
- codice ottimizzato intel
Questo naturalmente non è di per se un male: strutturare BD in quel modo è una scelta architetturale che si spera porti nel complesso vantaggi rispetto a SB.
Ma in un raffronto core-to-core dubito che SB finirà in svantaggio.
Se poi dovesse succedere, tanto meglio per AMD! ;)
Io seguivo il ragionamento di Cionci, che avendo riportato che un BD X4 (può darsi) che si posizioni tra SB X4 e SB X6, quindi, mettendolo ai numeri, = SB X5.
visto AMD in multicore sprinta meglio e il clock lo aiuta per via di un minor leakage,
un BD X8 = SB X10.
Inoltre, visto che BD sarebbe in commercio almeno 8 mesi prima di SB X10, sarebbe presumibile un ulteriore step sia di silicio che di procio...
capitan_crasy
08-10-2010, 23:08
Allora chiudiamo il thread ed aspettiamo che esca :D
bè questo no, volevo solo sottolineare che la frase "ormai è assodato" è azzardata...:)
Non esiste solo l'IPC... :D
Esiste anche la frequenza... :D
E le latenze delle caches, le promesse di global foundries, le voci sul FO4 minore (che sarebbero confermate dalle latenze delle caches maggiori) fanno supporre che saranno moooolto alte. :D
Anche ammesso che l'IPC del BD non arrivi a quella del SB, ci sono buone speranze di clock di base del 30% superiori e di clock turbo anche oltre il 30% superiori... :D
Se il TDP e sopratutto il consumo reale (in idle e full load) sono comparabili, chi se ne frega se per avere le stesse prestazioni (o superiori) BD deve avere un GHZ in più... :D
Le ultime voci su Bulldozer parlano dell'importanza della grandezza della cache L2 e di come possa essere molto più determinante di quanto sia nell'architettura K10...
Inoltre il nuovo controller RAM e la cache L3 saranno in grado di aumentare la banda passante; tutte cose che AMD non ha accennato alla presentazione di bulldozer...
io non sono certo un esperto ,ma bulldozer è qualcosa che è stato progettato per essere il numero ''uno'' sia in single che multi-tread;ora questa cosa puo ,chiaramente,avverarsi oppure non completamente(è pure progettato per la futura scalabilità dei moduli,che rappresentano la piu piccola unità logica che riesce ad auto gestirsi) ;ora senza tifare per uno o l'altro ,ma semplicemente mi viene il dubbio proprio che il 32nm e proprio quello idoneo(per il momento) come processo, perchè le pipeline proprio per ''svuotarsi'' richiederanno alte(e pure spinte) frequenze.(se non si'' intoppano troppo e si ingoffano'')...ed il turbo farà vedere il suo ''senso'' a frequenze già spinte
è chiaro che anche le slide siano soggette a variazioni(per la teoria della possibilità) ma in una slide amd del 26 july 2007 i nuovi core ''bulldozer'' venivano(ci sognavo che sarebbe uscito a 45 nm con 8 core sandiger,ma la sfida prese un altra via...vediamo ora la ''RIPROPOSTA'' ) proiettati ad avverarsi come(in alcuni aspetti descrittivi)
''CONTINUED :D scaling for single-tread performance''
''designed to be the highest performing single and multi-threaded compute core in history:eek: '' :eekk:
dichiararmi incredulo a questo non avrebbe senso ,e neanche tanto meno pensare di garantirmi la sfida impostandomi come solo ottimista sognatore,ma una cosa non perdo mai d'occhio;che tutt'altro è che una parte di un disegno all'orizzante molto più ampio e piu VARIO(ci sara pure ati dentro il processore)
e tutto questo che ci aspettiamo non è solo una trepida attesa....ma anzi tutt'altro ,....l'inizio di un gradevole viaggio verso il futuro...verso il vero ''CORE'' della fusione:read:
paolo.oliva2
08-10-2010, 23:30
Secondo me, per avere una situazione il più possibile vicina alla realtà, dobbiamo partire da questo punto:
Il 32nm HKMG AMD permetterà un margine del 33% sopra al clock Intel sia nella condizione Turbo che in quella stock per tutti i core.
Vantaggio Intel odierno sul Phenom II (Valori IPC approssimativi e, proprio per cercare un esempio concreto, non ho certo riportato differenze di IPC scarse, anzi, tutt'altro)
i7 = 30% di IPC maggiore del Phenom II.
SB = 45% di IPC maggiore del Phenom II.
Ora, rapportando un IPC per BD = a quello del Phenom II con il clock del 32nm HKMG AMD, uscirebbe questo:
Un i7 avrebbe una potenza (IPC x clock) del 3% inferiore a BD.
Un SB avrebbe una potenza (IPC x clock) del 12% superiore a BD.
Discutere poi se l'IPC di BD sia = al Phenom II, sia del 15% superiore, ok, si può ipotizzare qualsiasi IPC, ma comunque rimane di fatto che a tutti gli effetti già solo per il clock un BD si posizionerebbe sopra di poco un X4 i7 e sotto di poco ad un SB X4.
Con queste differenze, se già andassimo a teorizzare un BD X8 vs SB X8, visto la scalabilità migliore degli AMD, non mi sembra azzardato già reputare per certo una parità.
Se fino a qui siamo concordi, questo vorrebbe dire che BD senza incrementi di IPC rispetto ad un Phenom II si posiziona alla pari rispetto ad un SB. Ma... se ci fossero variazioni positive di IPC in BD, mi sembra abbastanza chiaro che BD andrà più di SB.
Ora... se AMD ha creato BD con l'intento di contrastare SB, IPC o non IPC, direi che l'obiettivo è centrato.
Sarebbe veramente interessante se nel secondo trimestre 2011 AMD commercializzasse BD X8 a 400€. Cosa darei per vedere la faccia dei commerciali Intel nel rivedere il loro listino :)
http://www.hwupgrade.it/forum/showpost.php?p=33085038&postcount=3254
Io la sapevo cosi' (dimmi se penso male!):
le macro-operazioni sono le operazioni richieste dal programma in esecuzione. Le macro operazioni sono le operazioni complesse relative in questo caso all'ISA x86, un ISA CISC, appunto (quindi in grado di supportare operazioni complesse).
I processori per poter eseguire queste macro-ops devono prima scomporle in micro-ops (RISC) , attraverso la fase di decode, e poi eseguire queste singole micro-ops (fase execute), per poi ricomporle nei risultati "complessi" che il programma si sarebbe aspettato (quello che fanno le retire units), e quindi renderle disponibili al programma stesso, scrivendone i risultati in memoria (fase di write-back).
Ad esempio (esempio stupido) se esegui una potenza sara' una operazione intera, ma a livello di unità intere non hai la possibilità di eseguirla direttamente. Userai quindi le alu (parallelizzando i calcoli) per eseguire n volte la moltiplicazione come se fosse un albero, utilizzando tanti figli quante unità ALU avrai nella tua INT unit. Moltiplicherai tra loro i risultati di ogni "foglia" componendo il risultato finale nelle retire units. Una volta avrai il tuo "macro" risultato potrai restituirlo al programma che te lo ha chiesto, rendendoglielo disponibile in memoria (fase di writeback).
ora da queste mie "nozioni" (che ripeto, potrebbero essere sbagliate) guarda questa figura:
http://www.techreport.com/r.x/bulldozer-uarch/bulldozer-frontend.jpg
Come vedi le due unità intere (cores) hanno un solo fetch ed un solo decoder, pur avendo ognuno la sua retire. Sappiamo inoltre che la cache l1 relativa alle istruzioni è UNIFICATA per entrambi. La mia ipotesi parte appunto da queste considerazioni, ed in effetti non sarebbe un vero e proprio "reverse hyperthreading" (lo sarebbe forse a livello di "micro-istruzioni"), in quanto agirebbe alternativamente su due unità intere senza creare un vero e proprio altro thread, ma gestendo l'unico esistente in maniera alternata e potenzialmente doppia. L'output sarebbe comunque seriale ed identico a quello di processori con singolo core.
Il paragone con l'SLI calza a pennello:
Preso da wikipedia (http://it.wikipedia.org/wiki/Scalable_Link_Interface):
Considera appunto il primo caso, ed immagina l'output seriale come la sequenza di frame che vedi su schermo.
Ogni frame e' la tua MACRO istruzione, composta da tantissime micro-istruzioni (calcoli sui vertici, effetti, ecc.ecc.)
Hai 2 GPU, ed ognuna di loro si alterna nei calcoli relativi ad una Macro-istruzione (frame), restituendoti una sequenza seriale (la visione di una schena 3d) potenzialmente al doppio della velocità.
Io ragiono in macro-istruzioni. Che poi vengano scomposte e gestite da N alu dove ognuna lavorerà ad una singola micro-istruzione non mi importa, perche' dovresti comunque ragionare come se la loro portata (in input ed in output) fosse virtualmente "doppia", capisci cosa intendevo? :)
Ciao
E' vero che l'isa x86 sia CISC, ma ogni istruzione non è una macro ops, ovvero una LEA m->r ad esempio , calcola l'effettivo indirizzo di un operando (m) e lo salva in un registro R, come puòi vedere si tratta di operazioni scomponibili in un calcolo dell'indirizzo (AGU) e suo store in registro (gprs od i registri architetturali) specificato. Bene nelle arhcitetture amd i decoder leggono questa istruzione e la decodificiano in una singola mop, in intel invece si avranno diverse micro op, ma l'istruzione x86 è sempre una.
Queste sono le fasi del decoding fetch del k10\k8
1. Instruction fetch 1. 32 bytes per clock cycle on K10, 16 bytes on K7 and K8.
2. Instruction fetch 2 and branch prediction.
3. Pick/Scan. Can buffer up to 7 instructions. Distributes three instructions into the
three decoder pipelines. The following stages are all split into three parallel pipes.
4. Decode 1. Splits the instruction codes into their components.
5. Decode 2. Determines input and output registers.
6. Pack. Up to six macro-operations generated from the decoders are arranged into
lines of three macro-operations for the three execution pipelines.
7. Pack/Decode. Register renaming. Integer registers are read from the "Integer Future
File and Register File". Submits integer macro-operations to the three integer pipes.
Submits floating point macro-operations to the floating point pipes.
Un punto per il reverse hypertreading, le L d dovrebbero avere delle porte di comunicazione cosi come le L\S unit...
astroimager
09-10-2010, 13:15
Mamma mia, ho esigenze quasi immediate di mobilità... quando vedremo secondo voi le prime soluzioni Ontario (a prezzi non da latrocinio)?
capitan_crasy
09-10-2010, 13:17
Mamma mia, ho esigenze quasi immediate di mobilità... quando vedremo secondo voi le prime soluzioni Ontario (a prezzi non da latrocinio)?
primi mesi del 2011 (forse già a gennaio)...
astroimager
09-10-2010, 13:25
primi mesi del 2011 (forse già a gennaio)...
Sarà dura resistere... 2 giorni fa stavo già per cedere (cornificando AMD)!
Sono anche un po' preoccupato da questo:
http://www.hwupgrade.it/articoli/portatili/2562/acer-aspire-one-521-con-amd-vision_5.html
Speriamo di vedere presto una paronamica completa sulle prestazioni (ivi inclusi i consumi)!
Sarà dura resistere... 2 giorni fa stavo già per cedere (cornificando AMD)!
Sono anche un po' preoccupato da questo:
http://www.hwupgrade.it/articoli/portatili/2562/acer-aspire-one-521-con-amd-vision_5.html
Speriamo di vedere presto una paronamica completa sulle prestazioni (ivi inclusi i consumi)!
Ciao
A chi lo dici. Chi non ha mai provato un netbook con atom non può capire:cry:
Dal mio phII 3.7GHZ al netbook con atom ho sentito una differenza pazzesca, 3 ore per apire una slide od estrarre un archivio ... Eppure pure io purtroppo ho esigenze di mobilità da netbook però sta cpu fa veramente troppo schifo:(
Ontario dove sei?
capitan_crasy
09-10-2010, 13:56
Aggiornamento sui southbridge Hudson per le piattaforme Sabine e Ontario:
http://www.pctunerup.com/up//results/_201010/20101009134909_AMD_Hudson_M.png
In pratica non cambia nulla sulla notizia data qualche tempo fa su questo thread...
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=32843601&postcount=1778)
I southbridge con le USB 3.0 saranno le versione Hudson serie 3; questo componente con tutta probabilità sarà presente sulle piattaforme Scorpius, la quale saranno utilizzate le CPU Bulldozer...
Clicca qui... (http://www.semiaccurate.com/2010/10/08/amd-readying-three-mobile-fusion-chipsets/)
paolo.oliva2
09-10-2010, 14:13
Ciao
E' vero che l'isa x86 sia CISC, ma ogni istruzione non è una macro ops, ovvero una LEA m->r ad esempio , calcola l'effettivo indirizzo di un operando (m) e lo salva in un registro R, come puòi vedere si tratta di operazioni scomponibili in un calcolo dell'indirizzo (AGU) e suo store in registro (gprs od i registri architetturali) specificato. Bene nelle arhcitetture amd i decoder leggono questa istruzione e la decodificiano in una singola mop, in intel invece si avranno diverse micro op, ma l'istruzione x86 è sempre una.
Queste sono le fasi del decoding fetch del k10\k8
1. Instruction fetch 1. 32 bytes per clock cycle on K10, 16 bytes on K7 and K8.
2. Instruction fetch 2 and branch prediction.
3. Pick/Scan. Can buffer up to 7 instructions. Distributes three instructions into the
three decoder pipelines. The following stages are all split into three parallel pipes.
4. Decode 1. Splits the instruction codes into their components.
5. Decode 2. Determines input and output registers.
6. Pack. Up to six macro-operations generated from the decoders are arranged into
lines of three macro-operations for the three execution pipelines.
7. Pack/Decode. Register renaming. Integer registers are read from the "Integer Future
File and Register File". Submits integer macro-operations to the three integer pipes.
Submits floating point macro-operations to the floating point pipes.
Un punto per il reverse hypertreading, le L d dovrebbero avere delle porte di comunicazione cosi come le L\S unit...
Io non ho la capacità tecnica di seguirti... però c'è una cosa:
Ogni vocina di corridoio, anche la più incredibile, alla fine si è dimostrata molto più vicina alla realtà (Vi ricordate quelle slide dell'FX a 4GH-4,4GHz stock? Ultimamente poi si è scoperto che il progetto c'era, quindi poteva essere realtà).
Questo hypertreading è da mo' che si sussurra...
Nella mia ignoranza, però, nel BD io intravedo una logica troppo complessa per essere reputato uno "snellimento" del K10.
Inoltre, se AMD non avesse nulla da nascondere, non vedo il nesso di non far vedere i die dei core bene in chiaro. A me sembra un messaggio più che esplicito che non ha da nascondere solo le latenze delle cache ma un qualche cosa di più. E poi a me sembra che ci sia troppa sicurezza in AMD. Dalla scotto del Phenom I, AMD è stata più che attenta sia nelle date di distribuzione di nuovi prodotti che sia su false "speranze" di potenza.
Sarebbe mai andata AMD di "fianco" all'IDF con presentazioni del Phenom I? Con BD l'ha fatto. Ma non ha mai fondato il discorso sulla potenza di BD sul silicio, ma ha sempre incentrato (sul vago purtroppo) sull'architettura.
BD deve essere un concentrato di novità su studi ed esperienze recenti e passate di AMD.
Boh... io pensandoci non vedrei una strategia di marketing basata sul discorso "BD è potente perché il silicio lo permette", ma più su "BD è potente perché l'architettura è innovativa e grazie a GF per il suo silicio, lo sarà ancora di più".
Io ho questa sensazione... sinceramente non credo di sbagliarmi.
paolo.oliva2
09-10-2010, 14:22
Ciao
A chi lo dici. Chi non ha mai provato un netbook con atom non può capire:cry:
Dal mio phII 3.7GHZ al netbook con atom ho sentito una differenza pazzesca, 3 ore per apire una slide od estrarre un archivio ... Eppure pure io purtroppo ho esigenze di mobilità da netbook però sta cpu fa veramente troppo schifo:(
Ontario dove sei?
^^
La mia ragazza ce l'ha un Atom.
Io non riesco neppure a scriverci i post per questo TH... l'ho usato una volta e... ho sclerato immediatamente. Non si può scrivere una frase e come guardi per rileggerla ti accorgi che... ancora non c'è :eek: e devi aspettare qualche secondo.
Fare cavallo di battaglia sull'autonomia della batteria tralasciando che... in un altro portatile le stesse cose le faresti in metà tempo... scusate, allora non è meglio un cellulare? E' pure più piccolo ed ha maggiore autonomia. :sofico: .
Io non ho la capacità tecnica di seguirti... però c'è una cosa:
Ogni vocina di corridoio, anche la più incredibile, alla fine si è dimostrata molto più vicina alla realtà (Vi ricordate quelle slide dell'FX a 4GH-4,4GHz stock? Ultimamente poi si è scoperto che il progetto c'era, quindi poteva essere realtà).
Questo hypertreading è da mo' che si sussurra...
Nella mia ignoranza, però, nel BD io intravedo una logica troppo complessa per essere reputato uno "snellimento" del K10.
Inoltre, se AMD non avesse nulla da nascondere, non vedo il nesso di non far vedere i die dei core bene in chiaro. A me sembra un messaggio più che esplicito che non ha da nascondere solo le latenze delle cache ma un qualche cosa di più. E poi a me sembra che ci sia troppa sicurezza in AMD. Dalla scotto del Phenom I, AMD è stata più che attenta sia nelle date di distribuzione di nuovi prodotti che sia su false "speranze" di potenza.
Sarebbe mai andata AMD di "fianco" all'IDF con presentazioni del Phenom I? Con BD l'ha fatto. Ma non ha mai fondato il discorso sulla potenza di BD sul silicio, ma ha sempre incentrato (sul vago purtroppo) sull'architettura.
BD deve essere un concentrato di novità su studi ed esperienze recenti e passate di AMD.
Boh... io pensandoci non vedrei una strategia di marketing basata sul discorso "BD è potente perché il silicio lo permette", ma più su "BD è potente perché l'architettura è innovativa e grazie a GF per il suo silicio, lo sarà ancora di più".
Io ho questa sensazione... sinceramente non credo di sbagliarmi.
Ciao Paolo :)
Io non sono un tecnico esperto, però concordo in parte con la tua visione.
Dico subito che concordo che bd sarà più potente di un PhII (e secondo me avrà un ipc molto simile a quello del nehalem dunque abbastanza vicino a sandy bridge) per motivi architetturali (presumo un 15-20% di ipc in più in media) sia perchè hanno strutturato l'architettura per essere capace di salire di clock a più non posso. Quello che non condivido è l'idea che ci possa essere un hypertreading inverso, perchè comporterebbe cores abbastanza grossi e difficili da produre visto l'ammontare di logica, che, presumo richiedano se implementassero tale tecnologia.
Sempre secondo me BD sarà molto migliore del PhII per l'architettura più efficiente e votata al salire di clock.
Ovviamente se poi implementassero il reverse HTT con incrementi a doppia cifra sul singolo thread e clock alti sarei molto stupito, una cosa è certa amd ha il know how per poterlo fare, solo non penso in BD
^^
La mia ragazza ce l'ha un Atom.
Io non riesco neppure a scriverci i post per questo TH... l'ho usato una volta e... ho sclerato immediatamente. Non si può scrivere una frase e come guardi per rileggerla ti accorgi che... ancora non c'è :eek: e devi aspettare qualche secondo.
Fare cavallo di battaglia sull'autonomia della batteria tralasciando che... in un altro portatile le stesse cose le faresti in metà tempo... scusate, allora non è meglio un cellulare? E' pure più piccolo ed ha maggiore autonomia. :sofico: .
Quto tutto purtroppo :cry:
Ontario mio al day one sempre se non costa mezzo stipendio mio, quindi deve costare molto poco:(
astroimager
09-10-2010, 14:39
Ciao
A chi lo dici. Chi non ha mai provato un netbook con atom non può capire:cry:
Dal mio phII 3.7GHZ al netbook con atom ho sentito una differenza pazzesca, 3 ore per apire una slide od estrarre un archivio ... Eppure pure io purtroppo ho esigenze di mobilità da netbook però sta cpu fa veramente troppo schifo:(
Ontario dove sei?
Onestamente il netbook da 180 euro che ho provato mi è sembrato più reattivo del mio vecchio Athlon XP-M 2200+, con il quale ovviamente arranco parecchio usando applicativi moderni.
Secondo me Atom per fare operazioni basilari è più che sufficiente. Quello che mi aspetto da Ontario è un gradino nettamente superiore a livello di multimedialità e longevità, ovviamente a parità di consumo.
astroimager
09-10-2010, 14:45
Aggiornamento sui southbridge Hudson per le piattaforme Sabine e Ontario:
http://www.pctunerup.com/up//results/_201010/20101009134909_AMD_Hudson_M.png
In pratica non cambia nulla sulla notizia data qualche tempo fa su questo thread...
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=32843601&postcount=1778)
I southbridge con le USB 3.0 saranno le versione Hudson serie 3; questo componente con tutta probabilità sarà presente sulle piattaforme Scorpius, la quale saranno utilizzate le CPU Bulldozer...
Clicca qui... (http://www.semiaccurate.com/2010/10/08/amd-readying-three-mobile-fusion-chipsets/)
:(
Avevo capito male: ma quindi per Ontario niente Gigabit e soprattutto USB 3.0, se non con chip dedicati?
Spero che sia per contenete i costi... anche perché la Gigabit ormai si trova anche nei netbook più scandalosi!
Onestamente il netbook da 180 euro che ho provato mi è sembrato più reattivo del mio vecchio Athlon XP-M 2200+, con il quale ovviamente arranco parecchio usando applicativi moderni.
Secondo me Atom per fare operazioni basilari è più che sufficiente. Quello che mi aspetto da Ontario è un gradino nettamente superiore a livello di multimedialità e longevità, ovviamente a parità di consumo.
Ciao
certo per leggere mail e navigare su internet è sufficiente, ma come reattività, guarda non so che netbook hai provato, ho un aspire one con n270 1gb di ram ed hd da 160gb, beh sto provando in questo momento a tenere la pagina del forum aperta e comprimere un po di dati ricevuti via mail. E non è un esperienza entusiasmante, credimi. Giocare ad un giochino flash è quasi impossibile, oppure vedere un fimato youtube a definizione più di 480p..:cry:
Poi vabbeh magari non sono abituato io, ma è snervante.
capitan_crasy
09-10-2010, 14:58
:(
Avevo capito male: ma quindi per Ontario niente Gigabit e soprattutto USB 3.0, se non con chip dedicati?
Spero che sia per contenete i costi... anche perché la Gigabit ormai si trova anche nei netbook più scandalosi!
Hudson X1 non è altro che SB810M (super) castrato...
Per la porta Lan non cè problema; chip esterno come hanno sempre fatto...;)
Athlon 64 3000+
09-10-2010, 15:04
Sono molto interessato ad Hudson-D3 che per mè si chiamerà SB950 per via del supporto a 4 porte usb 3.0 native.
Se poi verrà confermato che le mobo AM3+ potranno ospitare le cpu AM3 allora potrei decidere di prendere una mobo con 990X o 970A tenendomi il mio Phenom II 955 C3 e aspettare più avanti a prendere Buldozer.
astroimager
09-10-2010, 16:14
Ciao
certo per leggere mail e navigare su internet è sufficiente, ma come reattività, guarda non so che netbook hai provato, ho un aspire one con n270 1gb di ram ed hd da 160gb, beh sto provando in questo momento a tenere la pagina del forum aperta e comprimere un po di dati ricevuti via mail. E non è un esperienza entusiasmante, credimi. Giocare ad un giochino flash è quasi impossibile, oppure vedere un fimato youtube a definizione più di 480p..:cry:
Poi vabbeh magari non sono abituato io, ma è snervante.
Ho provato un N450 su XP, non penso sia molto più veloce.
Secondo me pretendi un po' troppo da questi gingilli, che nascono appunto per consentire operazioni basilari, costare e consumare il meno possibile.
Se è richiesta una potenza decente meglio un notebook economico, o una soluzione come quella di Spitfire.
In altre parole... ci spero, ovviamente, ma non penso che a parità di autonomia Ontario consenta un boost prestazionale straordinario rispetto ad Atom.
astroimager
09-10-2010, 16:22
Sono molto interessato ad Hudson-D3 che per mè si chiamerà SB950 per via del supporto a 4 porte usb 3.0 native.
Se poi verrà confermato che le mobo AM3+ potranno ospitare le cpu AM3 allora potrei decidere di prendere una mobo con 990X o 970A tenendomi il mio Phenom II 955 C3 e aspettare più avanti a prendere Buldozer.
Stessa cosa farò probabilmente anch'io, specie se le nuove mobo saranno fin da subito ben progettate e sufficientemente stabili. Sarà l'occasione per passare alle DDR3 e sfruttare appieno le potenzialità del 965.
Ho provato un N450 su XP, non penso sia molto più veloce.
Secondo me pretendi un po' troppo da questi gingilli, che nascono appunto per consentire operazioni basilari, costare e consumare il meno possibile.
Se è richiesta una potenza decente meglio un notebook economico, o una soluzione come quella di Spitfire.
In altre parole... ci spero, ovviamente, ma non penso che a parità di autonomia Ontario consenta un boost prestazionale straordinario rispetto ad Atom.
Cmq guardate che l'hanno messo in mostra Ontario ,facendo vedere un gioco in directx 11,non vi sembra sufficiente ?
A me personalmente anche se uno dura 12 ore e un altro 6 ore ,che parliamo a fare
Ontario ,proprio per quando riguarda internet ,gli puoi montare anche Windows 7 ,e pure 8
Ontario è un altro livello,inutile fare paragoni,anche se l'autonomia è importante e possa suscitare indecisione
astroimager
09-10-2010, 18:01
Cmq guardate che l'hanno messo in mostra Ontario ,facendo vedere un gioco in directx 11,non vi sembra sufficiente ?
A me personalmente anche se uno dura 12 ore e un altro 6 ore ,che parliamo a fare
Ontario ,proprio per quando riguarda internet ,gli puoi montare anche Windows 7 ,e pure 8
Ontario è un altro livello,inutile fare paragoni,anche se l'autonomia è importante e possa suscitare indecisione
Ma infatti Ontario non credo andrà su netbook da 200 euro... almeno non all'inizio. Penso si inserirà, prestazionalmente, fra i netbook di livello medio-alto, e notebook ultra-thin. Offrendo ovviamente di più rispetto sia agli Atom sia - complessivamente - ai CULV.
dark.halo
09-10-2010, 19:10
Ma infatti Ontario non credo andrà su netbook da 200 euro... almeno non all'inizio. Penso si inserirà, prestazionalmente, fra i netbook di livello medio-alto, e notebook ultra-thin. Offrendo ovviamente di più rispetto sia agli Atom sia - complessivamente - ai CULV.
Ontario è per i netbook. Per i notebook ultra -thin e nettop ci sarà zacate.
Ontario dovrà non dico essere più economico di atom n4xx ma di sicuro più dello stesso però affiancato a ion.
Per me si posizionerà come prezzo a metà strada tra un netbook classico e uno dotato di ion. Zacate prenderà la fascia attualmente occupata dalla piattaforma congo sia come prezzo sia per prestazioni (forse qualcosina in più lato cpu,molto meglio lato grafico).
Ovviamente Zacate sarà mio al day one per sostituire il mio muletto PIV Northwood :sofico:
astroimager
09-10-2010, 19:28
Ontario è per i netbook. Per i notebook ultra -thin e nettop ci sarà zacate.
Ontario dovrà non dico essere più economico di atom n4xx ma di sicuro più dello stesso però affiancato a ion.
Per me si posizionerà come prezzo a metà strada tra un netbook classico e uno dotato di ion. Zacate prenderà la fascia attualmente occupata dalla piattaforma congo sia come prezzo sia per prestazioni (forse qualcosina in più lato cpu,molto meglio lato grafico).
Ovviamente Zacate sarà mio al day one per sostituire il mio muletto PIV Northwood :sofico:
Giusto, dimenticavo Zacate.
Il succo del mio discorso è che questa nuova architettura è destinata a un target da leggermente a molto diverso rispetto ai netbook "classici"... lasciando perdere tutti quei modelli (e ne vedo sempre di più) che deviano non poco dalla filosofia del netbook (max economicità e autonomia).
Mi auguro che AMD spazzi via tutta questa roba inutile (tutti i net sopra i €250, insomma)...
astroimager
09-10-2010, 19:30
A proposito di Zacate... e ritornando agli SB: anche nella piattaforma di queste APU non è prevista l'integrazione di USB3.0 / Gigabit?
capitan_crasy
09-10-2010, 19:53
A proposito di Zacate... e ritornando agli SB: anche nella piattaforma di queste APU non è prevista l'integrazione di USB3.0 / Gigabit?
(quarta e ultima colonna)
http://www.pctunerup.com/up/results/_201008/20100816104928_RoadmapHudson.jpg[/QUOTE]
Il Gigabit sarà gestito nativamente nella versione AES, anche se in teoria tutti i southbridge Hudson sono compatibili con tutte le APU e CPU di prossima generazione...
Non escludo che qualche produttore possa presentare qualche versione di Zacate con SB diversi dalla versione 1...
Ciao
E' vero che l'isa x86 sia CISC, ma ogni istruzione non è una macro ops, ovvero una LEA m->r ad esempio , calcola l'effettivo indirizzo di un operando (m) e lo salva in un registro R, come puòi vedere si tratta di operazioni scomponibili in un calcolo dell'indirizzo (AGU) e suo store in registro (gprs od i registri architetturali) specificato. Bene nelle arhcitetture amd i decoder leggono questa istruzione e la decodificiano in una singola mop, in intel invece si avranno diverse micro op, ma l'istruzione x86 è sempre una.
Beh, innanzitutto ti ringrazio per le info tecniche relative all'implementazione del fetch/decode. :)
Tuttavia il fatto che AMD alcune istruzioni le codifichi in una sola micro-op ed intel no dipende penso dalla archietettura, dal numero di alu, dalla loro effettiva implementazione ecc.ecc. (e non e' detto che AMD sia piu' veloce per questo.. non conosco le latenze e gli effettivi algoritmi, quindi non mi esprimo)
Il fatto comunque di poter eseguire in maniera alternata due macro-ops gia' codificate non cambia, indipendentemente dalla architettura (ovviamente il decoder dovrebbe avere una capacità di codifica doppia!).
Si avrebbe comunque il doppio di capacità di calcolo teorica con svantaggi piuttosto ridotti in termini di complessità architetturale, ma anzi avendo la vera possibilità di poter seriamente condividere tutto quanto all'interno del modulo.
Quella l1 instr condivisa.. quelle retire separate.. quel fetch e decode unificato.. uhm.. io rimango della mia idea, che per la cronaca, come ho specificato, non si tratterebbe di un vero e proprio reverse-hyperthreading, ma piu' di uno sdoppiamento di un singolo thread su due unità intere in due rami codificati e distribuiti alternativamente dal decoder potenziato ed unificato.
Magari proprio come se fosse il contrario di Intel che con 4 core gestisce 8 thread (anche se 4 sono praticamente "fasulli"), AMD potrebbe gestire magari 4 threads con 8 cores (magari solo all'occorrenza, chissà) ed occupare pure meno silicio nel confronto "core vs modulo" :) Se fosse cosi' sarebbe prestazionalmente parlando superiore in qualunque campo, non credi?
Un punto per il reverse hypertreading, le L d dovrebbero avere delle porte di comunicazione cosi come le L\S unit...
..però non capisco cosa intendi con questa affermazione.. :mc:
Comunque le load/store delle unità int sono autonome, separate, specifiche ed indipendenti tra i due cores, da quello che avevo letto..
Spitfire84
09-10-2010, 20:51
Ho provato un N450 su XP, non penso sia molto più veloce.
Secondo me pretendi un po' troppo da questi gingilli, che nascono appunto per consentire operazioni basilari, costare e consumare il meno possibile.
Se è richiesta una potenza decente meglio un notebook economico, o una soluzione come quella di Spitfire.
In altre parole... ci spero, ovviamente, ma non penso che a parità di autonomia Ontario consenta un boost prestazionale straordinario rispetto ad Atom.
M301z anche per te? :cincin:
astroimager
10-10-2010, 00:42
M301z anche per te? :cincin:
Un net ora mi sarebbe stato d'aiuto in alcuni compiti... tiro avanti con quello che ho, e dopo Natale si vede... ;)
F1R3BL4D3
10-10-2010, 01:06
^^
La mia ragazza ce l'ha un Atom.
Io non riesco neppure a scriverci i post per questo TH... l'ho usato una volta e... ho sclerato immediatamente. Non si può scrivere una frase e come guardi per rileggerla ti accorgi che... ancora non c'è :eek: e devi aspettare qualche secondo.
Fare cavallo di battaglia sull'autonomia della batteria tralasciando che... in un altro portatile le stesse cose le faresti in metà tempo... scusate, allora non è meglio un cellulare? E' pure più piccolo ed ha maggiore autonomia. :sofico: .
:D se va beh, adesso non esageriamo...Io che ho un eeePC 701 4G non ho questi problemi (ed è una cavolatina a livello hardware).
M301z anche per te? :cincin:
anche il dell m101z, la versione con il k325, mi ha detto l'amico al quale l'ho consigliato che va una bomba :)
paolo.oliva2
10-10-2010, 09:59
:D se va beh, adesso non esageriamo...Io che ho un eeePC 701 4G non ho questi problemi (ed è una cavolatina a livello hardware).
Perché esagero?
Il mio 97mini è più veloce se faccio internet... prb di ritardo riga non ne ho... ma chiaramente la tastiera del telefonino non è "compatibile" con le mie dita... :)
Tra l'altro l'ha pagato 320€ 1 anno fa, un HP.
Che sia piccolo, portatile, mettici tutto quello che vuoi, ma costa pur sempre quasi come un 1090T + mobo... se fai un rapporto prezzo-prestazioni, non è che sia poi tanto economico (e questo vale per tutti, AMD compresa).
Edit:
P.S.
Voglio precisare, per non creare polemica, che l'obiettivo Atom, come potrebbe pure essere un procio AMD nella medesima situazione, è quella di fornire un "computer" con l'obiettivo di avere la più lunga possibile autonomia, a scapito delle prestazioni. Su quest'ottica, è inutile poi pensare che le prestazioni siano uguali a quelle di un computer normale. Nel mio modo di pensare, se uso un PC voglio avere un PC a tutti gli effetti, senza limitazioni alcune (altrimenti in casa avrei tenuto un Sempron di 4 anni fa). Se mi serve la mobilità, a scapito della potenza, molte cose che si possono fare con un sistema portatile di scarsa potenza, si possono avere ugualmente con l'utilizzo di un telefonino con programmi similari ed al limite ottimizzando sicuramente la spesa. Questo è la mia ottica di pensiero, che rimarrà uguale sia se ora parlo di Atom, sia in futuro con AMD nel caso di prestazioni simili. Altri, con altre esigenze, possono tranquillamente avere opinioni differenti, ma io con l'Atom della mia ragazza sclero, e certamente non esagero perché non mi sento di avere un vero PC tra le mani e non mi "accontento".
Penso che sia abb prematuro chiederlo, ma per Ontario e relative schede madri è prevista anche la vendita retail cm per Atom?
Con uno di questi processorini si potrebbe avere a disposizione il nas-mediacenter definitivo!!!
dark.halo
10-10-2010, 13:57
Penso che sia abb prematuro chiederlo, ma per Ontario e relative schede madri è prevista anche la vendita retail cm per Atom?
Con uno di questi processorini si potrebbe avere a disposizione il nas-mediacenter definitivo!!!
penso proprio di si.
Asus ci sta lavorando su...
http://www.nordichardware.com/news/69-cpu--chipset/40827-asus-uses-ontario-fusion-in-mini-itx-htpc-board.html
The few benchmarks available with Ontario points to nearly twice the performance of Intel's dual-core Atom D525 CPU and then we haven't even begun to discuss the integrated DirectX 11 GPU and as expected it will not only enable playback of HD video but even performance for an enjoyable gaming experience.
The processor is expected to consume more power than Intel's Atom but still be a lot more efficient than most competing products used on the HTPC market and we look foward to hearing more about this.
eddai che ci esce un vero htpc senza l'aborto atom....:D
F1R3BL4D3
10-10-2010, 15:11
Perché esagero?
Il mio 97mini è più veloce se faccio internet... prb di ritardo riga non ne ho... ma chiaramente la tastiera del telefonino non è "compatibile" con le mie dita... :)
Tra l'altro l'ha pagato 320€ 1 anno fa, un HP.
Che sia piccolo, portatile, mettici tutto quello che vuoi, ma costa pur sempre quasi come un 1090T + mobo... se fai un rapporto prezzo-prestazioni, non è che sia poi tanto economico (e questo vale per tutti, AMD compresa).
Edit:
P.S.
Voglio precisare, per non creare polemica, che l'obiettivo Atom, come potrebbe pure essere un procio AMD nella medesima situazione, è quella di fornire un "computer" con l'obiettivo di avere la più lunga possibile autonomia, a scapito delle prestazioni. Su quest'ottica, è inutile poi pensare che le prestazioni siano uguali a quelle di un computer normale. Nel mio modo di pensare, se uso un PC voglio avere un PC a tutti gli effetti, senza limitazioni alcune (altrimenti in casa avrei tenuto un Sempron di 4 anni fa). Se mi serve la mobilità, a scapito della potenza, molte cose che si possono fare con un sistema portatile di scarsa potenza, si possono avere ugualmente con l'utilizzo di un telefonino con programmi similari ed al limite ottimizzando sicuramente la spesa. Questo è la mia ottica di pensiero, che rimarrà uguale sia se ora parlo di Atom, sia in futuro con AMD nel caso di prestazioni simili. Altri, con altre esigenze, possono tranquillamente avere opinioni differenti, ma io con l'Atom della mia ragazza sclero, e certamente non esagero perché non mi sento di avere un vero PC tra le mani e non mi "accontento".
Non so, io ci navigo con una decina di schede di firefox aperte contemporaneamente, mentre scrivo con qualche editor di testo (Office per esempio), elaboro foto (è vero in maniera molto marginale) e non ho di quei problemi. E il mio è il primo netbook uscito praticamente (decisamente meno potente degli ultimi).
Su uno smartphone queste cose? Non sarebbe possibile.
E' vero anche che più potenza a parità di consumo non è assolutamente da scartare (o leggermente meno potenza ma anche meno consumo). I netbook sono nati come soluzioni compatte a basso prezzo e poi si sono evoluti con soluzioni più raffinate ma comunque si parla ancora degli albori del mercato.
bè questo no, volevo solo sottolineare che la frase "ormai è assodato" è azzardata...:)
Le ultime voci su Bulldozer parlano dell'importanza della grandezza della cache L2 e di come possa essere molto più determinante di quanto sia nell'architettura K10...
Inoltre il nuovo controller RAM e la cache L3 saranno in grado di aumentare la banda passante; tutte cose che AMD non ha accennato alla presentazione di bulldozer...
Questo probabilmente perchè, essendo le L1 minuscole, il prefetch magari lo fanno nella L2... Credo. O comunque essendo le L1 minuscole, c'è molto più traffico verso la L2 in fase di riempimento L1...
Secondo me, per avere una situazione il più possibile vicina alla realtà, dobbiamo partire da questo punto:
Il 32nm HKMG AMD permetterà un margine del 33% sopra al clock Intel sia nella condizione Turbo che in quella stock per tutti i core.
Vantaggio Intel odierno sul Phenom II (Valori IPC approssimativi e, proprio per cercare un esempio concreto, non ho certo riportato differenze di IPC scarse, anzi, tutt'altro)
i7 = 30% di IPC maggiore del Phenom II.
SB = 45% di IPC maggiore del Phenom II.
Ora, rapportando un IPC per BD = a quello del Phenom II con il clock del 32nm HKMG AMD, uscirebbe questo:
Un i7 avrebbe una potenza (IPC x clock) del 3% inferiore a BD.
Un SB avrebbe una potenza (IPC x clock) del 12% superiore a BD.
Discutere poi se l'IPC di BD sia = al Phenom II, sia del 15% superiore, ok, si può ipotizzare qualsiasi IPC, ma comunque rimane di fatto che a tutti gli effetti già solo per il clock un BD si posizionerebbe sopra di poco un X4 i7 e sotto di poco ad un SB X4.
Con queste differenze, se già andassimo a teorizzare un BD X8 vs SB X8, visto la scalabilità migliore degli AMD, non mi sembra azzardato già reputare per certo una parità.
Se fino a qui siamo concordi, questo vorrebbe dire che BD senza incrementi di IPC rispetto ad un Phenom II si posiziona alla pari rispetto ad un SB. Ma... se ci fossero variazioni positive di IPC in BD, mi sembra abbastanza chiaro che BD andrà più di SB.
Ora... se AMD ha creato BD con l'intento di contrastare SB, IPC o non IPC, direi che l'obiettivo è centrato.
Sarebbe veramente interessante se nel secondo trimestre 2011 AMD commercializzasse BD X8 a 400€. Cosa darei per vedere la faccia dei commerciali Intel nel rivedere il loro listino :)
E pensa che dato il FO4 minore e le dichiarazioni di GF (+40% di clock a parità di tutto), l'incremento di clock potrebbe (e dovrebbe) essere ben superiore al 33% da te stimato... :sofico:
Io prevedo (almeno a regime, forse non da subito) +50% rispetto a phenom II a default e +60-70% in modalità turbo (sempre rispetto a Phenom II)... A parità di core... Anche considerato che due core BD (un modulo) probabilmente avranno meno transistors di due core Phenom II...
astroimager
10-10-2010, 17:31
^^
La mia ragazza ce l'ha un Atom.
Io non riesco neppure a scriverci i post per questo TH... l'ho usato una volta e... ho sclerato immediatamente. Non si può scrivere una frase e come guardi per rileggerla ti accorgi che... ancora non c'è :eek: e devi aspettare qualche secondo.
Fare cavallo di battaglia sull'autonomia della batteria tralasciando che... in un altro portatile le stesse cose le faresti in metà tempo... scusate, allora non è meglio un cellulare? E' pure più piccolo ed ha maggiore autonomia. :sofico: .
Con il mio portatile, che ha quasi 8 anni alle spalle e potenza un po' inferiore ai sistemi Atom, ho effettuato stacking di migliaia di frame, ridotto spettri, programmato in IDL, elaborato con PS... sfido a fare lavori del genere con un cellulare.
Sarò all'antica, ma a me il cellulare serve solamente per chiamare, mandare qualche mex, ora-sveglia, e al più cazzaggiare quando sto sopra il water.
Ricordati sempre che è il MANICO che conta. Riguardati questo simpatico articoletto:
http://www.appuntidigitali.it/10073/cosa-non-posso-fare-col-mio-netbook/
ivano444
10-10-2010, 17:54
fanno pena i netbook basati su intel perche quelli con processore athlon neo e grafica radeon non sono affatto male
Giusto, dimenticavo Zacate.
Il succo del mio discorso è che questa nuova architettura è destinata a un target da leggermente a molto diverso rispetto ai netbook "classici"... lasciando perdere tutti quei modelli (e ne vedo sempre di più) che deviano non poco dalla filosofia del netbook (max economicità e autonomia).
Mi auguro che AMD spazzi via tutta questa roba inutile (tutti i net sopra i €250, insomma)...
Appunto c'è zacate, poi non per essere troppo ottimimista, ma un single core amdkz non mi ricordo quale numero a 1.7ghz da un autonomia simile ad un netbook con atom e ion, e prestazioni superiori, beh considera che un dual core bobcat darà circa il 90% di performance di un dual core k10 (ad es un athloon xII) ed a quanto mi ricordo questi fanno girare di tutto.
Beh, innanzitutto ti ringrazio per le info tecniche relative all'implementazione del fetch/decode. :)
Tuttavia il fatto che AMD alcune istruzioni le codifichi in una sola micro-op ed intel no dipende penso dalla archietettura, dal numero di alu, dalla loro effettiva implementazione ecc.ecc. (e non e' detto che AMD sia piu' veloce per questo.. non conosco le latenze e gli effettivi algoritmi, quindi non mi esprimo)
Il fatto comunque di poter eseguire in maniera alternata due macro-ops gia' codificate non cambia, indipendentemente dalla architettura (ovviamente il decoder dovrebbe avere una capacità di codifica doppia!).
Si avrebbe comunque il doppio di capacità di calcolo teorica con svantaggi piuttosto ridotti in termini di complessità architetturale, ma anzi avendo la vera possibilità di poter seriamente condividere tutto quanto all'interno del modulo.
Quella l1 instr condivisa.. quelle retire separate.. quel fetch e decode unificato.. uhm.. io rimango della mia idea, che per la cronaca, come ho specificato, non si tratterebbe di un vero e proprio reverse-hyperthreading, ma piu' di uno sdoppiamento di un singolo thread su due unità intere in due rami codificati e distribuiti alternativamente dal decoder potenziato ed unificato.
Magari proprio come se fosse il contrario di Intel che con 4 core gestisce 8 thread (anche se 4 sono praticamente "fasulli"), AMD potrebbe gestire magari 4 threads con 8 cores (magari solo all'occorrenza, chissà) ed occupare pure meno silicio nel confronto "core vs modulo" :) Se fosse cosi' sarebbe prestazionalmente parlando superiore in qualunque campo, non credi?
..però non capisco cosa intendi con questa affermazione.. :mc:
Comunque le load/store delle unità int sono autonome, separate, specifiche ed indipendenti tra i due cores, da quello che avevo letto..
Ciao
Perchè vi sia un reverse HTT efficace è necesario che gli operandi di un core li abbia anche l'altro :) (a mia opinione piuttosto modesta a dire la verità)
dunque i due cluster dovrebbero avere L\S comunicanti. Poi scusami, lo sdoppiamento di un thread su core che vantaggi porterebbe rispetto ad avere un core largo come la somma dei due singoli? Inoltre quello che ho capito fino ad ora che tu pensi sia implementato in bd, e scusami se è poco in verita, è che dopo la fase di fetch (32byte) i decoder inviino lo stream di istruzioni a due core int. Ma come coordineresti e sincronizzeresti l'esecuzione? Ovvero core A branch che punta ad un una determinata locazione di memoria x, core b branch che punta ad una locazione y, ecco bene, che si fa? La logca di fetch si splitta in 2 e carica contemporaneamente 2 differenti porzioni di codice? E se una è dipendente dall'altra come risolvi? Nel senso il register renaming dovrebbe essere condiviso come logica OoO, i gprs condivisi pure loro..
capitan_crasy
10-10-2010, 18:44
Questo probabilmente perchè, essendo le L1 minuscole, il prefetch magari lo fanno nella L2... Credo. O comunque essendo le L1 minuscole, c'è molto più traffico verso la L2 in fase di riempimento L1...
Resta interessante come AMD abbia voluto dire il valore della L1 e tenga ben nascosto i valori della L2 e L3...
Le caratteristiche che mancano saranno quelle più determinanti...:)
astroimager
10-10-2010, 18:50
Appunto c'è zacate, poi non per essere troppo ottimimista, ma un single core amdkz non mi ricordo quale numero a 1.7ghz da un autonomia simile ad un netbook con atom e ion, e prestazioni superiori, beh considera che un dual core bobcat darà circa il 90% di performance di un dual core k10 (ad es un athloon xII) ed a quanto mi ricordo questi fanno girare di tutto.
Autonomia simile ad Atom/Ion e prestazioni superiori? Allora mi ero perso qualcosa... ti ricordi dov'era stato fatto questo testa a testa?
Per simulare la potenza di un Bobcat da netbook quindi si potrebbe prendere come riferimento un Athlon2 da, tipo, 1 GHz? E magari da 1.5 GHz per note ultra-thin?
astroimager
10-10-2010, 18:57
anche il dell m101z, la versione con il k325, mi ha detto l'amico al quale l'ho consigliato che va una bomba :)
Ci credo! :ciapet:
Ciao
Perchè vi sia un reverse HTT efficace è necesario che gli operandi di un core li abbia anche l'altro :) (a mia opinione piuttosto modesta a dire la verità)
Continui a dire che non sei un tecnico e che la tua opinione è piuttosto modesta...invece mi sembra tu ci capisca molto ;)
Autonomia simile ad Atom/Ion e prestazioni superiori? Allora mi ero perso qualcosa... ti ricordi dov'era stato fatto questo testa a testa?
Per simulare la potenza di un Bobcat da netbook quindi si potrebbe prendere come riferimento un Athlon2 da, tipo, 1 GHz? E magari da 1.5 GHz per note ultra-thin?
Ciao
Si, e questo con un single core k10 ad 1.7ghz, blackshard aveva postato ciò in un commento sulla review di un net con procio amd. (qui su Hwupgrade)
tecnicamente il 90% di un athlonII vuol dire prestazioni pari ad un e6xxx. Che è una bella bestiola. Si potrebbe dunque simulare un bobcat ad 1.6ghz mediante un athlonII ad 1.35ghz. Ma penso che qualche cosa in più in frequenza di 1.6ghz li possa avere, ovvero se riescono a tirare un k10 a 1.7ghz per infilarcelo nei netbook con una architettura ad hoc non dovrebbero aver grossi problemi. :)
Edit:
con l'aggiunta di aver una grafica integrata che ti permette di veder un film in Hd, che non è da poco.
Ciao
Perchè vi sia un reverse HTT efficace è necesario che gli operandi di un core li abbia anche l'altro :) (a mia opinione piuttosto modesta a dire la verità)
dunque i due cluster dovrebbero avere L\S comunicanti. Poi scusami, lo sdoppiamento di un thread su core che vantaggi porterebbe rispetto ad avere un core largo come la somma dei due singoli? Inoltre quello che ho capito fino ad ora che tu pensi sia implementato in bd, e scusami se è poco in verita, è che dopo la fase di fetch (32byte) i decoder inviino lo stream di istruzioni a due core int. Ma come coordineresti e sincronizzeresti l'esecuzione? Ovvero core A branch che punta ad un una determinata locazione di memoria x, core b branch che punta ad una locazione y, ecco bene, che si fa? La logca di fetch si splitta in 2 e carica contemporaneamente 2 differenti porzioni di codice? E se una è dipendente dall'altra come risolvi? Nel senso il register renaming dovrebbe essere condiviso come logica OoO, i gprs condivisi pure loro..
beh, innanzitutto io non penso sia implementato, ma penso che potrebbe essere un'ipotesi! :)
Comunque io parto dal presupposto che una unica unità INT con larghezza doppia e pari alla somma delle due sarebbe comunque piu' lenta, perche' le latenze sarebbero piu' alte e le macroistruzioni piu' difficili da gestire con troppe unità ALU. Riguardo alle possibili "collisioni" di indirizzi ecc.ecc. penso che non sarebbero possibili, non piu' di quanto lo sarebbero in una logica classica, visto che come ripeto il flusso sarebbe comunque sequenziale, e non parallelo (non si caricano 2 istruzioni alla volta, ma una sola.. ma alla metà della velocità, ecco perche' il decoder deve essere piu veloce).
Il branch poi sarebbe anch'esso comune (si vede anche dal grafico), infatti verrebbe calcolato singolarmente per istruzione (ed e' qui che però bisognerebbe aggiungere un altro algoritmo per il controllo di flusso relativo ad i due alberi di macroistruzioni e che consideri la logica OoO di calcolo)
vabbe', penso sia inutile andare avanti oltre.. sarebbe piu' facile un confronto a parole.. ;) aspettiamo e vedremo XD
beh, innanzitutto io non penso sia implementato, ma penso che potrebbe essere un'ipotesi! :)
Comunque io parto dal presupposto che una unica unità INT con larghezza doppia e pari alla somma delle due sarebbe comunque piu' lenta, perche' le latenze sarebbero piu' alte e le macroistruzioni piu' difficili da gestire con troppe unità ALU. Riguardo alle possibili "collisioni" di indirizzi ecc.ecc. penso che non sarebbero possibili, non piu' di quanto lo sarebbero in una logica classica, visto che come ripeto il flusso sarebbe comunque sequenziale, e non parallelo (non si caricano 2 istruzioni alla volta, ma una sola.. ma alla metà della velocità, ecco perche' il decoder deve essere piu veloce).
Il branch poi sarebbe anch'esso comune (si vede anche dal grafico), infatti verrebbe calcolato singolarmente per istruzione (ed e' qui che però bisognerebbe aggiungere un altro algoritmo per il controllo di flusso relativo ad i due alberi di macroistruzioni e che consideri la logica OoO di calcolo)
vabbe', penso sia inutile andare avanti oltre.. sarebbe piu' facile un confronto a parole.. ;) aspettiamo e vedremo XD
Be sperando che dopo tutto queste speculazioni ci sia qualcosa di vero ;)
beh, innanzitutto io non penso sia implementato, ma penso che potrebbe essere un'ipotesi! :)
Comunque io parto dal presupposto che una unica unità INT con larghezza doppia e pari alla somma delle due sarebbe comunque piu' lenta, perche' le latenze sarebbero piu' alte e le macroistruzioni piu' difficili da gestire con troppe unità ALU. Riguardo alle possibili "collisioni" di indirizzi ecc.ecc. penso che non sarebbero possibili, non piu' di quanto lo sarebbero in una logica classica, visto che come ripeto il flusso sarebbe comunque sequenziale, e non parallelo (non si caricano 2 istruzioni alla volta, ma una sola.. ma alla metà della velocità, ecco perche' il decoder deve essere piu veloce).
Il branch poi sarebbe anch'esso comune (si vede anche dal grafico), infatti verrebbe calcolato singolarmente per istruzione (ed e' qui che però bisognerebbe aggiungere un altro algoritmo per il controllo di flusso relativo ad i due alberi di macroistruzioni e che consideri la logica OoO di calcolo)
vabbe', penso sia inutile andare avanti oltre.. sarebbe piu' facile un confronto a parole.. ;) aspettiamo e vedremo XD
Ciao
Non per forza un core int cosi grosso deve computare con latenze maggiori rispetto ad un core più snello, vedi ad es i c2q oppure il k10 stesso, le latenze anche per operazioni con operandi nella memoria (e non nei registri) sono abbastanza basse. Semmai come giustamente dici tu, si avrebbe una grossa difficolta a mantenere occupate tutte queste alu e potenzialmente un grosso spreco di energia ogni branch miss o cache miss (flush della pipeline in ambo i casi)
Scusami ancora, riguardando il discorso delle collisioni di indirizzi, mi sono espresso male io :) non intendo alias di indirizzi per ops di load e store, ma mi riferisco alla instruction fetch, prendi una direzione di branch vai a fetchare una particolare porzione di codice, (sempre se hai preso la diramazione giusta). Poi non ho capito, e mi scuso, l'utilita di caricare una istruzione alla volta. Ovvero istr a core b ed istr c core a?
paolo.oliva2
10-10-2010, 21:19
E pensa che dato il FO4 minore e le dichiarazioni di GF (+40% di clock a parità di tutto), l'incremento di clock potrebbe (e dovrebbe) essere ben superiore al 33% da te stimato... :sofico:
Io prevedo (almeno a regime, forse non da subito) +50% rispetto a phenom II a default e +60-70% in modalità turbo (sempre rispetto a Phenom II)... A parità di core... Anche considerato che due core BD (un modulo) probabilmente avranno meno transistors di due core Phenom II...
Riesco a portare un Thuban a screen a 4,876GHz (vedi firma)... aspetta che ho il Thuban... :sbavvv:
paolo.oliva2
10-10-2010, 21:36
Con il mio portatile, che ha quasi 8 anni alle spalle e potenza un po' inferiore ai sistemi Atom, ho effettuato stacking di migliaia di frame, ridotto spettri, programmato in IDL, elaborato con PS... sfido a fare lavori del genere con un cellulare.
Sarò all'antica, ma a me il cellulare serve solamente per chiamare, mandare qualche mex, ora-sveglia, e al più cazzaggiare quando sto sopra il water.
Ricordati sempre che è il MANICO che conta. Riguardati questo simpatico articoletto:
http://www.appuntidigitali.it/10073/cosa-non-posso-fare-col-mio-netbook/
Io Astro non ti do mica torto... infatti io ho postato "per me"... poi siccome il discorso era sull'Atom, non volevo che la mia opinione fosse interpretata come anti-Atom, infatti ho voluto sottolineare che se AMD facesse un portatile con prestazioni simili, a me non passa manco per l'anticamera del cervello di comprarlo.
Ti faccio questo confronto OT, per farti un'idea: con le vetture, io ho "dovuto" comprare sempre o pari CV o superiori... perché mi conosco e se passassi da una macchina "superiore" ad una "inferiore"... non mi troverei bene e mi resterebbe il magone in gola. Con questo, non è che un 1200 non ti porterebbe mai dove ti porta un 2000, ma il problema che chiederei al 1200 che andasse come il 2000. Con la stessa tipologia, non avendo necessità di mobilità di computer, se io cambio PC, lo farei unicamente per un sistema più potente e se dovessi affiancarlo con un altro sistema, farebbe la fine del mio portatile (si è bruciata la mobo perchè... dopo 6 mesi di non utilizzo, si sono invertite le polarità alla batteria).
carlottoIIx6
11-10-2010, 00:36
Be sperando che dopo tutto queste speculazioni ci sia qualcosa di vero ;)
mi chiedo una domanda
come sarebbero le rpestazioni del k10, se avrsse una fp più generosa?
mi chiedo una domanda
come sarebbero le rpestazioni del k10, se avrsse una fp più generosa?
Avrebbe prestazioni migliori nelle applicazioni che usano l'unità FP. Quindi le prestazioni non aumenterebbero in toto. Magari nella fisica dei giochi, sicuramente nella codifica audio/video.
Ciao
Non per forza un core int cosi grosso deve computare con latenze maggiori rispetto ad un core più snello, vedi ad es i c2q oppure il k10 stesso, le latenze anche per operazioni con operandi nella memoria (e non nei registri) sono abbastanza basse. Semmai come giustamente dici tu, si avrebbe una grossa difficolta a mantenere occupate tutte queste alu e potenzialmente un grosso spreco di energia ogni branch miss o cache miss (flush della pipeline in ambo i casi)
Scusami ancora, riguardando il discorso delle collisioni di indirizzi, mi sono espresso male io :) non intendo alias di indirizzi per ops di load e store, ma mi riferisco alla instruction fetch, prendi una direzione di branch vai a fetchare una particolare porzione di codice, (sempre se hai preso la diramazione giusta). Poi non ho capito, e mi scuso, l'utilita di caricare una istruzione alla volta. Ovvero istr a core b ed istr c core a?
Io parlo di istruzioni singole a livello di fetch e decode, anche se in effetti alle unità intere come avevo specificato addietro arriverebbero dei "pacchetti" bufferizzati di microistruzioni.
Come e' stato dimostrato unità intere con piu' di un certo numero di ALU non darebbero alcun vantaggio (da qui l'inutilità di avere una mega-unità intera con ALU doppie).. Ma se il nostro decode riuscisse a codificare a velocità doppia del normale le nostre istruzioni, potrebbe per ogni macro-istruzione mandare le microistruzioni ad essa appartenenti ad un "buffer" FIFO del core0, e mentre questo lavora mandare le micro-istruzioni della istruzione successiva al buffer del core1. I due cores lavoreranno quindi cosi' come hanno sempre fatto, su micro-istruzioni da ricomporre poi nelle loro retires (separate).
Il fatto di smistare le istruzioni alternativamente ed una alla volta servirebbe per avere meno problemi di dipendenze e sarebbe fondamentale per poter semplificare gli algoritmi di predizione, tutto qui..
semplificando al massimo la logica di funzionamento sarebbe quella che ho descritto in vari post addietro:
http://www.hwupgrade.it/forum/showpost.php?p=33280331&postcount=3967
Ovviamente qui non prevedo le pipelines all'interno delle ALU, ma anche pensando che ci siano sarebbe semplicemente un po' piu' compleso da gestire l'algoritmo di controllo di flusso sui due rami (l'unico da "aggiungere", possibile algoritmo di cui parlavo vari post fa) in quanto dovrebbe tenere conto anche del numero di stadi appunto delle pipelines, ma nulla di impossibile, comunque.. praticaemnte bisognerebbe semplicemente controllare le dipendenze su un cammino ipotetico "doppio" rispetto a quello normalmente considerato (in quanto i pacchetti vengono smistati du due unità identiche)
capitan_crasy
11-10-2010, 11:39
Due piccoli aggiornamenti:
Al 90% le GPU di Llano e Ontario/Zacate supporteranno la tecnologia Blu-ray 3D...
Ci saranno nuove informazioni su Bobcat al "AMD Technical Forum and Exhibition" il 18 ottobre 2010; è probabile che AMD parlerà anche di Llano e Bulldozer...
http://www.pctunerup.com/up/results/_201010/th_20101011113911_018.jpg (http://www.pctunerup.com/up/image.php?src=_201010/20101011113911_018.jpg)
Una cosa: bulldozer supporterà ddr 3 1333 oppure solo 1600 ed oltre?
greeneye
11-10-2010, 11:52
In uyn post ieri jf-amd ha riassunto le nuove istruzioni supportate da bulldozer:
what compiler change, does bulldozer need, for the integer workload it is mostly design for?
There are few changes that need to be comprehended.
New instructions are mainly SSSE3, SSE 4.1 and 4.2, AVX, AES, FMA4, XOP, PCLMULQDQ; these mostly refer to FP and less to integer.
.... non so se è un po' old....ma mi pareva che non fosse dichiarato in modo netto.
capitan_crasy
11-10-2010, 11:57
Una cosa: bulldozer supporterà ddr 3 1333 oppure solo 1600 ed oltre?
Le ultime voci davano un supporto alle 1866Mhz, ma il fatto che AMD non abbia ancora rilasciato ufficialmente questo parametro fa pensare che non abbia ancora raggiunto una decisione definitiva; in teoria potrebbe supportare anche le 2133Mhz:D o forse solo le 1600Mhz:cry: ...
aaadddfffgggccc
11-10-2010, 11:59
Le ultime voci davano un supporto alle 1866Mhz, ma il fatto che AMD non abbia ancora rilasciato ufficialmente questo parametro fa pensare che non abbia ancora raggiunto una decisione definitiva; in teoria potrebbe supportare anche le 2133Mhz:D o forse solo le 1600Mhz:cry: ...
Beh.. io ho ordinato le 2000Mhz, una via di mezzo! :D
No lo chiedo perché vorrei prendere delle memorie che possibilmente vadano bene anche su bulldozer.. se prendo delel 1333 e poi si deve downcloccare non è il massimo :rolleyes: :mbe:
paolo.oliva2
11-10-2010, 13:17
No lo chiedo perché vorrei prendere delle memorie che possibilmente vadano bene anche su bulldozer.. se prendo delel 1333 e poi si deve downcloccare non è il massimo :rolleyes: :mbe:
Secondo me si potrebbero prendere anche delle 2100MHz e oltre.
Il supporto alle ram è solamente in base al Jdec. Del resto, il Thuban è ancora fermo alle 1333, ma supporta tranquillamente le 1600 senza agire sulla frequenza del bus e sino a 2000 se supportato dalla mobo.
Mi sembra che lo standard Jdec per le 1600-1800-1866 dovrebbe essere definito a novembre di quest'anno... per questo ancora non c'è nulla di ufficiale.
Come e' stato dimostrato unità intere con piu' di un certo numero di ALU non darebbero alcun vantaggio (da qui l'inutilità di avere una mega-unità intera con ALU doppie).. [...]
Secondo me questo è il punto, ed è anche ciò che non capisco del tuo ragionamento: in che modo due core potrebbero essere più efficienti di un singolo core "grosso"?
E' come se dicessi che un crossfire di due gpu piccole sia meglio di una singola gpu monolitica di grandi dimensioni con gli stessi elementi e la stessa frequenza.
Questo non è mai vero, la singola GPU sarà sempre superiore.
Se quindi ci fosse la possibilità di sfruttare più alu (più di quelle che già si utilizzano) in un singolo core, volendo aumentare l'ipc di un singolo core, la soluzione più diretta sarebbe quella di potenziare tale core aggiungendo tali alu (e ovviamente quanto di contorno necessario per sfruttarle).
Ma se questo non è possibile, come potrebbe essere possibile invece ottenere questo risultato con più core?
Nella mia ignoranza questa cosa non ha davvero alcun senso.
Io parlo di istruzioni singole a livello di fetch e decode, anche se in effetti alle unità intere come avevo specificato addietro arriverebbero dei "pacchetti" bufferizzati di microistruzioni.
Come e' stato dimostrato unità intere con piu' di un certo numero di ALU non darebbero alcun vantaggio (da qui l'inutilità di avere una mega-unità intera con ALU doppie).. Ma se il nostro decode riuscisse a codificare a velocità doppia del normale le nostre istruzioni, potrebbe per ogni macro-istruzione mandare le microistruzioni ad essa appartenenti ad un "buffer" FIFO del core0, e mentre questo lavora mandare le micro-istruzioni della istruzione successiva al buffer del core1. I due cores lavoreranno quindi cosi' come hanno sempre fatto, su micro-istruzioni da ricomporre poi nelle loro retires (separate).
Il fatto di smistare le istruzioni alternativamente ed una alla volta servirebbe per avere meno problemi di dipendenze e sarebbe fondamentale per poter semplificare gli algoritmi di predizione, tutto qui..
semplificando al massimo la logica di funzionamento sarebbe quella che ho descritto in vari post addietro:
http://www.hwupgrade.it/forum/showpost.php?p=33280331&postcount=3967
Ovviamente qui non prevedo le pipelines all'interno delle ALU, ma anche pensando che ci siano sarebbe semplicemente un po' piu' compleso da gestire l'algoritmo di controllo di flusso sui due rami (l'unico da "aggiungere", possibile algoritmo di cui parlavo vari post fa) in quanto dovrebbe tenere conto anche del numero di stadi appunto delle pipelines, ma nulla di impossibile, comunque.. praticaemnte bisognerebbe semplicemente controllare le dipendenze su un cammino ipotetico "doppio" rispetto a quello normalmente considerato (in quanto i pacchetti vengono smistati du due unità identiche)
Ciao:)
Mi scuso per la lentezza, ma ho avuto qualche difficoltà a capire.
Dunque, tu ipotizzi che dopo la fase di fetch i decoders decodifichino 2 stream di istruzioni un viene mandato al core 0 e dopo un ciclo di clock (suppongo per fare uno scoreboard per vedere le dipendenze tra istruzioni mandate al core 0 ed al core1) l'altro al core 1, questo sottoforma di un pack buffer( che già viene utilizzato per il dispatch delle mops decodificate) più in giù nelle pipes dei due core. Dopo ciò si dovrebbe ritirare le ops in buffer separati e ricomporre lo stream come il codice prevede.
Se ho capito bene, mi sa che ci vuole qualcosina di esoso in termini di logica, non vorrei essere ripetitivo, ma si dovrebbe (sempre ad opinione mia, ovvero valore 0) implementare un pò di logica, molta di più di un raddoppio di alu e buffer connessi.
1) Dovresti possedere dei decoder che non si stoppino(per il calcolo del nuovo address di memoria inteso come qualsiasi memoria tranne i registri dpve fetchare la nuova porzione di codice) ad ogni branch incontrata.
2) Logica di fetch: Ogni branch risolta ti punta ad una locazione x di memoria dove prendere codice y. Bene se tutte e due i core ricevono una branch, e devono caricare due locazioni z,k quale processore carica per primo?( si parla di 2 core che eseguono uno stesso thread) Se ambedue sbagliano a calcolare una branch hai perso un sacco di energia oltre che cicli preziosi. Se le due branch sono "dipendenti" nel senso che dal risultato di una puoi prendere o meno l'altra, come fai a gestire il fatto che in 2 cicli hai riempito due core e magari solo uno ha fatto un lavoro utile ? Ad es core 0 branch presa che fa saltare il procio ad un altra porzione di codice mentre quello che fa il core 1 non è più necessario,
3)Tecniche OoO e register renaming.
I due cores 0 ed 1 che eseguono lo stesso thread hanno i gprs condivisi? Se se una lea che fa il core 1 dice di scrivere su EBX mentre un altra op m-> dice di scrivere su EBX come si risolve il conflitto? register renaming si potrebbe pensare ma se son impegnati? e come si implementerebbe questa tecnica su due cores differenti con ognuno operandi\indirizzi da salvare in questi registri.
4) sincronizzazione dei cores e comunicazione intercores.
Ciao:)
Mi scuso per la lentezza, ma ho avuto qualche difficoltà a capire.
Dunque, tu ipotizzi che dopo la fase di fetch i decoders decodifichino 2 stream di istruzioni un viene mandato al core 0 e dopo un ciclo di clock (suppongo per fare uno scoreboard per vedere le dipendenze tra istruzioni mandate al core 0 ed al core1) l'altro al core 1, questo sottoforma di un pack buffer( che già viene utilizzato per il dispatch delle mops decodificate) più in giù nelle pipes dei due core. Dopo ciò si dovrebbe ritirare le ops in buffer separati e ricomporre lo stream come il codice prevede.
Se ho capito bene, mi sa che ci vuole qualcosina di esoso in termini di logica, non vorrei essere ripetitivo, ma si dovrebbe (sempre ad opinione mia, ovvero valore 0) implementare un pò di logica, molta di più di un raddoppio di alu e buffer connessi.
ESATTO! hai capito cosa intendevo! :)
Secondo me invece non sarebbe per nulla cosi' esoso in termini di risorse, ma al contrario una implementazione di questo tipo ti permetterebbe davvero di avere tutto quanto condiviso (bisognerebbe certo aggiungere qualche logica, ma sarebbe minima, a parer mio).
1) Dovresti possedere dei decoder che non si stoppino(per il calcolo del nuovo address di memoria inteso come qualsiasi memoria tranne i registri dpve fetchare la nuova porzione di codice) ad ogni branch incontrata.
secondo me teoricamente basterebbe un decoder identico a quello di un k10 ma con velocità di codifica doppia. Tu stai continuando a pensare ad un calcolo istantaneamente parallelo, mentre secondo la mia ipotesi sarebbe alternato ed esclusivo per ogni core (mentre uno calcola, l'altro restituisce il risultato e viceversa)
2) Logica di fetch: Ogni branch risolta ti punta ad una locazione x di memoria dove prendere codice y. Bene se tutte e due i core ricevono una branch, e devono caricare due locazioni z,k quale processore carica per primo?( si parla di 2 core che eseguono uno stesso thread) Se ambedue sbagliano a calcolare una branch hai perso un sacco di energia oltre che cicli preziosi. Se le due branch sono "dipendenti" nel senso che dal risultato di una puoi prendere o meno l'altra, come fai a gestire il fatto che in 2 cicli hai riempito due core e magari solo uno ha fatto un lavoro utile ? Ad es core 0 branch presa che fa saltare il procio ad un altra porzione di codice mentre quello che fa il core 1 non è più necessario,
da quello che si e' visto ogni core ha la sua logica L/s indipendente. in ogni caso visto che i calcoli sarebbero alternati (e mai eseguiti nello stesso istante di clock), sarebbe virtualmente impossibile avere richieste del genere nello stesso istante.. al max si potrebbero avere in tempi dimezzati rispetto al normale..
3)Tecniche OoO e register renaming.
I due cores 0 ed 1 che eseguono lo stesso thread hanno i gprs condivisi? Se se una lea che fa il core 1 dice di scrivere su EBX mentre un altra op m-> dice di scrivere su EBX come si risolve il conflitto? register renaming si potrebbe pensare ma se son impegnati? e come si implementerebbe questa tecnica su due cores differenti con ognuno operandi\indirizzi da salvare in questi registri.
beh, ovviamente ognuna dovrebbe avere dei registri "proprietari", oltre che appunto cache "data" autonome (infatti abbiamo visto che sarà cosi').. Ma questo sarebbe inevitabile anche se si pensasse a questi moduli come dei "veri" dual core.. sbaglio? Al max quello che non tornerebbe nel caso del "dual core classico" e' la l1 Instr comune (e sappiamo che pero' sarà cosi')
4) sincronizzazione dei cores e comunicazione intercores.
la sincronizzazione avverrebbe "a monte", quando si decide da che parte far andare una istruzione, in modo da minimizzare le possibilità di conflitto, per il resto opererebbero in maniera alternata, quindi sincronizzati direttamente sul clock di sistema. La comunicazione intercores sarebbe utile tanto quanto potrebbe esserlo tra uno stadio di pipeline e l'altro in un core "classico". La "lunghezza" su cui potrebbero verificarsi dipendenze e/o conflitti sarebbe semplicemente doppia rispetto a quella normale, ma per il resto sarebbe esattamente la stessa cosa!
Comunque non devi scusarti di nulla: mi piace molto parlare di queste possibili speculazioni con persone come te (molto piu' esperte di me).. Probabilmente c'e' davvero qualcosa che non sto considerando.. ma se così non fosse AMD potrebbe avere fatto davvero centro! ;)
chissà.. :D
paolo.oliva2
11-10-2010, 15:30
Secondo me questo è il punto, ed è anche ciò che non capisco del tuo ragionamento: in che modo due core potrebbero essere più efficienti di un singolo core "grosso"?
E' come se dicessi che un crossfire di due gpu piccole sia meglio di una singola gpu monolitica di grandi dimensioni con gli stessi elementi e la stessa frequenza.
Questo non è mai vero, la singola GPU sarà sempre superiore.
Se quindi ci fosse la possibilità di sfruttare più alu (più di quelle che già si utilizzano) in un singolo core, volendo aumentare l'ipc di un singolo core, la soluzione più diretta sarebbe quella di potenziare tale core aggiungendo tali alu (e ovviamente quanto di contorno necessario per sfruttarle).
Ma se questo non è possibile, come potrebbe essere possibile invece ottenere questo risultato con più core?
Nella mia ignoranza questa cosa non ha davvero alcun senso.
Potrebbero subentrare dei motivi di ottimizzazione?
Cioè... concordo con quello che dici... però, entrando nella filosofia di BD, visto come ottimizzazione di spazio nello sfruttamento di risorse condivise... potrebbe avere un senso se visto in ottica sia di clock che TDP ad area?
Cioè... faccio un esempio nella mia ignoranza terra terra.
L'HT è stato reso indipendente dall'NB appunto per non essere vincolato dal clock.
"Sdoppiare" il lavoro renderebbe di per sé più snella la cosa. E' vero che comunque se varie parti del procio sono in dipendenza di un dato, gli stalli se non ottimizzati ci sarebbero, ma è anche vero che se vediamo la cosa come un core "grosso", tutta la superficie sarebbe sotto carico, mentre se la cosa fosse divisa in più parti logiche indipendenti, appunto perché non dipendenti, potrebbero entrare in IDLE e comunque se pur non aumentando l'IPC, contribuirebbero a diminuire il TDP.
(Se dico castronerie non fustigatemi).
Se una pipeline dovesse "servire" ad esempio 3 INT, a parte l'ottimizzazione che in alcuni casi gli INT potrebbero "lavorare" in parallelo, comunque la pipeline non potrebbe accettare nuovo lavoro sinché non è svuotata...
Con più pipeline, non potrebbe crearsi la situazione ad esempio che una volta volta che il risultato è passato alla L2 (e non necessariamente alla L3/RAM), la seconda pipeline potrebbe da subito caricare il dato nuovo eliminando così i cicli di svuotamento?
Cioè... tra un ciclo e l'altro, se la L2 potesse gestire a scelta una pipeline, praticamente potrebbe eliminare dei cicli servendo la prima pipeline che è già pronta e libera.
Poi... perché è stato scelto il modulo per i P-State e non i core? D'accordo... i 2 core hanno parti condivise e quindi è impossibile che una parte vada del modulo vada in idle e l'altra no... però è anche vero che se è stato scelto di inquadrare il modulo e non il singolo core... inoltre una L2 condivisa, di per sé può serivire sia il core A o core B... mi suona un po' strano che sia solo per "risparmiare" spazio, soprattutto senza avere l'obiettivo di incrementare l'IPC, perché di fondo il problema di AMD non è il TDP, ma l'IPC.
Secondo me questo è il punto, ed è anche ciò che non capisco del tuo ragionamento: in che modo due core potrebbero essere più efficienti di un singolo core "grosso"?
E' come se dicessi che un crossfire di due gpu piccole sia meglio di una singola gpu monolitica di grandi dimensioni con gli stessi elementi e la stessa frequenza.
Questo non è mai vero, la singola GPU sarà sempre superiore.
Se quindi ci fosse la possibilità di sfruttare più alu (più di quelle che già si utilizzano) in un singolo core, volendo aumentare l'ipc di un singolo core, la soluzione più diretta sarebbe quella di potenziare tale core aggiungendo tali alu (e ovviamente quanto di contorno necessario per sfruttarle).
Ma se questo non è possibile, come potrebbe essere possibile invece ottenere questo risultato con più core?
Nella mia ignoranza questa cosa non ha davvero alcun senso.
beh, perche' nel caso dei calcoli FP piu' unità di calcolo hai piu' puoi parallelizzare e quindi teoricamente avere piu' FLOPS (floating operation per second).
Nel caso delle istruzioni complesse x86 è molto piu' importante il fatto di codificare in microistruzioni. Praticamente "scomponi" in pezzi piu' piccoli. Se hai possibilità di scomporre in pezzi ancora piu' piccoli (avendo piu' ALU) non e' detto che avrai un guadagno prestazionale, anzi.. potresti invece avere una perdita! Se invece mandi in esecuzioni due macro-istr codificate (esegui 2 macro-istr, ovvero ad esempio 8 micro-op in parallelo supponendo che una macro-instr la scomponi in 4 micro-ops) sulla stessa alu e nello stesso istante potresti avere dei seri problemi nel gestire le dipendenze ed i branch, proprio perche' sono eseguite tutte NELLO STESSO ISTANTE. (tra parentesi eseguire nello stesso istante flussi diversi di macro istruzioni sarebbe davvero un reverse hyperthreading, perche' dovremmo virtualmente fetchare e codificare due "parti" di thread istantaneamente ed arriverebbero anche NELLO STESSO ISTANTE i risultati da ricomporre!)
La mia ipotesi invece non prevede l'esecuzione di due rami di istruzioni NELLO STESSO ISTANTE, ma in maniera alternata.
L'auto-quote che ho fatto prima relativo a quello che scrissi qualche giorno fa era un esempio semplicissimo che forse vale piu' di mille parole..
http://www.hwupgrade.it/forum/showpost.php?p=33280331&postcount=3967
Ripeto ancora: posso aver solamente fantasticato in maniera assurda ed inconsistente.. Pero'.. chissà XD
ESATTO! hai capito cosa intendevo! :)
Secondo me invece non sarebbe per nulla cosi' esoso in termini di risorse, ma al contrario una implementazione di questo tipo ti permetterebbe davvero di avere tutto quanto condiviso (bisognerebbe certo aggiungere qualche logica, ma sarebbe minima, a parer mio).
secondo me teoricamente basterebbe un decoder identico a quello di un k10 ma con velocità di codifica doppia. Tu stai continuando a pensare ad un calcolo istantaneamente parallelo, mentre secondo la mia ipotesi sarebbe alternato ed esclusivo per ogni core (mentre uno calcola, l'altro restituisce il risultato e viceversa)
da quello che si e' visto ogni core ha la sua logica L/s indipendente. in ogni caso visto che i calcoli sarebbero alternati (e mai eseguiti nello stesso istante di clock), sarebbe virtualmente impossibile avere richieste del genere nello stesso istante.. al max si potrebbero avere in tempi dimezzati rispetto al normale..
beh, ovviamente ognuna dovrebbe avere dei registri "proprietari", oltre che appunto cache "data" autonome (infatti abbiamo visto che sarà cosi').. Ma questo sarebbe inevitabile anche se si pensasse a questi moduli come dei "veri" dual core.. sbaglio? Al max quello che non tornerebbe nel caso del "dual core classico" e' la l1 Instr comune (e sappiamo che pero' sarà cosi')
la sincronizzazione avverrebbe "a monte", quando si decide da che parte far andare una istruzione, in modo da minimizzare le possibilità di conflitto, per il resto opererebbero in maniera alternata, quindi sincronizzati direttamente sul clock di sistema. La comunicazione intercores sarebbe utile tanto quanto potrebbe esserlo tra uno stadio di pipeline e l'altro in un core "classico". La "lunghezza" su cui potrebbero verificarsi dipendenze e/o conflitti sarebbe semplicemente doppia rispetto a quella normale, ma per il resto sarebbe esattamente la stessa cosa!
Comunque non devi scusarti di nulla: mi piace molto parlare di queste possibili speculazioni con persone come te (molto piu' esperte di me).. Probabilmente c'e' davvero qualcosa che non sto considerando.. ma se così non fosse AMD potrebbe avere fatto davvero centro! ;)
chissà.. :D
Ciao
Anche me fa piacere parlare di queste cose.
Ho finalmente capito il tuo punto di vista, ovvero un reverse SMT di intel! Invece di caricar un thread nuovo su uno stesso cores, tu ne carichi lo stesso su due cores ognuno con il proprio set di gprs buffer rob, rimane comunque la comunicazione tra L\s unit e data chache che deve avvenire per sincronizzazione e share di operandi. In pratica alterneresti in maniera interleaved l'esecuzione di uno stesso thread su due cores.
ora bisogna aspettare e vedere se amd ha risolto alcuni problemucci, che come dicevamo prima, anche se non si esegue in maniera parallela due pacchetti di istr sono comunque presenti.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.