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

[Trokji]

Originariamente inviato da Ratatosk

Ne prevede comunque il doppio di Sandy Bridge (e aggiungo io perfettamente inutili in ambito desktop se non per fare codifica video).

Ad ogni modo in campo server gli Opteron 62xx saranno per sistemi 2P/4P, quindi fino a 64 core per macchina e no, non ci sono schede enthusast per server

Boh io avevo visto già ora una scheda con 2 socket per opteron se nn erro con il crossfire, rivolta agli enthusiast. Era in una news qui o su tom's però era un pc completo non so se la venderanno separatamente
64 cuori sono una bella roba.. a boinc potrei salire alle prime posizioni...

[Ren]

Su questo ho un grosso dubbio, nel senso che invertendo l'ottica con cui guardi la questione invece di avere una FPU condivisa potresti avere due INT dove nella CPU intel ne troveresti una.

Dalle roadmap che ho visto fin qui SB sarebbe 4c (quindi 4int 4fpu) contro 8c (8int 4fpu)...

Mi riferivo alle performance in AVX, non al intero processore.
Parlando sempre di performance secondo me ormai è più indicato considerare i thread più che i core. Vedremo in futuro se amd riuscirà ad estrarre maggior parallelismo scindendo i core, invece di tener alu maggiormente occupate con SMT.

Ti vorrei far presente una cosa, la Fpu di amd non è deficitaria, a mio avviso, dunque da ignorante, rispetto a quella di intel, perchè a meno che di non aver letto cacchiate, ogni unità FPU è dual ported con la cache http://citavia.blog.de/2010/04/22/pr...lated-8429143/ quindi 2 istruzioni 64bit o 2 128bit od 1 256bit in una passata,poichè le unità dual issue e dual ported come si vede dal grafico, a, ergo una sola passata per srcivere una istruzione avx, comunque poi scusa il bus L1-D e gia di 256bit nei k10 capisco se magari il bus verso la cache L1 fosse di 128 ed allora fossero necessari due cicli di clock, ma non penso che in bd diminuiscano il bus, il contrario semmai. Ergo non vedo la mancanza di potenza in Fp.

Figurati, sono anche io un ignorantone che ha appreso quel poco che sa da articoli e forum.

Il bus del K10 è un 128+64, quindi facendo parallelo ci vorrebbero due cicli di clock.

La mia idea nasce dal principio (forse errato) che aumentare eccessivamente il bus "di ogni via" dovrebbe essere uno spreco laddove si usano prevalentemente istruzioni intere 64bit.

[Ren]

Riguardo ai thread, ci sono situazioni in cui l'SMT peggiora le prestazioni, questo con cores non può accadere.

Purtroppo per noi utenti desktop, la vera battaglia che conta è nei server, dove SMT è molto efficace, tant'è che IBM, presente solo nel settore high-performance ne ha una variante 4 vie per i suoi power 7, pur avendo solo due alu intere ed una pipeline 20 stadi.

Avevo capito, per questo ti dico che non è uno svantaggio (numericamente parlando), visto che sarebbe 4 vs 4, il vantaggio lo avrebbe al più AMD nell'INT, trovandosi in 8 vs 4.

Stranamente avevo considerato come base un 6 core(forse sono troppo fissato con i server), comunque se la scrittura avverrà, come ipotizzo, in due passate intel avrà comunque un lieve vantaggio...

[Pihippo]

Originariamente inviato da Ren

Mi riferivo alle performance in AVX, non al intero processore.



Figurati, sono anche io un ignorantone che ha appreso quel poco che sa da articoli e forum.

Il bus del K10 è un 128+64, quindi facendo parallelo ci vorrebbero due cicli di clock.

La mia idea nasce dal principio (forse errato) che aumentare eccessivamente il bus "di ogni via" dovrebbe essere uno spreco laddove si usano prevalentemente istruzioni intere 64bit.

Ciao
In effetti bus ampi richiedono più transistor, qui bjt2 ne saprà più di me e potrà dirci lui. Il fatto è prevedere se le avx a 256bit saranno utilizzate molto nei programmi vari, applicativi professionali e giochini vari. Solo dopo si potrà dire se un probabile aumento del bus sia stato utile. Comunque è vero, hai ragione 2 read a 128 bit ed 1 store(write) a 64bit. Quindi due cicli di clock.

[Pihippo]

Originariamente inviato da Ren

Purtroppo per noi utenti desktop, la vera battaglia che conta è nei server dove SMT è molto efficace.

Ciao
E dove magny c con 12 cores reali va molto bene aggiungerei.

[bjt2]

Originariamente inviato da Ren

