PCTuning fórum

Tak IPC alebo 'singl'?

IPC vážne nestúpa už od 486 alebo Pentia (superskalárneho) a v perfektne sériovom kóde bude mať Skylake nižší výkon (teda skôr hlavne IPC) ako Cortex M0.

Ale priepustnosť jedného vlákna rásť môže. S AVX2 a AVX512 je teda problém, že na tom staršie SIMD neškálujú, ale to je problém implementácie Intelu, pretože to tlačí všetko stále len na 2 porty. Možno keby to dali na viac portov (tak ako POWER9) tak by sa výsledok dostavil.

Napríklad pokiaľ si ZEN+ ponechá súčasnú konštrukciu a namiesto AVX512 a striktného FMA na jednom porte (ala Intel) pridá viac pipeline tak by to mohlo mať lepší dopad na výkon. AVX512 sa rozdelí na viac 128bit vektorov (ktoré sa ale dajú vykonávať zároveň bez nutnosti testovania dátových závislostí ako pri neprepojených inštrukciách) a v SSE/skalárnom kóde to bude eventuálne tiež dosahovať vyšší výkon vďaka tomu že to bude schopné spustiť viac ako 2 inštrukcie naraz.

Power má více protů ale single thread výkon power architektury je mizernej, někde na úrovni Core2. Ono ne vždy více něčeho přinese výkon. Jak už tu padlo, já souhlasim s tim že brzdou je SW, kterej nevyužívá potenciálu novejch arch, novejch instrukcí, neni dostatečně paraelní, atd. Naopak mi přijde že SW je čím dál horší a horší kvality. Se koukněme na novej Dishonored 2 třeba, vim že je to hra, ale hry jsou motorem pokroku, u PC vždy byly, v době kdy PC zažíval nejětší výkonnostní boom, ala cca od 386 do Nehalemu byly tahounem nová pokroková OS a hry. To se oboje zastavilo, přicházej od MS OS které lidi nesnášej + nic dobrého nového nám nepřinášej, naopak tunu humusu a šmírování, a hry jsou místo toho aby byly čím dál lepší čím dál horší a hlavně hůře a hůře optimalizované. Když se kouknu na takovej uncharted 2 nebo The last of us a kouknu na čem to běželo (PS3 ala PowerPC Cell + 256MB XDR RAM + 256GDDR3 Vram + GPU o síle cca Geforce 6800GT) a pak se kounu na to co vychází dnes a jak to až na vyjímky běží chce se mi blejt.

Když vyšel první unreal měl podporu 5ti API, z toho 2 low-level a vše fungovalo dobře a stable, nehledě na to že se spustí na jakejchkoliv windows co uměj spustit win32 executable a to dodnes, tzn i SW dobrá kompatibilita. Bum, přesunem se o 16 let do budoucna a máme tu rozbyté krámy které kolikrát potřebujou měsíe patchů po vydání aby to vůbec ňák chodilo či tam nebyly kritické bugy a stejně to jede mizerně.

Když přišly vícejádra tak to vypadalo tak nadějně, za chvíli to bude 10 let od 4 jádra a dodnnes se to moc nepohnulo, stále nám škáluje dobře jen to co škálovalo vždy, ala rendering, enkóding, šifrování a komprese, jinak prd.

Dodnes sedíme v době defakto Nehalemu protože dodnes je vše optimalizované na jeho pipeline a šmitec. Je to tak do očí bijící že VIA okolo toho třeba i navrhla HW, nové 28nm nano je instrukčně kompatibilní s nehalemem a i se tim pyšnili v materiálech, to proto že to zajistí že dnes kompilovanej SW tam poběží fajn. Jenže to už je zas 8 let stará arch, kde mmáme běžnej SW co využije AVX, FMA, TSX, atd? A to vše s threadovánim do dejme tomu 20+ protože už máme 20 thread consumer CPU. I API, mantle, vulkan, DX12, ty threadujou do 16 jen samotné API, ale neni SW co by to využil protože samotnej SW stojí za prd, nové API použili jen ke snadněnších a ještě zprasenějším protům z konzolí, ne k epickejem enginům s tunou geometrie, postav, drawcalls, atd.

