Měření výkonu CPU na scestí: ovlivnit výsledky testů lze mnoha způsoby

Na tohle téma mě zase po letech přivedlo zkoumání toho, jak výkonný je vlastně můj nový procesor. Tedy jaké výsledky v kontextu jiných CPU dává 6jádrové Core i5–10400F v testu toho či onoho webu, případně cokoli jiného z této generace procesorů Intel (pozn. 14nm Comet Lake, uveden na trh na jaře 2020).

Autor: David Ježek, podle licence: CC BY-SA 4.0

Víceméně nezajímavé Comet Lake PC

Jak lze vytušit z existence tohoto textu, rozpory se samozřejmě našly, a to nejen napříč různými recenzemi těchto CPU na různých webech, ale i v mých vlastních výsledcích. Tím jsem se obloukem dostal zpátky k mému oblíbenému tvrzení: čím detailnější je metodika testování CPU, tím méně přesná ve vytváření obrazu o výkonu toho CPU je a současně tím rychleji výsledky zastarávají. Než vám ukáži některá vlastní měření, dovolte mi krátce vzpomenout pár příkladů z let minulých, kdy mě testování počítačových komponent živilo.

Příklad první: Dostávám na test grafickou kartu před jejím uvedením na trh. České zastoupení jednoho výrobce grafických karet explicitně požaduje, aby všechna měření nové grafické karty byla provedena bez sundání chladiče, ale aby tento chladič nebyl vůbec demontován (kvůli fotografii PCB). Samozřejmě vyhovuji, je to slušnost. Kartu změřím, následně putuje do dalších redakcí (typicky v ČR býval jeden vzorek na celou zemi a musel se redakcemi protočit před termínem uvedení / konce NDA). Po pár týdnech se mi karta vrací se slovy „teď už ji měli všichni, tak klidně chladič sundej“.

Vyzkoušel jsem na ní vícero teplovodivých past, od levného bílého silikonu za 19 Kč, až po nějaký Arctic Cooling MX, tehdy bratru za 300 Kč. Kupodivu výsledky s levným silikonem nebyly špatné (výkon karty stejný, jen provozní teplota o ~2 °C vyšší, ale vše v limitech před throttlingem), pasta Arctic MX odvedla o několik °C lepší práci než výchozí pasta z výroby. Teoreticky tak poskytovala kartě možnost běžet na zvýšených frekvencích, pokud bych to jako uživatel nastavil. Současně s nižší teplotou přišel i velmi mírný až zanedbatelný pokles spotřeby. Přesto v případě přepastování karty Arcticem před vlastními měřeními by v recenzi vyšla o něco lépe.

Příklad druhý: testuji 220W procesor od AMD. Očekávat lze jisté výsledky, zejména s ohledem na známé chování daného chladiče a dané pasty. Pokusů o správné napatlání CPU pastou jsem provedl asi 7, z nichž pouhé 2 se povedly tak, že výsledek byl odpovídající, tedy nedocházelo k nárazovému přehřívání CPU a thermal-throttlingu. Veškeré úskalí bylo právě jen a pouze ve způsobu nanesení teplovodivé pasty na povrch CPU a způsobu osazení chladiče na něj (ten se šrouboval ve čtyřech rozích CPU a tak bylo žádoucí na začátku procesu vše provést rychle, aby pasta napatlaná určitým způsobem nebyla vytlačena nerovnoměrně).

Jak ovlivnit výsledky CPU v testu

Dnešní procesory, ať již vezmete CPU či GPU, jsou úžasné. Obecně platí, že jsou schopny neustále (klidně tisíckrát za sekundu) monitorovat svoje provozní parametry a přizpůsobovat je požadované činnosti či zátěži a do toho vše balancovat na zvolené hraně mezi výkonem / spotřebou (napětími).

Když se budeme držet CPU, tak ta dnes prakticky není nutné přetaktovávat. Už dávno disponují různými turbo režimy, kdy v závislosti na počtu vytížených CPU jader může jejich špičková frekvence z (například) základních 3,0 GHz být (například) 4,0 GHz, nebo také 5,3 GHz. Vše omezené jen tím, aby se CPU nepřehřálo (ani lokálně některá jádra), nepřetěžovaly se napájecí obvody, ale poskytovaný výkon byl maximální možný.