Purtroppo per noi utenti desktop, la vera battaglia che conta è nei server, dove SMT è molto efficace, tant'è che IBM, presente solo nel settore high-performance ne ha una variante 4 vie per i suoi power 7, pur avendo solo due alu intere ed una pipeline 20 stadi.



Stranamente avevo considerato come base un 6 core(forse sono troppo fissato con i server), comunque se la scrittura avverrà, come ipotizzo, in due passate intel avrà comunque un lieve vantaggio...

Già adesso i K10 possono fare due letture a 128 bit o una scrittura a 128 bit per ciclo. I buldozer avranno le nuove cache a 8 transistor che non richiedono più acrobazie (ossia andare al doppio della frequenza della CPU) per fare due letture per ciclo. Probabilmente potranno fare 2 letture e 2 scritture a 128 bit per ciclo, se non di più. Non lo sappiamo. E' probabile, poi, l'uso del moltiplicatore e dell'adder separati oppure uniti per l'FMA (mi pare ci sia un brevetto AMD), infine il power con SMT a 4 vie mi pare sia in order issue, così da occupare meno transistros, sprecare meno risorese e salire di più...

[Trokji]

Ma non è un peccato allora che neppure il prossimo windows sia a 128 bit? quanto incrementerebbero le prestazioni? o non c'entra niente..?

[Ren]

Già adesso i K10 possono fare due letture a 128 bit o una scrittura a 128 bit per ciclo. I buldozer avranno le nuove cache a 8 transistor che non richiedono più acrobazie (ossia andare al doppio della frequenza della CPU) per fare due letture per ciclo. Probabilmente potranno fare 2 letture e 2 scritture a 128 bit per ciclo, se non di più. Non lo sappiamo. E' probabile, poi, l'uso del moltiplicatore e dell'adder separati oppure uniti per l'FMA (mi pare ci sia un brevetto AMD),

Non sapevo che amd utilizzasse un doppio clock per le sue cache data...

Ti confermo (amdzone) che le unità fmac mantengono piena compatibilità con le sse/x87 con un minomo degrado prestazionale, circola anche un pdf con lo studio delle performance.

infine il power con SMT a 4 vie mi pare sia in order issue, così da occupare meno transistros, sprecare meno risorese e salire di più...

Ti sbagli, è un Out of order con 12 unità funzionale(non ricordo quante porte) con un SMT 4vie. La pipeline dovrebbe essere una evoluzione di quella del power4.

IBM lavora con i Power7 dove non lavorano né Xeon né Opteron, anche l'areodinamica di una Ferrari è molto vantaggiosa rispetto a quella di una Panda 4x4, ma se devi fare fuoristrada leggero l'areodinamica della Ferrari è un limite

Stiamo parlando di server ad alte prestazioni non penso che bulldozer sia nato per il mercato desktop, al massimo si è cercata una lieve convergenza per adattarlo ad i settori inferiori.

Il tuo paragone è calzante per i processori non general purpose.

In ogni caso non si verificherà mai il caso in cui 4c/8t è meglio che 8c/8t; se va meglio il primo dei due il vantaggio non è sicuramente dovuto all'SMT

Guarda che non ho mai pensato una cosa simile.
Ho semplicemente detto che SMT permette un ottimo boost prestazionale, perchè maschera le latenze ed ottimizza il carico, rendendo meno gravose le bolle nella pipeline.

[Pihippo]

Originariamente inviato da Ren

Cut
Guarda che non ho mai pensato una cosa simile.
Ho semplicemente detto che SMT permette un ottimo boost prestazionale, perchè maschera le latenze ed ottimizza il carico, rendendo meno gravose le bolle nella pipeline.

Ciao
Attenzione però, il SMT da un boost prestazionale buono se lo scheduler del S.O fa un ottimo lavoro, sopratutto se assegna ad i core logici i thread con poco lavoro di memoria, visto che alla fine hai LSu e agu dimezzate.
Quindi in ambito server, a meno di particolari architetture come quella di IBM che è più efficiente in questo campo del nehalem, almeno cosi ho letto, meglio più cores fisici che logici. Ed ovviamente tonnellate di mem bandwidth.

Edit:
Pensavo fosse noto che amd ha mantenuto adder e multiplier separati, altrimenti a che prò implementare le avx se con le istruzioni vecchie hai cali notevoli di performance?

[mack.gar]

Originariamente inviato da Ren

Non sapevo che amd utilizzasse un doppio clock per le sue cache data...

Ti confermo (amdzone) che le unità fmac mantengono piena compatibilità con le sse/x87 con un minomo degrado prestazionale, circola anche un pdf con lo studio delle performance.



