Vlákno názorů k článku AMD mění memy ve skutečnost. Výkon Zenu 5 se zlepší s budoucími aktualizacemi Windows od Pavka - Ryzeny 9000 mají v linuxu výrazně vyšší výkon....

Je to o dost složitější. Když člověk kouká na testy na Phoronixu, tak jsou to z většiny úplně jiné aplikace než se testují na Windows, i dost jiný charakter softwaru. A taky třeba ten Phoronix test suite se snad kompiluje ze zdrojáků, takže je to jiná situace, než když se spouští třeba tři roky stará binárka, která je "agnostická" (nebo optimalizovaná pro Intel...). Čili dost může dělat až ten software, ne OS. A i rozdíly ve výkonu OS (naměřené, když běží stejný software) nemusí úplně jednoznačně být způsobené tím, že jsou Windows pomalejší nebo "scheduler CPU" blbější, jak se často předpokládá. Windows toho obvykle dělají víc na pozadí (pod Linuxem typicky nebudete mít spuštěný antivir, například). O trošku horší výkon aplikace zase může být tím, že Windows můžou být víc vyladěné na responzivnost UI, aby se dalo dál pracovat, i když máte vysokou zátěž procesoru, protože jsou v prvé řadě mířené na klientské PC, zatímco Linux na server.

Pokud jde o tenhle konkrétní případ té "opravy" predikce větvení, tak to nebude záměr určitě. Ale byl bych hodně opatrný i s "bugem". V médiích se to tak objevilo a nejmenovaná konkurence píše, že ve Windows "nefunguje korektně predikce větvení", ale to je IMHO nepochopení, hlavně protože ze začátku chyběla informace, o co vlastně jde.

Predikce větvení v tom CPU samozřejmě normálně funguje, protože do té OS procesoru nekecá. Kdyby prediktor nefungoval, tak jde výkon do kolen tak, že by lidi, co se jim Zen 5 zdá jako fail, teprve koukali :)

O co tady jde, je něco jiného: že pro Zen 5 (a ukazuje se, že Zen 3, Zen 4 taky) není úplně optimální ošetření chyb Spectre. Ten problém není o tom, že by špatně fungovala predikce větvení, týká se jenom toho, jakým způsobem OS řídí invalidaci obsahu těch BTB, což jsou cache používané prediktorem větvení. Pomáhají mu pracovat s vyšším výkonem a lepší přesností, ale tenhle "natrénovaný" stav prediktoru se dá zneužít k těm známým spekulativním útokům. Proto jak Linux, tak Windows při přepínání procesů a při přepínání mezi jádrem a běžícím procesem pošlou signál, aby se všechno z těch BTB vymazalo a začalo se s čistým listem. Po tomhle vymazání ale má prediktor chvíli horší výkon, než se zase "naučí". Nějaký výkon se při tom tedy vždycky kvůli té bezpečnosti ztrácí. MS se stejně jako vývojáři Linuxu snažili to nějak zmírnit, jak se dalo.

Jenže to ošetření těch spekulativních útoků vznikalo v době prvního Zenu, Zenu 2 a nejspíš měl jako majoritní dodavatel větší důležitost Intel. A když kontrolovali, aby to moc neubližovala Ryzenům, tak to bylo testováno na o dost starších jádrech, tudíž to vyladění z tehdejší doby nemusí být dnes optimální.

K čemu dochází teď, je že Microsoft vyvíjí/vyvinul alternativní codepath, který je vyladěný na to, aby měl co nejmenší propad výkonu na procesorech AMD, a bude se používat novějších CPU od AMD. To znamená, že je to nový kód, ne oprava bugu, trvá nějakou dobu to vyladit, aby to fungovalo co nejlíp, pak se to musí testovat, a opravit chyby. Je to dost důležitá věc, takže se to nedá moc uspěchat. Není bůhvíjak divné, že to chvíli trvá a že se do dostane do reálného nasazení pozdě. Při vývoji Linuxu některé změny taky nejsou schopné dostat se do mainline klidně roky.

To je zjednodušené vidění IMHO. Je OS, který míval/mívá problémy s tím, že GUI zadrhává až mrzne, když uživatel přesouvá z disku na disk obří soubor, protože to zabere paměť přes diskovou cache. Nebyly to Windows...Stejné ladění, které tohle způsobovalo, možná vzniklo proto, že v určitých benchmarcích díky tomu byl o 2% vyšší výkon...