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

[Pihippo]

Originariamente inviato da capitan_crasy

E' chiaro che ho frainteso alcune letture sul Reverse HTT e AVX...
Chiedo scusa per la mia ignoranza...

Ciao capo
Scusarti di che? Il forum serve a questo!
Anzi meno male che ci sei tu che fai sti thread che secondo me sono utili ed ottimi
Ho dato una lettura approfondita all'articolo linkato sopra, morale della storia, ci serve bjt2 per qualche spiegazione visto che non c'ho capito una fava

[Ren]

Ciao
Infatti secondola mia modesta opinone non centra nulla. Magari c'è confusione che le unita fp di un modulo di bd sono due shared con 2 cluster di int, che non si sa se sono 4x4, ovvero 4 alu+4agu o 2x2 ovvero 2alu+2agu, con datapath a 128bit, quindi è probabile che in caso di AVX a 256bit una esegua i lower 128bit dell'istruzione l'altra la parte superiore, ma sempre in una passata comunque.
Comunque un pò di info http://citavia.blog.de/2010/04/22/pr...lated-8429143/
I commenti sono molto interessanti.

Grazie, ma già lo conoscevo.
Io stesso lo ho segnalato nella vecchia discussione del K10.

Ho dato una lettura approfondita all'articolo linkato sopra, morale della storia, ci serve bjt2 per qualche spiegazione visto che non c'ho capito una fava

Se intendi quello linkato dal capitano, non dice nulla di nuovo.

[bjt2]

Originariamente inviato da genesi86

Bhè sono grandi numeri, però ho il timore che i prezzi non saranno poi bassissimi, almeno in relazione a quanto potrei spendere adesso per un mini pc con grafica integrata sulla motherboard.

Beh, INTEL lo ha fatto. Certo, la sua GPU è molto più piccola, ma è prodotta a 45nm. Qua il tutto sarà 32nm SOI...

Originariamente inviato da genesi86

Ma la GPU andrà ad aiutare la CPU anche per le normali operazioni che adesso gravano solo sui processori?

L'integrazione CPU-GPU non potrebbe cannibalizzare il mercato delle schede video dello stesso produttore? almeno quelle di fascia bassa, che comunque, pur avendo margini di profitto ridotti, fanno grossi numeri.

Questo è in un progetto futuro (MOLTO futuro)

Originariamente inviato da ippo.g

poco meno di una 5750
e su quale tipo di ram si appoggerà?

Originariamente inviato da ippo.g

bus? 64 o 128?

Meno di una 5750 che ha bus a 128 bit, ma GDDR5 che vanno a 3600...

Originariamente inviato da capitan_crasy

Il controller sarà in Dual channel (128Bit)...

Se non sbaglio il Reverse HTT si era ipotizzato per eseguire le istruzioni AVX a 256bit...

Originariamente inviato da Ren

Non capisco cosa centri il reverseHT(un modo per estrarre più parallelismo dal codice, in hardware) con l'eseguire in due passare delle istruzioni 256bit.
Per farti un esempio, molte implementazioni delle sse prevedevano alu 64bit con registri ed istruzioni 128bit da risolvere in due passate.

Originariamente inviato da capitan_crasy

E' chiaro che ho frainteso alcune letture sul Reverse HTT e AVX...
Chiedo scusa per la mia ignoranza...

Originariamente inviato da Pihippo

Ciao capo
Scusarti di che? Il forum serve a questo!
Anzi meno male che ci sei tu che fai sti thread che secondo me sono utili ed ottimi
Ho dato una lettura approfondita all'articolo linkato sopra, morale della storia, ci serve bjt2 per qualche spiegazione visto che non c'ho capito una fava

Ora leggo...

[bjt2]

Originariamente inviato da bjt2

Ora leggo...

Beh, nulla di nuovo rispetto a quanto detto:

Ipotizza che le unità intere siano 2 ALU + 2 AGU e che le unità FP sono collegate tra di loro, quindi sospetto che possano fare 1 istruzione AVX in un solo ciclo, ovviamente per solo uno dei due cores alla volta... E' questo che ha fatto nascere il mito del reverse Hyperthreading: quando non si sapeva nulla, si pensava che ogni core avesse la sua brava FPU a 128 bit e che una istruzione a 256 bit venisse eseguita usando le FPU di 2 cores. Ma non è così. Ora sappiamo che una sola FPU doppia da 2x128 bit è condivisa da due cores. Così è molto più facile fare una istruzione a 256 bit in un ciclo. In sostanza questa FPU è molto flessibile: può fare una istruzione a 256 bit o 2 a 128 bit e non mi stupirei se potesse fare 4 istruzioni a 64 bit (MMX / 3dnow)

[capitan_crasy]

Originariamente inviato da bjt2

Beh, nulla di nuovo rispetto a quanto detto:

