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 - Jinak ještě k tomu výraznému rozdílu v Solidworks,...

Jinak ještě k tomu výraznému rozdílu v Solidworks, co zmiňuješ. Vzpomínám si, že jsi psal pár let zpátky víceméně to samé, akorát tam byly starší generace CPU od AMD a Intelu.

Nezkoušel jsi tomu nějak víc přijít na kloub?

Jestli jsem to pochopil správně, kdyžtak mě oprav..
Solidworks resp. Parasolid, má určité operace, které jedou jednovláknově (znám podobné vlastnosti například u Autodesk Maya, kde je to kombinace stáří enginu a neoptimalizace v době vzniku a principiálních věcí, které souvisí s tím jak je tam udělaná konstrukční historie - což je obdoba feature tree u CADů).
Tvé výsledky jsou, že na AMD procesoru s více CCX (čiplety) zabere stejná operace 100 % času, na AMD ze stejné řady/generace a jedním CCX pak 60 % a na porovnatelném Intelu pak 50 %.

Ten razantní propad výkonu s více CCX je zarážející, protože je opravdu hromada praktických a testovaných jednovláknových úloh, co nejsou citlivé na latenci (kam patří i tyhle výpočty), kde tahle architektura žádný zásadní výkonový dopad nemá, proto bych mluvil spíš o anomálii.

Platí opravdu to, co psal @cc, tzn. scheduling threadů provádí čistě OS. Sice k tomu, kde co poběží, bere informace i od firmware (např. podle typu jader i aktuálního stavu frekvencí, teplot) a samotných aplikací, ale není to nic schovaného.
Migrace threadů mezi jádry se dá velice dobře monitorovat. Ať už třeba obyčejným Task Managerem ve Windows při jednovláknových úlohách, kde je to znatelně vidět (není to až tak často), až po exaktní trasování a záznam se systémových senzorů (WPT, WPA - Windows Performance Toolkit, Analyzer).
To že se to přehazuje mezi jádry, aby na CPU nevznikaly hotspoty, je standardní věc, kterou dělá i můj 10 let starý Haswell.
Kde by to teoreticky mít vliv mohlo, je případ, kdy by systém přehazoval thread na jiné CCX a nastávaly tam situace, kdy by se zhoršilo využití L1 a L2 cachí.
Abych si tuhle hypotézu s konkrétním workloadem případně potvrdil, tak bych uměle omezil scheduling jen na jádra v rámci jednoho CCX.
To by mělo být jednoduché, pokud se zjistí která logická CPU jsou na kterém CCX, tak potom buď spustit Solidworks přes příkaz start /affinity něco program, nebo i za jízdy přes Task Manager.
Potažmo se v určitých případech dají dokonce v Ryzen Masteru určitá jádra kompletně vypnout (což může mít pak samozřejmě vliv i na vyšší frekvence těch ostatních).
Jestli to bude tímhle, tak by ses měl dostat na víceméně stejné hodnoty jako na tom AMD CPU s jedním CCX.

Kdyby se to potvrdilo, bylo by asi na místě zakomunikovat a tlačit na Solidworks. Velice podobné problémy se řešily třeba pár lety u DAW aplikací, kdy se objevily CPU s více čiplety, různě dynamicky taktovanými jádry a později i hybridy s různými typy jader (E, P cores).
Běžná DAW má při běhu třeba stovky threadů, přičemž jen některé jsou velmi kritické na latenci zpracování a použití cache. Takže zjednodušeně řečeno šlo tam o to, zjistit si topologii procesoru a správně hintovat ty důležité thready, aby je systém nepřehazoval mezi CCX a na ty pomalá jádra.
Doplnění programů o správné nastavení affinity u workerů a používání SetThreadIdeal­Processor() s těmito workloady evidentně pomohlo.
Další věc s výkonem Ryzenů byla, že okolo r. 2019 zlepšil Windows 10 scheduler. Ten pak respektuje CPPC2 z firmware, co hintuje aktuální preferovaná jádra (z hlediska teplot, taktů).

Možná by stálo za to se v tom trochu pošťourat a zkusit s tím u SW také pohnout. Počítám že to bude podobné jako třeba u té Mayi, tam je potřeba na jednom stroji v různých situacích jak jednovláknový, tak vícevláknový výkon. A odpískat si celou řadu CPU jen kvůli mizerné optimalizaci programu je škoda.