Názory 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

Takze ak tomu rozumiem. Je to pomalšie ako predchádzajúca generácia. Je to rovnako drahé ako AMD ktoré je rýchlejšie a zároveň to žere násobne viac ako AMD a ako bonus to má peticu pre jednu generáciu. Či niečo som zle pochopil?

Tak hlavně malá jádra mají za pár let skončit, pak se to třeba normalizuje.

https://diit.cz/clanek/konci-intel-s-malymi-jadry-planuje-eliminaci-do-3-4-generaci

Třeba se zbaví těch e-cores ještě dřív než bude AVX10 aka AVX2 v novém kabátku.

Tak nějak - a to nejdůležitější: nemá to AVX-512 :-D :-D

Kupovat v roce 2024 nové CPU, které mají SIMD z doby Haswellu, to musí být pořádný ořišek pro markeťáky.

Většina uživatelů AVX-512 vůbec neřeší, bohužel. Proč jsou AVX-512 pro tebe tak důležité a "snad 1000x lepší než stařičké AVX2"? Neviděl jsem, že by jejich použití v programu přineslo až takové přínosy, protože se nepřiblíží ani k 2x lepšímu výkonu.

28. 10. 2024, 15:05 editováno autorem komentáře

AVX-512 obchází limit dekodérů instrukcí na x86, kdy dekódováním jedné AVX-512 instrukce za jeden cykl "protáhne" stejně "práce" za jeden cykl, jako 2 normální instrukce. Samozřejmě to platí jen pro SIMD operace, což i tak je alespoň polovina use-casů.

Jinak díky AMD se teď AVX-512 implementuje všude, protože AMD je na serverech a PC doma. Intel je jen v OEM, kde výkon nikdo neřeší (počítače často za trest).

Intel
AVX? Ne. Nebo jen někde.
Splňuje požadavky na Copilota+? Ne.
Bude se další generace Intelu rozpadat? Snad už ne.

AMD
Splňuje požadavky na Copilota+? Ne.
Možné problémy s pamětmi. Lze ohlídat.
Problémy mezi jedním? čipsetem a PCIE 5.0. Lze ohlídat.
AVX? Ano.

Hybridi vs OS. Nekonečný příběh...

Nitpick: Když napíšeš AVX, tak technicky mluvíš o "AVX" z éry Sandy Bridge, pak přišlo AVX2 a pak AVX-512.

Intel umí AVX2, AMD umí AVX-512, které je snad 1000x lepší než stařičké AVX2.

Tak Intel měl historicky AVX512 jako první, ale podle jakého klíče jej dává do procesorů, to je mi dodnes záhadou. Nevím jak je to v současnosti, ale v začátcích uměl Avx512 intel cpu zpracovat pouze bez turba a jen v jednom vlákně (jelikož technicky se použily dvě AVX2 jednotky na jeden výpočet AVX512).

Co se týká Hybridní architektury, tak s poslední generací Intelu tu máme dokonce tři druhy jader v jednom pouzdře (P, E, LPE), takže totální zmatek pro OS scheduler. O tom, že by se to mělo rušit nevím, zato jsem četl, že Intel plánuje zrušit Hyperthreading.

Nemluvím technicky o AVX jiném než 512(10). Předpokládám, že to chytrý čtenář pochopí.

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

A kdyz bys mluvil o TPM, predpokladal bys ze bude chapano "TPM 2.0"? Proste kdyz se spatne vyjadris, nesvadej to na nechytrost ctenare ;⁠-⁠)

Nejde o nechytrost, ale znalost. A k tomu jaké AVX jede je jednoduché se dobrat, protože pokud jí ta apka umí tak je to dost poznat. Pak se ti to vryje do paměti samo.

Když někdo tankuje naftu, předpokládám, že má pod kapotou dieselový motor.
Když se bavím o moderních noteboocích, předpokládám přítomnost TPM 2.0. Jsou z roku 2014(2011). Letos je 2024.

Jesli sis nevšiml, bavím se o nových počítačích, které se dají koupit a zda splňují specifikaci Copilota.
Ty předpokládáš, že mají TPM 1.2? Nebo jen AVX1-2?

28. 10. 2024, 12:36 editováno autorem komentáře