Proto se u Intel CPU dnes nehovoří jen o hodnotě TDP (Thermal Design Power), například 65 W. To je číslo, které víceméně udává, na jakou hodnotu je potřeba dimenzovat dlouhodobé chlazení (ale nechytejte mě prosím za slovo, třeba to tak už dávno není). Kromě toho ale Intel specifikuje zejména dvě další hodnoty: PL1 a PL2 (PL1 často splývá s TDP). Tohle přišlo nejpozději s generací Sandy Bridge (leden 2011), která právě Turbo Boost 2.0 přinesla.

Jelikož u posledních zhruba šesti generací CPU Intel tyhle hodnoty měly různý význam, velmi obecně řekněme, že TDP je nepodstatná hodnota a je to právě limit PL1, na který by měl uživatel cílit s chlazením (u procesoru s TDP 65 W může být tento limit někde kolem 150 W), protože představuje trvalejší hodnotu vyjadřující výkon/spotřebu/tepelné vyzařování procesoru. Za ním je ještě PL2 limit, který představuje časově silně omezenou možnost jít s frekvencí CPU, tedy výkonem, výrazně nad udržitelné limity CPU, přičemž v případě posledních generací Intel CPU se tato hodnota pohybuje na úrovni 250 W pro 65 až 125W desktop procesory.

Těchto limitů je dosahováno jen za velmi optimálních okolností a po krátkou dobu zvanou tau, která je v řádu desítek sekund (typicky 28 s pro běžné procesory a 56 s pro K-modely, tedy ty s odemčeným násobičem). Na PL2 limitu procesor běží, pokud je dostatečně chladný, má dostatečné dodávky energie a je co nejvyšší výkon požadován.

Jinými slovy: dnešní Intel CPU mohou některé krátké, ale výpočetně náročné úlohy vykonat při běhu na frekvenci, na kterou by při třeba hodinu trvajícím encodingu videa nemohly, protože by se přehřály a zasáhla by teplotní ochrana (známá prováděním tzv. thermal throttlingu). Výhodné pro recenze CPU, pokud v Intelu víte, že CineBench na daném CPU běžícím na 5,3 GHz proběhne v časovém limitu pro režim PL2. Proto přišel benchmarkovací nástroj Cinebench ve verzi R23 s tím, že skóre vyhodí až po 10minutovém běhu testu.

Nicméně toto je jeden ze způsobů, jak měření značně ovlivnit. Dnes často BIOSy desek umožňují nastavovat chování a limity stavu PL1, případně veškerá omezení PLx vypnout. Samozřejmě jde o nastavení vhodné pro overclockery, kteří adekvátně tomu zajistí chlazení CPU i napájecích obvodů základní desky. BIOSy také umožňují nastavit výběr limitů PLx podle toho, jaký chladič je na CPU osazen. Legrační je to v tom, že pro BOX chladič dodávaný s CPU je PL1 či PL2 limit často výrazně nižší než uváděný pro lepší chladiče.

Autor: David Ježek, podle licence: CC BY-SA 4.0

Nastavení PL limitů u MSI B460M-A PRO (aneb s BOX chladičem bude výkon CPU výrazně nižší)

Ale to není vše. Pro procesor, i kdyby optimálně napatlaný dokonalou teplovodivou pastou a osazený hi-end chladičem, bude stále platit, že pokud je provozován v místnosti s teplotou okolního vzduchu 18 °C, budou jeho limity jinde, než v místnosti s 28 °C. Ne vždy je teplota okolí v recenzích uváděna.

Nezapomeňme na výrobce a jeho zájmy

Do všeho ještě vstupuje jeden dosti podstatný faktor. Aby daný web měl recenzi produktu hotovu a vydanou v den a hodinu, kdy končí informační embargo a produkt jde na trh, musí jej mít zapůjčen minimálně o týden, lépe o dva dříve. To ve většině případů neznamená nic jiného, než zápůjčku přímo od výrobce, spolu s dalšími komponentami (v případě CPU řekněme ještě RAM, základní deska, chladič a případně i zdroj), včetně softwarové podpory (výjimkou není, že redaktor během prací a testu dostane nový firmware či ovladač, který u grafické karty řeší nějaký výkonnostní problém a najednou musí přeměřit všechny dosud získané výsledky).

