Procesory AMD 15h "Bulldozer&Bobcat"- info, testy, spekulace

[del42sa]

vlastně nevím co by bránilo tomu, aby při určitém počtu výpočetních jednotek nějaká vnitřní logika procesoru určovalo, kolik se jich pro zpracování určitého úkolu použije... Flex FPU se už takto chová, proč by se tak nemohly chovat ALU ?

Dokud neexistoval modul, tak to byly dost divoké spekulace. Jak by se z dvou zcela oddělených jader mohlo udělat "virtuálně" jedno jediné silné ?? těžko...

U modulu už to ale tak těžko představitelné není... Možná že next big step není jen FLEX FPU, ale FLEX celý modul nebo FLEX ALUs.

\\Existoval by jen blíže neurčený počet výpočetních jednotek (8) a ta vnitřní logika by z nich mohla udělat buď jedno supersilné jádro, nebo dvě silné jádra/2 threads a nebo třeba 4 slabší jádra/ale čtyři threads na modul.Podle situace by jim přidělovala sdílené cache a FPU jednotky. Vše na bázi ring busu.

[ArgCZ]

vůbec bych se nedivil kdyby s něčím takovým přišel Intel a AMD zas utře

[flanker]

webwalker:Podobně mohu argumentovat tím, že BD je vyvíjen už 5 let a následující BD bude architekturou také jiný (už dnes se spekuluje o změně v modulu - 4 jádra v modulu a předělaná FPU i frontend), ale původcem nosné myšlenky změny byl prostě současný BD

4 jádra v modulu, to už musí být slušnej bottleneck. Mě by se spíše více líbila myšlenka, že za určitých okolností by se modul mohl chovat jako jediné jádro a tím nemyslím že se jedno jádro vypne, ale spojení výpočetních jednotek každého jádra do jediného celku. Takže namísto 2x2 (ALU/AGU) by to mohlo být 1x4(ALU/AGU).Vzrostlo by IPC a k tomu by mohli přidat dvě 256bit FPU jednotky(místo 128bit). http://del42sa.rajce.idnes.cz/Bulldozer ... e_core.jpg

ostatně původní návrh od AMD naznačuje, že skutečně počet ALU/AGU mohl být pro každé jádro dvojnásobný oproti současnému návrhu 2x2 (dvě ALU a dvě AGU pro jádro)





Vlastně to připomíní něčím tu formu obráceného hyperthreadingu, o které se kdysi spekulovalo kolem roku 2006 i když tohle by nebyl hyperthreading ale spíše jakási "SLI"- ALU/AGU dvou jader http://www.bit-tech.net/news/hardware/2 ... hreading/1

toto mě také napadalo

yuri, hoď odkaz, vypadá to dle specifikace na jeden nejmenovaný model ,-)

[webwalker]

ArgCZ: to už tady také bylo
http://techreport.com/discussions.x/10247

[THANATOS]

ArgCZ Preco by s tym prisiel skor Intel? Ten este stale frci na HT a modul tak skoro nebudu mat a urcite by bolo tazsie spojit 2 jadra ako 2 integer klustre, ked maju vsetko ostatne v module zdielane.

flanker takze zacneme spekulovat nad konspiracnymi teoriami, ze AMD ma v rukach nejake eso Musim dodat, ze prvy slajd som videl prvykrat ale druhy som uz niekde videl len neviem ci s takym mnozstvom ALU/AGU .

[ArgCZ]

webwalker: zajímavý link

THANATOS: proč by nemohl, APU měl taky první když se s tím AMD crcmalo 6 let nebo kolik (aspoň myslím že SB tu bylo před Ontario/Zacate, ale můžu se mýlit) a navíc Intel si dovede ty dobré myšlenky od AMD "vypůjčit" a zapracovat k sobě vcelku rychle, abys pak po ivy nekoukal na dokonalý Dozer od intelu

[del42sa]

[THANATOS]

ArgCZ Kolko trvalo Intelu kym integroval pamatovy radic do cpu a ktore APU bolo skor ti fakt nepoviem, ale myslim, ze INTEL ich predbehol v uvedeni.
Ked uz ma byt ich cpu na baze modulu tak to fakt nebude skor ako v roku 2013 a vtedy tu uz modul od AMD bude nejaku dobu a budu mat s nim viac skusenosti ako Intel, ale mozno budes mat pravdu a AMD bude mat s tym problemy a Intel ich predbehne, ale najpravdepodobnejsie sa javi to, ze nic take nebude ani od Intelu ani od AMD.

