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í.
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.