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.
Já jsem se taky bál mírného poklesu výkonu (tak do 1-2 %). Ale stejně, správné řešení by bylo změnit metodiku měření. Takhle AMD žehlí problémy, které ani nejsou skutečné, a ještě nejsou na jejich straně.
>Takhle AMD žehlí problémy, které ani nejsou skutečné, a ještě nejsou na jejich straně.
Podobne ako to robí nVidia, lebo toto je oprav z podobnej kategórie:
ex-inženýr Nvidie: Každou hru vydávají rozbitou, opravujeme to v driverech
11. 3. 2015
„Téměř každá hra je vydána rozbitá. Řeč je o významných AAA titulech od výrobců, kteří patří k nejznámějším v branži. Někdy řešíme i donebevolající porušení pravidel APU - jedna D3D9 hra se ani neobtěžovala s voláním BeginFrame/EndFrame. Leccos jsou chyby nebo přehlédnutí - jeden titul byl vydaný s chybnými shadery, které silně snížily výkon našich ovladačů. Takové záležitosti jsou na denním programu bug-trackeru. Pak se na to někdo podívá, zjistí, co je v té hře zvorané a vytvoří záplatu, aby si s tím ovladač poradil.
V ovladači už existuje dlouhá řada volitelných záplat, které prostě pro jednotlivé hry zapínáme nebo vypínáme - a pak jsou tam hacky specifičtějšího rázu -
!!!až po kompletní náhradu původních shaderů za verzi připravenou našim softwarovým týmem.!!!
https://diit.cz/clanek/bugy-ve-hrach-resi-ovladace-graficke-karty
Presne tak. Pobavilo me:
"Někteří uživatelé měli obavy, zda tato změna negativně neovlivní výkon procesoru."
.... hmm takze ovlivneni vykonu ovladacem je mega zasadni problem, ale monitorovaci aplikace ktera prida "20ms zátěž každých 200 ms" tj ~10% vykonu, problem neni. Nebo to bylo mysleno jako vsechny aplikace na pozadi, maji 20ms zatez kazdych 200ms ? .... nevim, kazdopadne je to k*revsky hodne. 10% vykonu je u 4Ghz procaku 400M cyklu/s, za tu dobu zvladne dle IPC 300M-1G operaci. Co to dela, pocita Pi na milion desetinnych mist ? tezi bitcoiny ? Se fakt nekdo divi ze mu procak za tu dobu skoci na max frekvenci... lol
> Ale stejně, správné řešení by bylo změnit metodiku měření
Zmenili ji. Kdyz se podivate na to PDF "dokumentace ke zmenam", pisou tam:
"NEW BEHAVIOR: Report a short-duration rolling average of all temp sensors in the chip."
"NEW BEHAVIOR: Report the average voltage requested of the regulators, which presents a
“whole chip” view that factors in sleeping cores, idle cores, and active cores."
Takze teploty i voltage budou reportovany jako prumer. Ostatne, u cipu ktery umi menit svoji frekvenci 1000x za vterinu, moc jinych rozumnych moznosti neni (leda kontinualne kreslit graf).
Existuje nějaké logické vysvětlení jak mohlo dojít k zvýšení výkonu při pomalejším růstu frekvencí? Nedošlo ještě k nějaké další změně?
Vzhledem k nižší spotřebě(což se logicky dalo čekat) to ukazuje na podivnou metodiku měření výkonu než na perpetum mobile(procesor běhá častěji na nižších taktech a přesto má výšší výkon).
Co třeba faktor "úspory" TDP? Na krátké spiky se nevyužije plného TDP, které je tak zachováno "do foroty" pro delší vytížení?
Že by zůstal chladnější pasív a vydržel pak déle boost než se ohřeje?
Delší boost by zase zvyšoval či dorovnával spotřebu, která je nižší.
Ale teoreticky asi ano, IMO záleží na poměru zátěže(delší boost, vyšší výkon, vyšší spotřeba) a flákání(nižší spotřeba). Chtělo by to průběhy zátěže a frekvencí.
P.S. Doporučuji podívat se na zdroj je tam další graf - je odlišný průběh frekvencí CPU pro zátěž určitého počtu jader.
>při pomalejším růstu frekvencí?
ale tak isto pri pomalšom/menej častom poklese.
>podivnou metodiku měření výkonu než na perpetum mobile(procesor běhá častěji na nižších taktech a
>přesto má výšší výkon).
Nie nutne, Latencie(od to be late) bývajú nižšie na pomalších CPU. A ak je aplikácia závislá na latenciách viac ako na výkone pri dlhých kódoch, tak zníženie frekvencie navýši výkon v nej-
"ale tak isto pri pomalšom/menej častom poklese."
dle článku ne:
"V idle bude používán obvyklý 15ms interval, při zátěži dojde na kratší 1ms."
nebo máte nějaké lepší/podrobnější informace?
Zaprve, latence nejsou mensi na pomalejsich systemech. To je hovadina. Latence, cesky prodlevy jsou zpusobeny tim, ze neco nekde ceka. Napr jadro ceka nez se nactou data - tomu pomahaji ruzne algoritmy, nebo zasobniky.
Zpravidla prave na rychlejsich systemech (za predpokladu, ze cely system je rychly) jsou latence nizsi, nez na pomalejsim vykonu. Leda by nekdo neco zeslonil a dal doprostred pomaly prvek. Ale i tak to bude nejmene tak pomale, jako pomaly system.
A druha vec je s tema reakcema na zatez. AMD tvrdi, ze z IDLE je potencialne pomalejsi nastup na max frekvence. Co by v kratkodobych zatezich mohlo mit vykonostni regresi, ale zadna zatez evidentne neni tak mala (15ms) aby se to projevilo.
Ale naopak kdyz CPU vali, tak je detekce rychlejsi, 1ms, takze muze rychleji prejit do klidu.
Takze obe tvoje teorie jsou mimo.
nie úplne. Ak si zoberieme latencie na operáciách typu context switch a v RT a áno aj jadro, aj mikroarchitekúra a jej verzia na to má vplyv a áno uvedieme merania z hard relatime, kde je dôležitá maximálna latencia pri videu a hrách ide o soft realtime, teda o typickú hodnotu laterncie a možno pri inom type záťaže.. Ale zníženie frekvencie nemusí spôsobiť zvýšenie latencie, práve naopak , to najhoršie jadro sa môže vplyvom napr. teploty, vhodnejšej frekvencie zlepšiť..
Intel
https://www.osadl.org/Latency-plot-of-system-in-rack-1-slot.qa-latencypl...
https://www.osadl.org/Latency-plot-of-system-in-rack-3-slot.qa-latencypl...
https://www.osadl.org/Latency-plot-of-system-in-rack-2-slot.qa-latencypl...
https://www.osadl.org/Latency-plot-of-system-in-rack-0-slot.qa-latencypl...
AMD
https://www.osadl.org/Latency-plot-of-system-in-rack-1-slot.qa-latencypl...
a
https://www.osadl.org/Latency-plot-of-system-in-rack-c-slot.qa-latencypl...
resp. Hieroflacon, čo je ARM od AMD (https://www.tweaktown.com/news/48020/amds-new-8-core-hierofalcon-soc-spo...)
https://www.osadl.org/Latency-plot-of-system-in-rack-a-slot.qa-latencypl...
"najhoršie jadro sa môže vplyvom napr. teploty, vhodnejšej frekvencie zlepšiť"
A jak je na tom tedy Ryzen, platí pro něj to zlepšení skutečně nebo jen teoreticky?
Ty grafy nemaji zadnou vahu v diskuzi.
Popisuji cetnost a delku prodlev, ale uz v grafu neni zachyceno, jestli a jak se to meni s rychlosti jednotlivych casti systemu (RAM, CPU, I/O). Takze zase kus zbytecneho textu.
"to najhoršie jadro sa môže vplyvom napr. teploty, vhodnejšej frekvencie zlepšiť.."
Tak zaprve, pokud by jedno jadro melo nejak vylozene mimo latence, znamenalo by to problem architektury. Nerikam, ze se to nemuze stat, muze mit napr. neprimy pristup do RAM (coz je to vlozeni pomaleho prvku).
Zadruhe kdyz jedno jadro vypne a neco na nem bezelo, musi nutne aktivitu prebrat zbytek jader. Cim nutne zvysuje prodlevu, protoze ty zbyle jadra samozrejme musi resit prepinani kontextu casteji.
Pokud jsi to myslel tak, ze nastane okamzik, kdy misto 3 jader na max, 2 podtaktovanych a 3 na zakladu pobezi vsech 8 jader na zakladni + nejaky maly boost, tak to je vec scheduleru. Kazdopadne latence je neco jineho.
1-2% by se dalo považovat za odchylku měření, nebo došlo k dalším optimalizacím, aby dopad byl nejmenší a z toho vznikl kladné zvýšení výkonu, ale bavit se o zvýšení, snížení nebo rozdílu výkonu v jednotkách procent mi přijde ulítlé
Tady jsi v táboře rudých, tady je bomba když karty zrajou jak víno a koná se veselice i kdyby výkon novými ovladači stoupl o 0,0001%.
A hlavně se to zveřejňuje hned.
zprávy o nVidii se tady přechází jako by neexistovala a jen v ojedinělých věcech se tady něco vytáhne.
"Nelze tedy říct, že by nový ovladač řešící vyšší takty v klidu měl jakýkoli měřitelný negativní dopad na výkon nebo na spotřebu."
Zajímavý výrok, mně to měřitelné přišlo a někdy to bylo i negativní. Zajímavý je i ten graf, který tu chybí (Závislost frekvence CPU na zatížení jader :-)
Tyhle veci nema smysl moc resit, pokud tam nejsou nejake vykyvy, ktere se pak v tom prumeru ztraci. Tady je to vsechno vicemene v ramci chyby mereni. Otazka je, jak se to bude chovat na jine instalaci Win, na jine desce, atd. Tam to muzou namerit trosku jinak a porad to bude spravne.
Kdyz jsi zminil treba graf frekvenci jader v zavislosti na zatizeni, tak tady bych si tipnul, ze tam je bota..nedava totiz smysl, aby 9T frekvence byla vyssi hodnota nez na 8T..spis to vypada, ze presne tady je nejaka anomalie, kterou by jsi musel potvrdit na vice systemech, jinak nedava smysl.
V principu je to ale stejne jedno..protoze ty odchylky jsou tak male, ze z praktickeho hlediska o nich nema smysl ani mluvit :)
Souhlasím, že to nemá cenu řešit, ale proč by to nemělo být měřitelné?
Jaká je dle Vás chyba měření? Jak jste ji určil? :-)
"Kdyz jsi zminil treba graf frekvenci jader v zavislosti na zatizeni, tak tady bych si tipnul, ze tam je bota..nedava totiz smysl, aby 9T frekvence byla vyssi hodnota nez na 8T..spis to vypada, ze presne tady je nejaka anomalie, kterou by jsi musel potvrdit na vice systemech, jinak nedava smysl."
Přesto je to v pořádku, jak jste si sám odpověděl:
"Otazka je, jak se to bude chovat na jine instalaci Win, na jine desce, atd. Tam to muzou namerit trosku jinak a porad to bude spravne."
P.S. A přesto jsou na základě těchto výsledků uváděny závěry pro celou platformu:-)
Je dobre vidiet, ze sa to pod trvalou zatazou chova podobne a nenastala degradacia vykonu.
Ktovie ako sa to prejavuje v zatazi typu 90% idle, 10% load - napr v Lightroom, Photoshop alebo Resolve, Premiere, After Effects, kde clovek meni slidermi parametre a triafa sa do ziadaneho vysledku :) A prave tam je dobre mat max rychlost odozvy.
Alebo hociake kreslenie, design, modelovanie....
Trošku opačný efekt, tak jak všichni ostatní uživatelé.
https://www.youtube.com/watch?v=q85iV-ly5K4&t=
to je zas bomba.. intelisti, co se pod clankama o zaplatach na spectre hadali, jak si 30% propadu vykonu pri presunech dat normalni clovek nevsimne, tedy resej ze v dilcich testech ryzenu klesnul vykon o 1-2 % kdyz v jinejch stoupnul o 4-6 %.. (: si rikam jak asi musej bejt dusevne fixovany na intel a jak musej bejt zoufaly, kdyz uz na amd nenachazej nic zasadnejsiho ke kritice nez propad na urovni chyby mereni v dilcim testu nejakyho driveru na cipset.. ((:
jo, ze v prumeru stoupnul vykon o 1,5% je zanedbatelny a vubec by se o tom nemelo mluvit, ale ze v dilcim testu vykon o 1,5% klesnul, to zanebdatelny neni a musi se to poradne rozmaznout.. (: get a life.. (=
Na nejaky Intel sere pes :)
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.