PCTuning fórum

mr.qeg píše:Tak jsem trochu uvažoval nad tím, proč vlastně Intel na ADL zakázal úplně AVX512, když tam má ten Thread-Director, který by dle PR slajdů měl dynamicky přidělovat instrukce těm nejvhodnějším jádrům. Identifikovat AVX512 a posílat ji jen a pouze na GC jádra by tak neměl být žádný problém, což?

z diskuze :

pokud mam proces a rad bych v nem pustil 24 threadu a nechal to bezet na vsem co procesor ma, musim se omezit na tu mnozinu instrukci, ktere umi mala jadra a zapomenout na rozsireni, co umi velka jadra?


Ano, musis. Staci si uvedomit, jak funguje scheduler v OS. Mas rekneme 1000 aktivnich vlaken z procesu, a je 24 vlaken CPU. Scheduler nemuze vedet, kdy ktera uloha uvolni procesor, a kdyz se nejakej CPU thread uvolni, mozna ze jedinej volnej proces thread bude takovy, ktery predtim bezel na uplne jinem CPU threadu. = Driv nebo pozdeji musis prohodit proces thread mezi malym / velkym CPU a naopak.

Kdyz scheduler "vraci" nejakej thread procesu na nejake CPU, musi obnovit stav procesoru presne do stavu v jakem byl kdyz CPU "odebral" tomu threadu. Jinak receno, musi se ulozit do pameti / obnovit vsechny registry CPU. Rekneme ze mas thread ktery bezel na velkem CPU, a pouzival AVX512 registry. Pak mu byl CPU odebran, a pak pridelen malej CPU. Kam obnovis ty AVX512 registry ? a kdo bude vykonavat ty AVX512 instrukce...

Existuji reseni... ale vsechny jsou nahovno. Mohl bys rozhodnout jestli program bude mit povoleno pouzivat AVX512... jenomze tohle musis rozhodnout uplne na zacatku pri spusteni. Pokud jednou pouzije AVX512 tak uz musi bezet jen na velkych CPU. Jak bys tohle resil ? budes delat whitelist / blacklist vsech programu na svete... asi ne ze. Skenovat binarky jestli pouzivaji AVX512 nelze, protoze dneska existuje spousta programu ktere si dynamicky vybiraji kod za behu.

Takze intel vlastne udelal jedinou logickou vec - omezil vsechna CPU na stejnou sadu instrukci.


https://diit.cz/clanek/alder-lake-zarad ... ru-avx-512

Jistě, toto je odpověď, kdyby tam žádný Intel Thread Director (IDT) neexistoval. Ale Intel ve slajdech přece popisoval, jak je to cool sofistikovaná věc, co např. bude automaticky házet "NOP" instrukce, co nic nedělají, na malá jádra. Takže by úplně stejně mohl házet AVX512 instrukce jenom na velká. Každá instrukce v x86 má unikátní binární kód, tak by to bylo i celkem snadné.

Spíš to opět jen naznačuje, co tu už psalo pár lidí, že ve slajdech k IDT byli popisováni papíroví draci a hlavní bedra stejně budou na OS Schedulleru a celé IDT budou ve skutečnosti jen nějaké upřesňující hinty pro Scheduller navíc.

jenže i když tam je ten Thread dDirector, tak stejně o tom kam která úloha pujde na jaké jádro bude nakonec rozhodovat OS scheduler, už to tady bylo dříve zmiňováno... a ta homogenita instrukcí je pak nezbytná, aby ten big-little koncept mohl vůbec fungovat.

Ano, ta nepodpora je vlastně jen potvrzením faktu Nepsali to ti stejní Koduriho chlapci, co dělali prezentace na Radeon Vega?

Ohledně Thread Directoru, AnandTech to má pěkně vysvětlené ve svém IAD 2021 reportu

AnandTech - Intel Architecture Day 2021: Alder Lake, Golden Cove, and Gracemont Detailed - Intel Thread Director

