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

[mtk]

Originariamente inviato da paolo.oliva2

Credo sia un milione di $...

no no,era un miliardo abbondante di dollari....se la memoria non mi inganna 1,5....ci facevo il pieno al razzo

edit.
1.25 miliardi

[bjt2]

Originariamente inviato da papafoxtrot

Non credo sia proprio così semplice, anceh se può essere. Non ricordo bene.
E' stata la soluzione extragiudiziale della controversia tra AMD e Intel presso la corte di new york.
Intel ci metteva le licenze X86 e non so se e quali altri brevetti e un miliardo di dollari. AMD non impiantava altre cause legali legate alla vicenda.
Se fosse così secondo me al prossimo giro AMD aggiungerà anche SMT. Male non farà, e può essere tranquillamente aggiunto ad ogni pipeline intera.
Una cosa ancora sulla FMAC che può eseguire una mul ed una add di due processi diversi. Ciò richiede in effetti i quattro operandi in input di cui si è parlato, contro i tre operandi canonici di una FMA.

Probabilmente quando anche intel passerà alel FMA allora si eseguiranno veramente (nel senso che il compilatore le manderà in esecuzione) operazioni FMA; e allora sostituiranno l'input con i tre operandi canonici e toglieranno questo riarrangiamento.

Una domanda: Il passaggio alle oeprazioni FMA è un passo in direzione di fusion? Voglio dire, per sostiture una FPU x86 con uno shader core (GPU) immagino che si debbano dare in input oeprazioni in forma di FMA. Per cui questo passaggio potrebbe essere obbligato per arrivare ad usare lo shader core delle GPU come FPU.
Sbaglio?

Il brevetto AMD predeve una FMAC a 3 bus, che poi può essere comunque a 4 operandi. Dresdenboy ha ipotizzato un quarto bus per sfruttare MUL e ADD contemporaneamente con istruzioni diverse. Quando INTEL introdurrà le FMA a 3 operandi, la FMAC dovrà comunque avere 3 bus minimo, ma non vedo il motivo per AMD di tornare a 3 bus...
L'FMAC è un passo verso l'uso delle SP delle GPU. E AMD è in vantaggio...

[bjt2]

Originariamente inviato da Ren

Il power 7 è un Out of Order con 6 dispatch unit,8 issue slot e 12 unità funzionali.

ps. ti confondi sempre...

Hai ragione... Mi confondo sempre con il SUN Niagara e il SUN Rock...

[F1R3BL4D3]

Originariamente inviato da mtk

no no,era un miliardo abbondante di dollari....se la memoria non mi inganna 1,5....ci facevo il pieno al razzo

edit.
1.25 miliardi

Si, 1,25 miliardi di $.

[B|4KWH|T3]

Originariamente inviato da paolo.oliva2

Credo sia un milione di $...

Un milione sarebbero noccioline

Era proprio un miliardo di dollari (anzi 1,2 se non erro)

[bjt2]

Originariamente inviato da cionci

Questo non lo so sinceramente. Aggiungerebbe un ritardo non facilmente prevedibile per la terminazione dell'istruzione AVX. A rigor di logica dovrebbero essere portate avanti contemporaneamente.

Se sono tutte e due libere certamente... Ma se ci sono altre istruzioni in coda, molte istruzioni in coda, è meglio stallare tutte e 2 le parti a 128 bit per farle assieme oppure farle tutte e due in sequenza su una sola pipeline?
Il motivo di avere pipeline a 128 bit è per la granularità. INTEL deve per forza fare l'istruzione a 256 bit tutta assieme, AMD no...

Immagina un thread che spara istruzioni AVX e un thread legacy che spara istruzioni a 128 bit... INTEL deve fare una istruzione a 256 e una a 128 bit in due cicli. AMD può fare 1 da 256 e DUE a 128 bit in 2 cicli...

[Megakirops]

Originariamente inviato da paolo.oliva2

Credo sia un milione di $...

no no era proprio un miliardo o poco più