Superpočítače se vyvíjej směrem GPU, protože ty se nám stále rapidně vyvíjej a roste jim výkon. Nvidia tam teď rekordně rejžuje protože oops GP100 je cca 2x rychlejší než nejlepší Xeon PHI, Intel nám trochu zaspal, vlastně se úplně zbláznil s tim jeho přistupem konkurovat SP jednotkám v GPU pomocí tuny slabejch x86 jader a nad to naroubovanejma AVX jednotkama haha. Ten koncept se ukázal jako fail už u prvního larabee a dodnes se to snažej protlačit, přijde mi to jako další netburst story, jen v profi sféře.

Pri POWER som myslel skôr nárast medzi generáciami. A že by bol jednovláknový výkon Core2 príliš nízky... však je len pár percent pod Nehalemom http://images.anandtech.com/doci/8423/I ... ements.png , v ne-SIMD to bolo ešte menej ak si správne spomínam... POWER8 sa mu rovná max v desktopových (teda neoptimalizovaných) benchmarkov, v databázových je myslím niekde inde...

KNL je jasný príklad toho, ako to dopadne s nedostatkom portov. 64 Flops za takt na dvoch portoch... Výsledok: ak tam nieje perfektne optimalizovaný kód (FMA, 2 vlákna na jadro, presný počet inštrukcií v každom vlákne) tak výkon fatálne padá. Na grafikách to má oveľa nižší dopad.

Ne neni, je pár % v historickym SW, v moderních aplikacích optimalizovanejch pro Nehlaem je Core2 naprostej propadák. Jde o to že Nehalem je to poslední pro co se ňák optimalizuje, cokoliv modernějšího defakto jako by neexistovalo. Jedinou vyjíámkou je použití AVX u H265 enkodérů, ale v běžnym SW nic.

A mezigenerační nárůst u Power je velkej protože z mizérie se jednodušeji roste. U Sun Sparcu to bylo ještě větší ale to proto že generace předtim byla jestě in-order eh...

Intelu taky rostlo IPC dříve, jde o to, ala o čem tu byla řeč, že dnes už skoro neroste. U PowerPC architektury se můžeme bavit o tom že je lepší až bude mít IPC jak Intel a poroste dál, momentálě je ale v IPC stále dekádu pozadu. Ta arch má ale jiné přednosti, obrovskou prostupnost, je optimalizovaná na jiné úlohy.

Samotné PowerPC si taky prošlo mnoha vývojovými cikly, třeba taková Power G4 má mnohem vyšší IPC než G5, G5 byla taková netburst-style věc. Neplatí že by se u powerPC IPC vždy zvedal, taky dělaj přešlapy.

Nevím na co by běžný SW měl používat vektory.

Co já vim, já nejsem programátor. Já nevim jak optimalizovat kód pro moderní čipy, ale vim že ti co to maj dělat na to kaděj, někam to natřískaj, proženou to kompilátorem a jsou rádi když to funguje, jako by ti co dělaj solidní SW vymřeli.

Na co narazim v praci posledni dobou je i to, ze programatori nejsou schopni definovat OS a HW pozadavky na jejich zbastlenej SW. Proste si to ubastej na svem PC a pak se divi, ze to na serveru s default instalaci nejede. A jeste ti odpovi, ze jste IT a urcite musite tusit, co jejich zbastelna appka potrebuje pro svuj provoz.

Jak jsem psal, ty vektorove instrukce nejdou pouzit na vsechno, jsou to specializovane ulohy a je malo aplikaci ktere z toho opravdu benefituji. Porad plati ze vetsina programu vyuziva jednoduche integer operace.

Ano a taky to, že u většiny běžných algoritmů používaných na PC (včetně her) je paralelizace na více vláken, kvůli různým časovým závislostem poměrně složitá, nemožná, nebo by nemusela přinést žádný výkonostní benefit. Čestnou výjimkou jsou různé video enkodéry či rendorovací softy.

