To, ze Windows neskaluje s vyssim poctem jader se vedelo od dob, co nekdo zkusil dual-xeon - nevim zda se konkretne jednalo o 48/96, 56 jader nebo tech 72/144 z Phi. Tj. cca v 2017 :-)

no rozhodne je to prijemnejsi odhaleni, kdyz je procesor v poradku a chyba je v software a oprava jej zrychly nez naopak, kdy treba meltdown a spectre je v procesoru a oprava to zpomali :)

Ted už jen chybí aby to někdo přetestoval na e-zinech a poupravil tak ty dosavadní příšerné výsledky.

Budeme-li postupovat dle rozsahleho uvodu v clanku, muzeme odhalit i duvody, proc to na Windows nefunguje a Microsoftu je to jedno. Autor se nad tim uz ale nezamyslel.

Epyc temer nikdo pod Windows nepouziva, servery a tedy i serverove procesory se pouzivaji skoro vyhradne na linuxu, BSD apod. Dost mozna ani Microsoft ve Windows oddeleni zadny Epyc k dispozici nema, k cemu.
TRipper vcelku nikoho nezajima, procesor je na okraji zajmu konzumentu a porizuji si ho predevsim fanousci AMD nebo ti, kteri spoustu jader potrebuji do specializovanych aplikaci a tech mnoho neni. TRipper opravdu neni procesor mainstreamu a tudiz zajem Microsoftu je slaby.
RyZen podobny problem nema. v soucasne dobe ma nejvic 8 jader a ocekava se RyZen 9 generace 3000, ktery by mel mit 16 jader a to je maximum co Windowsy umi.

Zaroven to tedy muze byt i urcitym poucenim pro AMD (fanousci se moc poucit nedaji ikdyz by to nekdy bylo treba), ze zvysovani poctu jader neni vsechno a pro Windows uz AMD v nasledujici generaci dosahne stropu. (AMD to i pravdepodobne vi, protoze z uniku to zatim vypada, ze AMD u nasledujici generace RyZenu vyznamne navysila i IPC, tudiz presne to co je pro Windows potreba.)

Srovnání v prostředí bez limitace Windows, tj na Linuxu. Cenově mírně dražší i97980xe dostává výrazně na frak. A to jen díky operačnímu systému. Nikdo neřeší škálování multivláknových operací samotných aplikací. Takže rezervy ještě budou.
Kvalitní test - recenze:
https://techgage.com/article/linux-performance-amds-threadripper-2990wx-...

Ale problém závisí kravy málo jadro Linux v roku 2013. A toto je ono(článok dnes o Windows a článok o jadre Linux z roku 2013). To samozrejme.e odhaľuje prečo Linux expert vie problém MS Windows opraviť, a aj po premietaní, to stále nestačí..

Dalším experimentováním, kdy různými metodami zasahoval do způsobu, jakým Windows využívají jednotlivá vlákna, přišel na to, že ač OS reportuje všechna jádra procesoru jako vytížená, je ve skutečnosti polovina výpočetních prostředků zkonzumována na jakýsi řízený chaos, kdy OS přesouvá vlákna z jednoho jádra na druhé a zpět
https://diit.cz/clanek/coreprio-az-zdvojnasobi-vykon-threadripper-2990wx

4 March 2013
There's also a scheduler patch to fix a "bouncing cow" problem by when running fewer processes on the system than number of processor cores, the process could be bounced around between cores and yield poor performance. This bouncing cow fix for the scheduler yields a performance boost by 15x in a worst-case scenario. More work will come to future Linux kernel releases.

https://www.phoronix.com/scan.php?page=news_item&px=MTMxNzA

Coreprio Can Help AMD Threadripper Windows Performance, But Linux Still Leading Performance Race
Written by Michael Larabel in Operating Systems on 6 January 2019.
https://www.phoronix.com/scan.php?page=article&item=windows-coreprio-lin...

Edit:
ešte kúsok viac

A relatively simple scheduler patch fixes the "bouncing cow problem," wherein, on a system with more processors than running processes, those processes can wander across the processors, yielding poor cache behavior. For a "worst-case" tbench benchmark run, the result is a 15x improvement in performance.

https://lwn.net/Articles/538101/

A ten patch(oprava) je úchvatný..riadky začínajúce
- sa vymažú
+ sa pridajú

- int cpu = smp_processor_id();
- int prev_cpu = task_cpu(p);
struct sched_domain *sd;
struct sched_group *sg;
- int i;
+ int i = task_cpu(p);

- /*
- * If the task is going to be woken-up on this cpu and if it is
- * already idle, then it is the right target.
- */
- if (target == cpu && idle_cpu(cpu))
- return cpu;
+ if (idle_cpu(target))
+ return target;

/*
- * If the task is going to be woken-up on the cpu where it previously
- * ran and if it is currently idle, then it the right target.
+ * If the prevous cpu is cache affine and idle, don't be stupid.
*/
- if (target == prev_cpu && idle_cpu(prev_cpu))
- return prev_cpu;
+ if (i != target && cpus_share_cache(i, target) && idle_cpu(i))
+ return i;

/*
* Otherwise, iterate the domains and find an elegible idle cpu.
@@ -3284,7 +3277,7 @@ static int select_idle_sibling(struct task_struct *p, int target)
goto next;

for_each_cpu(i, sched_group_cpus(sg)) {
- if (!idle_cpu(i))
+ if (i == target || !idle_cpu(i))
goto next;
}
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commi...

Podle toho politického* úvodu by ten, komu umíraly krávy, měly být AMD s Microsftem. Opravdu obviňovali ostatní jak je naznačováno?

*Aby bylo všem jasné, kde je dobro a kde zlo:-)

P.S. Ten výraz "oversimplified" IMO perfektně vystihuje snahu webů s HW a SW zaměřením o zasáhnutí co nejširšího publika, tak pozor, aby to nebyla také střelba do vlastní nohy(ten úvod je možná vtipný, ale určitě je zjednodušující). Například: nechtějí Amazon=nechtějí pracovat, zaručené důvody proč telefony hoří atp.

A nebo Intel namazal, aby se neopravovalo, dokud to nebude vadit i jemu ;) Nebylo by to poprvý.

Chybí ještě jeden dílek skládačky aby to celé dávalo smysl. Proč 28/56 xeony v těch problémových aplikacích (třeba to Indigo) nad 16 jader škálují síce hůře, ale škálují, kdežto AMD vůbec, nebo dokonce škálují záporně?

Microsoft resi v aktualizacich 10 dulezitejsi veci jako je realne/efektivni vy-rizeni velkeho poctu jader, k prikladu znovu asociace souboru s MS aplikacema, vetsi spehovani, mazani uzivatelskeho nastaveni, 10 sou jednoduse sračka.