Mohu z vlastní ruky potvrdit, že se stává, že vzorek produktu, který recenzenti na celém světě dostanou do ruky, je velmi výběrový kus křemíku, nejlepší z dosud vyrobených. Měl jsem kupříkladu před mnoha lety v testu grafickou kartu, jejíž GPU bylo schopno po celou dobu běhu držet frekvence až o 15 % vyšší než drtivá většina karet následně v běžném prodeji. Tím si výrobce GPU zajistil, že karta v recenzích vypadala lépe, než jaká byla realita trhu.

Čert vem, že reálné karty v prodeji byly pomalejší (a tudíž ne výkonnější než půl roku stará konkurence), v recenzích prostě vše vypadalo lépe a málokterý web si mohl dovolit sehnat kartu z běžného prodeje a věnovat týden práce redaktora přeměření. Efekt prvních recenzí po uvedení na trh už tím beztak nebylo možné plně zvrátit a usadit do skutečné reality.

Totéž jistě platí i pro CPU, která jsem typicky netestoval, ale mohu posloužit jedním příkladem: tam, kde většina uživatelů, včetně šikovných overclockerů, byla ráda, že má dobrou revizi daného CPU běžící ne na výchozích 3,4GHz, ale na 4,5GHz, byť s mírným zvýšením napětí, já měl k dispozici kus, který běžel zcela stabilně na 4,7GHz bez nutnosti zvyšovat napětí. Náhoda? Něčemu takovému už dávno nevěřím.

Softwarová stránka věci

Každopádně to jsme ještě ani nenastartovali operační systém. Držme se tedy prozatím uzavřeného softwaru, kde například CineBench R23 je jediná možná binárka, zkompilovaná samotným tvůrcem animačního programu Cinema4D. I Cinebench lze pouštět různými způsoby, resp. na různých verzích Windows s různými nástroji v pozadí. Dovolte mi vzpomenout dobu, kdy AMD přišla s procesory architektury K10 zvanými Bulldozer. U nich použila nový typ uspořádání CPU, kdy 8jádrové procesory měly 8 ALU jednotek a 4 FPU, vždy sdílené dvojicí CPU. Procesor se plně tvářil a choval jako 8jádrový, ale 8 plnohodnotných CPU jader ve smyslu, jaký by tehdy člověk očekával od x86 procesoru, měl-neměl. Však také AMD za toto schytala hromadnou žalobu u soudu.

Bohužel pro ní ale Windows, tedy zcela převažující operační systém, nebyl schopen si svým schedulerem optimálně poradit s novou CPU architekturou a tak Bulldozery vykazovaly nižší výkon, než bývaly byly mohly. Možná i proto se uvádí, že nadcházející procesory Intel Alder Lake ponesou hardwarový scheduler. Ale i toto je zkrátka cesta, která může vésti k tomu, že dané CPU v daném testu nevykáže reálně dostupný výkon.

Každý, kdo kdy pustil nějaký benchmark vícekrát po sobě, třeba i s rozestupem několika dní, či po aktualizaci Windows, jistě ví, že ani testy typu Cinebench nedávají vždy stejný výsledek. Rozptyl zde určitý je, i když jistě blíže ±0,5 %, než ±5 %.

Nicméně to je bezpečný klidný svět měřících nástrojů s uzavřeným zdrojovým kódem a jedinou oficiální binárkou. Náš svět Linuxu a open-source v tom dělá ještě řádově větší brajgl. Chcete místo Cinebenche použít Blender? Dobře, ale zkompilujete jej pomocí GCC7, GCC8, GCC10, GCC12? Nebo použijete Clang? A co LTO / PGO? A co -o2 či -o3?A poběží vám to pak na Ubuntu 16.04 LTS s Unity, nebo na Fedoře 34 s GNOME a Waylandem, nebo na Slackware s Pekwm, nebo na Intel Clear Linuxu? A jak budou kompilovány či připraveny ovladače grafické karty? Poběží to na X.Org, nebo na Waylandu?

Mimochodem, použijete konkrétní neměnnou verzi, nebo s každým dalším CPU nové denní sestavení? Protože kdy to bude neměnná verze, pak váš test nic moc nevypovídá, protože za poslední týden-měsíc-rok mohly do Blenderu přijít nějaké optimalizace na úrovni využití instrukčních sad / assembleru. Ale pokud vždy použijete nejnovější sestavení, nelze výsledky přímo porovnávat. Vlastně byste ideálně měli dělat obojí současně. A aby v tom nebyl rozptyl, tak ideálně vše změřit třikrát (či víckrát) a výsledky zprůměrovat / zahodit extrémy. A po vší té práci, kdy po dvou týdnech usilovného měření CPU budete chtít vše publikovat, můžete se slzou oku sledovat, kterak Blender vydal novou verzi s překopaným enginem a vy jste vše naměřili na verzi, která je odteď pouhou historií.