Ipotizza che le unità intere siano 2 ALU + 2 AGU e che le unità FP sono collegate tra di loro, quindi sospetto che possano fare 1 istruzione AVX in un solo ciclo, ovviamente per solo uno dei due cores alla volta... E' questo che ha fatto nascere il mito del reverse Hyperthreading: quando non si sapeva nulla, si pensava che ogni core avesse la sua brava FPU a 128 bit e che una istruzione a 256 bit venisse eseguita usando le FPU di 2 cores. Ma non è così. Ora sappiamo che una sola FPU doppia da 2x128 bit è condivisa da due cores. Così è molto più facile fare una istruzione a 256 bit in un ciclo. In sostanza questa FPU è molto flessibile: può fare una istruzione a 256 bit o 2 a 128 bit e non mi stupirei se potesse fare 4 istruzioni a 64 bit (MMX / 3dnow)

Infatti nel mio piccolo avevo interpretato l'aggiunta del Reverse HTT per eseguire le istruzioni AXV in un solo ciclo di clock...
P.S.
Che ne pensi dell'aggiunta del macro-op fusion?

[Ren]

Beh, nulla di nuovo rispetto a quanto detto:

Ipotizza che le unità intere siano 2 ALU + 2 AGU e che le unità FP sono collegate tra di loro, quindi sospetto che possano fare 1 istruzione AVX in un solo ciclo, ovviamente per solo uno dei due cores alla volta... E' questo che ha fatto nascere il mito del reverse Hyperthreading: quando non si sapeva nulla, si pensava che ogni core avesse la sua brava FPU a 128 bit e che una istruzione a 256 bit venisse eseguita usando le FPU di 2 cores. Ma non è così. Ora sappiamo che una sola FPU doppia da 2x128 bit è condivisa da due cores. Così è molto più facile fare una istruzione a 256 bit in un ciclo. In sostanza questa FPU è molto flessibile: può fare una istruzione a 256 bit o 2 a 128 bit e non mi stupirei se potesse fare 4 istruzioni a 64 bit (MMX / 3dnow)

Sono curioso di come verranno gestiti i calcoli degli indirizzi e lo store nella cache delle unità FP. Chissà se introdurranno un altra LSU intermedia per il virgola mobile o i dati rimbalzeranno dentro i core interi per l'interfacciamento con la cache...

[bjt2]

Originariamente inviato da capitan_crasy

Infatti nel mio piccolo avevo interpretato l'aggiunta del Reverse HTT per eseguire le istruzioni AXV in un solo ciclo di clock...
P.S.
Che ne pensi dell'aggiunta del macro-op fusion?

Se non è limitata come quella INTEL è una ottima cosa.
Ricordo che la macro op-fusion INTEL funziona solo in pochi casi e solo per una coppia di istruzioni ogni 5. Se ci sono più coppie consecutive fondibili, solo la prima è fusa...

[bjt2]

Originariamente inviato da Ren

Sono curioso di come verranno gestiti i calcoli degli indirizzi e lo store nella cache delle unità FP. Chissà se introdurranno un altra LSU intermedia per il virgola mobile o i dati rimbalzeranno dentro i core interi per l'interfacciamento con la cache...

La seconda che hai detto... Infatti dai vari schemi non c'è più l'unità FSTORE...

[capitan_crasy]

Non mi ricordo se questa immagine è sta stata analizzata...



Lo schema dovrebbe essere non confermato...

[Ren]

La seconda che hai detto... Infatti dai vari schemi non c'è più l'unità FSTORE...

Conosco lo schema di dresdenboy, ma non sono sicuro se possiamo definirlo confermato...

Ancora ne passerà di tempo prima di vedere sto benedetto bulldozer.

[bjt2]

Originariamente inviato da capitan_crasy

Non mi ricordo se questa immagine è sta stata analizzata...



Lo schema dovrebbe essere non confermato...

E' questa l'immagine a cui mi riferivo quando ho detto nulla di nuovo...

Si vede il 2+2, le FPU collegate per poter fare l'operazione a 256 bit, la mancanza della pipeline fstore, il collegamento con le unità di load/store della pipeline intera...

[capitan_crasy]

Originariamente inviato da Ren

Conosco lo schema di dresdenboy, ma non sono sicuro se possiamo definirlo confermato...

Ancora ne passerà di tempo prima di vedere sto benedetto bulldozer.