[paolo.oliva2]

Originariamente inviato da calabar

Però riflettici:
- SMT risulta meno efficace negli attuali i7 6x, perchè il numero di thread gestiti comincia ad essere eccessivo per un uso desktop.
- BD è improntato per avere core più piccoli e in maggior numero. Questo ha fatto dire ad alcuni (anche tu se non erro) che proprio a causa di questo BD rischia di non essere competitivo sul mercato desktop nelle sue versioni con più di 4moduli/8core, perchè l'eccessivo numero di core difficilmente sarà gestito da applicazioni reali, mentre i core più potenti di SB gestiranno meglio la situazione.

Con questo scenario, aggiungere SMT ad un progetto già fortemente improntato al multicore, sarebbe davvero così vantaggioso?
O potrebbe rivelarsi uno spreco di silicio e tempo (la tecnologia va comunque studiata, adattata e implementata... e potrebbe non essere efficace come quella intel che su questa ha molta più esperienza), senza contare che AMD ha proprio dichiarato di voler evitare che i propri processori possano avere dei cali prestazionali in quelle situazioni in cui SMT crea problemi.

Io aggiungerei che come detto da AMD, l'intenzione sia quella di fornire un procio a parità di TH di quello Intel, con la differenza che quello Intel ha 2 TH su 1 core fisico, mentre quello AMD avrebbe i TH uguale ai core fisici.
L'SMT ulteriore creerebbe unicamente problemi e nessun vantaggio, visto che comunque l'SMT non supera mai in alcuna condizione il rendimento di 1/2 core fisico.
Al limite dei casi, come hai detto pure tu, quando SB X6 e X8 lo avremo nel desktop (dopo BD X8) e vagliato l'effettiva prestazione di BD, AMD potrebbe sempre vagliare l'opportunità di portare BD X12 e X16 (già pronti da tempo) pure nel desktop.

Originariamente inviato da capitan_crasy

Ciao:

Guarda, le informazioni che ho raccolto sui socket in questi ultimi tempi si sono rilevati del tutto inaffidabili, comprese le compatibilità.
Appurato che le CPU Bulldozer NON andranno sull'attuale socket AM3, le voci parlano di compatibilità (anche se presunta) delle CPU socket AM3 sul socket AM3+, dato che il nuovo socket nasce dalla base di quello vecchio e che Bulldozer aggiunge alcune caratteristiche e non toglie quelle che ci sono già.
Credo che avremo notizie ufficiali a novembre; non escludo che nelle prossime settimane ci siano nuove indiscrezioni sui nuovi socket e nuovi chipset...

Allora non mi resta che attendere...
Te l'ho chiesto perchè nei lab di Asus bolle qualche cosa in pentola ma nessuno si sbilancia.

[paolo.oliva2]

Originariamente inviato da Megakirops

no no era proprio un miliardo o poco più

Ops. mi scuso, non era ironia.

[mtk]

Originariamente inviato da F1R3BL4D3

Si, 1,25 miliardi di $.

Originariamente inviato da B|4KWH|T3

Un milione sarebbero noccioline

Era proprio un miliardo di dollari (anzi 1,2 se non erro)

Originariamente inviato da Megakirops

no no era proprio un miliardo o poco più

esatto...e oltre ai soldi intel ha fatto cadere le accuse di violazione di brevetti per lo spin off di globalfoundries e ha prolungato di 5 anni l utilizzo dei brevetti condivisi tra intel e amd.
e c e' ancora pendente la multa europea dell anti trust(intel ha fatto ricorso) e forse quella della fcc statunitense

[cionci]

Originariamente inviato da bjt2

Se sono tutte e due libere certamente... Ma se ci sono altre istruzioni in coda, molte istruzioni in coda, è meglio stallare tutte e 2 le parti a 128 bit per farle assieme oppure farle tutte e due in sequenza su una sola pipeline?
Il motivo di avere pipeline a 128 bit è per la granularità. INTEL deve per forza fare l'istruzione a 256 bit tutta assieme, AMD no...

