HW novinky: světlé zítřky Broadwellu-E versus temná mračna nad Bulldozerem (diskuse)

[Jendа]

Zrovna drtím floaty na FX-8150, žere ho to něco přes půlku. Dá se v Linuxu nějak udělat, aby se to alokovalo na procesory tak, aby to pokud možno nesdílelo FPU? Je to gnuradio, tedy tisícivláknová aplikace v C++ slepená Swigem.

[pc2005]

No mohl bys množiny procesů seskupit do CPUset v kontrolních skupinách (CONFIG_CGROUPS/CONFIG_CPUSETS, oblíbený systemd ). A každé skupině pak nastavit affinitu procesoru. A samozřejmě zjistit topologii nejdřív.

Ale jestli tam máš tisíc vláken, tak i kdyby jsi polovinu jader vyřadil (třeba úplně vypnul někde v /sys/bus/cpu/devices/cpu0/ po natažení cpuhotplug), tak se ti stejně budou na zbylých mezi sebou přetahovat o zdroje.

[Jendа]

Ale jestli tam máš tisíc vláken, tak i kdyby jsi polovinu jader vyřadil (třeba úplně vypnul někde v /sys/bus/cpu/devices/cpu0/ po natažení cpuhotplug), tak se ti stejně budou na zbylých mezi sebou přetahovat o zdroje.

Mně jde o to, abych vedle tisícivláknového floatového gnuradia, kterému efektivně stačí čtyři jádra (protože ten signál mi tam prostě přitéká realtime, takže ho víc není), mohl provozovat ještě celočíselné aplikace (které bych rád naalokoval na ta zbylá jádra). Ty cgrupy zní jako dobrý nápad.

[Michal Kubeček]

Pokud nemáš hodně staré jádro, tak se defaultně scheduluje tak, aby se přednostně obsazovala jádra v různých modulech. Takže pokud mi na FX-8150 poběží jen čtyři thready, nestane se, že by měly dohromady jen dva nebo tři FPU schedulery. Pokud jich ale poběží tisíc a jen čtyři budou používat FPU, pak to AFAIK scheduler sám nepozná, aby je podle toho přemigroval.

Zajímavé je, že je k tomu využit stejný mechanismus, který se používá kvůli intelímu hyperthreadingu, takže třeba lscpu reportuje údaje, které jsou vůču Bulldozerům hodně nefér:

unicorn:~ # lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    2
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             AuthenticAMD
CPU family:            21
Model:                 1
Model name:            AMD FX(tm)-8150 Eight-Core Processor
...

De facto je to pravý opak toho, kvůli čemu je ta žaloba.

[pc2005]

Prťavoučké ARM jádro Cortex-A35

To bude zajímavý porovnat real life výkon s tím Intel Quarkem. Podle všeho Intel tvrdí, že Quark má menší spotřebu, ale při takových velikostech bude záležet i na pár kB RAM. Chtělo by to tabulku závislosti taktu a spotřeby (předpokládám, že ten ARM půjde taktovat dost dolů).

Bylo by hustý mít v kalkulačce něco co může skutečně spustit třeba Octave (a na rozdíl od výkonného CPU to utáhnou i wonderky).

Pro AMD hovoří to, že historicky je CPU (dnes CPU jádro) chápáno jako jednotka pro integer výpočty

Nechápu proč všechny zpravodajské servery řešej integer výpočty, některý procesory nemusí umět ani násobit, nebo jen omezeně. Důležité je kolik zvládne najednou skoků. Každopádně žalující by mohl být nemile překvapen až zjistí, že moderní procesory obsahují SIMD instrukce, kde se pracuje nad několika integery současně .

BTW RISC architektury můžou v jedné superskalární pipeline počítat třeba se třema integer a dvěma float operacema najednou (integer trvá třeba 2 takty, float třeba 4).

P.S. Doufám, že nikdo nebude žalovat třeba cache plánovač, že děla bubliny (teda spíš halt) v pipeline .

[j]