[yuri.cs]

ad AMD&[H]: Fotky BD nejsou, jen dojmy a postrehy ucastniku. Zminka o frekvenci a dalsi info z akce: http://hardforum.com/showpost.php?p=103 ... tcount=364.

ad
...x86 CMT navrh se pry hodi pro 2 nebo 4 ALUs. Tohle jsou ovsem slidy vyrobene planet3Dnow ve spolupraci s DB na 1.4.2010 - April.

ad "vypujcovani" technologii: Intel a AMD maji uzavreno plno smluv o vymene patentu a know-how. Urcite by bylo zajimave vedet ceho se presne tykaji. Stejne doba zapracovani zmen v navrhu bude zavratna. Napr. DK nekdy vypocitaval, ze AMD pravdepodobne znalo realny vykon Nehalemu, ale hned za par mesicu nasledoval freeze BD.

ad SpMT: Spekulativni multithreading byl dle vseho zkouman v Intelu i AMD. Zatim nebyl predveden v C2D, Nehlaemu, SB, IB a zrejme ani Haswellu a BD. To, ze pozenete thread po 2 jadrech se projevi ve spotrebe, ale zrejme potencionalni zrychleni to nevyvazi.

ad prvni x86 APU: Docela prekvapive to pry (dle diskuze tady na pct) bylo http://en.wikipedia.org/wiki/MediaGX z roku 1997

[THANATOS]

yuri.cs tak s tym APU si ma dostal, ked to predstavili ja som bol este na zakladke.

To, ze pozenete thread po 2 jadrech se projevi ve spotrebe, ale zrejme potencionalni zrychleni to nevyvazi.

a preto by to mohli uviest s BD, lebo vacsinu jadra ma zdielanu, takze by tam spotreba nemala narast viac ako vykon, a v dnesnej dobe dokazu cpu vypnut nevyuzite jadra, tak by to hadam nemal byt taky problem.

[del42sa]

...x86 CMT navrh se pry hodi pro 2 nebo 4 ALUs. Tohle jsou ovsem slidy vyrobene planet3Dnow ve spolupraci s DB na 1.4.2010 - April.

to se ale moc nesekli od reality

[yuri.cs]

to se ale moc nesekli od reality

Ono toho bylo znameho hodne. Hlavni neznama byl pocet ALUs, coz je diky AGLUs tak trochu nejasne doted.
Btw zamer se taky na pritomnost L0/trace cache a L4. V tom clanku taky myslim byla frekvence 5.8GHz, vykon nad Intelem, atd. Nakonec to asi museli stahnout.

[del42sa]

jo trace cache to je jak u Nehalemu No s těma 4 ALU/AGU mě to zaujalo, proto jsem tu předtím psal o těch čtyřech ALU na jádro a tím pádem větším IPC. http://pctforum.tyden.cz/viewtopic.php? ... 0#p8185470

[0xR]

Panove, kdy uz konecne pochopite, ze "reverse hyperthreading", nebo cokoliv tomu podobneho je naprosty nesmysl a zbozne prani lidi, co tomu nerozumi. Kdyby to bylo mozne, tak tu ted nemame vicejadra, ale vysoce vykonne jednojadra a programatori by nemuseli pracne vyvijet neefektivni multithreadove aplikace.

U standarniho kodu (napr. x86) neni vykon urcen poctem pouzitych ALUs, ale spis efektivitou OoO enginu. I proto slo AMD cestou snizeni poctu ALUs v jadru z 3 na 2. Problem je totiz ten, ze prumerne vytizeni je nekde kolem 1 (vic to proste paralelizovat z principu nejde). Takze i kdybyste jich meli treba 8, tak vyssiho vykonu nedosahnete - spis naopak, drasticky stoupne slozitost OoO engine a tim spotrebovana energie, nizsi takty atp. A propojit 2 jadra v ramci modulu, tak aby to fungovalo (a na stejnych frekvencich), je uz uplny nemysl. I kdyby to bylo mozne, tak urcite ne bez ohromneho mnozstvi dalsi logiky (v podstate dalsi a mnohem slozitejsi OoO engine) a snizeni taktu (fyzikalni limity na vzdalenost). Jednodussi by uz bylo udelat jedno velke jadro, ale to je presne to, co AMD nechce .

