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

[webwalker]

0xR: Pravda, pravdoucí.
Praktické IPC se opravdu pohybuje kolem 1, nicméně programy se dají optimalizovat pro daný cpu i na vyšší hodnoty(nebo nižší). Zvláště pak u Intelu, který vlastní svůj compiler. Mimochodem, už z ICC byly odstraněny sporné "optimalizace" dle cpuid?

[THANATOS]

webwalker u AMD Deneb to bolo 2.8 z 3 ALU.

[THANATOS]

udajne chyby pri jednotlivych BD verziach.
http://translate.google.com/translate?j ... 99971.html

P.S. podla mna BS

[del42sa]

0xR: Pravda, pravdoucí.
Praktické IPC se opravdu pohybuje kolem 1, nicméně programy se dají optimalizovat pro daný cpu i na vyšší hodnoty(nebo nižší)....

myslím že je to trochu jinak , to ideální číslo 1 se týkalo Procesoru SUN T1 a jeho CPI (Cycles per instruction) :









různé instrukce vyžadují různý počet cyklů:

THANATOS:u AMD Deneb to bolo 2.8 z 3 ALU.

to nebylo IPC, ale max. možné praktické využití (utilization) ALU.

[0xR]

myslím že je to trochu jinak , to ideální číslo 1 se týkalo Procesoru SUN T1 a jeho CPI (Cycles per instruction) :

A ja si zase myslim, ze tady michas dohromady jabka s hruskama . Bavime se tady o realnem prumernem IPC pri zpracovavani bezneho x86 kodu a nikoliv a teoreticke propustnosti ruznych CPU v syntetickych testech. To cislo 1 je dano tim kodem a jeho (ne)paralelizovatelnosti a nikoliv poctem nebo propustnosti ALUs. Jinymi slovy - brzda je vetsinou program a CPU s tim nema sanci nic udelat, at ma jednotek kolich chce.

[del42sa]

samozřejmě že IPC samo o sobě není jediná určující veličina, jedna věc je teoretický výkon a jiná reálný výsledek:

http://abinstein.blogspot.com/2010/09/ipc-myths.html