Nic nedělající NOP instrukce, která neovlivní paměť, registry atd. by měla bez problémů jít poslat kamkoliv.
Vzít AVX512 instukci z vykonávaného kódu je jiná věc: zaprvé to malý jádro musí tu instrukci identifikovat (to by snad šlo). Potom je ale nutný minimálně vyklidit registry nějakého velkého jádra a předat mu celý proces. Dělat to po instrukcích je pěkná kravina, protože v tom procesu nebude jen 1 AVX512 instrukce a procesor by přehazoval instrukce mezi jádry místo jejich vykonávání.
Vzhledem k tomu, že OS přehazuje procesy podle toho, který CPU se zrovna uvolní/který proces zrovna na něco čeká, tak jako minimum by to vyžadovalo udržovat informace o procesech, které vykonaly AVX512 instrukce (jak už bylo řečeno, spolehnout se na to, že to víme dopředu, nejde) a scheduler by je poslal jen na velká jádra. V tomhle IDT obecně moc dělat nemůže, protože jakmile by sám začal přidělovat prostředky, bude v konfliktu s OS schedulerem a nepřetržité stěhování procesů/dat/registrů by výkonu rozhodně neprospělo. Proto pro vyžití jader s různými instrukčními sadami je nutná spolupráce OS (to dnes není), potenciálně i spolupráce softwaru (to nikdy nebude).

mr.qeg píše:Jistě, toto je odpověď, kdyby tam žádný Intel Thread Director (IDT) neexistoval. Ale Intel ve slajdech přece popisoval, jak je to cool sofistikovaná věc, co např. bude automaticky házet "NOP" instrukce, co nic nedělají, na malá jádra. Takže by úplně stejně mohl házet AVX512 instrukce jenom na velká. Každá instrukce v x86 má unikátní binární kód, tak by to bylo i celkem snadné.

Spíš to opět jen naznačuje, co tu už psalo pár lidí, že ve slajdech k IDT byli popisováni papíroví draci a hlavní bedra stejně budou na OS Schedulleru a celé IDT budou ve skutečnosti jen nějaké upřesňující hinty pro Scheduller navíc.

Uh. Ono to fakt neni tak jednoduchy.

Jednak v binarce nemas sanci predem poznat, co je kod a co jsou data, takze muzes chybne interpretovat data jako AVX512 instrukci a druhak muzes mit aplikaci, co v sobe AVX512 instrukce ma, ale nepouziva, takze bezi i na jadru, co je nepodporuje.

Taky muzes mit aplikaci bez AVX512, co se na zacatku zepta na podporu AVX512, a pokud se nahodou spustila na velkym jadru, dostane odpoved ano (pokud by ty velky jadra porad mely podporu) a ten kod s AVX512 teprv vygeneruje.

EDIT: neco jako prehazovani vlakna na jiny jadro jen kvuli vykonani AVX instrukci je totalni nesmysl, samotny jedno prepnuti kontextu muze trvat klidne dobu nekolika tisic instrukci (a to za predpokladu, ze uz mas volny velky jadro).

WILLLESS píše:Nic nedělající NOP instrukce, která neovlivní paměť, registry atd. by měla bez problémů jít poslat kamkoliv.
Vzít AVX512 instukci z vykonávaného kódu je jiná věc: zaprvé to malý jádro musí tu instrukci identifikovat (to by snad šlo). Potom je ale nutný minimálně vyklidit registry nějakého velkého jádra a předat mu celý proces. Dělat to po instrukcích je pěkná kravina, protože v tom procesu nebude jen 1 AVX512 instrukce a procesor by přehazoval instrukce mezi jádry místo jejich vykonávání.
Vzhledem k tomu, že OS přehazuje procesy podle toho, který CPU se zrovna uvolní/který proces zrovna na něco čeká, tak jako minimum by to vyžadovalo udržovat informace o procesech, které vykonaly AVX512 instrukce (jak už bylo řečeno, spolehnout se na to, že to víme dopředu, nejde) a scheduler by je poslal jen na velká jádra. V tomhle IDT obecně moc dělat nemůže, protože jakmile by sám začal přidělovat prostředky, bude v konfliktu s OS schedulerem a nepřetržité stěhování procesů/dat/registrů by výkonu rozhodně neprospělo. Proto pro vyžití jader s různými instrukčními sadami je nutná spolupráce OS (to dnes není), potenciálně i spolupráce softwaru (to nikdy nebude).

Ano máš vlastně pravdu, to jsem si neuvědomil při tom přemýšlení nahlas. Díky za rozepsání.

No, nevyplyvalo z vlastni podstaty fungovani Thread Directoru, ze musi OS poskytovat napovedu pro kazdy aktualne bezici thread? Nebo mozna, ze by ITD sam uchovaval OS thread IDs (pres FS registr) a k nim prirazoval metriky a napovedy... Tezko rict, ale nejspis bude tuhle historii mit na svych bedrech OS scheculer. Bude si drzet historii od HW - kdyz jsem naposled scheduloval muj thread 123, tak mi pak HW rikal, ze musi bezet na E jadru, protoze je vyhodnocen jako backgroud task...

