Vlákno 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 Martin Stransky - Testovani CPU na hrach je celkem k nicemu,...

Testovani CPU na hrach je celkem k nicemu, lepsi je testovat na realnych ukolech. Pro vyvojare napr. doba buildu kernelu:

https://openbenchmarking.org/test/pts/build-linux-kernel-1.16.0

Každému co jeho jest. K čemu je někomu test konpilace, když na tom reálně jenom hraje?

To se většinou nehodí do krámu. Například při stejné sestavě (Solidworks) - identické výpočetní úlohy a výsledky jsou úplně jinde. Když R7 7700X natrhne zadek R9 7950X i o 40 %, natož aby se měřil s W1390P, který to zvládne za polovinu času (doba, kdy člověk nemůže pokračovat v práci), tak se může člověk moc divit. Přepočet probíhá neustále (drobné změny jsou hned, přepočet struktury je zcela jiné kafe u velké sestavy).

Mě třeba nezajímají kompilace, nýbrž Solidworks, proto jako příklad dávám právě Solidworks. Důvod je prostý, R9 je prostě slepenec a interní logika to přehazuje (údajně z důvodu tepelné námahy) z jádra na jádro a protože přepočet volných ploch, struktura ... nemůže běžet na více vláknech, rozhoduje to jedno jediné a jak dobře to mají udělané.

Co myslíš tím interní logika?

Z jádra na jádro něco může přehodit jen OS. To co myslíš bude komunikace mezi jádry kvůli konfliktu k přístupu do paměti. V praxi může vlastnít jen jedno jádro jednu cache-line pro write přístup v jednom čase, a tady je většinou problém.

Ale... Ty ostatní CPU to mají taky. Intel Hybrid to má stejné a Apple Silicon taky. Každý CPU to stojí různé cykly, atd... ale nedá se to úplně odstranit. A přístup AMD je lepší než dělat drahé monolity.

To se většinou nehodí do krámu.
Komu myslíš, že by se to nemělo hodit do krámu? Recenzentům obecně (cui bono?), nebo Davidu Ježkovi?
Nebo tobě do vašeho Solidworks krámu?

27. 10. 2024, 12:34 editováno autorem komentáře

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.

Nesmysly o líných programátorech, Intel lobby, chybějících optimalizacích, teoriích o mučení zákazníků, … se táhnou hluboko do minulosti. Většinou takové debaty končí absurdním návrhem přechodu, bez ohledu na celý dodavatelský řetězec (PLM/PDM). Potíž je v tom, že ono to vlastně nejde jinak udělat už v samotném principu. Těžko zahájíš XY návazných výpočtů bez znalosti předešlého výsledku. Úspěšně se zdokonaluje paralelizace, rychlé výpočty, větvení apod. ale ne všechno jde udělat, protože některé přepočty zkrátka probíhají chronologicky v přesně stanoveném pořadí. Tak tomu vždy bylo a bude. Zcela stejně to bude počítat i Catia, Creo, nebo NX.

V minulosti, poté jsem to přijal jako fakt a dál se po tom nepídil. 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. Přetaktuj a poznáš to ještě rychleji. Při běžných přepočtech si toho moc nevšimneš, ty jsou hned, ale pokud potřebuješ přepočítat celou strukturu stromu u opravdu velké sestavy, potom velice rychle pocítíš sílu krále W-1390P (v minulosti kralovala dlouhé roky i7-2600k). Zajímavé je, že TR 1920x s tím problémy neměl, vlastně ani nové generace TR neprovádí žádný jaderný ping-pong. Děje se tak pouze u Ryzen 9.

Popravdě řečeno, já už to ani zkoumat nechci. U pracovní stanice stejně moc na výběr nemám, tam jde o certifikace (jak to nemá certifikace, tak se podpora nepřetrhne) a přirozeně stabilitu v produkčním prostředí. Chybí mi motivace, natož čas. HP Z2 mám prakticky novou, domů jsem si pořídil R5-8600G a už se tím nezabývám. Právě pracovní stanice Integra s on-site a ISV certifikací postavené na Ryzen 7/9 mi nabízeli, po vyzkoušení jsme se dohodli na HP Z2 a tím to pro mě skončilo. Podobně jak už neřeším, proč na HP 845 s Ryzen Pro nefungují sériové Socomec (stejně se to chová na T14 – pošahané USB-C).

