Názor k článku Fenomén CPU Intel: výsledky testů značně různé, v čase nárůst výkonu i o desítky procent, Arrow Lake je tu od msmucr - Já to s tím starým jádrem myslel primárně...

Já to s tím starým jádrem myslel primárně k té Maye, protože je tam v určitých aspektech dost podobností, díky té její plné konstrukční historii se při určitých operacích taky ten strom propočítává celý. Zároveň ale jsou tam místa, která by se evidentně daly vylepšit, protože konkurenční programy s novějšími jádry se škálují výrazně líp a tam bych to skutečně přisoudil spíš tomu, že ten vývoj sahá do 90. let, existuje spousta doplňků, co s ním určitým způsobem interagují a ty změny by musely být opravdu výrazné.
Taky mi je jasné, že ten základní software se nedá jednoduše vyměnit a je tam spousta aspektů. Pro naše použití se to dá naštěstí docela v pohodě kombinovat, takže třeba větší scény nebo vrstvy s částicovými systémy (kouř, sníh, déšť atp.), kde už to fakt mohlo hnije, se dá udělat v jiném softu a spojit třeba až na úrovni společného rendereru. Což beru s CADem integrovaným do nějakého prostředí moc dobře nejde.
A taky chápu, že ne všechno se dá paralelizovat, viz i třeba ty zmíněné případy se zpracováním zvuku, kde máš na určitých místech prostě za sebou sériově zapojené alogritmy, které nemá smysl pouštět ve více vláknech.

Ale o.k. to, že je to nějaká jednovláknová úloha je daná charakteristika, nemělo být meritem toho předchozího postu, a taky čert vem značky (je mi to jedno, používám oboje podle potřeby), ale mě prostě zarazil na AMD ten rozdíl s těmi dvěmi CCXy.
Opravdu tohle není normální, že by se nad tím dalo jednoduše mávnout rukou, pokud by to byl obecný problém, projevilo by se to i ve většině jednovláknových úloh, což tak není.

Můžeš v sheduleru přiřazovat natvrdo co chceš, ale jakmile to začne tepelně namáhat jedno jádro, tak ti to začne lítat mezi vlákny jak horká brambora.
Je to obráceně, vlákno (s výpočtem) kdyžtak migruje mezi jádry. Při context switchi, se prostě rescheduluje jinam - ale jen tam, kde má hlavní proces nastavenou affinity, jinam z principu nemůže. Ano konkrétní jádro pro scheduling může být podle určitého algoritmu "doporučené" ze samotného CPU (přes CPPC2) na základě aktuálních provozních vlastností i třeba s ohledem na ty hotspoty (což mají dnes víceméně všechna vícejádrová CPU). Ale, a to je hlavní point, můžeš to ovládat - pokud vlákno "zapinuješ" třeba na prvních 8 jader (ať už si to řeší sama aplikace, nebo třeba natvrdo zvenku), systém to nikdy nebude schedulovat jinam. Ať už budou na těch vybraných jádrech jakékoliv teploty, poběží to pořád jen tam.
To zmíněné CPPC2 přišlo, myslím, později než první generace TR, takže jestli je to tohle, co tam případně dělalo u R9 neplechu, tak by to i vysvětlovalo, proč bys tím TR 1920x neměl problém.
A všechno zmíněné se dá vcelku přesně monitorovat.

Ale nic, jestli jsi přesně tyhle pokusy už dělal, a třeba nějakým opakovaným testem s těmi samými operacemi to vůbec nic nehodilo, tak asi smůla.
Mě to jen prostě přišlo, že ty problémy téměř přesně sedí na věci, které se řešily třeba okolo r. 2019-20, když se víc rozšiřovaly Ryzeny a TR s více CCXy, a dodavatelé různých softů dělali aktualizace, aby to líp chodilo na těchhle konfiguracích.
Nemyslím, že to byly nějaké zásadní zásahy do logiky těch softů, jak jsem psal, tak to v podstatě znamenalo přidání nějaké runtime detekce a případné správné maskování jader a značení vláken tak, aby to nelítalo napříč CCX.