Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Komprese:
Cache má pozitivní vliv.
Viz dobré výsledky X3D v odkazu níže.
Dekomprese:
Přes 2M bodů zvládne i Ryzen 9 5950X
Takže 16 starých jader porazí 128 jader EPYC 9754?
Za dobrými výsledky EPYC 9755 bych nehledal AVX512. Ale spíš cache a propustnost RAM omezenou počtem chipletů.
https://www.hwcooling.net/amd-ryzen-9-9950x-na-samom-vrchole-v-1-aj-v-32...
Patice zůstává, takže propustnost se tolik nemění, cache má vliv, ale až tak zase ne. Vylepšené vektorové jednotky už by mohly. Patrně jde o kombinaci více vlivů.
Co Tě vede k tomu, že větší cache u 7zipu, bude mít malý vliv? Řekl bych, že to bude právě dost naopak a čím víc, se toho do cache vleze, tím víc bude v této zátěži výpočtní jádro využité a tudíž rychlejší. Samozřejmě, pokud už má 7zip podporu AVX-512, tak i to mohlo pomoct, plus další vylepšení Zen5.
Vtipné, v 7zipu exceloval i Bulldozer :)
A kde jsem napsal, že malý. Přečti si to znovu.
Kutil: "...cache má vliv, ale až tak zase ne.".
A mohla by zdvojnásobit výkon sama o sobě? Beze změny kapacity?
Teď vůbec netuším, na co se ptáš? Turin kapacitu velmi zvýšil, což podle mě hodně pomohlo v prezentovaném rozdílu 7zip z tohoto článku.Samozřejmě i další vylepšení jako širší OoO, více ALU a i full-speed AVX-512, pokud jej 7zip umí využít, hrálo roli.
Ty jsi napsal, že cache měla malý vliv. Jestli teď jen slovíčkáříš, aby ses vykroutil z toho, cos sám napsal, tak asi nemusíme dál diskutovat.
Napsal jsem to, což jsi nepochopil, že to není jen cache. L1 a L2 je dvojnásobně rychlá, ale L3 ne, zvýšila se kapacita ale pouze L1 datové z 32 na 48 KB. To co jsem napsal je: Všechny změny v jádri, kterých opravdu hodně, mají vliv. Význam cache bych tolik nepřeceňoval, ta jen pomáhá eliminovat latence hlavní paměti. A to že jsou algoritmy, které jsou na cache citlivější tím rozhodně neodmítám. Jen znovu opakuji, že bez dalších změn v jádře by vliv vylepšení cache, by nárůst výkonu takový nebyl.
Naopak, masivní cache je u širokého jádra naprostý základ.
Ale musi byt to siroke jadro. O tom je rec. Ze kes mela vliv, ale ne 100%, nebo 80%, nebo 60%, nebo.. toho narustu vykonu.
Ale neudělá sama o sobě bez dalšího dvojnásobný výkon a to je o čem jsme se přeli. Vliv cache nepopírá, má svůj důvod a účel, ale takových částí je v procesoru víc.
Můžeš to teď obkecávat něčím dalším a popírat tvá vlastní slova. Jen tak btw. se třeba mrkni, jak se daří v 7zipu 3D verzím oproti ekvivaletům bez té velké 3D cache ;-)
Nic nepopírám ani nevyvracím, ale nemůžu za to, že někdo z něčeho tak nepřesného a jednoduše napsaného dělá nějaké závěry. Znám dobře vliv cache ostatně používá už dost dlouho u procesorů. Jen opakuji, že sama o sobě bez dalších změt, jen změna v cache, nemá až takový vliv. Kdyby došlo k významné změně v její velikosti, což nastane opět u Epyců F a X řad a X3D Ryzenů, tam ano. Ale házet vše na cache u procesoru, kde došlo na jádře k takovému množství změn, je trochu hloupé.
Jo, přesně kvůli velké cache na tu dobu.
A teď si vynasobte spotřebu 5950x počtem jader :-)
Tak to ale nefunguje, protože serverové Epyc jedou na nižším taktu, tedy s větší efektivitou. A navíc, zde máme centrální chiplet a jeho vliv nějak jednoduše vynásobit nejde.
U vacsiny kompresnych algoritmov zalozenych na slovnikoch je dekompresia relativne trivialna operacia v porovnani s kompresiou. Hlavne pre dnesne procesory, ktore hravo narvu cely slovnik do cache.
Dekompresiu ako taku by som nevidel ako nejaky super-relevantny test vykonu procesora.
A co kompresi? Navíc ta data tím procesorem prostě musí projít a nezáleží na tom, jak náročné to výpočetně je.
Kompresia uz je vypoctovo narocnejsia. Treba nad tymi datami pocitat hafo veci.
No a hej, data procesorom prejst musia, ale dekompresia je vo vacsine pripadov take copy-paste zo slovnika na zaklade skomprimovaneho streamu.
Tam je ten postup vacsinou taky, ze pozri v skomprimovanom streame tag, ktory je +- offset do slovnika a skopci zo slovnika XY bytov/bitov; rinse and repeat.
Takze to viac menej testuje priepustnost datapath, nez hruby vypoctovy vykon procesora.
No a kedze procesor ako taky je nasobne rychlejsi, nez jeho datapath, tak je otazne, ci to bude limitovane rychlostou RAM, cache, zbernic, alebo v najextremnejsich pripadoch priepustnostou diskoveho subsystemu.
A všiml sis, že tam jsou výsledky obojího?
".. data procesorom prejst musia .."
Dokonce dvakrát (komprimovaná dovnitř a rozbalená ven)
Proto dává smysl aby komprimovaná data pro GPU rozbalovalo GPU přímo u sebe.
Nezbývá než čekat, až se to stane šířeji implementované.
Pokud namítáte, že článek je o serverových GPU, tak zkuste přemýšlet kolik úloh v módním AI spočívá v tom, že CPU krmí akcelerátor daty.
Jde snad o článek o serverovém CPU, kde v něm píšou o AI?
A ještě o GPU, tady si někdo ráno nedal kafe. XD
Doktorka mi nemůže zakázat chlast, kouření, tak mi alespoň omezila pití kafe :(
Ve skutečnosti je to ještě horší než to vypadá.
Jsem si ráno nevzal ani prášky.
Bez toho kafe jsem na to nějak zapomenul :(
To ze najbrutalnejsie 128C256T serverovske monstrum od AMD (iba s velkymi jadrami) by mohlo mat tu drzost a v peaku vyssiu spotrebu ako z retaze odtrhnuty desktopovy 24C=8P+16E Ci9 14900K (kde su 2/3 Atom zmrdy), tak tato fakticka poznamocka mi prisla naramne vtipna takto po ranu :)
To je No-Xův sofistikovaný trolling. 😃
Intel už v dohledné době nic nezastaví. Dominance AMD je drtivá.
omyl
Naspodku tých ázijských screenshotov som si všimol údaj "threads: 64". Znamená to, že ten 7-Zip benchmark beží iba na 64 vláknach namiesto dostupných 256?
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.