Zalujici postavi zalobu uplne jednoduse - veme jedno(dvoj)jadrovy CPU a zmeri jeho vykon, 8 jader = rekneme 7-7,5x zvednuti vykonu. Pokud to pro AMD neplati (pro libovolnou ulohu) tak ma AMD problem a to hodne velkej.

A dost pravdepodobne se mu povede dolozit, ze prave pro vypocet ve float ... je to "8mijadro" jen cca 3-3,5x rychlejsi nez jedno jadro.

Ohanet se tim, ze v dobe XTcek a naposled v dobe i386 se to delalo jako extra swab ... lol, stejne tak muzu vytahnout, ze od dob 486 az do prvniho vicejadra byl vzdy soucasti kazdeho CPU i matematickej modul.

[Michal Kubeček]

Zalujici postavi zalobu uplne jednoduse - veme jedno(dvoj)jadrovy CPU a zmeri jeho vykon, 8 jader = rekneme 7-7,5x zvednuti vykonu. Pokud to pro AMD neplati (pro libovolnou ulohu) tak ma AMD problem a to hodne velkej.

A dost pravdepodobne se mu povede dolozit, ze prave pro vypocet ve float ... je to "8mijadro" jen cca 3-3,5x rychlejsi nez jedno jadro.

Tímhle způsobem pomocí vhodně zvolené úlohy "dokážete", že žádný procesor nemá tolik jader, kolik uvádí (kromě jednojádrových, pochopitelně). Takže spíš - jako obvykle - půjde o to, kdo bude mít přesvědčivější právníky a experty.

[pc2005]

A navíc existujou i procesory, co maj <1 IPC.

[Heron]

Multicore není totéž co více samostatných cpu. Jádra v multicore cpu z definice něco sdílí (třeba zrovna socket, že ), obvykle také vyšší levely cache, instrukční dekodéry, paměťové řadiče apod. Důležité tedy není najít test, který vytíží danou jednu sdílenou jednotku a vítězoslavně vyplivne výsledek: 1x, ale test, který dokáže, že ten cpu je schopný paralelizace. Protože to, že je něco sdílené víme, to se nemusí testovat.

Dál, cpu není black box, výrobci cpu uvádějí, jaké je vnitřní uspořádání, aby bylo možné napsat OS a optimalizovat aplikace. To, že zrovna FPU je sdílené se ví. Stejně tak se ví, že jedno jádro umí (a to už od Athlonů) zpracovat víc integer výpočtů současně (na škole v 2002 jsme se bavili tím, jak AMD Athlon správně napsanou smyčkou počítající 4 integer výpočty projde na takt 4x rychleji, než tehdejší P4). Takže co? Je to snad každé jádro čtyřjádro? Ne není.

Pokud chcete skutečnou paralelizaci bez kompromisů (i když...) tak nutně potřebujete x kompletních cpu. I tam potom budete řešit takové srandy jako třeba velmi drahý přesun procesů mezi cpu a koherenci cache. Pro některé úlohy je lepší multicore (protože jádra jsou blízko, na stejné sběrnici, rychlejší už to nebude), pro některé úlohy s oddělenými procesy je lepší více cpu.

Potom je také otázkou cena takového řešení.

Je velmi úsměvné, jak se v některých případech a v některých redakcích dělá z Intel HT "skutečné" 2*Xjádro, zatímco skutečné AMD osmijádro se degraduje na 4 jádro, protože si dovolí sdílet FPU (a ještě to drze přiznává). No tak si to pro ty real výpočty nekupujte. Nebo možná si raději spočítejte, zda nebude stále levnější si ty AMDčka koupit dvě (kdykoliv si k tomu sednu, naposledy letos v létě, tak pořád vychází AMD cca 2x levnější než stejně výkonný Intel s tím, že za ušetřené peníze za CPU lze nakoupit i desku a paměť), získat tak "plný" FPU výkon a jako bonus, dvojnásobný integer (nejen).

[Jendа]

Pokud to pro AMD neplati (pro libovolnou ulohu) tak ma AMD problem a to hodne velkej.