Příklad jménem ffmpeg

Multimediální balík ffmpeg je vděčným nástrojem pro testování. Čas od času vyjde v nové verzi, ale do toho je možné stahovat denní sestavení, případně si vše sám kompilovat z kódu třeba přímo z Gitu. Vzhledem k automatizaci, která je při znalosti syntaxe možná, je to ideální nástroj na dávkové provádění mnoha testů.

Já jsem v posledních dnech vyzkoušel mnoho různých měření s ffmpegem. Odpíchl jsem se konkrétně od Karášova testu z DIIT, u kterého prostým pohledem do grafů v recenzích zjistíte, že 12jádrový Ryzen 5900X vykoná test rychleji než 16jádrový Ryzen 5950X a je tudíž jasné, že vypovídací hodnota je poměrně malá.

Ano, ffmpeg je potvora, takže já mohu rovnou na úvod říci, že statický build přímo z webu projektu, který je sestaven s GCC 8.3 a běží od Linuxu 3.2 výše, neumí naplno vytížit 6jádrový/12vláknový procesor od Intelu (top hlásí vytížení kolem 650 %, když pustím dvě instance současně, je to kombinované vytížení na úrovni 1 050 %). Ale to odbočuji, v reálné situaci mi to nevadí, protože jsem zvyklý kódovat více videí současně a pouštím vždy dvě dávky ffmpegu ve dvou terminálech najednou. A možná to není problém ffmpegu, jako spíše x265.

Ale pojďme na konkrétní čísla.

S ffmpegem totiž narážíme na jeden zcela zásadní problém, který okomentujme hned na začátku: velikost výstupního souboru se s aktuálními verzemi balíku oproti verzi 3 roky staré liší, a to velmi výrazně. Blíže jsem tento fenomén nezkoumal, předpokládám, že došlo ke změně dílčích hodnot kompresních parametrů, které ffmpeg používá u profilu veryslow, případně kvalitativního parametru -crf 26, v testu použitých. Kromě toho, že se mezi verzemi pochopitelně liší využití schopností CPU, bude zde bezpochyby i visuální dopad. Starší build ffmpegu z roku 2018 zkrátka produkuje o 12 % menší výstupní video a stihne to za ±56 % času.

Dobře tedy, podívejme se na časy komprese testů, které produkují stejně velký výstup v podobném čase. I zde můžete vidět několik věcí. Tou první jsou různé hodnoty doby komprese pro tři různé buildy (dva pro Windows, třetí spouštěný na Mageie s jádrem 5.13.x). Ve všech případech šlo o tři měření spouštěná po sobě a ffmpeg v terminálu byl jedinou uživatelsky spuštěnou aplikací v OS. Rozptyl hodnot je od ~787 po ~808 s, tedy dá se říci, že měření dává výsledek zhruba 798±11 s, neboli 100±1,4 %.

K tomu si přičtěme rozdíl daný kvalitou napatlání procesoru teplovodivou pastou, možné jemné nuance v nastavení všech sw vrstev mezi „železem“ a ffmpegem, jemné rozdíly měření okolní teploty v místnosti a dostaneme se zkrátka k nepřesnosti měření v řádu ±jednotek procent. A to je prostě příliš v situaci, kdy se porovnávají CPU architektury lišící se výkonem do 10 %.

Druhý příklad, který si ukážeme, používá testy Cinebench R23 a GeekBench 5. Srovnávám s hodnotami, které má Ľubomír Samák ve svém nedávném testu procesorů 10400F a 11400F na Cnews.

Já provedl dvě měření v GeekBenchi. Nepřekvapivě mám dva různé výsledky, které se navíc liší od Ľubomírových. Stejné platí i pro CineBench. Na vině může být například základní deska (já nemám hi-end) a výkonnější paměti, případně chladič (ale to spíš ne, protože i já používám dobře dimenzovaný model od Noctuy).