Ti sbagli, è un Out of order con 12 unità funzionale(non ricordo quante porte) con un SMT 4vie. La pipeline dovrebbe essere una evoluzione di quella del power4.



Stiamo parlando di server ad alte prestazioni non penso che bulldozer sia nato per il mercato desktop, al massimo si è cercata una lieve convergenza per adattarlo ad i settori inferiori.

Il tuo paragone è calzante per i processori non general purpose.



Guarda che non ho mai pensato una cosa simile.
Ho semplicemente detto che SMT permette un ottimo boost prestazionale, perchè maschera le latenze ed ottimizza il carico, rendendo meno gravose le bolle nella pipeline.

Ciao, se non mi ricordo male, le cache L1 del k8/k10 leggono due dati per ciclo di clock perchè organizzata in 8 banchi: se i due dati non sono presenti nello stesso banco riesce a leggerli, se no ne legge solo uno. La cella di memoria sram non è dual ported e non opera al doppio della frequenza.
Qui nei forum leggo spesso commenti curiosi, tipo che è un peccato che amd non abbia implementato l'smt su BD. Il punto chiave dell'architettura nuova è proprio che NON ha voluto farlo! L'SMT non è Gratis: bisogna "spendere" transistor per realizzarlo, Intel mi pare che a suo tempo aveva dichiarato un 5% di transistor in più sull'insieme della cpu, ora amd dichiara (mi pare) che per un 10% in più di transistor ti dà un core in più. Quindi: spendo il 5% in più per avere circa il 20% di performance in più o il 10% per l'80% di performance in più? Amd ha scelto la seconda... Solo il tempo ci dirà chi ha fatto le scelte migliori...

[bjt2]

Originariamente inviato da Trokji

Ma non è un peccato allora che neppure il prossimo windows sia a 128 bit? quanto incrementerebbero le prestazioni? o non c'entra niente..?

128 bit vuol dire che i registri interi sono a 128 bit e anche gli indirizzi. Attualmente 64 bit basteranno per probabilmente almeno 50 anni. Se vuoi fare calcoli a 128-256 bit usi le estensioni vettoriali.
Il supporto alle SSE e AVX deve essere presente a livello di SO (è anche a quello, credo, che servano i drivers del processore), perchè a ogni task switch devono essere conservati. Infatti sia le estensioni SSE che AVX devono per prima cosa essere supportade dalla CPU, e infine supportate e ABILITATE dal SO, che deve sapere che a ogni task switch deve allocare lo spazio per i registri a 128/256 bit nella memoria del kernel. Questo perchè esiste una istruzione specifica delle CPU x86 che fa tutto il lavoro sporco di salvare i registri. Però deve essere allocato lo spazio sufficiente...

[bjt2]

Originariamente inviato da mack.gar

Ciao, se non mi ricordo male, le cache L1 del k8/k10 leggono due dati per ciclo di clock perchè organizzata in 8 banchi: se i due dati non sono presenti nello stesso banco riesce a leggerli, se no ne legge solo uno. La cella di memoria sram non è dual ported e non opera al doppio della frequenza.
Qui nei forum leggo spesso commenti curiosi, tipo che è un peccato che amd non abbia implementato l'smt su BD. Il punto chiave dell'architettura nuova è proprio che NON ha voluto farlo! L'SMT non è Gratis: bisogna "spendere" transistor per realizzarlo, Intel mi pare che a suo tempo aveva dichiarato un 5% di transistor in più sull'insieme della cpu, ora amd dichiara (mi pare) che per un 10% in più di transistor ti dà un core in più. Quindi: spendo il 5% in più per avere circa il 20% di performance in più o il 10% per l'80% di performance in più? Amd ha scelto la seconda... Solo il tempo ci dirà chi ha fatto le scelte migliori...

Avevo letto da qualche parte che la cache andava al doppio del clock, ma non per fare due letture per ciclo, ma per sovrapporre lettura tag e accesso. Più che andare al doppio del clock, mi pare che una parte funzioni su un fronte e una sull'altro...

[Ren]

Non so quanto costi a Intel, AMD dichiara +5% die area per l'aggiunta di un core INT.

Penso si riferiscano alle sole unità intere(scheduler,registri ecc...), senza tenere conto della lsu con relative cache dati.

[mack.gar]

Originariamente inviato da Ratatosk

Non so quanto costi a Intel, AMD dichiara +5% die area per l'aggiunta di un core INT.

"Our engineers estimate that the amount of discrete circuitry that is added to each Bulldozer module in order to allow for a second integer thread to run only adds ~12% additional circuitry to each module, which translates into only ~5% of circuitry to the total Bulldozer die"