Aby pak tímhle způsobem neplatil i Intel. Ten může viset třeba na sdílené cache nebo na čekání na paměť.

[pc2005]

Navíc protože Amdahlův zákon.

[pc2005]

ze od dob 486 az do prvniho vicejadra byl vzdy soucasti kazdeho CPU i matematickej modul

Nebyl .

Já jsem nikde o externím švábu nepsal. Dokonce jsem ve své úvaze vyhodil i ALU.

[little.owl]

Zalujici postavi zalobu uplne jednoduse - veme jedno(dvoj)jadrovy CPU a zmeri jeho vykon, 8 jader = rekneme 7-7,5x zvednuti vykonu. Pokud to pro AMD neplati (pro libovolnou ulohu) tak ma AMD problem a to hodne velkej.

To je pitomost, scaling neni dan jen poctem vypocetnich jader a sdileni casti subsystemu procesoru je celkem bezne. AMD se zde chova v mezich standardu a architekturu na teto urovni netajilo, at na urovni verejne prezentace ci manualech pro vyvojare.

[Šrotovací stolice]

Pokud to bude škálovat jen na 3-3,5násobek, tak bude chyba v programu, že prostě nesaturuje osm vláken, ne v Bulldozeru. I přes to sdílení FPU dokáže ten modul škálovat oběma jádry tak na 1,8násobek (a víc) jednoho vlákna, když je úloha MT-friendly.

Čili pokud si řekneme, že teoretické ideální osmijádro by mělo škálovat na 8,0x, tak Bulldozer je tomu docela blízko, kór když v praxi škálování není lineární asi nikdy a ten "ideál" bude pro osm jader spíš tak 7,7-7,8x nebo méně.

[Jendа]

Pokud to bude škálovat jen na 3-3,5násobek, tak bude chyba v programu, že prostě nesaturuje osm vláken, ne v Bulldozeru.

Jo, určitě to bude tím, že jsem ve skutečnosti nespustil osm vláken, a ne tím, že ve všech počítám floaty a AVX a tyhle jednotky tam jsou prostě jenom čtyři, nebo že čekám na náhodné přístupy do paměti, nebo že jsem zahltil paměťovou sběrnici, nebo že už se mi ty dvě paralelně běžící FFT nevejdou do sdílené L2 cache, zatímco jedna instance se tam těsně vešla.

[Brad]

ROFL, jestli podobná věta padne u toho soudu tak to AMD projede na plný čáře

[pc2005]

Na pravý n-jádro bys stejně potřeboval n čipů. A pak bys stejně mohl žalovat výrobce desky, že nemůžou používat RAM současně.

[Brad]

Chápu jak to tu někteří myslí, když to trochu zjednoduším tak z pohledu CPU je FPU „ten divnej soused ob dva baráky vedle„, ovšem aby vesnice správně fungovala tak tam toho divnýho matematika prostě potřebujou, půjčovat si ho z vedlejší vesnice je dost naprd.

V dnešní době, kdy se šifruje a jedou multimédia snad na každým kroku (i když osobně si teď nejsem jistej, jestli komprimace jedou floaty) je od AMD nerozvážnost tam ty jednotky nemít, i když to nepochybně nemysleli zle a od začátku deklarovali, že to tak je (ovšem že v aplikacích s mnoha vlákny a výpočty s plovoucí řádovou čárkou bude menší výkon na krabici napsaný neměli). Srovnání s cache není tak úplně na místě, resp. byla by menší ostuda mít málo cache (protože to se dá snadno okecat a navíc není třeba řešit optimalizace kompilátorů). Intelu taky kdysi neprošlo když měl na prvních Pentiích chybu právě v FPU, a taky by principiálně šlo tehdy říct „tak tu jednotku prostě vypnem a u složitějších výpočtů si chvíli počkáte”.

[Heron]

V dnešní době, kdy se šifruje a jedou multimédia snad na každým kroku (i když osobně si teď nejsem jistej, jestli komprimace jedou floaty) je od AMD nerozvážnost tam ty jednotky nemít

