PCTuning fórum

Richie Rich píše:Navíc si vemte, že ARMy umí počítat vektorory o šířce 2048 bit díky SVE2 instrukcím. Zatímco uživatelé Intelu hýkají blahem nad AVX512 tak ARM umí 4x delší vektory.

Na zbytek se mi reagovat nechce, ale k tomuhle. Nic s implementovaným SVE ještě neexistuje. Zatím jedinej ohlášenej čip je speciálka od Fujitsu pro jejich superpočítače. A IIRC je navrženej pro šířku 512 bitů, hehe.

BTW laikovi ta flexibilní šířka SIMD vektrou u SVE možná může připadat jako super nápad, ale IMHO by v praxi mohla být problematická. Podle mě je to něco dělané jen s ohledem na autovektorizující kompilátory a HPC, ale třeba v multimediálním kódu a v případě ručně psaného asembléru by to mohlo být na prd a spíš vadit.

Pardon, omylem jsem dal citdovat/odpovědět místo edit, a ani jsem si to nevšim.

Richi s těma cache jsem to myslel tak, že víme že velká síledná cache strmě zvedá herní výkon, ale až od určité velikosti, prostě dokud se do ní danná operace nevejde je její efekt malej. Ala je jedno jestli mam 4MB nebo 16MB když můj výpočet potřebuje 40MB paměti. To samá platí o latenci do RAM. Tohle jso uale jen easy změřitelné příklady dementující tvou terii že v této oblasti je "všechno v pohodě a vyřešené", ne naopak, neni.

Zdaleka vše není vyřešeno. Zkus si trochu zapojit fantasii a představit že by třehba samotná ALU měla v sobě malou cache, ještě rychlejší a blišší jak L1, nebo naopak co kdyby každej CPU měl k dispozici X GB prostoru HBM cache místo jen RAM a pod. Spousta věcí je bottlenckovaná pamětí. Studie říkaj že CPU dnes strávěj nejvíce času a spálej nejvíce energie tim že se data přesouvaj či získávaj a ne samotnym výpočtem. Problém je že i SW vývoj se naučil žít s tim že tak to prostě je a novej se tak píše.

Padaly tady taky velký fantasmagorie o šířkách registrů a vektorech a pod. Zde je problém v tom že pokulhává praxe. V praxi jsme tu neměli žádnou velkou revoluci přes dekádu a nic v dohlednu nevidim. Ani slavnej Ryzen tím neni. Ryzen se dotáhl tam kde má bejt, je to revoluce uvnitř AMD pro AMD, ne pro svět CPU jako takovej. Dále "širší" neni vždy lepší ale to už tu taky padlo. Ve sposutě případů prostě potřebuji mít ňákej primitivní výpočet hotovej co nejdříve a tam mi fakt nepomůže že můj CPU dovede zěžvejkat v jednom cyklu 2048-bit vektor, protože kdybych to měl poslat tam dostanu to zpět pěkně latentně a pomalu.

Je velkej rozdíl mezi svižnym systémem a tim co má velkej throughput, to by jsme pak mohli označit za skvělé CPU jako POWER či SPARC jenže oni jsou dobré jen v něčem, rozhodně ne obecně.

Já vidim budoucnost v heterogenim computingu. Ano budem potřebobat to i to a i ty akcelerátory s fixní funkcí. A OS co to dovede vše optimálně pioužívat. Nevidim jako relistickou budoucost super CPU kterej bude ve všech ohledech lepší jak to co máme + bude mít super široké registry, hordy ALU + FPU a ňákym zázrakem toto celé poběží na OK frekvenci a budeme mít jader na rozdávání. Tohle je čistá utopie a ňáké fantasmagorie Kellera z 90.tých let nikomu nepomohou.

Problém s OS plánovačmi je v tom, že výber vhodného vlákna stojí výpočtový výkon. Už tu bol x86 procesor s MT4 (nie SMT4), Xeon Phi KNL. Tam mali 3 a 4 vlákna na jadro negatívny vplyv na výkon pretože CPU strávil viac času arbitrážou. ZEN jadro je oveľa výkonnejšie ale stále x86...

Dedikované akcelerátory sú teoreticky ideálne riešenie (najviac výkonu pri najmenšej ploche kremíka, najmenšej spotrebe...). SPARC má data analytics akcelerátory s priamym prístupom do cache a vďaka tomu je na jadro >2x rýchlejší ako Xeony. Ale aj tak si väčšina ľudí myslí, že sú to procesory naprd pretože tu bude vždy otázka, akej úlohy sa má ten akcelerátor týkať.

No a potom su tú tie veci, že efektívne fungujú až od určitej veľkosti bloku dát, vyššia latencia...

"Konečně někdo, kdo tomu rozumí"

Jan Olšan píše:

Richie Rich píše:Navíc si vemte, že ARMy umí počítat vektorory o šířce 2048 bit díky SVE2 instrukcím. Zatímco uživatelé Intelu hýkají blahem nad AVX512 tak ARM umí 4x delší vektory.

Na zbytek se mi reagovat nechce, ale k tomuhle. Nic s implementovaným SVE ještě neexistuje. Zatím jedinej ohlášenej čip je speciálka od Fujitsu pro jejich superpočítače. A IIRC je navrženej pro šířku 512 bitů, hehe.

BTW laikovi ta flexibilní šířka SIMD vektrou u SVE možná může připadat jako super nápad, ale IMHO by v praxi mohla být problematická. Podle mě je to něco dělané jen s ohledem na autovektorizující kompilátory a HPC, ale třeba v multimediálním kódu a v případě ručně psaného asembléru by to mohlo být na prd a spíš vadit.

SVE je novinka a vypovídá to o tom, že ARM vymyslel rozšíření instrukční sady na 20 let dopředu. Odborníci ve světě to považují za zásadní věc, která umožní mimo jiné i slabým čipům s 64--bit FPU zpracovat 2048-bit vektory, HW si to vyřeší 1000x rychleji než SW. Stejně jako BD uměl zpracovat AVX na dvakrát, to bylo taky naprd, lepší kdyby neuměl AVX vůbec, že? Obrovská výhoda je, že existuje pouze jeden kód a HW si to sám zpracuje dle jeho schopností. Ve světě x86 máš SSE, SSE2, SSE3, SSSE3, SSE4, SSE4.1, SSE4.2, AVX, AVX2, AVX512 a jako bonus má IceLake rozšířenou verzi AVX512 s instrukcemi navíc, takže AVX512.2. To všechno musí program detekovat kterou sadu CPU zvládá a program použije příslušnou část kódu. Výsledkem je kód zbytečně větší o růzvné verze, CPU načítá instrukce které se nikdy nepoužijí, cache je zaplácnutá, zabírá to víc místa na disku, déle se to kompiluje a jako bonus to poběží pomaleji protože kompiler vkládá hromadu větvení programu. A tak se zpětná kompatibilita omezuje a tedy x86 kód na stále výkonném starším CPU nejede, nikoliv protože dosahuje 80% výkonu nového CPU, ale protože neumí novou instrukční sadu. Však si kup novej ne? To je ta slavná kompatibilita x86 ala Intel.

Pokud si mám vybrat jestli budu věřit zahraničním odborníkům a špičkovým HW inženýrům ARMu.... nebo Janu Olšanovi, který umí akorát zahraniční články prohnat google translatorem ..... logicky budu věřit inženýrům z ARMu.


Zen3 jakožto 19h Family by mohl klidně přinést novou instrukční sadu. Kdyby to byla obdoba SVE2 která umí měnit šířku vektorů od 128-bit až do těch 2048-bit, tak to by byla bomba. Ručně optimalizovaný kód by se nemusel každé 4 roky předělávat a vydržel by třeba 15-20 let. To by ulehčilo práci SW vývojářům a na to zákazníci slyší.

DOC_ZENITH píše:Richi s těma cache jsem to myslel tak, že víme že velká síledná cache strmě zvedá herní výkon, ale až od určité velikosti, prostě dokud se do ní danná operace nevejde je její efekt malej. Ala je jedno jestli mam 4MB nebo 16MB když můj výpočet potřebuje 40MB paměti. To samá platí o latenci do RAM. Tohle jso uale jen easy změřitelné příklady dementující tvou terii že v této oblasti je "všechno v pohodě a vyřešené", ne naopak, neni.

Zdaleka vše není vyřešeno. Zkus si trochu zapojit fantasii a představit že by třehba samotná ALU měla v sobě malou cache, ještě rychlejší a blišší jak L1, nebo naopak co kdyby každej CPU měl k dispozici X GB prostoru HBM cache místo jen RAM a pod. Spousta věcí je bottlenckovaná pamětí. Studie říkaj že CPU dnes strávěj nejvíce času a spálej nejvíce energie tim že se data přesouvaj či získávaj a ne samotnym výpočtem. Problém je že i SW vývoj se naučil žít s tim že tak to prostě je a novej se tak píše.

Padaly tady taky velký fantasmagorie o šířkách registrů a vektorech a pod. Zde je problém v tom že pokulhává praxe. V praxi jsme tu neměli žádnou velkou revoluci přes dekádu a nic v dohlednu nevidim. Ani slavnej Ryzen tím neni. Ryzen se dotáhl tam kde má bejt, je to revoluce uvnitř AMD pro AMD, ne pro svět CPU jako takovej. Dále "širší" neni vždy lepší ale to už tu taky padlo. Ve sposutě případů prostě potřebuji mít ňákej primitivní výpočet hotovej co nejdříve a tam mi fakt nepomůže že můj CPU dovede zěžvejkat v jednom cyklu 2048-bit vektor, protože kdybych to měl poslat tam dostanu to zpět pěkně latentně a pomalu.

