Vcelku odpovídá, jen bych měl 2 úpravy - místo svahilštiny má být "indiánština" a po tom, co se ozve Intel se vše vrací úplně na začátek, ne jen patch final final patche :)

A ted uvaz, ze podobnej seznam ma manager, ktery ma na starosti rozhodovani ktere bugy se budou fixovat a ktere ne. Akorat ti chybi ta analyza na zacatku: podivame se na zavaznost problemu, kolik nas to bude stat, podivame se jaky potencial to ma rozdrbat existujici aplikace (vcetne 150 let starych MSDOS programu, co kdyby nahodou nekdo pouzival ucetnictvi z ejtys), a podivame se na prinos. Problem: par blbu si koupilo 8+jadro a nas scheduler z pleistocenu to nedava. Prinos: tem par blbum by to zvedlo vykon. LOL, dyt ti nerdi si stejne nainstaluji komunistickej linux, a jader maji tolik ze +- 10% vykonu si ani nevsimnou. Zaver: serem na to, nic se fixovat nebude.

Možná taky NDA jako u Melt, Specter a Zombieků u Intelu, prostě aby měl Mrkvosoft čas udělat nový scheduler, ale ten na to očividně dlabe tak proč to nevypustit do světa a svalit to vše na něj.

Můžeš přestat psát samé nesmysly?

Jestli můžu mluvit za sebe, já se směju tomu, jak vehementně řešíte, podle vlastních slov už 2 měsíce, v podstatě neexistující problém.

Resp. co jsem pochopil, kámošovi procesor funguje ke spokojenosti, naměřený je podle očekávání a jediný „problém“ je, že nějaká monitorovací aplikace ukazuje mírně nižší frekvenci než si představujete.

Tys tu psal hrozne kraviny.

Napr. si tu psal neco o tom, ze Ryzeny desive topi. Coz nebyla pravda, naopak recenze zminovali jako dost dobre provozni vlastnosti.

Proste faktem je, ze si slozil kamaradovi PC ze srackoidnich komponent, neoveril sis prave jak spolu funguji. Fungovali temer optimalne, ale ty si tu hulakal, ze chces ABSOLUT!!!

V tom tkvem tvuj problem. A co se ti tu lidi snazili vysvetlit. Specificky to, ze tvuj anekdotni dukaz nemuzes pouzit pro obecnou kritiku produktu AMD.

A proc to nereklo AMD drive? Ja osobne sazim na to, kvuli zachovani co nejlepsich vztahu s M$. Prvne asi zkusili zatlacit na vyvojare v M$ aby udelali konecne zmeny v planovaci. To se jim nepodarilo, tak postupne ladili svoje ovladace a nastroje. Ale nakonec narazili na dno svych moznosti a dalsi uz bezpodminecne musi byt na strane M$, proto prisli s tou zpravou. Kdyby se jim podarilo oblbnout kernel M$, nebo se s nimi domluvit, tak nemusi prat to pradlo na verejnosti a muzou to resit "manazersky" v ustrani :)

Pokud vím, tak
1. ti přihlouplí fanoušci se vám snažili dost pomoct a poradit a to i přes to, že se pořád chováte jako rozmazlený frocek.
2. co má co marketingové oddělení AMD dělat s tím, že v M$ jsou jelita a nedokáží porádně udělat svou práci?

https://www.youtube.com/watch?v=Eb520HkZQvo

Vzhledem k max. taktum u EPYC Rome (pod 3,5GHz) předpokládám, že asi není moc chipletů co by to nezvládlo. AMD má v nabídce i Epyc 8-core se 128MB L3 cache, což by teoreticky umožnilo vyrábět jej z osmi chipletů s jediným funkčním CCX disponujcím jedním funkčním jádrem (možná s ohledem na náklady bude sestaven ze čtyř chipletů s osmi CCX po jednom aktivním core). Uplatnitelnost chipletů bude tedy asi opravdu značná.

Myslím si, že k opuštění NUMA v rámci jednoho socketu u Epyc/Tr patrně přispěl velkou měrou svým neúsilím právě Microsoft. A za to bychom mu měli být vděčni. ;-)

To není práce navíc pro scheduler, je to ztráta procesorového času. Podobná jako context switching.

Minule se Microsoft bránil, že dostal vzorky a specs od AMD pozdě. Můžeme si o tom myslet cokoli, ale úplně stejně si AMD nevyřešilo scheduler v Linuxu (kde je spousta možností, jak má plánovač pracovat). DD tvrdil, že to si měla vyřešit firma LINUX (ty jeho hovadiny mi zůstávají v hlavě dlouho...). Ne, to si mělo vyřešit AMD, nikdo jiný. A i AMD to řešilo až po vydání. Nelze se tedy divit Microsoftu, že na tom byl podobně, když samotné AMD v tom mělo mezery.
Jiná věc je to teď, když je Zen na trhu už pěkně dlouho. Linux tyhle problémy už dávno nemá. Hádám, že Microsoft prostě nemá potřebu se přizpůsobovat, a pokud k tomu má skutečně takhle dřevácký přístup, AMD nezbývá, než ten scheduler oblbovat.
Zajímalo by mě, jak krkolomné je dostat do NT vlastní scheduler. Je mi jasné, že to bude v rozporu s licencí, ale dokázal by to vůbec někdo?