Na šifrování je tam spešl HW podpora a šifrování v CPU je mnohem rychlejší, než jak rychle jsou schopné jakékoliv konvenční zdroje dat (síť, disky - možná až na PCI-E SSD) ta data dodávat. Na šifrování navíc FPU není potřeba, to jsou většinou logické operace nad bloky dat, tam se víc hodí SIMD.

Na multimedia existují AVX. Buldozer má dvě 128b jednotky na modul (tedy jednu FMAC na jádro) a umožňuje je spojit do jedné 256b. Tedy čtyřmodulový buldozer má buď 8x128b FMAC nebo 4x256b FMAC (přičemž není nutné spojovat všechny jednotky). (Převod do řeči AVX je komplikovaný, některé instrukce udělají v buldozeru jiné jednotky a FMAC je volná.) Každopádně, když něco komprimuju v handbrake (což je asi stejně jen nastavba nad ffmpeg), tak to jede skoro osmijaderně (asi tak 720%). Což nevím, zda je dáno tím, že něco nestíhá dodávat data do threadů, nebo je to dané architekturou toho programu. Je to celkem jedno, těch 300fps (při konverzi na něco jako 576p (něco jako full non interleaved pal) to umí 300fps). A zvládá to i realtime 1080p záznam během hraní her (stejně málokterá umí víc jak 2 výpočetní threadu).

Pokud někdo potřebuje FPU výpočty, tak je mu k disposici GPU. Tam to spočítá rychleji a levněji, než na kterémkoliv general purpose cpu. Tam třeba AMD směruje s APU (CPU + GPU v jednom socketu).

Intelu taky kdysi neprošlo když měl na prvních Pentiích chybu právě v FPU, a taky by principiálně šlo tehdy říct „tak tu jednotku prostě vypnem a u složitějších výpočtů si chvíli počkáte”.

Tj snad úplně jiné téma, ne? Mít tam vadnou jednotku a mít tam deklarovaný počet funkčních jednotek.

[Heron]

Jinak ještě k potřebě FPU obecně. Chápu, že někdo dělá výpočty (já jsem je taky dělal, ale tehdy ještě na jednojádře ), které se bez toho neobejdou a které ještě nikdo nepřepsal do OpenCL (pro výpočty na gpu). Ale troufnu si říct, že pro běžnou práci to až tak často potřeba není a navíc, když je zaměstnaná FPU, tak ALU může (pokud to dovolí out of order execution) vykonávat další instrukce. Takže kromě speciálních věcí je to stejně jedno.

[Michal Kubeček]

aby vesnice správně fungovala tak tam toho divnýho matematika prostě potřebujou

Ne všechny architektury ho mají. A zdaleka ne pro všechny úlohy ho potřebujete. Např. v jádře se nepoužívá vůbec a spousta userspace aplikací se bez FPU taky pohodlně obejde.

V dnešní době, kdy se šifruje a jedou multimédia snad na každým kroku (i když osobně si teď nejsem jistej, jestli komprimace jedou floaty) je od AMD nerozvážnost tam ty jednotky nemít

Tak třeba pro AES-NI se FPU nepoužívá vůbec (prakticky vyzkoušeno, na FX-8150 to škáluje perfektně až do osmi threadů) a tipoval bych, že výrazná většina šifrovacích algoritmů na tom bude stejně.

Sečteno a podtrženo, snažit se po tomhle vozit je nesmysl. Pokud někdo potřebuje vysoký výkon v aplikacích masivně používajících FPU, tak si takový procesor nekoupí. A pro zbávajících 100-ε procent aplikací vůbec nepoznáte, že jsou tam jen čtyři FPU. Naopak, kdyby jich tam dali osm a místo toho museli slevit někde jinde (třeba cache), byl byste na tom v drtivé většině případů hůř.

[Michal Kubeček]