Nevím, zda to tu bylo/nebylo, ale údajné značení Zen procesorů (pokud to není nějaký čísnký fake)

SRE3, SR5 a SR7

https://www.computerbase.de/2016-11/amd ... 7-sr5-sr3/

DOC_ZENITH píše:Ne neni, je pár % v historickym SW, v moderních aplikacích optimalizovanejch pro Nehlaem je Core2 naprostej propadák.

V moderných aplikáciách využívajúcich nové inštrukčné sady?
http://www.techspot.com/article/1039-te ... page2.html
Neviem, ak zohľadním na takty mi to tak jasne nepripadá. A ak neberiem do úvahy 4C kôli FSB...

DOC_ZENITH píše:A mezigenerační nárůst u Power je velkej protože z mizérie se jednodušeji roste. U Sun Sparcu to bylo ještě větší ale to proto že generace předtim byla jestě in-order eh...

Intelu taky rostlo IPC dříve, jde o to, ala o čem tu byla řeč, že dnes už skoro neroste. U PowerPC architektury se můžeme bavit o tom že je lepší až bude mít IPC jak Intel a poroste dál, momentálě je ale v IPC stále dekádu pozadu.

Tak IPC alebo singl? Mimochodom, v sériovom kóde je out-of-order nanič pokiaľ tam niesú inštrukcie ktoré je možné "prehadzovať", pretože pokiaľ ich je možné prehodiť tak už sa bavíme o vektorovom kóde, pretože tam nieje žiadna závislosť, takže sa tá druhá inštrukcia môže vykonať s prvou vektorovo (alebo povedzme pseudo-vektorovo, ak sa nejedná o rovnakú operáciu).

A o tom čo je vektorizovateľné (a čo aouto-vektorizuje sám kompilátor) sa popísalo veľa, odporúčam google, pre toho koho to zaujíma. Čítal som jeden článok o tom, že dnes je práveže problém nájsť kód, kde by kompilátor nepoužil SSE (bohužiaľ ho nemôžem nájsť). S AVX autovektorizáciou je to bohužiaľ horšie, to je možno dôvod prečo máš dojem že posledný procesor na ktorý sa optimalizuje bol Nehalem.

Pre ukážku tu je pár prikladov čo vektorizuje GCC: https://gcc.gnu.org/projects/tree-ssa/v ... ation.html

A všeobecne, napríklad integrácie alebo polynómy sú dobre vektorizovateľné, a využívajú sa na približné riešenie takmer všetkého. Napríklad goniometrické funkcie taylorovym polynómom. Alebo čiastkové súčty v nekonečných radoch (SuperPi).

A bude sa to používať aj v budúcnosti. Prečo sú asi neurónové siete tak populárne? Pretože to je len blbé násobenie matíc a pritom to dáva rovnaké výsledky ako explicitné algoritmy.

je něco "oficiálnějšího" ohledně značení SR3/SR5/SR7 ? Protože prozatím to je co článěk to jiná úvaha, někde píšou že SR3 bude 4c/8t, SR5 6c/12t, SR7 8c/16t, jinde zas že SR3 bude 6c/6t, SR5 8c/8t a SR7 8c/16t

Dolan:

Hele, zkusi si na stejnym taktu Nehalem a Core2 (pokud Nehalem má HT vypni ho aby to bylo fair) a zkus si třeba něco novějšího zharát, nebo zkonvertovat moderní video, atd. Příčemž nehalem nemá moc co teoreticky navíc oproti 45nm Core2 nabídnout co se týče instrukcí, ale v praxi jí vydrtí protože arch je total překopaná. Rozdíly se začaly v praxi projevovat s časem, při vydání to bylo jen cca 10-20%, protože inteláckej kompilátor (což používaj defakto všichni), časem začal plivat Nehalem friendly kód kterej nebral žádné ohledy na starší arch, zbavili se tim konkurence ale i Core2. Problém ale je, že jej plive dodnes tzn v tomto ohledu moderní čipy nemaj žádnej support.

