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.