Tzn. do ITD tecou nasamplovana relevantni data z klasicke monitorovaci jednotky celeho SoC. ITD si je sam vyhodnocuje se stavem ostatnich jader v SoC. No a v nejakem intervalu nastavuje OS viditelnou "napovedu" - o jake thready jde a co by mel idealne udelat pri pristi schedulovaci akci.

V tech Intel pripadech je to pak videt, ze treba jedno velke jadro jede nejaky spinlock - ITD tohle z instrukcniho mixu pozna. Tak tedy P jadro X je zbytecne na P - muze se tocit na E - a do OS tabulky zapise: "thread z P jadra X hod priste na E jadro Y". Nebo dokaze rict, ze tenhle thread na P X by fakt mel bezet na P, protoze je plny AVX2 nebo podobne b/w narocnych instrukci a ma tedy vyssi "P prioritu" nez ostatni.

Nebo by mel i dovest setrit napr. v pripade, ze vsechny thready aktualni pobezi na E cores, tak nebude cpat novy workload, dle defaultni politiky, na P core a probouzet tak P ze spanku.

Cele to porad ridi OS scheduler, ale IDT/HW by mu mel k tem threadum dodat info, jak se v runtime chovaji. No a pak je na nem, co si z tech napoved vybere a jak se zachova.

Nebo to mam uplne blbe?

K těm instrukcím řeknu jen to, že v minulosti nebyl problém provozovat PII a PIII spolu v dualu i když běžely na jiný frekvenci + jenda měla SSE a druhá ne. Když se pustil program co SSE vyžadoval, tak v praxi fungoval ok, v ten moment kdy SW vyžadoval SSE tak tuto operaci vykonal ten CPU co ty instrukce měl. Spousta SW nakonec stejně škálovala přes oba ač ve specs měla že SSE chce (třeba cinebench R11.5). Tzn ve win tohle nebude problém a OS se fakt nepodělá z toho že gracemont nemá AVX512, prostě se ten kód spustí tam kde to půjde a komplet to vyignoruje sheduler a priority.

https://wccftech.com/intel-alder-lake-c ... or-700-us/
kolik to asi bude u nás

yuri.cs píše:No, nevyplyvalo z vlastni podstaty fungovani Thread Directoru, ze musi OS poskytovat napovedu pro kazdy aktualne bezici thread? Nebo mozna, ze by ITD sam uchovaval OS thread IDs (pres FS registr) a k nim prirazoval metriky a napovedy... Tezko rict, ale nejspis bude tuhle historii mit na svych bedrech OS scheculer. Bude si drzet historii od HW - kdyz jsem naposled scheduloval muj thread 123, tak mi pak HW rikal, ze musi bezet na E jadru, protoze je vyhodnocen jako backgroud task...

Tzn. do ITD tecou nasamplovana relevantni data z klasicke monitorovaci jednotky celeho SoC. ITD si je sam vyhodnocuje se stavem ostatnich jader v SoC. No a v nejakem intervalu nastavuje OS viditelnou "napovedu" - o jake thready jde a co by mel idealne udelat pri pristi schedulovaci akci.

V tech Intel pripadech je to pak videt, ze treba jedno velke jadro jede nejaky spinlock - ITD tohle z instrukcniho mixu pozna. Tak tedy P jadro X je zbytecne na P - muze se tocit na E - a do OS tabulky zapise: "thread z P jadra X hod priste na E jadro Y". Nebo dokaze rict, ze tenhle thread na P X by fakt mel bezet na P, protoze je plny AVX2 nebo podobne b/w narocnych instrukci a ma tedy vyssi "P prioritu" nez ostatni.

Nebo by mel i dovest setrit napr. v pripade, ze vsechny thready aktualni pobezi na E cores, tak nebude cpat novy workload, dle defaultni politiky, na P core a probouzet tak P ze spanku.

Cele to porad ridi OS scheduler, ale IDT/HW by mu mel k tem threadum dodat info, jak se v runtime chovaji. No a pak je na nem, co si z tech napoved vybere a jak se zachova.

Nebo to mam uplne blbe?