Immagina un thread che spara istruzioni AVX e un thread legacy che spara istruzioni a 128 bit... INTEL deve fare una istruzione a 256 e una a 128 bit in due cicli. AMD può fare 1 da 256 e DUE a 128 bit in 2 cicli...

Non necessariamente bisogna stallarla, ma si possono anche cercare di schedulare insieme

Immagina invece lo scenario in cui metà istruzione venga eseguita e metà no e poi ci sia una dipendenza sui dati di questa. Non si complicherebbe un po' troppo ?

[F1R3BL4D3]

Originariamente inviato da mtk

esatto...e oltre ai soldi intel ha fatto cadere le accuse di violazione di brevetti per lo spin off di globalfoundries e ha prolungato di 5 anni l utilizzo dei brevetti condivisi tra intel e amd.
e c e' ancora pendente la multa europea dell anti trust(intel ha fatto ricorso) e forse quella della fcc statunitense

Con la FTC (penso sia quella che intendessi) si è arrivati all'accordo già da inizio Agosto.

[mtk]

Originariamente inviato da F1R3BL4D3

Con la FTC (penso sia quella che intendessi) si è arrivati all'accordo già da inizio Agosto.

si,scusa ho sbagliato a scrivere,allora ok mi sono perso l accordo ....comunque anche la multa europea se venisse confermata sarebbe una bella botta per intel,si parlava di 1 miliardo e qualcosa,non ricordo se dollari o euro pero'..

[bjt2]

Originariamente inviato da cionci

Non necessariamente bisogna stallarla, ma si possono anche cercare di schedulare insieme

Immagina invece lo scenario in cui metà istruzione venga eseguita e metà no e poi ci sia una dipendenza sui dati di questa. Non si complicherebbe un po' troppo ?

In termini di schedulazione e presenza in coda, per come sono fatti gli algoritmi di schedulazione, le due metà dell'istruzione a 256 o sono eseguite assieme nelle due pipeline o una dopo l'altra nella stessa pipeline, o comunque si può fare in modo che sia SEMPRE così. AMD può permettersi questa flessibilità, INTEL no... Perchè limitare le possibilità alla pipeline AMD? Non credo che sia così complicato, anzi credo cre non debba proprio farsi nulla... Pensa alle SSE quando il K8 era a 64 bit... Le istruzioni a 128 bit erano spezzate in 2 a 64 bit che andavano una dietro l'altra... Qui invece POSSONO (non debbono) andare in parallelo... E' l'unica differenza...

[cionci]

Originariamente inviato da bjt2

In termini di schedulazione e presenza in coda, per come sono fatti gli algoritmi di schedulazione, le due metà dell'istruzione a 256 o sono eseguite assieme nelle due pipeline o una dopo l'altra nella stessa pipeline, o comunque si può fare in modo che sia SEMPRE così. AMD può permettersi questa flessibilità, INTEL no... Perchè limitare le possibilità alla pipeline AMD? Non credo che sia così complicato, anzi credo cre non debba proprio farsi nulla... Pensa alle SSE quando il K8 era a 64 bit... Le istruzioni a 128 bit erano spezzate in 2 a 64 bit che andavano una dietro l'altra... Qui invece POSSONO (non debbono) andare in parallelo... E' l'unica differenza...

La differenza c'è nelle dipendenze dei dati. L'istruzione OP1 è una istruzione AVX che lavora anche sull'indirizzo X (una locazione di memoria generica).
Mettiamo che l'operazione OP2 sia a 128 bit, appartenga allo stesso thread di OP1 e sia successiva, ma necessiti di leggere da X.
Come faccio a schedulare OP1 ? Quale garanzia ho che OP1 venga eseguita dopo la seconda parte di OP2 ?

[affiu]

quindi ,per quanto abbia senso o sia utile ,aprendo piu applicazioni contemporaneamente , bulldozer dovrebbe all'umenatre di esse ,far vedere la sua potenza