If we compare actual SPECint measurements of Core 2 (22.6) with Nehalem (25.1 or 27., we see that Nehalem has 11% to 23% higher single-thread performance after taking into account potentially 20% turbo frequency. Thus Nehalem's IPC for SPECint is at most ~20% higher than Core 2, and most likely much less when exclude the turbo mode effect. In other words, if Core 2's IPC for SPECint sub-benchmarks were 0.4~1.8, then Nehalem's should be between 0.5~2.1. Both are far below what is implied by their 4-way pipelines or any sexy-sound marketing features

[Jafpu3]

Nejsem na tyhle věci odborník, ale předpokládám, že ty nízké hodnoty praktických IPC jsou průměrné. V určitých fázích programu může na čas vylézt IPC mnohem výše. Pokud se nepletu, tak pravděpodobně končící Itanium 2 má teoretických 6 IPC, stejně jako Power7. Kdyby se k těmto hodnotám programy nemohly svými požadavky ani přiblížit, Intel a IBM by se nenamáhaly tak vysoké IPC do svých architektur implementovat.

V tomhle světle by mě zajímalo, jak moc dnešní x86 architektury brzdí těch pouhých 16 registrů. 4 instrukce za takt, z nichž každá okupuje dejme tomu 3 registry a hned je skoro těch 16 registrů fuč. A to ještě s příchodem AVX vzroste počet operandů ze 2 až na 4. Jak si s tím vůbec ty dnešní x86 CPU dokáží poradit? Dokáže tohle nějak vyžehlit register renaming?

[ttxman]

Jafpu3: oni tyhle serverovy/vypocetni procesory jdou vyuzit tak vysoko, protoze se na to primo pise kod. Kdyz programujes neco co ma bezet na 4 a vic generacich CPU od 2 vyrobcu tak je tezky napsat to HW na miru tak aby to chodilo vsude. To sami optimalizace kompilatoru se daji udelat specificky na CPU efektivneji. Viz kousek zpatky, ze phenomy prumeru vytezovali 1.8 ALU ale specilizovanej kod zatizi 2.8 ALU ze 3.

ad x86:

Problem s tvejma 16 registrama je v tom, ze ty 4 instrukce budou chtit pouzit stejny registry ne nejaky dalsi a jak si prisel na cislo 16? x86 sama o sobe ma pro vypocty 4 (A,B,C,D) a jeste nejsou plne zamenitelny - vysledky prevazne do A, citac cyklu v C... Pak tam jsou 2 registry pro stringovy operace a 2 k obsluze stacku. atd. x87 (stara FPU) ma tusim 8 vlastnich 80bit registru. MMX meli taky 8 registru, ale puvodne byly sdileny s temi z FPU. SSE z nich udelalo 8 128bit samostatnejch. Pak tu mame x86-64, ktere pridalo snad 8 64bit registru snad univerzalnich stylem ABCD.

Je dulezity si uvedomit, ze vnitrne se dnesni x86 CPU chovaj uplne jinak nez to vypada zvenku. Vsechny instrukce se prekladaji do mikroinstrukci a ty se teprve vykonavaji.

Register renaming slouzi k tomu, ze pokud mam 2 (a vic) instrukce pouzivajici stejny registry, ktery mohou probehnout najednou tak se jim "podstrci" jiny sady registru a muzou si pocitat bez toho aby jejich vstupy a vystupy kolidovali, takze to pomuze a bez toho by se nedalo prakticky vubec dosahnout IPC prez 1.

Vnitrne to funguje tak, ze mikroinstrukce proste v sobe jako soucast maji i kam budou ukladat -> takze nactisi si A a B, ale vysledek nevracej do A jak by udelala x86 instrukce, ale zatim ho uloz tamhle odkud ho pouzije dalsi mikroinstrukce. Detaily o tom jak presne to funguje a kolik tech registru je se snad ani nedaj zjistit, vsichni vyrobci x86 si to celkem hlidaj .

Dokonce sem nekde zahlid, ze CPU obsahuji nekolik kompletnich sad registru pro rychlejsi context switching procesu (proste pridelovani casu aplikacim). ukladani a nacitani contextu 1 vlakna tak muze bezet na pozadi zatimco to aktivni porad pracuje, tim se minimalizuje pocet taktu nutnych k prepnuti aktualne vykonavaneho procesu na jiny...

ad Limitace poctem registru. Ja myslim, ze neni prakticky zadna, nebo je miziva v porovnani s nutnosti udrzovat kompatibilitu kodu. Ten se ted kompiluje na "virtualni procesor", kterej neexistuje a nikdy neexistoval a ten kod si kazdy CPU snazi prelozit co nejlip pro sebe a to je misto kde x86 architektura pokulhava.

[0xR]

x86 sama o sobe ma pro vypocty 4 (A,B,C,D) a jeste nejsou plne zamenitelny

Je jich 8 (eax, ebx, ecx, edx, edi, edi, ebp, esp) v 32b modu a 16 v 64b modu a jsou (az na drobne vyjimky) plne zamenitelne. U SSE jich je opet 8 / 16 (32b / 64b).

ad Limitace poctem registru. Ja myslim, ze neni prakticky zadna, nebo je miziva

V 32b modu je dost velka, protoze si vynucuje mnohem vic pametovych operaci a brani pouziti nekterych algoritmu (v pripade rucniho psani asm). Tech 16 v 64b modu je uz docela dostacujicich.

Detaily o tom jak presne to funguje a kolik tech registru je se snad ani nedaj zjistit, vsichni vyrobci x86 si to celkem hlidaj

Preklad na microops je popsan v kazdem optimalizacnim manualu od vyrobce a celkovy pocet registru taky neni zadne tajemstvi. U soucasnych CPU se tusim jejich pocet pohybuje kolem 128. Ale tim si nejsem jisty.

[flanker]

pro zajímavost benchmark "System stability tester"
Zdá se, že tento "superpí" test AMDčkům sedí slušně..
http://systester.sourceforge.net/downloads.html

[ttxman]

Preklad na microops je popsan v kazdem optimalizacnim manualu od vyrobce a celkovy pocet registru taky neni zadne tajemstvi. U soucasnych CPU se tusim jejich pocet pohybuje kolem 128. Ale tim si nejsem jisty.

Hmm sem si rikal, ze sem to nekde videl, ale uz sem to asi 3* nemoh najit tak sem si myslel ze uz to verejne nevydavaj. Apson sem zase moudrejsi a priste budu vedet kde to hledat.


Jinak dik za doplneni, naposledy sem v asembleru delal neco tak pred 6-7 lety a jen tak rekreacne, takze uz zapominam.

[webwalker]

... Jinymi slovy - brzda je vetsinou program a CPU s tim nema sanci nic udelat, at ma jednotek kolich chce.

Pokud pravda, pak příčina nižšího výkonu cpu AMD (nepočítám (ne)výkon FPU) se jeví v optimalizaci kódu pro cpu Intel. Pak by tedy nemělo být žádné překvapení, že se AMD snaží o změny v architektuře BD tak, aby i on těžil z těchto optimalizací. IMHO

Mimochodem, už se něco provalilo detailnějšího o int ALU v BD a pipeline? Zatím pořád slyším, že pipeline je hodně dlouhá, ale nic konkrétního. Přišlo by mi to trochu divné, kdyby BD měl pouze dvě ALU a k tomu ještě dlouhou pipeline, která IPC dále snižuje

[del42sa]

jedině tohle http://support.amd.com/us/Processor_TechDocs/47414.pdf od strany 32.

[webwalker]

del42sa: Díky. Mám za to, že z toho pdf-ka čerpal abinstein:
http://abinstein.blogspot.com/2011/04/f ... dozer.html

[del42sa]

přiznám se že ta fóra o Bulldozeru a jeho IPC jsou plné docela komplikovaných a překombinovaných matematických výpočtů a různých odhadů na základě různých architektur a při jejich procházení se v tom už začínám docela ztrácet Takže zanechám teorie a raději počkám na výsledky a budu držet AMD palce, ať jim to vyjde !!

[flanker]

přiznám se že ta fóra o Bulldozeru a jeho IPC jsou plné docela komplikovaných a překombinovaných matematických výpočtů a různých odhadů na základě různých architektur a při jejich procházení se v tom už začínám docela ztrácet Takže zanechám teorie a raději počkám na výsledky a budu držet AMD palce, ať jim to vyjde !!

já to vzdal hned po prvním řádku , procházel jsme jen textovou část

[THANATOS]

del42sa flanker pridavam sa, zacina ma z toho boliet hlava .

[webwalker]

del42sa, flanker, THANATOS:
Nic nepočítejte, je to hrůza. Škola hrou - doporučuji pro zábavu následující:

http://www.cpuid.com/softwares/perfmonitor.html

Můžete si sami vyzkoušet, jaké IPC dosahuje váš PC při vašich oblíbených činnostech

PS: Monitorovat toho můžete mnohem, mnohem více. Přeji pěknou zábavu.

[del42sa]

a proč bysme to dělali když ti vždycky stejně vyjde 1

[DOC_ZENITH]

Čemu vlastně říkáte IPC? já mám pod pojmem IPC zafixováno kolik instrukcí naráz dokáže pipeline té či té architektury při ideální situaci zpracovat.

Ala 486 - 1 IPC
586 (Pentium 1) - 2 IPC
686 ( Pentum PRO až Core1) - 3 IPC
K8, P4, Core2, K10 - 4 IPC
Nehalem - 5 IPC.
Poslední Itanium, IBM POWER GEN. 7, - 6 IPC.

Tohle. Pokud frekvence či počet jader ovlivňuje IPC tak se bavíme o jinejch IPC než já....