Toto vypadá, jako použitelný mechanismus, jak by to mohlo fungovat. Další otázka do pranice - spinlock na P jádru a jeho případné přehození na E jádro, nebude to opět drahý kontext switch, jak tu už někteří zmiňovali a nebude tedy v konečném důsledku lepší a efektivnější se na to v*srat a nechat to čekat na P, byť ho to bude zbytečně blokovat?

del42sa píše:https://wccftech.com/intel-alder-lake-c ... or-700-us/
kolik to asi bude u nás

Tak se třeba co nevidět dočkáme nějakých testů

yuri.cs píše:..

já jsem spíš zvědavý jestli opravdu budou v scheduleru win 11 takové změny, nebo jsou to jen marketingové kecy Intelu a snaha vymáčknout z BL architektury maximum a které přímo nesouvisí se samotným schedulerem ale se změnami ve win 11 obecně.

Krteq píše:Tak se třeba co nevidět dočkáme nějakých testů

Bez zakladnich desek tezko. Ale aspon se muzeme podivat jak budou vypadat krabicky
https://videocardz.com/newz/intel-core- ... een-leaked

K i9 clovek dokonce dostane i "waffer".

Sobo píše: Bez zakladnich desek tezko. Ale aspon se muzeme podivat jak budou vypadat krabicky
K i9 clovek dokonce dostane i "waffer".

tak k Buldozeru jsi dostal plechovku na kafe

del42sa píše:

yuri.cs píše:..

já jsem spíš zvědavý jestli opravdu budou v scheduleru win 11 takové změny, nebo jsou to jen marketingové kecy Intelu a snaha vymáčknout z BL architektury maximum a které přímo nesouvisí se samotným schedulerem ale se změnami ve win 11 obecně.

cit. ..."Na optimalizácii programu Intel Thread Director sme úzko spolupracovali so spoločnosťou Microsoft. Windows 11 využíva svoje vstupy aj na viac než len na plánovanie vlákien. Tipy z hardvéru pomáhajú operačnému systému rozhodnúť sa, ktoré jadrá zaparkovať a vybrať z dôvodu úspory energie. Rozhranie PowerThrottling API tiež umožňuje vývojárom definovať atribúty kvality služby pre vlákna, vrátane novej klasifikácie EcoQoS, ktorá definuje preferenciu energetickej účinnosti pred výkonom. Prehliadač Edge spolu s ďalšími súčasťami systému Windows 11 využíva túto schopnosť na zvýšenie energetickej účinnosti a zabezpečenie dostupnosti jadier P pre vlákna kritické z hľadiska výkonu."...
zdroj: https://medium.com/intel-tech/alder-lak ... f2533c6326

"Tralalák"cit. ..."Na optimalizácii programu Intel Thread Director sme úzko spolupracovali so spoločnosťou Microsoft. Windows 11 využíva svoje vstupy aj na viac než len na plánovanie vlákien. Tipy z hardvéru pomáhajú operačnému systému rozhodnúť sa, ktoré jadrá zaparkovať a vybrať z dôvodu úspory energie. Rozhranie PowerThrottling API tiež umožňuje vývojárom definovať atribúty kvality služby pre vlákna, vrátane novej klasifikácie EcoQoS, ktorá definuje preferenciu energetickej účinnosti pred výkonom. Prehliadač Edge spolu s ďalšími súčasťami systému Windows 11 využíva túto schopnosť na zvýšenie energetickej účinnosti a zabezpečenie dostupnosti jadier P pre vlákna kritické z hľadiska výkonu."...

ano to je hezké citovat marketingové slajdy od Intelu, ale realita může být zcela odlišná. I kdyby to byl ten nejhoší výrobek na světě tak v marketingových materiálech bude stejně popsán jako "super-truper" a jak inženýři Intelu při jeho navrhování zachránili svět před ekologickou katastrofou. Samozřejmě s požehnáním Gréty

JJ a poroto maj sustained power do socketu specifikovanj nad 250W heh.

Jako je cool jestli zefektivnili práci C-states a laptopům to trochu ušetří proud ale eeeh. S tim jejich super efektivnim jádrem se nedivim že v laptopech budou hodně potřebovat "preferenciu energetickej účinnosti pred výkonom" a držet vše na gracemontech jak jen to půjde.

Ono ostatně to easy otestujeme jak to funguje na OS bez prodpory a S.

Údajný únik Core i9-12900K naznačuje, že Alder Lake bude úplným šampiónom pri pretaktovaní RAM
zdroj: https://www.neowin.net/news/alleged-cor ... rclocking/

P.S. kvapalný dusík to je parketa pre .flankera