Operační systém Windows má jednu slabinu. On jich ve skutečnosti bude mít víc, ale tentokrát budeme mluvit o jedné konkrétní, která má vztah k dnešnímu tématu a která přivádí k šílenosti už několik generací informovaných uživatelů. Jde o systém, kterým Windows přehazují zátěž z jednoho jádra na jiné. Logicky správně systém vychází z předpokladu, že je-li jedno jádro procesoru příliš zatížené, bylo by vhodné zátěž rozdělit mezi nevytížená jádra. Je však pod jeho rozlišovací schopnost, zda je jádro zatíženo více procesy nebo jedním náročným, takže i v případě, že jde o jeden proces, jej začne přehazovat na různá jiná procesorová jádra.

To s sebou nese několik problémů. Asi první zásadnější, který byl objeven před mnoha lety, vyplýval z faktu, že když OS přehazuje zátěž z jednoho jádra na druhé, nemůže žádné zůstat po rozumně dlouhou dobu uspané a procesor má pak zbytečně vysokou spotřebu, aniž by to mělo reálný přínos. Microsoft to tehdy neřešil přepracováním scheduleru, ale rozhodl se ponechat zmatený scheduler bez změny a zavést záplatu v podobě systému označeného jako core parking. Pokud je jádro nevytíženo, dojde k jeho zaparkování (uspání) a na zaparkované jádro není přehazována zátěž zmateným schedulerem. Nedokonalý core parking pak přinesl vlastní problémy, když zprvu nedokázal rozlišovat mezi jádry v rámci jednoho modulu Bulldozeru a mezi vlákny v rámci různých modulů Bulldozeru, takže pro změnu degradoval výkon, když umožňoval odparkovat další jádro až po zatížení obou jader v rámci předchozího modulu. Jádra v jednom modulu měla sdílenou FPU, takže z hlediska výkonu logicky bylo žádoucí, aby se nejprve vytížilo jedno jádro v každém modulu (aby byly optimálně využité FPU) a teprve potom se začala vytěžovat jádra sdílená.

Potíže způsobené bláznivým schedulerem OS Windows se ale vyskytují dosud. U předchozí generace Ryzenů postavené na modulech Zeppelin tu byl jiný problém. Scheduler Windows není schopný rozlišit mezi vláknem v rámci jednoho jádra, vláknem v rámci různých jader, nerozliší vlákna v rámci jednoho CCX nebo různých CCX, nerozliší mezi vlákny v rámci jednoho křemíkového modulu a dvou modulů. Když tedy scheduler začal u čtyřmodulových Threadripperů přehazovat zátěž mezi jádry různých modulů, musel se spolu s vlákny stěhovat i obsah cache pamětí z jednoho modulu na druhý. Toto neustálé a zbytečné přesouvání dat dokázalo zkonzumovat až 50 % výkonu (času) procesoru, takže se v mnoha aplikacích vůbec neprojevoval výkonnostní potenciál architektury. Princip tohoto problému začátkem roku izoloval Wendell Wilson, který přišel i s nápadem, jak bláznivý scheduler oblbnout a přehazování zastavit. Tím v kritických aplikacích stoupl výkon Threadripperu pod Windows až na dvojnásobek.

• CorePrio až zdvojnásobí výkon Threadripper 2990WX [video]

Jak se zdá, s potížemi kolem nemocného scheduleru OS Windows hned tak nebude konec. S vývojem vícejádrových procesorů přišli výrobci se způsobem jak otestovat a označit kvalitu jednotlivých jader. Stejně jako existuje variabilita výrobního procesu na úrovni jednotlivých čipů, tak se variabilita projevuje i na úrovni jednotlivých jader. Některá zvládají vyšší takty, jiná nižší. Některá si při konkrétním taktu řeknou o více energie, jiná o méně.

Jenže scheduler Windows, který nepozná ani zda jádro leží v jednom křemíku nebo jiném, natož jestli je v jednom CCX nebo druhém, je k nějakému rozlišování kvality jader slepý a hluchý.

Známý tuner a overclocker 1usmus si na dvanáctijádrovém procesoru Ryzen 9 3900X všiml, že když dojde na zátěž omezenou na minimum jader, nejen že ji scheduler Windows přehazuje z jednoho jádra na druhé, ale navíc že - přinejmenším v jeho případě - ji přehazuje mezi kvalitativně nejhoršími jádry. To znamená, že část výkon je sežrána přehazování, část tím, že je provozována na jádrech, které nezvládají nejvyšší takty a další část tím, že tato jádra mají vyšší spotřebu než ta nejlepší, takže může být teoreticky dříve vyčerpáno TDP určitého jádra nebo CCX (případně dosaženo limitní teploty daného kusu křemíku), což může mít zpětně negativní dopad na taktovací frekvence.

Pro upřesnění je nutné říct, že samotného problému si nevšiml nyní, ten je v obecnější rovině známý docela dlouho a v dubnu letošního roku přišla informace, že aktualizace Windows 10 pro druhé pololetí by ho měla řešit. Protože se desítky v příslušné konfiguraci dostaly do rukou tunera 1usmus, měl možnost si toto vylepšení otestovat a zjistil, že téměř nic neřeší a problém přetrvává.

Připravil z toho důvodu vlastní záplatu pro Windows 10 a Ryzen 3000 (Zen 2), kterou implementoval jako vlastní „Power Plan“ a poskytl ho uživatelům. Řešení způsobí, že Windows přestanou chaoticky přehazovat zátěž z jednoho jádra nízké kvality na druhé jádro nízké kvality, ale budou zátěž o nízkém počtu vláken držet primárně na jádrech vysoké kvality:

Toto samo o sobě způsobilo, že při vyzkoušení v jednovláknovém testu CineBench běžel procesor (bez jakéhokoli přetaktování) na frekvenci o 200 MHz vyšší než před zásahem (4380 MHz -> 4580 MHz).

Podle autora dochází k nejvýraznějšímu zlepšení na Ryzenech 3000 složených ze dvou kousků křemíku. I u Ryzenů 3000 z jednoho křemíku může vylepšený Power Plan přinést zlepšení, ale je méně výrazné.

Pokud tedy nějaký ten Zen 2 / Ryzen 3000 na Windows 10 provozujete, můžete 1usmus Ryzen Power Plan vyzkoušet.

1. Stáhněte archiv

• odkaz (na web TechPowerUp, kde je uložen - stáhnete vlevo tlačítkem Download)

2. Nainstalujte

• rozbalte archiv
• spusťte „install.bat“ (zařadí 1usmus Ryzen Power Plan do nabídky Windows 10)

• v ovládacích panelech najděte možnosti napájení a v nich vyberte „1usmus Ryzen Power Plan“ (je možné, že nabídku bude potřeba rozkliknou)

3. Restartujte s zkontrolujte nastavení BIOSu

Aby vše fungovalo, je potřeba, aby byly následující položky nastavené níže uvedeným způsobem. Najdete je pod „CPU Features“ nebo „AMD_CBS“:

• Global C-state Control = Enabled
• Power Supply Idle Control = Low Current Idle
• CPPC = Enabled
• CPPC Preferred Cores = Enabled
• AMD Cool'n'Quiet = Enabled
• PPC Adjustment = PState 0

Pokud tyto položky v BIOSu nemáte, je pravděpodobné, že jsou skryté a ve výchozím stavu nastaveny správně.

Po uložení a restartu by vše mělo fungovat. Na základě dosavadních zkušeností uživatelů je však možné, že se zlepšení plně projeví jen pokud máte na desce BIOS AGESA 1.0.0.4 (nikoli starší).