Hybridi vs OS. Pribeh (temer) kazdeho mobilniho telefonu.

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?

Přesně naopak - nekupovat žádný produkt na základě víry, že se to někdy v budoucnu "spraví".

Ten článek zvláště po přečtení závěru jako kdyby hatil význam testů a říká vždyť je to jedno záleží čeho jste fanoušek AMD či Intel.
Ale pokud se pohybujete v komunitě počtářů, kteří jedou full cpu load 24/7, tak tam jde vidět jasný posun od Intelu k AMD. Ono benchmarky se sice udělaly v nějakém čase a nevíte za jakých podmínek.
No ale oni mají přístup k živým statistikám vytvářené dnes a denně. Taky na zásuvce to poznají daleko více než běžný domácí uživatel hrající hry nebo dělajíc něco jiného max pár hodin denně, třebaže spousta počtářů pomáhá na domácích strojích.
Doufám že víte co mám na mysli, nejsem proti určitým výrobcům CPU, nicméně v této skupině lidí je daleko větší tlak na skutečný výkon a skutečnou spotřebu. Ne tu z obrázků anebo prezentací.

25. 10. 2024, 21:11 editováno autorem komentáře

Podle mě to jde nejvíc vidět v cloudu - ten je mnohem důležitější než nějaký desktop/laptop segment a ten posun směrem k AMD/Epyc je neuvěřitejný.

V komunitě 24/7-čkářů jsou POCHOPITELNĚ jiná kritéria výběru než u běžných smrtelníků. Ale to jsem psal už v článku, možná jste to přehlédl.

Třebas chtějí, aby to fungovalo. Což je dost nefér požadavek diskriminující Intel.

Máte nějaké zprávy, že i procesory Arrow Lake jsou poruchové?

Máš nějakou informaci, že by tahle generace konečně fungovala?

Jiné požadavky? Bavíme se o dvojčatech kde jedno má pihu a proto je jiné.
Ale ve své podstatě jsou to stejné dvojčata.

Neboli obě dvě skupiny chtějí výkon za rozumnou cenu. Akorát ta 2. skupina jsou nadšenci ochotní investovat více.

Poznám procesor Athlon 64. To bol celkom fail. Nebol pre to poriadny softvér a hráči naň nadávali, že aj tak musia púšťať 32 bit windows, lebo na tých 64 bit nefunguje skoro nič.

Takých absolútnych vyhlásení bolo viac, o tom, aký je ktorý procesor nanič. Čas ukáže. Nejdem si samozrejme Arrow Lake kúpiť, ja som ujetý iným smerom.

26. 10. 2024, 21:11 editováno autorem komentáře

Athlon64 jsem měl a byl jsem spokojený přestože Windows 64bit na to v době vydání nebyl.
Použil jsem prostě dostupný Windows, tak jaký fail?
Nechceš snad dávat AMD za vinu nepřipravenost Microsoftu :-D.
Ale není to poprvé kdy člověk z východu tu dává takové hlody ale hlavně si to nenechá vymluvit a pořád někomu chce něco dokazovat. Prostě trol.
Takže předpokládám stejný scénář.

Nedávno som bol v Belíne, máte to tam pekné. Ale s tým 64 bit windows, to bolo dosť issue. Microsoft bol nepripravený, ale nepripravení su aj tvorcovia aplikácii na nový hardvér. Bis bald!

"Nejlevnějším modelem z nové nabídky Intelu je 14jádrové Core Ultra 5 245K za cenu pod 9 tisíc"

Tenhle produkt nechápu. 14 jader umí intel vyrobit ve vlastních továrnách. Na taktu 5.2 GHz to bude dokonce stabilní. Do těch 159W by se to taky mohlo vejít. Jistě by to zvládl i pod 9 tisíc Kč.

Proč to vyrábí u TSMC?

Neznáme smlouvy, ale podle dostupnosti to vypadá, že si intel objednal 285Ku a dostal 245Ku. TSMC s ním pěkně zametla.

V tech jejich tovarnach ve kterych ani sami inzenyri z Intelu nevedi na jakem procesu vlastne skutecne jedou protoze marketaci jim to prejmenovali ? :-D

26. 10. 2024, 12:56 editováno autorem komentáře