Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
no super.. takze programator co si v recenzich precet ze avx512 po vypnuti malejch jader funguje a alder koupil, ma s upgradem biosu utrum.. muze se zacit modlit, aby se mu neprojevil nejakej bug.. to je ten Patuv transparentni marketing.. (:
Az to mali niekde v specke, alebo feature liste takto napisane (ziadne E-cores = AVX-512), to asi smrdi aj class-action lawsuitom.
Nikde to takto nemeli napsane. AVX 512 na tech procesorech bylo vzdy "undocumented feature". Podle me pocitali s tim, ze Microsoft udela podporu scheduleru pro procesory obsahujici jadra s ruznymi instukcnimi sadami, jinak by usetrili tranzistory a nedali AVX512 ani do velkych jader. Ale MS na ne asi hodil bobek pac by to znamenalo velkou komplikaci.
Stejna jadra jsou/budou v serverovych Sapphire Rapids. Takze o podpore ze strany MS to nejspis nebude, jinak to budou muset vypnout jako ve Workstastion, tak Serverovych chipech. Nemluve o Linuxu..
jo tak za to muze microsoft! ((: jen mi teda neni jasny proc intel do tech procesoru daval ten svuj thread director kerej muze rozlozeni vlaken mezi jadra nezavisle na ms scheduleru menit..
Nechapu proc si takovou blbost lidi porad mysli? Nic takoveho delat samozrejme nemuze. Muze jen doporucovat scheduleru v OS co kam dat.
Ne. Doporučuji přečíst si dokumentaci od Intelu. V základním stavu, tedy v aplikacích bez specifických optimalizací pro Alder Lake, přejímá scheduler Windows rozhodnutí vzešlá od ITD a nijak je nemění.
Podepíše to OS, takže nemůže.
Porad je to jen doporuceni. Kdyz si afinitou navazu proces na konkretni jadro, tak ho tam windows bude drzet a thread director mu muze tvrdit co chce. Zkratka to co psal je blbost- thread director nemuze narizovat scheduleru v OS co ma udelat a uz vubec nemuze zadna vlakna prehodit sam bez vedomi OS. Nerozumi priortitam, nerozumi potrebam operacniho systemu (nekjtera preruseni musi byt zpracovana urcitym jadrem kvuli lokalite cache) atd. TD se ani nemuze spolehnout na to, za jak dlouho scheduler v OS jakkoliv na doporuceni zareaguje (nebo zda vubec nekdy - nemusi pro to mit podporu) protoze scheduler rescheduluje procesy s urcitou periodou a ne kdyz si zrovna TD zamane. Takze takova predstava, ze TD zaridi preschedulovani na velke jadro kdyz v pipeline narazi na AVX512 instrukci je prudce naivni.
„Kdyz si afinitou navazu proces“
To ale není ani rozhodnutí scheduleru, ani rozhodnutí ITD, ale rozhodnutí uživatele. S touto logikou bych mohl tvrdit, že u non-Alder Lake procesorů jsou rozhodnutí scheduleru Windows pouze doporučení, protože je uživatel může změnit. Ano, změnit je lze, ale pokud do procesu nezasahuje žádný vnější podnět (uživatel nebo speciální optimalizace na straně aplikace), tak scheduler bez jakýchkoli změn přebírá rozhodnutí ITD. Ani tomu nemůže být jinak, protože ITD má daleko vyšší počet vstupů o dění na úrovni procesoru než scheduler Windows. Ten proto nemá důvody z vlastní iniciativy cokoli měnit, protože nemá informace ani prostředky, které by mohly vést k lepšímu výsledku.
Že do procesu může(!) zasáhnout uživatel rozhodně nevyvrací, že v implicitním stavu scheduler bez vlastního zásahu přejímá rozhodnutí ITD. Kdo tvrdí opak, nečetl nebo nepochopil oficiální dokumentaci.
Nejsme v zasade ve sporu. Ja jsem reagoval na to, co psal Tom "thread director kerej muze rozlozeni vlaken mezi jadra nezavisle na ms scheduleru menit" coz neni pravda. Nic menit nemuze. Dava jen doporuceni a nemuze se spolehnout na to, kdy a zda vubec je OS splni. Coz je vetsinou v pohode ale v situaci, o ktere se bavime nikoliv. Thread s avx512 by musel deterministicky skoncit na velkem jadre.
Je to presne tak. Thread Director nic nemeni a ani technicky nemuze. Jedine co dela je, ze poskytuje detailni "telemetricke" info o bezicim procesu. Prehozeni threadu je hodne slozita zalezitost a muze to udelat pouze OS. To, ze nejaky OS v defaultnim rezimu slepe posloucha TD (pokud tam neni nejake jine omezeni), na tom nic nemeni. Situace s AVX512 neni efektivne resitelna, takze jedine rozumne reseni (ac se mi to vubec nelibi), je jeho vypnuti.
Neni na tom nic rozumneho. Je to ciste pragmaticke rozhodnuti Intelu. Proste se rozhodl, ze ne.
Intel se svymi vazbami na MS muze a urcite taky ovlivnuje, jak se jeho scheduler chova, trakze by to MS mohl poresit. Pak tu mame linux, ktery Intelu pro desktop muze byt ukradeny, ale tam vetsinou pracuji lidi, co jsou schopni scheduler upravit tak, jak by to clovek cekal. A dalsi OS jak si moc neni...
Obecně k vláknu: HW asistence jen doporučuje OS, ale na OS je, jak nakonec rozhodne. Ano, rozhodovací kód ve Windows může být napsaný víceméně od Intelu (tak jako např. člověk z Intelu napsal v id Software optimalizaci perspective correct texture mapping přes pipelined FPU v Pentium 1 pro hru Quake 1). A samozřejmě je možnost, že uživatel přes nabízené volby OS sám přiřadí procesu konkrétní jádro.
Aby se rozhodoval sám CPU, muselo by být další jádro od OS skryté. Já si pod HW asistencí představuju telemetrii - protože jinak by OS musel např. při spuštění aplikace projít všechny instrukce, a pokud by narazil na AVX-512, tak proces pouštět jen na velkých jádrech. Co když ale aplikace má runtime detekci a takovou codepath nevyužije?
BSD, AIX, QNX, to nejsou OS? :-)
Rozumne je to v ramci nabizenych moznosti. Kdyby to OS automaticky hazel na velka jadra, tak by byl vykon horsi, nez to vypnuti. A to ani nemluvim o dynamickem vybirani instrukci za behu (napr. vsechen muj kod).
Neviem kde som čítal, že aj keď užívateľ pridelí aplikácii malé jadro, scheduller pridelí veľké ak je to väčšia záťaž. Mýlim sa? Kvôli tomu nie je možné pustiť benchmark len na malých jadrách.
Migracia elektronov? Preco by na to mali byt nachylne prave AVX obvody a nie zvysok logiky?
Nejspíš proto, že AVX obvody nezabírají moc místa, ale jsou dost žravé. V důsledku to znamená lokální přehřívání a proudové zatížení napájecích spojů (to by se asi dalo omezit, ale to přehřívání asi moc ne).
To je celkom zaujimave, 128-bitove vektorove jednotky su tu s nami uz nejaky ten piatok (20+ rokov), este za cias ~90nm obvodov. 5GHz sa sice vtedy nedosahovalo, ale niektore tie procaky dali 4GHz IIRC a nic take pozorovane nebolo. Zaujimave, ze rozsirenie na dvojnasobok tak zahustilo emitovanie tepla, ze treba kvoli tomu brzdit procesor.
10nm proces intelu proste ma svy mouchy..
Hlavně je z hlediska odolnosti/životnosti o dost jinde než jím zmíněných 90nm.
LOL, to jenom ukazuje, že Intel není seriózní firma, tedy, že jim nešlo o to, udělat dobré procesory, které fungují dobře v celém spektru různých výkonů (/spotřeby), ale že Alder Lake je specificky vytúněný, aby porazil Zen3.
Přístup AMD se mi líbí víc, prostě mají vizi do budoucna a od té se nenechají Intelem vynervovat, aby ztráceli čas/energii blbostma, jenom aby porazili konkurenci. Takže dlouhodobě bude mít AMD navrch, protože je solidnější než Intel a nehraje jeho blbé hříčky...
Intel nemusí nerovať AMD. AMD vynervovala Čína, ktorá zatiaľ nechce povoliť akvizíciu Xilinx-u. Všetko je pripravené ako organizačne, tak po stránke realizácie projektu "Magnum 2" ako pokračovanie
AMD se pustila do vlastního FPGA, představí ho ještě letos
10. 10. 2016
https://diit.cz/clanek/amd-magnum-fpga
https://diit.cz/sites/default/files/amd_fpga_hbm.png
Ale spustiť ho nejde pokým nedoistanú povolenie na akvizíciu
Xilinx je tvoje tapeta, když téma nezapadá do žádné škatulky (ale je to AMD)?
Nemaj trošku zpoždění?
Zvláštní je, že se o tom pak mlčelo ;-)
jo to je nad slnko jasne ze alder bol vydany s umyslom porazit zen3 a vyslo mu to (alderu) v JEDINOM parametri: 1T vykon, vo vsetkych ostatnych prevadzkovych parametroch a pomeroch parametrov je chudak alder nr. 2 a ked pride za tri kvartaly zen4 s 1T vykonom vyssim o 20% oproti zen3, tak raptor by musel oproti alderu zvysit 1T vykon velkych jadier o 10% aby dosialhol na 1T vykon zen4 .... nechame sa prekvapit (kazdopadne multiT vykon hypotetickeho buduceho raptoru i9 13900K s 8 velkymi a 16 malymi jadrami uz moze vo vacsine pripadov prekonat multiT vykon hypotetickeho buduceho r9 6950X s 16 jadrami zen4)
i5ka poráží v multithreadu 5800x ikdyž se dá koupit levněji než 5600x.
I7ka zase poráží ve všem 5900x, za levněji.
Nepřijde mi že by to byly špatné procesory.
Jediný alder lake který je nicmoc je i9 s nesmyslně vytáhlou spotřebou kvůli 3-5% výkonu navíc. MT výkon stejný jako 5950x, ST nejvyšší. Alespoň ta cena je o 3000 nižší než 5950x.
"i5ka poráží v multithreadu 5800x ikdyž se dá koupit levněji než 5600x."
.. mel by jsi zacit byt trosku specifictejsi. Ne kazda i5 porazi 5800x, naopak vetsina jich v MT 5800x neporazi. Jedinou vyjimkou je 12600k(f).
"I7ka zase poráží ve všem 5900x, za levněji."
.. jeste vetsi hloupost nez to predchozi tvrzeni. Je to presne naopak. I 12700k je principielne pomalejsi, pokud se bavime o MT ulohach.
A do tretice hloupost "MT výkon stejný jako 5950x,.."...
https://www.computerbase.de/2021-11/intel-core-i9-12900k-i7-12700k-i5-12...
Tak nějak si matně vzpomínám - nehodlá AMD v nových verzích Zen AVX512 zavádět? To by byla prča...
zen4 ma mit neco na zpusob avx512 ale to neznamena ze to bude zaply v desktopu..
Myslíš tedy - AVX2 na věčné časy a nikdy jinak?
V souvislosti s EPYC Geona / Zen 4 se mluvilo o podpoře tzv. AVX3-512. Nikdo ale neví, co to má být. Nejspíš podobný přístup jako Zen rozkládal 256bit na 2× 128bit. Anebo něco úplně jiného.
AVX3-512 je bud nesmysl, nebo nejaky marketingovy termin. Zen4 bude podporovat AVX512 na urovni IceLake + bfloat. Samotna implementace je zatim neznama a z pohledu nazvoslovi v podstate irelevantni. Muj osobni tip je, ze pujde o nejaky hybridni pristup - tedy ze nektere 512b instrukce se budou rozkladat (napr. FMA), ale jine ne (napr. permutace).
Už jsem to našel:
https://diit.cz/sites/default/files/zen_4_core_slide.jpg
Vypadá to jako výřez z nějakého oficiálního slajdu pro partnery, některé z uvedených informací se již potvrdily (např. více než 64 jader), takže bych to nezavrhoval (jako výmysl). Ještě by to mohl být překlep.
Jak se to nazve je celkem jedno (treba na to ma Intel copyright a i proto ten nazev AVX512 misto logictejsiho AVX3). Dulezite je, ze podle CPUID to technicky AVX512 je.
Myslim ze AVX3 znamena ze tam bude nativni bfloat, protoze v tech puvodnich AVX2 to neni - je to celkem novinka prece, ne?
AVX512 (512bit) tam bude určitě realizován jako 2x AVX-2 (256bit). Důležité je, že to bude podporovat požadované instrukce. Výkon to bude mít takjakotak - to už měl teď, díky mnohem většímu počtu jader. Nezapomeňte, že kromě nejvyšší verze Xeonu i Intel implementuje AVX512 pomocí 2 jednotek AVX-2 (a to nemluvím o tom, že Intel dodnes dělá CPU zcela bez podpory AVX512, včetně uměle zakázané, viz článek nad diskuzí - asi chtěj uvolnit prostor ARM s jeho SVE).
Nektere instrukce z AVX512 je velice slozite rozlozit na 2x256b. Napr. permutace ze dvou zdrojovych 512b registru. Tam ma jedna instrukce plny dynamicky pristup k celym 1024b informace a zapisuje 512b. Nenapada me reseni, jak tohle udelat na 256 bitech bez priserne degradace vykonu. Intel tohle ma ve vsech svych CPU jako plne 512b (stejne jako vsechny integer operace mimo nasobeni). U Intelu je to 2x256 (porty0+1) + 1x512 (port5). Na "nizsich" verzich CPU neni na portu 5 FMA, to je jediny rozdil.
AMD se degradace výkonu u exotických instrukcí nebojí, viz PDEP/PEXT u dřívějších Zenů.
Klidně to může být rozepsáno v mikrokódu na desítky taktů.
Koneckonců u Intelu jede celé AVX512 emulovaně, pokud tyhle instrukce nemají v kódu dost velkou "hustotu".
Tohle mě vede k jisté teorii: Intel to dělá kvůli výkonu aplikací (resp. benchmarků).
Existuje totiž jeden docela závažný problém při míchání AVX2 a AVX512, bez jednoznačného řešení.
Ten problém jsou falešné závislosti a zbytečné latence:
V momentě, kdy použiju 512b operaci, tedy horních i dolních 256 bitů dohromady, mají pak některé další 256b (AVX2) operace technicky závislost na horní půlce AVX512 registru. A to výrazně omezuje spekulativní a paralelní provádění. Koneckonců to samé existuje při míchání SSE a AVX(2).
Rozbít tuhle závislost jde, ovšem; myslím že to bylo vynulováním registru nebo podobně triviální. Ale co jsem četl, byl zde dost rozdíl chování AVX512 mezi KNL a Skylake. Na jedné z architektur ta instrukce byla nutná, na druhé ne, a naopak kód překvapivě výrazně zpomalovala (jako mfence). Už nevím, která byla která.
Hypoteticky tedy:
Pokud Intel přinese AVX512 do desktopu, pak standardní DLLky Windows, MSVC runtime a podobně tyhle instrukce samozřejmě použijí pro globální urychlení memset/memcpy a podobných obecných funkcí napříč systémem. Jenže kód samotných aplikací zůstane beze změny, max. AVX2.
Pokud někde mezi nebo před blokem AVX2 instrukcí aplikace zavolá memcpy, zmíněná falešná závislost vznikne, a boom, najednou je starý software na novém CPU pomalejší. Nebo alespoň povolené AVX512 navzdory očekáváním způsobí, že je software pomalejší.
Tohle platilo u SSE vs AVX. U AVX vs AVX512 uz ta falesna zavislost neni. Kazda AVX operace z definice nuluje vsechny horni bity az do "nekonecna".
Nemyslím si, že bych si to pletl, zvlášť když si pamatuju, že přímo v tom článku, resp. diskuzi, to přirovnávali k SSE vs. AVX. Ale je to možné. Možná to bylo něčím jiným. Možná jen na KNL.
Zkusím znovu dohledat...
U KNL byl jiny bottleneck, ktery omezuje prakticke maximum vykonu vuci predpokladanemu papirovemu:
https://sites.utexas.edu/jdm4372/2018/01/22/a-peculiar-throughput-limita...
AVX instrukce vsech typu a sirek je mozne libovolne kombinovat. K zadnym problemum nedochazi, mam to vyzkousene. Dokonce se tahle vlastnost vyuziva k nulovani hornich casti registru, aniz by se uvedla jejich plna delka. Napr. "vpxord xmm16, xmm0, xmm0" je nejefektivnejsi zpusob jak vynulovat 512-bitovy registr zmm16 (pomoci 128-bitove instrukce). S KNL jsem nedelal, ale z principu to musi fungovat stejne.
Hezky. Na KNL si to můžu vyzkoušet... mám tedy víc věcí co si chci vyzkoušet, ale zatím jsem neměl prostor žádné testíky nabouchat.
Tak zrovna tenhle priklad na KNL nepojede, protoze vyzaduje AVX512VL, ale to michani AVX a AVX512 by, alespon teoreticky, mohlo fungovat.
Hlavní důvod AVX512 jsou servery - jde o konkurenční výhodu Intelu (software speciálně napsaný pro akcelerační instrukce). Intel v hrubém (nespecializovaném) výkonu nemá proti AMD šanci. Víc výkonných jader vždy výkon Intelu překoná. Je jich o tolik víc, že nevadí, že Intel - za cenu výrazně větší spotřeby - dosahuje vyšších frekvencí. V desktopu výhoda AVX512 nepřekoná, že čip je dražší (menší marže) - tam zas využije Intel možnost vyšší frekvence v ST (i za cenu vysoké spotřeby). V desktopu stejně většina software nevyužije AVX512 (slepice, vejce - většina procesorů neumí, a dlouho ani nebude umět, AVX512, takže ani nevzniká podpora v SW). Navíc tam neběží jedna úloha, ale mnoho aplikací současně, takže buď CPU jede pomalu ne-AVX512 kód (snížení frekvence v AVX512 módu), nebo je AVX512 kód jen emulovaný (ne v AVX512 módu).
Tak zrovna permutace jsou hodne dulezite, zadna exotika. Je to jeden z piliru AVX512. Na Intelu jedou v jednom taktu (resp. 3/1 lat/tp). Mikrokodem by to totalne zabili.
Když je to takovej pilíř, proč Intel na AVX512 tak strašně kašle? Nenabízí plnohodnotné AVX512, často ho dokonce nenabízí vůbec, ve spoustě současných a i budoucích CPU (nemluvím o Atomech apod.). Aby se lidi nedočkali 512 bitů až s příchodem ARM do PC...
Nepsal jsem, ze AVX512 je pilir, ale ze permutace jsou jeho pilirem. Jsou proste hodne dobre a proto v AVX512 kodu hodne pouzivane. Jinak, co je to plnohodnotne AVX512 ? Vsechny soucasne implementace jsou plnohodnotne (a nektere jeste plnohodnotnejsi s dvema FMA jednotkami :)). Abych to upresnil - zadne 512b instrukce nejsou v zadnem Intel CPU rozkladany (za normalniho stavu pri plnem vykonu) na dve 256-bit ve smyslu skutecne nezavislych instrukci jako napr. u Zenu 1. Pokud se v pipeline nachazi 512b instrukce, dochazi ke slouceni portu 0 a 1 na jeden 512-bitovy. To mozna nektere lidi mate, ale tak to proste Intel vymyslel a je to u vsech CPU stejne, at je to Xeon nebo i3.
Ježiši to je stále niečo. Tento Alder hnus nám bol čert dlžný. Dnes vypnú AVX-512 a zajtra to budú atom jadrá.
To není Alderem, to je prostě Intelí marketing - nemusí být spokojený zákazník, ale markeťák, a/nebo akcionář.
Popravdě, režim 8P+0E s povolenými AVX-512 bylo to jediné co pro mne činilo platformu AL/Z690 zajímavou.
Nehledě na to, že možnost vypnout malá jádra (např. Scroll Lockem?) tam zůstává (kvůli neopatchovaným hrám s DRM, hlavně Denuvo).
Tak zase a opět místní komentáře nezklamali, patla, matla, jednoduché vysvětlení že? Výrobci desek to udělali neoficiálně a tím to začíná i končí, spousta al má prostě avx 512 části prostě defektní, jsou i tací experti kteří tyto procesory v rámci nefunkčnosti avx 512 reklamují, já myslím že to stačí, tady není už co řešit, že Intel udělal to co musel, kdo to nepochopil tak mě ho je líto.
Skutečně lidi reklamují AL pro nefunkčnost AVX512, tedy že funkčnost zapli (režim 8P+0E) a aplikace dělala problémy? Nejde jen o vracení, protože ani neví, jak to zapnout, ale v informacích o CPU si přečetli, že by to AVX512 mělo umět?
Už aby ten intel konečně uvedl nějakou reálnou konkurenci pro AMD, nebo se nám tady snowflaková intelata úplně roztečou. :-D Zatím jsou stále ve fázi (prudivý a tapetující) denial, tak je to dobrý...
Že by to už konečně začalo umírat bolestivou smrtí?
Nojo, nekdo (kdo tomu navic vubec nerozumi) placne nejakou blbost a troubove to musi omilat jeste roky pote :).
Ano, taky mě to napadlo, už při čtení titulku článku.
A přesně opačným směrem mě napadlo, že kdo o AVX512 opravdu stojí (a má ho v BIOSu natvrdo vypnuté), mohl by zvážit Coreboot...
"Porovnáním třetího výsledku s prvním zjišťujeme, že malá jádra zvládají akorát (přesně) vykompenzovat výkon ztracený vypnutím AVX-512."
Jak takovou věc o výkonu zjistíme z grafu porovnávajícího spotřebu energie?
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.