Infatti lo schema è dato come teorico o meglio sulle informazioni più o meno reali dell'architettura Bulldozer.
Quello che so è che i sample funzionanti ci sono, ma per ora non si sa esattamente quale sia il suo livello di sviluppo.
Lo sviluppo di Llano essendo basato sul K10 è più avanti, anche bobcat è praticamente finito; i tempi sono primo trimestre 2010 per la piattaforma Linx, secondo trimestre 2010 per la piattaforma Scorpius e Bobcat (quest'ultimo dipende dalla resa in volumi dei a 40nm bulk)...

[Ren]

Infatti lo schema è dato come teorico o meglio sulle informazioni più o meno reali dell'architettura Bulldozer.
Quello che so è che i sample funzionanti ci sono, ma per ora non si sa esattamente quale sia il suo livello di sviluppo.
Lo sviluppo di Llano essendo basato sul K10 è più avanti, anche bobcat è praticamente finito; i tempi sono primo trimestre 2010 per la piattaforma Linx, secondo trimestre 2010 per la piattaforma Scorpius e Bobcat (quest'ultimo dipende dalla resa in volumi dei a 40nm bulk)...

Secondo me, vedremo una timida offerta del bulldozer nel primo/secondo trimestre del 2011, ovviamente solo per il settore server.Per noi utenti desktop apparirà qualcosa 9-15mesi dopo...

Bobcat da come è disegnato sembra l'aggiornamento tecnologico del vecchio K6. (peccato per le sse castrate)

Tornando al discorso macroop, chissà se sarebbe realistica una fusione hardware (FP) tra una mul ed una mad, dato che le unità del bulldozer sono delle FMA...

[Pihippo]

Originariamente inviato da bjt2

La seconda che hai detto... Infatti dai vari schemi non c'è più l'unità FSTORE...

Ciao
Grazie dell'intervento bjt2
Dunque è curiosa questa cosa della mancanza di Fmisc\Fstore.
In pratica cosa comporterebbe? Ovvero da quanto letto sul blog di anger fog sebbene il k10 ed il k8 abbiano 3 agu, spesso , anzi secondo quanto dice lui molto spesso, e questo è anche una causa di perdità di performance importante visto che si stalla un poco tutto se non hai operandi indirizzi pronti, ogni ciclo di clock solo una o 2 agu possono produrre un indirizzo o compiere un operazione di memoria visto che le mop amd che arrivano allo scheduler sono 2 istruzioni logico\aritmetiche +1 di memoria.
Quindi la mancanza di una Fstore implica che magari è cambiato qualcosina nei decoder di amd e magari si ha una maggiore efficienza nel lavoro con la memoria stessa, cosi si liberano le unità, in questo caso fp per lavoro diciamo più intellettuale. Magari anche con performance migliori.

[bjt2]

Originariamente inviato da Pihippo

Ciao
Grazie dell'intervento bjt2
Dunque è curiosa questa cosa della mancanza di Fmisc\Fstore.
In pratica cosa comporterebbe? Ovvero da quanto letto sul blog di anger fog sebbene il k10 ed il k8 abbiano 3 agu, spesso , anzi secondo quanto dice lui molto spesso, e questo è anche una causa di perdità di performance importante visto che si stalla un poco tutto se non hai operandi indirizzi pronti, ogni ciclo di clock solo una o 2 agu possono produrre un indirizzo o compiere un operazione di memoria visto che le mop amd che arrivano allo scheduler sono 2 istruzioni logico\aritmetiche +1 di memoria.
Quindi la mancanza di una Fstore implica che magari è cambiato qualcosina nei decoder di amd e magari si ha una maggiore efficienza nel lavoro con la memoria stessa, cosi si liberano le unità, in questo caso fp per lavoro diciamo più intellettuale. Magari anche con performance migliori.

Non esiste più una FADD/FMUL e FMISC con tutti i problemi di routing delle istruzioni. Le due unità FP dovrebbero essere intercambiabili, nel senso di poter fare tutte le istruzioni anche le più complesse... Questo potrebbe risolvere un bel po' di problemi. Se poi una unità può addirittura fare una moltiplicazione e una addizione a 128 bit separatamente, spezzando l'lunità FMA, questo sarebbe ancora meglio...

[papafoxtrot]

Originariamente inviato da Ren

Secondo me, vedremo una timida offerta del bulldozer nel primo/secondo trimestre del 2011, ovviamente solo per il settore server.Per noi utenti desktop apparirà qualcosa 9-15mesi dopo...
...

9-15 mesi dopo le prime CPU server, di inizio 2011? Cioè da gennaio a giugno 2012? Ma stai scherzando?
Bulldozer arriverà assieme su desktop e su workstation/server... Per il 2012 nella roadmap ce già la seconda generazione...!

[Ren]

Sono più convinto per un debutto in volumi per fine 2011, se non hanno problemi di rese o di bug (probabili con una nuovissima architettura).

[capitan_crasy]

Originariamente inviato da Ren

Secondo me, vedremo una timida offerta del bulldozer nel primo/secondo trimestre del 2011, ovviamente solo per il settore server.Per noi utenti desktop apparirà qualcosa 9-15mesi dopo...
.

Esagerato...
Al massimo Zambezi uscità 40/60 giorni dopo la messa in commercio della prima CPU Bulldozer per il mercato server...
Dopo tutto le CPU Server e Desktop AMD condividono da generazioni lo stesso core con qualche modifica del caso...

[Athlon 64 3000+]

Secondo me con le cpu Buldozer da server e desktop avranno roadmap molto simile alle piattaforma K10 uscite quest'anno.
Q1 2011 per Interlagos e Q2 2011 per Zambesi.
Per le Zambesi verrà presentato per maggio dell'anno prossimo.

[Claudio-x64]

Salve a tutti. Seguo questo 3D da mesi ormai, ed è molto interessante.

Mi chiedevo ... ma AMD ha mai parlato ufficialmente di Reverse Hyper Threading ? Esiste qualche altro processore (non x86) che utilizza un architettura simile a quella di Bulldozer (CMT) ?

Ciao