AVX-512 by měl být ten hlavní důvod proč teď ne Intel, teda pokud člověk chce aby ten CPU i za pár let byl relevantní.
Avx je naopak naprosto nezajimavy argument, protoze vyuziti je tak specificke a tak uzke, ze nedava zadny smysl. Na drtivou vetsinu uloh kde by to vubec smysl davalo je totiz radove vyhodnejsi pouzit GPU.
A na tom se nic nezmeni. Naopak. Jak bude dochazet k obmenovani GPU, tak bude rust pocet lidi kterym AVX nic neda.
Jenomže jsou případy viz Asteriods@home kdy aplikace využívající AVX-512 byla rychlejší na CPU než na GPU. A to nemluvím i spotřebě CPU vs GPU.
Takže opravdu je AVX nezajímavý argument?
7. 11. 2024, 12:56 editováno autorem komentáře
Falesny argument, GPU je radove energeticky efektivnejsi per jednotka vykonu.
A pokud dobre vidim, tak oni se chlubi tim, ze tu appku maji navrzenou prave pro avx, a tudiz nikoli pro gpu, kdyby ji predelali pro gpu byla by o rad vykonejsi.
Ja ovsem nezpochybnuju to ze muze existovat nejaky velice uzky okruh uloh, ktere budou tak specificke, ze pro je avx bude vyhodnejsi. Ale jak sem rek, takovych bude naprosta minorita.
A pokud budu resit sw pro nejaky distribuovany vypocet, tak GPU ma radove vice lidi, nez cpu s avx.
Tak to je moc smutné, že jsi přišel na jednu jedinou takovou a navíc z praktického hlediska zcela nezajímavou ;-) A ještě není jisté, zda to není tím, že GPU implementace byla mizerná...
Nevím co tím chceš říct, nicméně jestliže buď neumíš kontaktovat Karlovu univerzitu s návrhem na zlepšením kódu pro GPU anebo alespoň přispět výpočetním výkonem v CPU výpočtech, tak se řadíš do zástupu tlachajících ubožáků, sorry.
Už sdílím výkon CPU/GPU 20 let pro BOINC a tak jsem zanechal nesmazatelnou stopu ve srovnání s kecálkama. Takže co si budeme povídat.
Z těchto argumentů už jsem unavený, většinou to píšou lidi co o tom nic neví nebo AVX-512 nikdy nepoužili. AVX-512 vs GPU je úplně jiný use-case, ale já už to nechci pořád vysvětlovat.
Bez ray tracingu se taky říkalo, že pak GPU bude bezcenné, špatné atd....
Ve finále na první dojem seto zapne a jinak je to vypnuté kvůli FPS... Takže pojem relevantní ve světě IT je těžké, protože se to mění rychle...
Ale ano, Intel by to měl mít, ale že by se nedal používat se fakt říct nedá...
AVX512 je v procesorech už 8 let a furt nic - skoro žádné aplikace to nepoužívají. Kolik je teda těch "pár", dalších 8?
AVX512 je v procesorech už 8 let, ale možných kombinací co který CPU podporoval/nepodporoval bylo spousta, tak není divu že to zatím skoro nikdo nepoužíval. Viz např. článek zde na rootu.
Ve skutečnosti přináší AVX-512 tak rozsáhlou změnu, že je rozděleno do několika podmnožin, přičemž zdaleka na všechny mikroprocesory musí podporovat všechny podmnožiny. To má zajímavý důsledek – počet možných kombinací podporuje/nepodporuje je obrovský.
https://www.root.cz/clanky/rozsireni-instrukcni-sady-f16c-fma-a-avx-512-na-platforme-x86-64/#k16
Ok, v takovém případě upravuji svůj odhad z osmi na dvanáct let: 6 let než si to sedne do nějaké koncenzuální úrovně aby nebylo třeba dělat v kódu hromady výhybek, 4 roky než market share takových procesorů dosáhne úrovně aby to developeři začali brát vážně, 2 roky, než se to dostane do reálného softu. No a samozřejmě Debian upraví defaultní -march aby gcc ty instrukce směl použít za dalších 10 let ;-)
Ty kombinace jsou ale v reálu jen 2 - Skylake a Icelake/Zen4/Zen5.
AVX-512 je sice fragmentované (hodně CPUID bitů pro různé specifické rozšíření), ale procesory víceméně implementujou to stejné, takže jako první se dá označit AVX-512 v Skylake, které bylo celkem omezené, a pak průnik IceLake a Zen4.
Ty novější rozšíření jsou navíc hodně specifické a některé přináší jen pár instrukcí, které ne každý dokáže využít, takže obecný AVX-512 kód je prostě takový baseline použitelný na většinu věcí.
Většina aplikací kde jde o výkon to ale používá, spíš Intel zaspal a tím, že to odstranil z consumer segmentu se dal vlastní facku. Díky AMD vidím doslova boom v používání AVX-512, protože to je jediná možnost jak využít nové CPU naplno.
16000 za 16 jader není mnoho, pořád to není mainstream a není tak daleko doba, kdy bylo běžné kupovat 4 jádra za >4000. A do toho ještě musí promluvit inflace posledních let.
Máte někdo praktické zkušenosti s těmi "3D" variantami Ryzenů? Zajímají mne hlavně úlohy, které na delší dobu plně zatíží všechna jádra, např. build jádra nebo encoding videa (x265, SVT-AV1), případně třeba i Stockfish. Co jsem se k tomu snažil hledat, vypadalo to, že na rozdíl od herních benchmarků může být u tohoto typu úloh výkon dokonce o něco nižší než u normální verze, a i kdyby ne, určitě neodpovídá vyšší ceně. Koneckonců je to vidět i na tom testu na Moronixu, kde je v buildu jádra 7950X o chloupek rychlejší než 7950X3D a 7900X než 7900X3D (u "devítkové" generace tam bohužel přímé srovnání chybí). Bohužel tam ale autor nesmyslně používá defconfig, takže je benchmark dost daleko od reálné praxe (tam by to ale pro "X3D" mohlo být ještě horší). Podobně vyznívají i testy x265.
Jestli má někdo reálné zkušenosti "ze života", docela bych je ocenil.
Tímhle problémem z technologických důvodů trpěl ZEN4, prostě měl snížené TDP a frekvence bez možnosti přetaktování. U ZEN5 se to podle všeho podařilo vyřešit. Asi zejména tím, že vrstva s cache není nad jádry ale pod. Má to ale i nevýhodu - 9800X3D žere v plné zátěži o dost víc než 7800X3D.
7. 11. 2024, 09:35 editováno autorem komentáře
Dobře, řekněme že 9900X3D nebo 9950X3D nebude pomalejší než "obyčejné" varianty. Bude ale v tomhle typu zátěže dvojnásobná L3 cache takovou výhodou, aby to výkonem ospravedlnilo nezanedbatelně vyšší cenu? Tím si právě nejsem vůbec jistý, ale asi holt budu muset počkat, až někdo udělá přímé srovnání.
Na to zatím nelze spolehlivě odpovědět páč se zatím neví, zda budou mít větší cache na obou CCD nebo ne (spíše nebude), což bude mít výkonnostní tak i cenové implikace. Ale nápovědou může být srovnání 9800X3D vs 9700X, kterých je po včerejšku plný internet.
Vyuzitelnost/vliv cache hodne zavisi na typu ulohy, ne na zatizeni CPU. Uloha ktera bude provadet nejaky vypocet na omezene velkych datech, z toho pochopitelne bude tezit maximum, ale takovych uloh asi v beznem svete moc nebude.
A naopak, ta vetsi cache typicky limituje vlastni jadra - zvysuje odber, tudiz teplo, takze typicky opet jadra bezi ve vysledku pomaleji.
Takze pokud neco takoveho nepocitas, tak se to rozhodne nevyplati.
Problém je, že tohle u netriviálních apek často neodhadne ani její autor jak se to bude chovat. Navíc se jedná o L3 takže ti může noisy neighbor všechno změnit. Musí se to vyzkoušet v praxi. Před příchodem 5800x3d se někdo ptal Kovarexe (autora Factoria) zda se vyplatí počkat. Říkal, že netuší a kdyby měl hádat, tak že spíš ne. Výsledek - Factorio hrou, které x3d pomáhá snad nejvíc :)
Problém je právě v tom, že si netroufám odhadnout, jak na tom budou právě ty úlohy, které jsou pro mne důležité. A pak taky, že 128 MB vypadá na první pohled impozantně (na tuhle velikost paměti jsem se IIRC dostal až někdy kolem roku 2000), ale je to pro celý procesor - a když se to vydělí 12/16 (nebo dokonce 24/32), tak už to tak obrovsky nevypadá.
U buildu jádra, který mne pochopitelně zajímá nejvíc, se obávám, že L3 cache až takovou roli hrát nebude. U x265 by teoreticky pomoci mohla, celé video je typicky obrovské, ale jednotlivé kusy, které se zpracovávají, už by se tam možná vejít mohly - ale pak je zase otázka, jestli by se nevešly i do té poloviční. No a Stockfish má zase nějaké pomocné tabulky, které sice asi budou sdílené, ale konfigurační dialog pro ně umožňuje vyhradit až 512 MB.
Nakonec stejně bude potřeba si počkat i na to, jak vůbec budou vypadat ceny.
Tak nektery ulohy muzes pro ten CPu nejakym zpusobem optimalizovat, ale zase, co pocitas? Kompilujes ? Tam to vliv bude mit podle me naprosto nicotny, protoze ti cache funguje jen jako prutokac. Nejakym zpusobem ti samo pomuze zajistit kontinuitu prisunu dat/vyrovnavani zpozdeni ramky, ale na to nepotrebujes moc.
To video by to sice mohlo ovlivnit, ale za predpokladu, ze tu kompresi prave pro ten konkretni cpu nakonfigurujes tak, aby se zpracovavany blok spolehlive vesel. A pak je taky pomerne zasadni otazka, jak k tomu pristupuje prave ten kodek. Jak casto to delas? A co od toho cekas? Rozdil bude do 10% v extremnim pripade.
Prakticky prave cim dal horsi latence ramek je presne to, co (castecne) leci L3.
IMO to muze pomoct jeste v situaci, kdy ti na stroji beha opravdu hodne uloh soucasne, takze se nemuseji porad dokola nacitat z ramky. Ale to spis jako uzivatel vubec nezaznamenas, ackoli by se to asi dalo zmerit v podobe nizsich latenci.
https://www.youtube.com/watch?v=BcYixjMMHFk&t=668s
render v premiere pro 9700x -> 9800x3d +10,6 %
https://www.youtube.com/watch?v=tDbutc4iAAI&t=639s
handbrake rescale - chybi provonání s 9700x... ale z jiných výsledků je patrné, že cache moc nepomáhá
https://www.youtube.com/watch?v=s-lFgbzU3LY&t=1596s
chromium kompilace (windows, visual studio) +14,3 %
Znamená to ale, že stejný přínos bude i v gcc nebo clang? to právě není vůbec jisté.
Znamená to ale, že stejný přínos bude i v gcc nebo clang? to právě není vůbec jisté.
Spíš je otázka, jestli lze u těchto testů vůbec o přínosu mluvit. Pokud dobře vidím, 9800X3D běží na frekvenci 4.7 GHz, zatímco 9700X na 3.8 GHz, to je 23.6% rozdíl. Takže pokud je výkon 9800X3D sice vyšší, ale výrazně méně, než by odpovídalo poměru frekvencí (oba jsou osmijádrové), tak bych takový výsledek hodnotil spíš jako zklamání. (Boost frekvence jsou sice podobné, ale ty by u úloh zatěžujících všechna jádra po delší dobu hrát roli neměly.)
Já bych to řekl spíš takto - pokud se problém co řešíš do té cache vleze, tak budeš mít neuvěřitelný výkon, pokud ale ten problém potřebuje třeba 64GB RAM, tak to sice bude lepší, ale způsob používání RAM, predikce čtení z paměti, možná i manuální prefetch, bude mít mnohem větší vliv na celkový výkon.
3D cache u Zen 4 má nižší max napětí než je teoreticky možná max mez napětí CPU. A protože ta cache využívá napětí CPU tak logicky ten CPU nemůže dosáhnout tak vysoké frekvence jako ne-3D verze.
Proto se můžeš setkat s aplikacemi které jedou o pár procent pomaleji v případě že neumí benefitovat z 3D cache.