A jinak, pořád se bavíme o <5% výkonu, nic, co by potřebovala většina uživatelů řešit.

"Já to řeknu slušně, jo? NIC!"

Update na 1909 s tím neudělal nic, protože na jádro Windows vůbec nesáhl.

Intelu to taky nevyhovuje.

Treba si uvedomit, ze Microsoft je obrovska nabobtnana korporacia, v ktorej nezriedka este pracuju ludia, co programovali MS-DOS a Windows 3.11. A podla toho to tam aj vyzera.

Faktor cislo jedna v tomto pripade je, ze sa zatazuju falosnou spatnou kompatibilitou. Falosnou preto, lebo vsetci deklaruju, ze sa nieco neda zmenit aby to nerozbilo kompatibilitu s existujucim SW, ale v skutocnosti to, s cim by ten system mal byt akoze spatne kompatibilny uz davno nejde spustit kvoli tomu, ze zmeny inde v systeme ten program davno rozbili.

Samotna spatna kompatibilita nie je zla vec, ak by sa neudrzovala spatna kompatibilita so SW zalozenym na scestnych napadoch. Tym, ze su vo firme menezeri, co robili pred 30timi rokmi developerov, ma Microsoft tendenciu sklzavat k rieseniam, ktore su velmi tesne zalozene na probleme, ktory prave riesia. V dobe prvych dvojjadrakov s turbom asi riesili problem lokalneho prehrievania sa, tak to vyriesili takto "od podlahy" komunikaciou s BIOSom o tom, ktore vlakno sa da v zavislosti od teploty najviac vytazit. Na toto jednoduche riesenie nastokli primitivny scheduler a bolo dobre.

Jednak je to API medzi BIOSom a OS strasne zle, pretoze komunikuje velmi specificku informaciu, druhak je to API medzi dvoma vrstvami a tym padom je ho dost tazke zmenit. Asi by to trvalo roky... najprv musi Microsoft chciet, potom to musi navrhnut (co zasa bude site na mieru dnesnemu problemu pretoze Microsoft nevie riesit veci abstraktne, to nevedel naposledy ked kupili vyvojovy tim VMS aby im napisal NTcka) a potom este pre to musia urobit podporu ludia od BIOSov. Tipujem, ze na existujuci HW by nedoslo a podpora by sa objavovala pri medzigeneracnych obmenach dosiek. Ci uz CPU, chipsetu, alebo BIOSov.

Otazne potom je, ci primitivita toho schedulera bez akychkolvek middlewarov, ovladacov atd... dokaze vybrat najvykonnejsie jadro.

'' A proč to přehazování zátěže z jádra na jádro nejde vypnout? ''

protoze to ten primitivni microsofti scheduler neumoznuje a microsoft s tim zjevne nechce nic delat.. je fakt tak tezky tipnout si proc? ;)

Přehazovat je žádoucí, protože jinak by se opotřebovávalo jen jedno jádro. V článku to je, hned na začátku. Je však záhadou, že se opotřebovává jen ve Windows a v Linuxu ne :-)

Vědět proč to před řadou let vzniklo je fajn ;-).
Nicméně posledních pár let to již ani mobilním či desktopovým CPU Intelu nepomáhá, leckdy i poznateně škodí, a u HEDT platformy je to vyloženě hloupé a škodlivé.
U AMD to jejich procesorům nikdy nic pozitivního nepřinášelo, a u CPU Ryzen to škodí celou dobu co jsou na trhu.
Že Intel, narozdíl od AMD, si prozatím veřejně příliš nestěžuje, je fakt, že stávající "stoletý" scheduler škodí současným procesorům od AMD ještě o poznání více nežli těm Intelovským.
Microsoft to dobře ví, přesto ale na nevyhovující scheduler ve Windows v posledních letech nesáhl. Nejspíš právě tohle bude bude ten důvod proč mnozí, zdaleka nejen zde na Diitu, Microsoft kritizují. Řekl bych že stížnosti jsou zcela oprávněné.
Je jen otázkou, zda se "chlapci a děvčata" v Microsoftu konečně chytí za nos, a scheduler v dohledné budoucnosti předělají? Rád bych byl optimistou ;-) To je ale s MS dost těžké :-|

Ono CPU affinity si IIRC vie nastavit aj sam program, takze je mozne, ze niektore softy, co sa na multi package strojoch pouzivaju castejsie uz toto maju osefovane interne.