Sembra che siano giuste tutte e due le nostre cifre.... cambia solo il punto di vista...

[mack.gar]

Originariamente inviato da bjt2

Avevo letto da qualche parte che la cache andava al doppio del clock, ma non per fare due letture per ciclo, ma per sovrapporre lettura tag e accesso. Più che andare al doppio del clock, mi pare che una parte funzioni su un fronte e una sull'altro...

Non so che dirti... Non ricordo di aver letto niente al riguardo, ma ovviamente non vuol dire niente, di solito non ricordo nemmeno cosa ho fatto 5 min. prima... In realtà non ho nemmeno idea di che tag tu ti riferisca ti riferisci alla tag per l'indirizzo fisico? può essere, nel senso che fa i suoi look up alle tag ram (una per via) nel tempo di un ciclo per la decodifica dell'indirizzo.
Cmq la latenza di accesso è sempre di 3 cicli: il primo si decodifica l'indirizzo, al secondo si va a pescare il dato, al terzo lo si inoltra, il processo è ovviamente pipeline-izzato e la cache ha due porte (a 64 bit nel k8 e 128 nel k10), quindi fornisce due dati per ciclo di clock. 64 KB, 2 vie, 8 banchi, 64 byte line size, true LRU

[B|4KWH|T3]

Originariamente inviato da capitan_crasy

I 32nm infatti sono attesi per la produzione in volumi entro la fine del 2010 quindi tra 6 mesi che in termini di sviluppo non sono molti...
Per farti un esempio nel 2008 i 45nm SOI sono stati mostrati a inizio marzo 2008 sottoforma di sample perfettamente funzionanti per essere presentati a inizio 2009; siamo a giugno e ancora niente sample di 32nm mostrati...
Credi che i futuri investitori/produttori OEM si accontentino solo delle belle parole di AMD?
Arriverà, potrà, stupirà; ma in dò stà????

Guarda che ti stai confondendo con le schede video.
Nelle roadmap bulldozer&llano@32nm sono sempre stati riportati nel 2011. Da un paio di anni.

(basta fare una ricerca rapida su google)

[Pihippo]

Originariamente inviato da mack.gar

Non so che dirti... Non ricordo di aver letto niente al riguardo, ma ovviamente non vuol dire niente, di solito non ricordo nemmeno cosa ho fatto 5 min. prima... In realtà non ho nemmeno idea di che tag tu ti riferisca ti riferisci alla tag per l'indirizzo fisico? può essere, nel senso che fa i suoi look up alle tag ram (una per via) nel tempo di un ciclo per la decodifica dell'indirizzo.
Cmq la latenza di accesso è sempre di 3 cicli: il primo si decodifica l'indirizzo, al secondo si va a pescare il dato, al terzo lo si inoltra, il processo è ovviamente pipeline-izzato e la cache ha due porte (a 64 bit nel k8 e 128 nel k10), quindi fornisce due dati per ciclo di clock. 64 KB, 2 vie, 8 banchi, 64 byte line size, true LRU

Ciao.
Il tag è la parte più significativa dell'indirizzo dell' operando che risiede nella cache, ovvero il tag è quello che controlla l'hardware per vedere se il dato\operando è giusto, se è giusto si ha un hit e la cpu lo preleva dalla cache, grazie ad i prefetcher comunque l'hit rate è molto alto poichè di solito riescono a caricare preventivamente il dato nella cache. Purtroppo invece se il dato non è nella cache e lo si vuole prelevare bisogna calcolarne l'indirizzo, altrimenti le agu che ci starebbero a fare? quindi da ignorante totale posso dire con certezza al 10% che il cache tag non ti rappresenta l'idirizzo fisico nella ram dell'operando.
Edit: Ma la politica della cache Lru è cosi perchè è facile da realizzare con 128kb di L1? http://www.dis.uniroma1.it/~alberto/...tori/cache.pdf

[capitan_crasy]

Originariamente inviato da B|4KWH|T3

Guarda che ti stai confondendo con le schede video.
Nelle roadmap bulldozer&llano@32nm sono sempre stati riportati nel 2011. Da un paio di anni.

(basta fare una ricerca rapida su google)

GF ha dichiarato che la produzione in volumi dei 32nm SOI comincerà nella seconda parte del 2010 (fine 2010 per la precisione).
Clicca qui...
Naturalmente questo non significa che saranno disponibili per la vendita in quella data, dato che sono previsti nel 2011...

[papafoxtrot]

Originariamente inviato da Ratatosk