Ještě jsem zapomněl: taky je potřeba si uvědomit, že i většina z těch aplikací, které FPU využívají, neprovádí pořád jen FPU instrukce, takže ani tam nemusí nutně ke ztrátě výkonu docházet. Problém bude jen s těmi aplikacemi, které provádějí rozsáhlé výpočty (téměř) výhradně v FPU. A to už je hodně specifický use case a kdo takové aplikace ve velkém používá, dá si pozor, aby si pořídil procesor, který na to bude optimalizovaný.

[trekker.dk]

No, ten blb, co žaluje AMD, si asi pozor nedal. (Pokud to teda není soud čistě pro to, aby jim uškodil a/nebo aby z nich vyrazil prachy.)

[Michal Kubeček]

Jde o class action lawsuit, takže jediný, kdo má šanci na tom něco netriviálního vydělat, jsou právníci.

[trekker.dk]

...takže aby uškodil. A nebo - a nevim, jestli by to nebylo ještě horší - je to nějakej dobroser.

[Agent]

Rád bych se zeptal, u Zenu plánují až 40% nátůst výkonu, je to reálné a pokud jo, čím ho dosáhnou, když FPU jednotky nejsou až tak důležité? Zen prý staví na tom, že bude mít zas "plnohodnotné" FPU.

Jinak děkuji fšem za pěknou diskusi. Už asi začínám chápat, proč se AMD vydalo touto cestou. Každopádně podle různých (zejména herních) testů má FX nižší výkon hlavně v single tasku, čím to může být, kromě možná FPU, ještě způsobeno?

[Michal Kubeček]

u Zenu plánují až 40% nátůst výkonu, je to reálné

Uvidíme příští rok.

čím ho dosáhnou, když FPU jednotky nejsou až tak důležité?

Podle materiálů, které byly zatím zveřejněny, se má především zlepšit "instructions per clock" poměr, tj. snížit průměrný počet taktů potřebných k vykonání instrukce. To je zatím jeden z hlavních faktorů, v němž AMD za Intelem zaostává (druhým je tempo přechodu na vyšší hustotu součástek).

Zen prý staví na tom, že bude mít zas "plnohodnotné" FPU.

Nevím, tuhle informaci jsem zatím nezaznamenal a, upřímně řečeno, je mi úplně jedno, jestli je to pravda nebo mne. U aplikací, kde je pro mne výkon nejdůležitější, na FPU nezáleží.

nižší výkon hlavně v single tasku, čím to může být, kromě možná FPU, ještě způsobeno

Především již zmíněná vyšší taktová náročnost instrukcí. Tím při stejné frekvenci stejný kus kódu trvá déle. Možná tam bude i nějaký rozdíl v efektivitě přístupu do paměti, ale to nevím jistě.

Ale ono to celé záleží na tom, jak se porovnání postaví. Pro mne je třeba zajímavé kritérium "jsem ochoten za procesor dát přibližně 5000-6000 Kč, kdo mi nabídne nejvyšší výkon?" A v takovém případě odpověď zní AMD. Nasadím-li cenu dostatečně vysoko, odpovědí bude Intel. A stejně tak u kritéria "chci co nejvyšší výkon, ať to stojí, co to stojí" (tedy aspoň bavíme-li se o x86_64 architektuře) - jenže to je otázka, která zajímá především autory srovnávacích článků v časopisech a na webech, ty, kdo procesory opravdu kupují, většinou ne.

[trekker.dk]

Tohle mě docela fascinuje - jasně, Intel v segmentu "co nejvyšší výkon" jednoznačně vyhrává. Co ale lidi vede k tomu, že vezmou tuhle informaci, řeknou si "Intel je lepší" a pak si koupí midrange nebo lowend, to fakt nechápu.

[Michal Kubeček]

Někdo může spoléhat na to, že se mu vyšší pořizovací cena vrátí na nižší spotřebě. Většinou půjde spíš o iracionální potřebu mít tu lepší značku. Tedy samozřejmě u těch, kdo si procesor vybírají sami, skutečná většina si kupuje celý počítač, takže jde spíš o preference jejich výrobců.