Nechce se mi to zkrátka řešit, servery mám dlouhé roky na AMD (Tyan) a jsou zlaté, ale jak jde o pracovní stanici, nebo NTB a potřebu připojovat měření, převodníky, tak je Intel jednoznačnou průmyslovou volbou.

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.

My počtáři víme že při počítání primegrid multithread llr tasků na CPU 5950X je při počítání na všech jádrech oproti počítání 2 tasků přiřazených na jednotlivá CCD (2) ztráta cca 20% výkonu.
Proto si myslím že AMD uvádí zákazníka v omyl tvrzením že se jedná o 16ti jádrový procesor.
Naopak by měla tvrdit že to jsou dva 8 jádrové procesory a taky by se měly tvářit tak transparentně pro OS jako 2 nodes. Někde se k této informaci dá v systému dobrat ale je to dost dobře schované a ani linuxový scheduler se podle toho neřídí.
Pro Windows existuje program který umí vyčíst konfiguraci socketů, nodů atp. a dle toho přiřazovat aplikace ke správným jádrům a nazývá se Process Lasso.

27. 10. 2024, 22:41 editováno autorem komentáře

Nejbližší standardizovaná věc s více "nodes" je asi NUMA, ale to je trošku jiná záležitost, která řeší primárně lokalitu a adresaci paměti. Na některých EPYCech se dá přepnout nastavení L3AsNumaNode, kdy to fakticky udělá pro každý čiplet jeden node a bude to nejspíš míněno přesně na nějaké aplikace, co mají detekci NUMA nodů a specificky to třeba seskupí workery, které pak využijí sdílenou L3 cache a menší latenci v rámci CCX.
Viděl jsem to např. na severu s Milan 7003 EPYCy, ale nepoužívám to.

Jinak programově se dá topologie systému včetně všech úrovní cache dá zjišťovat třeba přes hwloc, resp. libhwloc.
https://www.open-mpi.org/projects/hwloc/
To bylo, podle mě, právě vymyšleno pro multiplatformní výpočetní aplikace tak, aby nemusely každá individuálně řešit runtime detekci topologie na různých systémech, platformách. Mimo CPU to podporuje i detekci dalších výpočetních zařízení přes různá API (CUDA, ROCm, OpenCL).
Ale nejsem "počtář" ;)

Problem je, ze pan Jezek tehdy testoval "příslušnou nově uváděnou hi-end GeForce (tuším, že to tehdy byla GTX 980)" a myslim, ze hry, respektive vykon v nich, jsou jedna z veci, co lidi u prislusnych uvadenych high-end GeForce velice zajimaji.

Hry jsou reálný úkol pro drtivě větší množství lidí než počet vývojářů :-) . Navíc potenciálně testují větší část CPU, jako komunikace s externími prvky (paměť, GPU), což je pro některé cílové skupiny významný faktor.

Kompilace kernelu je naopak značně omezená na malou podmnožinu celočíselných aritmetických, logických a store/load instrukcí.

U videa bude nejspíš zase hrát roli efektivita SIMD a k dřívějším poznámkám - můj i5 bez AVX-512 je rychlejší než o generaci starší i7 s podporou AVX-512 .

Takže záleží na použití. Ale většině to asi bude celkem jedno.

Ma vubec to testovani graficke karty kompilaci jadra nejaky smysl? Pouzivaji kompilatory nejakou GPU akceleraci? Kupuji si jaderni vyvojari herni graficke karty a da se cekat, ze clanek, ktery se zabyva kompilaci jadra s GTX 980 nebo GTX 960 nalaka dost jadernych vyvojaru, aby mel nejakou ctenost?