Spotřebu za běhu nemáme porovnatelnou, Ľubomír měřil zcela jinak. Ale já mohu říci, že pokud PC s klidovou spotřebou 37 W a procesorem s PL1 limitem 135 W dosahuje během testu CPU v GeekBenchi spotřeby pouze o +7W až +71W vyšší než je klidová, něco je špatně a tento test nepochybně neprovádí plné využití CPU a tedy nevypovídá tolik o jeho možnostech. Pokud to proporčně platí i pro jakékoli jiné CPU v něm testované, budiž, ale vypovídací hodnota je tímto zanedbatelná.

Ostatně toto platí obecně: když CPU zatížím naplno, vzroste spotřeba mé sestavy z typicky ~36W na maximálně ~127W. Tedy o ~90W, a to u procesoru s TDP/PL1 na hodnotě 65–135W. Někde sedí žába na prameni. Je možné, že v softwaru, je možné, že v napájecích možnostech mé základní desky, je možné, že někde jinde. Ale pokud u testovacích sestav v redakcích, kde typicky mají drahé hi-end modely desek, toto není, vypovídací hodnota je pro daného uživatele s levnou deskou či BOX chladičem prakticky nulová.

Pozor na testy CPU (a GPU)

Nezřídka vídáte titulky článků jako Produkt X: o 3% vyšší výkon, o 5% nižší spotřeba než produkt Y. Nemusí to být vůbec pravdivý odraz reality. V lepším případě správné hodnocení toho, jak se produkt X bude chovat většině uživatelů, v horším případě informace s nulovou hodnotou. Jak s každou další generací roste komplexita moderních CPU, stále víc a víc se i nezávislé recenze těchto CPU vzdalují od objektivní pravdy. O recenzích webů poklonkujících danému výrobci samozřejmě nemá vůbec smysl se bavit.

Stále více je potřeba číst mezi řádky a pokud některé informace chybí, vypovídací hodnota klesá směrem k pouze orientační. Recenzent by měl uvádět hromadu údajů, třeba teplotu v místnosti v době testu, ukázka způsobu nanesení a typu teplovodivé pasty, dokonce i ukázka rozmístění komponent v té či oné skříni (ano, i to má zaznamenatelný vliv na výsledky měření), přesná softwarová konfigurace (v případě Windows zejména z hlediska aplikovaných aktualizací OS), počet provedených měření a metoda zprůměrování jejich výsledků a zejména věc, na kterou se často hřeší (a i já na ni v letech dávno minulých hřešil): čtenář by měl mít možnost plně reprodukovat daný test.

Čili veškeré podklady (video, audio, foto atd.) poskytnout včetně konkrétních verzí nástrojů, se kterými se testovalo. Fajnšmekrovina by pak byla u open-source testů uvádět i kompilační parametry, pokud není použit nějaký generický build daného nástroje.

Vlastně nejblíže ideálu je způsob, jakým jsou výsledky testů dostupné na Phoronixu / OpenBenchmarking. Zde si má každý možnost ověřit jakýkoli výsledek. Na druhou stranu díky tomu právě často vidíme, že někdy u daných dílčích aplikací dochází k regresi výkonu, kdy měření s novým linuxovým jádrem, případně nově zkompilovanou aplikací, vykazuje horší výsledek. Někdy jsou rozdíly minimální, případně medián všech měření nevypovídá žádný zásadní závěr pro uživatele hledajícího srovnání v nějaké určité oblasti (např. výkon v 3D renderingu).

Stále více a více ale platí: je třeba být obezřetný v přebírání závěrů autorů recenzí z posledních stránek jejich testů pro vlastní rozhodování o nákupu komponent. Spíše je dobré celou recenzi projít, konfrontovat ji s dalšími recenzemi téhož produktu a vyvodit si závěry vlastní.

Ono i platí, že pokud za pár týdnů nějaký recenzent dostane do testu nový Intel Alder Lake Core i9–12900K, bude očekávat určitý výsledek, takže se s ním může i spokojit na první dobrou a nezkoumat blíže, jestli zde není zádrhel v nějakém nastavení základní desky. Stejně tak až za pár měsíců dostane do ruky Zen 4, bude očekávat, že dopadne lépe a tudíž ani nebude měsíc poté na vzorku z běžného prodeje zjišťovat, jestli se takto skvěle nechoval jen jeho kus zapůjčený výrobcem.

Možností, jak může recenze dopadnout jinak než co nejblíže realitě pozdějšího běžného uživatele, je obrovské množství a významná část z nich ani není vinou cílené akce recenzenta.