Naopak Sandy a Ivy moc pokrok nejsou takt na takt protože jediné navíc maj AVX ale jejich AVX je slow (na 2 průchody) tzn defakto useless, použitelné AVX má až haswell ale to se fakt zatim používá jen u h265 enkódingu. Haswell má FMA, fullspeed AVX, AVX2, jeho L1 cache má 2x takovou teoretickou prostupnost, atd. Ale v praxi kde se toto využívá? To samé Skylake, ten boduje jen v hrách díky vylepšenému paměťovému řadiči kterej konečně efektivně využívá prostupnost DDR4, ale arch jako taková a její pokroky leží ladem.

Co se power týče, tak myslim výkon na thread, tak. Co se in ourder out of order architektur týče, tak jsem srovnával ze světa x86 kde in roder arch jsou odpad, a přechod na out of order znamenal velkej boost výkonu, a jakmile se oběví něco in-order, tak i když je to moderní (Atomy třeba), tak je to hrozný. Sun taky měl největší nárůst IPC ve chvíli kdy přešel na out of order.

Jen pro OT fun, ICC se nepouziva majoritne, co jsem videl, tak na Win je to VCC a pro multi-platformu GCC.

Práve že som nedávno mal v rukách nejaké Core 2 a preto nechápem, prečo niektorí pripisujú až zázračné vlastnosti Nehalemom. Samotná architektúra jedného jadra je de-fakto rovnaká (Nehalem má SSE4 a inak organizované porty), a na jednovláknových benchmarkoch v tom teste je myslím vidieť, že ani Haswell nijak extrémne nedrví Core 2 (teda okrem nejakých chuťoviek). Rozdiel je hlavne v LLC a uncore, ktoré sú jasne lepšie ako FSB zlepence.

A nechápem to o slow AVX. Sandy malo 1 MUL a 1 ADD port takže FMA operácia musela ísť na jeden port a potom na druhý ale to je tak trocha irelevantné, keďže priepustnosť bola 1 FMA vektor za takt (teda 16 SP FLops). Zvýšila sa len latencia ale stále bola nižšia ako pri ne-FMA inštrukciách, pretože to nemuselo ísť 2x cez sheduler. Haswell mal 64 Flops ale to bolo kvôli širšej a rýchlejšej FPU, vďaka čomu aj klesla latencia. Ale nevýhoda bola že to mal všetko napchaté na jednom porte, takže ak sa objavila len ADD alebo len MUL inštrukcia, tak musela ísť na FMA port, kdežto IVY si mohol vybrať medzi ADD a MUL portom, pričom na každom z nich to šlo rýchlejšie ako keby to mala byť celá FMA operácia, takže to bolo teoreticky flexibilnejšie. Ale z pohľadu priepustnosti oba riešenia zabezpečili maximálnu priepusnosť FPU (v ideálnych prípadoch).

A čo sa týka Atomov tak tam in-order nebol hlavným problémom, však ani tie out-of-order neboli žiadna sláva. Preto vlastne Intel proti high-end ARMom nasadil prakticky desktopový silikón.

No, minimalne pri x265 encodingu neprinasi AVX na SB prakticky nic (mozna tak do 1% narustu).

dalsie info? Neviem ci to tu bolo...

http://www.guru3d.com/news-story/amd-ze ... -2017.html

Nieje x265 limitovaný integer výkonom? Sandy má myslím ešte stále len 128bit ALU. http://www.extremetech.com/wp-content/u ... dra211.png

CageJ píše:dalsie info? Neviem ci to tu bolo...

http://www.guru3d.com/news-story/amd-ze ... -2017.html

Tak uvedení na CESu je jisté na 99%, ta dostupnost 17.1. je asi zbožné přání. Záleží, jestli do tý doby budou desky. Tipuju, že jediná použitelná deska bude od Asusu a na další si budeme muset počkat.

17.1 vypadá divně, logická by byla dostupnost po čínskym novym roce.