[little.owl]

V dnešní době, kdy se šifruje a jedou multimédia snad na každým kroku (i když osobně si teď nejsem jistej, jestli komprimace jedou floaty) je od AMD nerozvážnost tam ty jednotky nemít,

Vetsina aplikaci jede na intech, vcetne sifrovani. V praxi FPU jednotka neni i u vetsiny aplikaci vytizena a tak jeji sdileni nevadi, a navic bottleneck je vetsinou u pristupu k pameti.

[ByCzech]

Architektura AMD XP procesorů není z dnešní doby, že? Navíc AMD umí počítat 8 vláken FPU ve 128 bit... To je jako se rozčilovat, že starší architektura Intel taky nezvládala rychleji 64 bit extensions rychleji, oproti 32 kódu, ale naopak pomaleji, kdežto konkurence byla v 64 bit režimu výrazně rychlejší.

Porovnávat to s zmetkovým výrobkem - FPU v prvních Pentiích je podle mě mimo.

[Šrotovací stolice]

Jo, určitě to bude tím, že jsem ve skutečnosti nespustil osm vláken, a ne tím, že ve všech počítám floaty a AVX a tyhle jednotky tam jsou prostě jenom čtyři

Z té argumentace vidím, že jsem to asi měl vysvětlit víc po lopatě.

Vidím, že máte představu, že ta sdílená FPU má prostředky akorát tak na to, aby ji vytížilo jedno z těch integerových jader a když by si chtělo líznout i druhé, tak oba dostanou jen polovinu toho, co by mohlo jedno, takže rychlost spadne na 50 %. Ale to je vyslověně cyhbný předpoklad a tak to nefunguje, na což jsem ve svém komentu narážel. Ve skutečnosti je ta FPU pro jedno jádro silně předimenzovaná, ona je skutečně stavěná na dva thready.

Právěže kdybyste si to pořádně ověřil benchmarky, tak byste dostal to škálování, o kteérm jsem mluvil, dejme tomu ze 100 % na jednom vlákně na 180 % na dvou. Platí to i pro úlohy které tu FPU silně vyěžují, například x264, které stráví 60% času v SIMD kódu (jede v té sdílené FPU). Ta jednotka má docela velkou kapacitu, jsou tam čtyři nebo u Steamrolleru tři pipe (eveidentně máte představu, že FPU je nějaká "jedna" jednotka), které jedno vlákno nemá v praxi moc šanci vytížit samo. Prostě v AMD nebyli dle vašeho předpokladu až tak pitomí aby si mysleli, že tam stačí šoupnout jednu FPU jaká by stačila na jedno jádro, ale použili o něco silnější.

Fakt si to na těch CPU zkuste vyzkoušet, než budete říkat s prominutím blbosti jako to ocitované.

[Šrotovací stolice]

Tady výsledky z wPrime 32M na čtyřjádrovém Bulldozeru (respektive Piledriveru, ale architektura je to stejná). Upozorňuju, že jsem nevypnutl turbo, takže při běhu jednoho vlákna to mělo až o cca 10% vyšší takt než při běhu čtyř, takže škálování je ve skutečnosti lepší než moje čísla ukazujou.

1 vlákno: 47,934 s (100 %)

2 vlákna 25,715 s (186,4 %)

3 vlákna 20,382 s (235,2 %)

4 vlákna: 17,154 (279,4 % jednoho vlákna, 150,0 % dvou vláken)

Tak a teď čekám, že svůj pohled obhájíte nějakým testem, kde na čtyřjádru dostanete ze čtyř vláken maximálně 100 % výkonu dvou vláken, což podle vaší představy zřejmě má nastávat :)

Ještě zkusím někde vzít čísla pro nějaké konvenční vícejádro, aby byla představa jak moc to škáluje bez sdílené FPU, ale myslím, že tu asi najdu akorát dvoujádro, bohužel.

[Šrotovací stolice]

Dvoujádro Core 2 Duo pro srovnání:

1 vlákno: 75,831 s (100,0 %)

2 vlákna 40,611 s (186,7 %)

3 vlákna 41,275 s (181,7 %)

4 vlákna: 40,343 (187,0 % jednoho vlákna, 100,7 % dvou vláken)

[Šrotovací stolice]

Jinak tohle dvoujádro turbo nemá, takže tady je to škálování reálné, nepodhodnocené jako u toho BD.

[Jendа]

Příloha:

• bench.tgz (1819 bytů)

Tak jsem si zkusil výpočet doublového FIR filtru z definice (samozřejmě v praxi se to dá řešit pomocí overlap-add) a singlové FFT pomocí FFTW.

Je to FX-8150, Debian s jádrem 3.16 a ověřil jsem si, že když spustím 4 vlákna, přidělí je to „správně“ tak, jak píše Michal.

FFTW škáluje až do 4 vláken dobře, v 8 vláknech má jen 530 % výkonu jednoho jádra.

Ten FIR je ale hustej, tipoval bych to na nějaké strašlivé cache problémy.

FIR dlouhý 8192 nad signálem 262144 (bench1.txt): 1 vlákno: 15 s, 2: 16 s, 4: 23 s, 8: 130 s.

Signál 131072 (bench2.txt): 4.5, 5, 5, 17 s

Signál 65536 (bench3.txt): 1.4, 1.4, 1.4, 2.6 s

V tom posledním je podle mě už vidět, že se to do cache vejde a perou se právo o tu FPU.

[Šrotovací stolice]

Nemusela to být jenom cache, ale třeba i výkon paměťového řadiče. Ten není tak efektivní jako u Intelu.

Hlavně chtělo by to chtělo srovnat s něčím co má osm samostatných jader (takže dneska asi jenom Xeon s vypnutým HT, na PS4 si to člověk bohužel asi nespustí...), protože ani tam to určitě škálování na 800 % nebude. A otázka teď je, jestli ta úloha na tom "pravém" osmijádru dává třeba 750 % nebo jenom 600 %, ergo jestli je jestli je těch 530 % u 8150 málo nebo ještě docela dost.

Jinak bylo to s turbem aktivním, nebo na fixním taktu?

[pc2005]

UnixBench, LMBench jsou opensource.

[little.owl]

Pro test FPU by to chtelo kod v assembleru, s minimem transferem dat. Cele je to postavene na tvrzeni, ze pokud by se pouzily dve FPU, bylo by to rychlejsi, jenze to neni v principu pravda, skutecne zalezi na tom, jak by takove FPU vypadaly a jak by byly integrovane. U Bulldozeru se nektere floating point operace provadi v integer unit, treba shuffle ci blend, tim se to jeste komplikuje.

[Michal Kubeček]

To mi trochu připomíná mou první zkušenost s FPU ještě v době, kdy to byl samostatný koprocesor (387). Když jsem si ho pořídil, chtěl jsem ho hned vyzkoušet, tak jsem narychlo v Turbo Pascalu napsal vizualizaci Juliovy množiny tím nejtupějším způsobem a v double precision. Přeložil jsem to bez využití koprocesoru a s ním; s využitím koprocesoru byl sice program rychlejší, ale jen asi třikrát, což mi přišlo málo. Tak jsem se podíval disassemblerem a nevěřil jsem svým očím. Překladač vyrobil kód, kde např. vynásobení tří čísel probíhalo asi takto:

• ulož A do FPU
• ulož B do FPU
• vynásob
• přečti výsledek z FPU
• ulož mezivýsledek (zpátky) do FPU
• ulož C do FPU
• vynásob
• přečti výsledek z FPU

Tak jsem vnitřní smyčku přepsal do assembleru s tím, že se celý výraz vždy počítal v FPU a zpátky se četl až výsledek. Finální verze byla oproti původnímu programu (bez FPU) rychlejší asi stokrát.