Avevo capito, per questo ti dico che non è uno svantaggio (numericamente parlando), visto che sarebbe 4 vs 4, il vantaggio lo avrebbe al più AMD nell'INT, trovandosi in 8 vs 4.

Riguardo ai thread, ci sono situazioni in cui l'SMT peggiora le prestazioni, questo con cores non può accadere.

Veramente te sandy bridge avrà 4 core nella fascia media... l'attuale lynnfield insomma.
Il sandy bridge di fascia alta, credo su socket 2011... Avrà 8 core con HT.

Per questo mi suona strano che AMD pensi di concorrere con intel con soli 4 moduli, 4 FPU e 8 INT.

Alla fine: al momento nel die di phuban ci sono stati 6 int e 6 fpu.
BD sarà a 32nm, quindi un buon 30% in meno, il che vuol dire che un thuban portato a 32nm avrebbe un diesize del 49% di quello che ha attualmente.
Praticamente a 32nm possono starci, nella stessa rea, due thuban.
Volete dirmi che loro riescono a farci stare solo 8 int (un 33% in più di thuban) e 4 FPU? (il 33% in meno=??)
Saranno anche più grandi queste FPU... ma caspita...
Consideriamo anche un die grande come quello di deneb, il 33% in meno di quello di thuban, che forse è fin troppo largo:
portiamo deneb a 32nm e quello già occupa la metà dell'area.
A questo punto per ogni INT aggiunta ci va via il 5% dell'area. Se aggiungiamo 4 int (deneb è quad core), l'area aumenta del 20%. Il 20% di una rea grande il 50% dell'attuale.
Quindi siamo ad un core 8int e 4 fpu che occupa il 60% dell'area di deneb.
C'è da considerare l'aumento di dimensione della cache, che in deneb porta via un sacco di spazio... Ma secondo me ci sta più materiale in quel chip!


E contro intel sarebbe numericamente svantaggiato... perché intel venderà comunque 8 int, come AMD, ma anche 8 fpu. Anche che quelle AMD siano il doppio più potenti (pare sia il doppio più potente di quelle attuali) e che quelle di intel non migliorino passando da nehalem a SB... Non ci sarebbe comunque un gran confronto! Al più al più sarebbero pari! Intel avrebbe comunque il multi-threading...

Diverso chiaro, se AMD implementasse 8 moduli. Allora avrebbe 8 fpu come intel. Ma mentre intel raddoppia i thread per core, amd raddoppia tutta la int... E quindi 16 int contro 8 multi threaded...

Ora io non voglio fare dell'ottimismo sfrenato e pensare che ci stanno fregando dicendoci che ci sono meno core di quelli che ci sono in realtà... Però mi sembra che abiano la possibilità di metter su più carne di quella che ci dicono...
Consideriamo anche che con HKMG il chip consumerà meno... vuol dire che:
- o possiamo fare chip più grandi
- o possiamo salire di più con la frequenza

Ma la frequenza che raggiungiamo dipende molto dalla lunghezza delle pipeline, che come abbiamo visto con netbuirst alal fine non conviene allungare più di tanto... Già Deneb/thuban mi sembra abbiano pipeline piuttosto lunghe...più di nehalem.
E con le lunghezze di pipeline cui si sono assestate le architetture attuali alla fine più di 4GHz non si sale... Altrimenti il calore cresce molto più delle prestazioni e alla fine la soluzione non è efficiente.
Molto meglio ingrandire il die insomma...

[mack.gar]

Originariamente inviato da Pihippo

Ciao.
Il tag è la parte più significativa dell'indirizzo dell' operando che risiede nella cache, ovvero il tag è quello che controlla l'hardware per vedere se il dato\operando è giusto, se è giusto si ha un hit e la cpu lo preleva dalla cache, grazie ad i prefetcher comunque l'hit rate è molto alto poichè di solito riescono a caricare preventivamente il dato nella cache. Purtroppo invece se il dato non è nella cache e lo si vuole prelevare bisogna calcolarne l'indirizzo, altrimenti le agu che ci starebbero a fare? quindi da ignorante totale posso dire con certezza al 10% che il cache tag non ti rappresenta l'idirizzo fisico nella ram dell'operando.
Edit: Ma la politica della cache Lru è cosi perchè è facile da realizzare con 128kb di L1? http://www.dis.uniroma1.it/~alberto/...tori/cache.pdf

Si, la mia memoria fa cilecca confondevo con i problemi di alias sugli indirizzi. E' una LRU perchè è a due vie e basta un bit (per linea) per puntare alla via la cui linea deve essere sfrattata. Mi pare che intel adotti un pseudo lru che con 2 bit indirizza più vie, ma non so nulla dei processori recenti.