Je velkej rozdíl mezi svižnym systémem a tim co má velkej throughput, to by jsme pak mohli označit za skvělé CPU jako POWER či SPARC jenže oni jsou dobré jen v něčem, rozhodně ne obecně.

Já vidim budoucnost v heterogenim computingu. Ano budem potřebobat to i to a i ty akcelerátory s fixní funkcí. A OS co to dovede vše optimálně pioužívat. Nevidim jako relistickou budoucost super CPU kterej bude ve všech ohledech lepší jak to co máme + bude mít super široké registry, hordy ALU + FPU a ňákym zázrakem toto celé poběží na OK frekvenci a budeme mít jader na rozdávání. Tohle je čistá utopie a ňáké fantasmagorie Kellera z 90.tých let nikomu nepomohou.

DOCu, kdyby byla problém latence, tak by nikdy AMD nešlo do chipletového designu, který latence zhoršuje. Kdyby byl problém v propustnosti tak přešli na GDDR6. Pravda je že dnešní DDR4 jsou dobrý kompromis a nejsou hlavní brzdou výkonu. Jaký je rozdíl krmit 12-ti jádro 3900X nebo fiktivní 6-ti jádro Ryzen 4600X Zen3, které má řekněme 2x větší IPC? Žádný, obě potřebují stejnou propustnost instrukcí i dat, obě mají stejný výkon.

V CPU je kromě cache hromada jiných bufferů, vem si třeba re-order buffer OoO, celkově jak zmínil Keller má Sunny Cove okno pro 800 instrukcí. Chápu že když máš serverový CPU a hlavní výpočetní smyčka se ti vleze do L3 cache, tak to dost pomůže. Ale kolik je to v číslech? Je to 10x rychlejší? Není a nemůže. Ty 4 ALU prostě 40 instrukcí za takt nezpracují ani kdyby se rozkrájely.

v novembri by mala vyjst nova Agesa 1.0.0.4, ktora ma riesit lepsie OC, pridavat nejake vylepsenia a opravovat okolo 100chyb (marketingovy text)
https://www.guru3d.com/news-story/over- ... a-1-4.html

AMD : We Outperform Intel by 400%+ Per Dollar With Zen 2 Powered EPYC CPUs

https://wccftech.com/amd-we-outperform- ... epyc-cpus/

Za chviľku nebudeme mať porovnanie výkonu podľa IPC ale bude v móde performance per dollar

Tak v serverech je to asi lepší údaj než IPC

https://www.guru3d.com/news-story/amd-r ... st-25.html
kedze vlakno R9 3700-3900X je locknute, linkujem tu

Tu z iného zdroja ... procesor do mainstream segmentu s dual channelom rozbíja najvyššie Intel CPU z high end segmentu s quad channelom ... njn

https://www.techpowerup.com/260317/amd- ... rk-physics

Leonku, je fajn, že do mně furt valíš, ale už i na youtube je video, že je to fake a hloupost A nějakej 3Dmark nehraju.

Nebolo to vôbec na Teba. A postujem len to čo je, kľudne postni to video. O to lepšie, nech vieme, že to bola hlúposť. Chybu si priznám. Ja nepotrebujem silou mocou slepo propagovať jednu značku

Nejake slidy z Hot Chips: https://news.mynavi.jp/article/20191007-900041/

Uff, serverová IO die má 416mm2.

Male neni, viz https://www.flickr.com/photos/130561288 ... 938258367/

No, je síce veľká, ale zasa vyrábaná na starom node, takže predpokladám, že stojí "pár" šupov.

nemaj oni ještě stále povinnost odebírat nějaký počet waferů na 14/12nm od GF? Pokud ano tak to jsou dvě mouchy jednou ranou, předejdou penále a k tomu ještě smysluplně výrobou pro aktuální produkt(y)

velikost bude cca +100% proti IO Ryzenů 3000?

Já se divim velikosti. Je to 14nm, ale třeba můj velkej Haswell je na 28nm, má 18 jader, 45MB L3 a 40PCI-E linek + qua channel a celé to na 28nm má 622 mm².

Tohle má 0 jader, 128PCI-E, octa channel, 0 cache a je to velký jak prase (na 14nm) 416mm2. Na 28nm by to byl 800+mm2 čip. Trochu se ale bojim toho letování na 2 čtverce, doufjeme že to je monolytické.

Něco málo o AGESA 1.0.0.4

CB.de - AMD Ryzen 3000: Neue BIOS mit AGESA 1.0.0.4 heben Boost-Takt weiter an (DE)