[THANATOS]

0xR

Panove, kdy uz konecne pochopite, ze "reverse hyperthreading", nebo cokoliv tomu podobneho je naprosty nesmysl a zbozne prani lidi, co tomu nerozumi. Kdyby to bylo mozne, tak tu ted nemame vicejadra, ale vysoce vykonne jednojadra a programatori by nemuseli pracne vyvijet neefektivni multithreadove aplikace.

Nema byt reverse hyperthreading spracovanie jedneho threadu dvoma jadrami? V tom ti jedno jadro stacit nebude .

[del42sa]

Panove, kdy uz konecne pochopite, ze "reverse hyperthreading", nebo cokoliv tomu podobneho je naprosty nesmysl a zbozne prani lidi, co tomu nerozumi. Kdyby to bylo mozne, tak tu ted nemame vicejadra, ale vysoce vykonne jednojadra a programatori by nemuseli pracne vyvijet neefektivni multithreadove aplikace.

U standarniho kodu (napr. x86) neni vykon urcen poctem pouzitych ALUs, ale spis efektivitou OoO enginu. I proto slo AMD cestou snizeni poctu ALUs v jadru z 3 na 2. Problem je totiz ten, ze prumerne vytizeni je nekde kolem 1 (vic to proste paralelizovat z principu nejde). Takze i kdybyste jich meli treba 8, tak vyssiho vykonu nedosahnete - spis naopak, drasticky stoupne slozitost OoO engine a tim spotrebovana energie, nizsi takty atp. A propojit 2 jadra v ramci modulu, tak aby to fungovalo (a na stejnych frekvencich), je uz uplny nemysl. I kdyby to bylo mozne, tak urcite ne bez ohromneho mnozstvi dalsi logiky (v podstate dalsi a mnohem slozitejsi OoO engine) a snizeni taktu (fyzikalni limity na vzdalenost). Jednodussi by uz bylo udelat jedno velke jadro, ale to je presne to, co AMD nechce .

heh snad nechceš říct, že výkon na jádro se nezvětšuje ? To by musela být 486 stejně silná v single threadu jako Sandy Bridge Výkon zvyšovat jde, ale souhlasím, že jednodušší je přidávat jádra než zvedat IPC a efektivitu

[Vivec]

heh snad nechceš říct, že výkon na jádro se nezvětšuje ? To by musela být 486 stejně silná v single threadu jako Sandy Bridge Výkon zvyšovat jde, ale souhlasím, že jednodušší je přidávat jádra než zvedat IPC a efektivitu

přetoč 486 na 3Ghz, dej jí cache, široký sběrnice a modení instrukce a možná budeš překvapenej

[del42sa]

řekni to Intelu, že několik let vyhazoval peníze zbytečně

[0xR]

A zabudas na fakt, ze modul ma skoro vsetko zdielane, takze aj keby potrebovali rozsirit engine, tak to nebude take narocne.

No, ten nesdileny OoO engine je prave to nejdulezitejsi a cele se to toci jen kolem toho. Napr. ALU je v podstate z pohledu velikosti a slozitosti CPU skoro zanedbatelna polozka . Kdyby to byl bottleneck, tak jich tam placnou treba 100 (viz GPU). Ale k cemu, kdyz by se jich tak 98 flakalo. A v tom spocia i vysvetleni, proc je nesmysl chtit zpracovavat 1 thread na vice jadrech. A i kdyby to nejakym zazrakem slo, tak by (u standardniho kodu) k zadnemu vetsimu zrychleni nemohlo dojit a naopak by se hodne zvysily latence a tim padem by nastalo zpomaleni.

[0xR]

heh snad nechceš říct, že výkon na jádro se nezvětšuje ? To by musela být 486 stejně silná v single threadu jako Sandy Bridge Výkon zvyšovat jde, ale souhlasím, že jednodušší je přidávat jádra než zvedat IPC a efektivitu

486 nemela OoO a vektorove instrukce (napr. SSE). Soucasna CPU jsou ale co se tyce extrakce IPC z jednoho x86 threadu blizko teoretickeho limitu. Proto se preslo na vicejadra. Samozrejme lze dale pridavat nove instrukce (AVX, FMA, XOP), rozsirovat registry (32b -> 64b, 128 SSE -> 256b AVX) a zvysovat pametovou propustnost (cache, sbernice, atd.).