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.
Takže by to nemusel kazit W11 scheduler? :-O Těším se na recenze!
To to klidně může. Místo, aby se držel stranou může se snažit "pomoci".
Míru čehož nám asi prozradí porovnání výkonu pod Win10 a Win11.
no pokud to chtějí mít pořádně tak ještě k tomu by měla být obdoba ITD, tam jde sice o regulaci menších jader, ale obecně jde o podobný problém - jak přiřadit procesy správně na daný čiplet. Samotný firmware to nespasí pokud o tom nebude vědět OS a umět s tím spolupracovat.
Já to pochopil tak, že firmware je schopen na základě zjištěného charakteru zátěže přečísluje jádra/vlákna, takže i když se OS scheduler bude chovat rigidně (tj. umísťovat zátěž od vláken 0 a dále), v případě hry půjde o jádra s V-cacha a jiných případech jádra s generickou L3 cache.
aby ten firmware byl takto chytrý no nevim, to už je hodně komplexní disciplína a zkoušet to hudlat bez vědomí OS nemusí dopadnout dobře. Můžou tam mít nahrané typické scénáře, ale na Win se často spouští víc aplikací, takže hodně obecný model aby to pak zase výkon neubíralo. HW implementace která by pracovala samostatně už by potřebovala samostatný koprocesor. Obecně je určitě lepší když Win prostě firmwaru sdělí co se spouští a ten už jen aktivuje předpřipravené scénáře.
Nemohlo by to být postaveno na vnitřních counterech instrukcí a load/store v CPU? Cílem by mohlo být dosáhnout maximálního počtu vykonaných instrukcí vůči load/store z RAM. Prostě metodou pokus omyl odhadnou alespoň lokální maximum.
Ano, to tam i pisu v biose "mem/cache activity > treshold". Najdolezitejsi bude pocet "cache miss". "Load z RAM" nie je sam o sebe dolezity. "Store" je este menej dolezity.
Cinebench ma nizky pocet "load" i "cache miss". Hra ma stredny pocet "load" a vysoky "cache miss".
To samotné by asj nestačilo, u aplikací co se vejdou do 32MB L3 cache bude pocet cache miss podobný. Rozhodující factor musí být aktuálně dosahovaný "Instructions Per Second", tj. snaha o co nejvíce vykonaného kódu. Pokud se vlákna CB běžícího dejme tomu na 8mi vláknech přeparkují na V-cache die klesne IPS (díky nižším taktům tohoto die) a algoritmus by je na základě toho měl vrátit zpět na generic die. A ani výrazně vyšší cache-miss ještě nemusí znamenat výsledný nižší výkon (pokud operace s RAM budou v celkovém měřítku minoritními).
Do L3 sa musia vojst data nie samotna aplikacia.
Teoreticky i jeden counter staci, bud IPC alebo cache miss. Ale v pripade IPC musis otestovat zataz na jednom i druhom CCD.
Pri cache miss to nie je vzdy nutne. Jeden cache miss znamena penalizaciu cca 250 clock cycles. RAM ma latenciu 60ns, L3 cache mala u 5800X3D 11-12ns. Takt bude cca 5.1-5.2GHz. Rychle jadra budu mat takt vyssi o cca 10%. Potrebujes znizit pocet cache miss o cca 2 miliony za sekundu na 1 jadro ak chces dohnat stratu 10%. Najprv testnes na rychlom jadre, ak je pocet cache miss nizsi nez 2mil, tak je rozhodnute, nechas na rychlom jadre. Ak je vyssi, tak musis testnut i na CCD s velkou cache a porovnat.
To by mohlo dávat smysl.
"Do L3 sa musia vojst data nie samotna aplikacia."
Pokud budu mít rozplizlý lineární kód s cyklem o délce 60MB s minimálním požadavkem na data, bude rychlost jeho výkonu na obou die shodný?
Jednoduchy linearny kod alebo data citane sekvencne/postupne nevyzaduju velku cache. Nezalezi na velkosti aplikacie/dat. Zrejme by tam stacilo i niekolko KB cache. Rychlejsie taktovane jadro tam bude mat vyhodu.
Edit: Ale i aplikacia je v cache, nie len data. No su to len male casti ktore CPU predpoklada ze v blizkej dobe vyuzije.
Pokud se takový kód vykonává rychleji než je možné jej načíst z paměti, větší L3 (kde přežije celý do dalšího cyklu) musí mít při opakování cyklu pozitivní dopad na rychlost.
Ok, mas pravdu.
"přečísluje jádra"
To potom nebude možné použít afinitu.
Předpokládal bych, že toto půjde v BIOSu zcela vypnout. Každopádně by se to hodilo.
Myslim, ze programek dAffinity to poriesi spolahlivejsie.
https://www.d7xtech.com/daffinity/
Ano ale jen pro aplikace které využijí max 6 jader pro 7900X3D a 8 pro 7950X3D.
Co uděláš s aplikací která využije více než 8 jader?
ja od kúpy Ryzen 3800x používam https://bitsum.com/ .
k tomu toto https://bitsum.com/parkcontrol/ aby jadrá "nezaspali" a zvýšil sa lag
Na to nepotřebuješ žádnou externí utilitku. Pokud by u nějaké aplikace fakt záleželo na jakých jádrech běží, lze ji spustit příkazem "start" s parametrem "affinity" a uvedením bitové masky dle kýžených jader.
to je síce pravda ale stále na tie jadrá môžu nabiehať požiadavky iných úloh. S utilitou ako používam natvrdo priradíš konkrétnym jadrám afinitu, prioritu.....a samo môžeš máť profily takže podľa spôsobu použitia pc v danom čase si zvolíš potrebné nastavenie
napr https://i.imgur.com/PK0WxGk.jpg
".. ale stále na tie jadrá môžu nabiehať požiadavky iných úloh .."
Pokud bude sheduler házet dálší vlákna na vytížená jádra, zatímco se mu vedle jiná flákají ..
.. no prostě ... Windows.
Stále je tu měřítko celkového počtu vykonaných instrukcí (za celé CPU) za časovou periodu. Přehazováním vláken může být asi docíleno vyšší hodnoty (nalezení lokálního maxima?), ale asi těžko zcela optimálního nastavení.
to aj robí, nabiehávajú tam nejaké úlohy os, ale je to podstatne menej akoby to bolo voľne prístupné všetkým úlohám.
Venku je udajny ofiko slide AMD k vykonu 7950X3D ve hrach. Podle jejich metodiky cca +6% v prumeru nad 13900k a 16% nad 7950x
https://videocardz.com/newz/amd-ryzen-9-7950x3d-is-6-faster-in-gaming-th...
Tak kromě Trashes of Singularity benchmarku to celkem jde. Ale čekal jsem trochu víc no.
Ja cekal taky vic, hlavne s ohledem za ten priplatek, co si AMD za to bude uctovat.
jenže je tu pořád KS model a u K verzí je možný na některých deskách 6Ghz režim, takže jen dohnání.
Rozdíl mezi K s 5,8GHz a KS s 6GHz je 3%.
Ale ve hrách se tato výhoda neprojevuje.
Bottleneck je jinde.
Není to jen o desce. Nezapomeň na chlazení.
Rozdil K a KS je "nula" na urovni chyby mereni.
Jedine co rozhoduje je, se kterym z tech dvou jsi schopen sparovat rychlejsi pameti. To ma daleko vetsi vliv nez nejaky pretopeny KS.
Cože? Rozdíl bude zas asi tak 15% jako u předešlého Zen3X3D, podle HUB má i top i9 13900KS náskok nad nejrychlejší Zen4 jen nějakých 5%... fakt by mě zajímalo, jak se z tohoto stane plichta (nebo dokonce jen dohánění, takže podle tebe jako ani nedorovná?... ale no tááák:)), když už teď to je v podstatě plichta...:) to je zas asi nějaká velmi fascinující matematika.
https://static.techspot.com/articles-info/2607/bench/1080p-p.webp
Hlavně bude prdel si pak zas porovnat tu efektivitu, když už teď to má stejný výkon při poloviční spotřebě, protože s touto 3D verzí se teď spotřeba ještě víc snižuje, protože nižší takty, přitom herní výkon se přes tu cache zvyšuje a většinou to ty nižší takty dokáže vynahradit... pro Intel teď asi docela nepříjemné mít 2x větší topítko a stejně to už výkonově ani nepřekonají... tak sis předtím říkal – OK no... sice vyšší cena, větší topení, ale nakonec aspoň i ten trochu vyšší výkon... teď máš akorát přímotop a houvno z toho.:)
Intel udela velke male jadra a pak si to ma scheduler hazet podle potreby - OMFG BAD
Amd udela velke male jadra de fakto a scheduler si to ma hazet podle potreby - Jóooo SUUPR
Ano máš naprostou pravdu. Nechápu proč máš tolik mínus.
Když dva dělají totéž. Není to totéž.
V desktopu AMD zatím žádná malá jádra nevydala a ani neplánuje. (Serverové a mobilní ZEN 4c se chystají tuším na příští rok).
Ryzen 9 7000X3D jsou velká jádra "big" + ještě větší BIGGER. Tedy koncept big.BIGGER.
BIGGER jádra mají o 10% menší takty, ale dohánějí to velikosti.
Malé E-prdíky od intelu jsou pomalejší o 30% a nemají to čím nahnat. Navíc jsou bez HT, AVX512.
7000X3D žádný BigBIGGER není. ty jádra jsou naprosto totožná.
jen jedny mají vyšší takty a druhé mají víc cache. ale velikostně jsou naprosto identické.
Trochu mi to trhá uši:
"Mají víc cache, ale jsou identické."
Tobě ne?
Ale jestli máš pravdu, tak to potom ani ZEN 4c nebudou malá jádra.
Rozdíl je hlavně v cache.
Další věc je "dark silicon" který AMD v ZEN 4c odstraní čím klesne plocha jádra ale takty taky(kvůli horšímu chlazení).
I cache je svým způsobem dark silicon.
Tuto funkci plní také IF. Zejména u ZEN 2.
https://en.wikipedia.org/wiki/Zen_3#/media/File%3AZen_2_vs_Zen_3_CCD_Lay...
Ono totiz jadro je identicke, V-cache je len dalsia cache, ktora sedi medzi jadrom a RAM.
Cache ziaden dark silicon nie je. Kedze procesory su dnes nasobne rychlejsie nez RAM, cache sa vyznamnym sposobom podiela na tom, aby procesol mal co zrat.
To je tvůj úhel pohledu.
Z mého pohledu větší cache zvedne výkon.
Tudíž zvedá IPC.
Ano z pohledu šířky je jádro identické.
Ale z pohledu délky je větší.
Dark silicon je tak trochu marketingový pojem.
Ale já jej chápu tak, že má umožňovat větší takty. Což L2 splňuje. Teplo z jádra se díky L2 může šířit do stran (ke krajům chipletu) a zvětšit tak plochu kterou se teplo odvádí do heaspreaderu. L3 má už menší vliv. A vertikální vrstva odvod tepla zhoršuje.
Dark silicon nemusí být jen cache. Můžou to být i ALU jednotky kterých má jádro víc než běžně použije a ty neaktivní pomáhají chladit ty aktivní.
Velikost jádra (fyzická) je zcela irelevatní, důležitější jsou jeho schopnosti a schopnost jádra nalézt potřebná data v 96MB L3 místo 32MB L3 z něj dělá jíné jádro. Stejně tak z něj dělají jiné jádro nižší takty. Označování big.SLOWER, big.BIGGER je pouze hraní si se slovíčky. Podstatný bude dosažený výkon a ten bude nejen o jádru, ale o kokrétní kombinaci jádro+kód. Například u 7zip komprese bylo na 7950X3D (V-cache na polovině die) údajně dosaženo 52% nárustu výkonu. To si skoro říká o označení big.HUGE. ;-)
https://cdn.wccftech.com/wp-content/uploads/2023/01/AMD-Ryzen-7000-X3D-C...
Je fajn že se s tím bude dát laborovat.
(Podle fotky to tak vypadá.)
Nadšenci jistě najdou ideální nastavení.
Které se potom nastaví všem ostatním.
Intel může leda přes afinitu zakázat použití některých jader. Což zas jen ubírá výkon. Řešení od AMD nabídne mnohem detailnější možnosti.
Hlavně se výkon posuzuje z pohledu jediné aplikace. Při běhu více úloh je s V-cache šance na větší cache-hit-ratio než s menší cache. Například na pozadí běžící 7zip s 32MB slovníkem (-mx=7) v kombinaci s dalšími úlohami. Bylo by fajn, kdyby se testování rozvíjelo i tímto směrem. Pravda asi by se muselo testování opakovat vícekrát s intervalovým výsledkem (odlišné výsledky vzhledem k asynchronnímu běhu paralelních úloh).
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.