cioe ,nel mio immaginario, se uno aprisse 2 bluray con 2 player diversi, fare 2 conversioni video, aprire un gioco e giocarci,+ tutti i social network e quantaltro......

lui macinerebbe come aprire un solo bluray su phenom?

[Pihippo]

Originariamente inviato da cionci

La differenza c'è nelle dipendenze dei dati. L'istruzione OP1 è una istruzione AVX che lavora anche sull'indirizzo X (una locazione di memoria generica).
Mettiamo che l'operazione OP2 sia a 128 bit, appartenga allo stesso thread di OP1 e sia successiva, ma necessiti di leggere da X.
Come faccio a schedulare OP1 ? Quale garanzia ho che OP1 venga eseguita dopo la seconda parte di OP2 ?

Ciao
In questo caso mi sa che ha fatto un gran casino l'icu della cpu. Perchè, almeno nel k10 gli indirizzi vengono sempre precalcolati dalle agu. Dunque la logica OoO dovrebbe sapere che OP1 è dipendente da OP2. Non capisco comunque cosa c'è di strano sono casi molto comuni e non solo per istruzioni Avx o fp ma anche per istruzioni int, anzi sopratutto per queste.
Sempre sperando di non aver detto minchiate.

[paolo.oliva2]

Originariamente inviato da bjt2

..sto leggendo su google gruppi che tra Thuban e Buldozer, c'è un progetto cancellato che aveva un FO4 di 13... Sarebbe arrivato a 5GHz con il 45nm! Dice anche che BD dovrebbe avere un IPC (A PARITA' DI FREQUENZA) del 20-25% in più. Il tizio sembra essere un ex dipendente AMD che ha lavorato al progetto... Il gruppo in guestione è http://groups.google.de/group/comp.a...14f6049?hl=de# e il tipo si chiama Mitch_qualcosa...

Sarebbe quasi fattibile. Ho analizzato un articolo postato dal @Capitano sul 1055T 95W e ho notato nei test di consumo, che il Thuban X6@4,03GHz consumerebbe quasi un 20% in meno di un i7 920 130W a def, e meno del 20% in più, confrontato ad un i870 dato per 95W.
Oltretutto, nonostante un aumento delle prestazioni del 20%, consumerebbe comunque un 20% in meno circa di un i980X, e se facciamo i conti tra consumo e potenza, avrebbe perfino un'efficienza migliore del 32nm HKMG Intel.

Fonte

Sintetizzato

[bjt2]

Originariamente inviato da cionci

La differenza c'è nelle dipendenze dei dati. L'istruzione OP1 è una istruzione AVX che lavora anche sull'indirizzo X (una locazione di memoria generica).
Mettiamo che l'operazione OP2 sia a 128 bit, appartenga allo stesso thread di OP1 e sia successiva, ma necessiti di leggere da X.
Come faccio a schedulare OP1 ? Quale garanzia ho che OP1 venga eseguita dopo la seconda parte di OP2 ?

Se entrambe leggono dalla locazione X, non c'è nessun problema. Se OP1 scrive su X e OP2 legge da X (il caso che sarebbe il più problematico) si schedulano entrambe le microoperazioni della OP1 come scriventi sulla locazione X e l'OP2 stallerà fino a quando ENTRAMBE avranno finito. L'unità di load/store è OOO ma nel caso di una lettura DOPO scrittura, è l'unico caso in cui le operazioni di memoria non possono essere riordinate. Quindi OP2 asperrterà ENTRAMBE le microoperazioni che risultano come se fossero due istruzioni separate che scrivono in X (e seguenti) e che vengono PRIMA di OP2 e che quindi DEVONO essere eseguite prima. Quindi in quel caso non ci sarebbe nessuna esecuzione fuori ordine. Però mentre in SB non potrebbe essere schedulata nessuna altra operazione, in Bulldozer potrebbe essere schedulata nello stesso ciclo della OP2 un'altra istruzione a 128 bit indipendente dello stesso thread o dell'altro thread...