Dnešní překladače jsou samozřejmě mnohem chytřejší, ale i tak je potřeba mít na paměti, že ani složitý výpočet ve float/double nemusí zdaleka celý probíhat v FPU. Ono i u "normálních" instrukcí se běžně stává, že se nějaká komplexní instrukce nepoužije, protože v konkrétním případě (nebo dokonce obecně) je rychlejší ji rozepsat do jednodušších.

[little.owl]

kdy to byl samostatný koprocesor (387).

Podobna zkusenost s 80287 a pocitanim fraktalu v assembleru .

Dnešní překladače jsou samozřejmě mnohem chytřejší, ale i tak je potřeba mít na paměti, že ani složitý výpočet ve float/double nemusí zdaleka celý probíhat v FPU.

Stale se nam u numerickych algoritmu vyplaci pouziti SIMD (NEON/AVX/SSEx) a compiler intrinsics.

[ByCzech]

Přesně tak. To co AMD brzdí občas k lepšímu škálování je sdílený dekodér instrukcí, který nestíhá zásobovat naopak velmi výkonná INT i FPU jádra. V ZEN by to mělo být vylepšeno. Každopádně kód optimalizovaný pro tuto HW výbavu vám to škálování blížící se násobku počtu jader zajistí. Stejně jako u konkurence. Protože je možné udělat v obou případech kód, na kterém se to bude uzlovat. Proto mají kompilátory optimalizace, že ;)

[fe]

>Ostatně podobným způsobem by se daly kritizovat procesory i jiných výrobců

Například obskurní UltraSparc T1 – ale společnost Sun tehdy nikdo nežaloval:
"The T1 only offered a single Floating Point unit to be shared by the 8 cores."

[Blaazen]

Možná to bylo naopak. Manažeři přišli za inženýrma a řekli jim: "Udělejte to tak, abysme mohli říkat, že je to osmijádro." "Tak tam dáme osm integer jedotek, ostatního stačí míň."

[Brad]

A když se to doslechli v Intelu tak nejdřív smíchem zbořili půl bafriky a pak rozdali mimořádný dovolený

[Michal Kubeček]

Spíš bych se vůbec nedivil, kdyby Intel s podobnou architekturou časem přišel taky. Koneckonců o řadiči paměti v procesoru nebo o Hypertransportu se taky hardcore Intel fans nejdřív vyjadřovali pohdavě, jaká je to blbost, dokud to Intel nezačal používat také.

[Brad]

Je to dost dobře možné, vzájemné dohody jim to umožňují... AMD je oproti Intelu poměrně malá firma a přesto v minulosti ukázali, že umí být proklatě inovativní, Intel od nich následně převzal už ledasco.

Na vysvětlenou jako shrnutí (vidouc, že jsem některé svými příspěvky dost zaujal) - z tohoto logicky plyne to, co možná v mých předchozích příspěvcích neplynulo dostatečně zřejmě, a sice že proti AMD celkem nic nemám a v rámci zachování tržní rovnováhy jim i tak nějak fandím. Bohužel a k jejich škodě, jak jsme viděli už na mnoha případech (a nejen u nich), hospodářské výsledky nedělá jen produkt samotný, ale začíná i končí to v marketingovém oddělení, a tam je v současnosti asi největší slabina AMD.

Zase na druhou stranu, Intel nenechá AMD padnout, protože pak by se stal monopolním dodavatelem na trhu a musel by se z moci úřední nějak rozdělit, a to se mu počítám taky nechce. Technologicky má náskok už značný, navíc na začátku roku koupil Alteru, jsem zvědav co z toho nakonec vyleze (tedy pokud se to někdy dozvíme - svého času nakoupil i patenty od Transmety a od té doby jsme o té firmě taky už nic neslyšeli).

[ByCzech]

Osobně si myslím, že u Intelu to právě není tím lepším marketingem, ale nekalokonkurenčními taktikami. Neprofláklo se jich málo.

BTW. co říkáte na toto, narazil jsem na to včera:

http://www.technologyx.com/featured/amd-vs-intel-our-8-core-cpu-gaming-performance-showdown/4/