DOC_ZENITH píše:Tohle máš pravdu, je to jeden z důvopů proč nyní jedu HT OFF. Windows doteď nedovedou používat korektně HT a považují jej za další fyzická jádra, tzn pokud viděj že maj k dispozici další volné prostředky a SW si o ně řekne, nahrnou to na HT jádra i když ony HT thready budou brzdit jinej soft kterému jsi dal větší prioritu. Prostě s HT ve win nefunguje process priority management.
Takze predpokladane chovani je, ze by "HT jadra" byla volna a vsechny dalsi procesy s normalni prioritou by v podstate cekaly?
Muzu to pak zkusit na Linuxu, ale asi i RT priorita tohle nezaridi.
It will be amazing in case after 10GHz we will see 20GHz, 30GHz and so on, just like we witnessed the thorny way from 10MHz to 33MHz in the eighties. -xbitlabs.com
Správné chování by bylo že když program A používá třeba 4 thready a nastavim mu vysokou prioritu, OS by měl zařídit aby dostal plný 4 jádra a nic ho nebrzdilo. To se ale nyní děje jen bez HT, když je v systému HT a proces B se rozhodne sežrat celej zbytek CPU, tak HT thready z prvních 4 jader budou onou součástí "zbytku systému" a klesne ti výkon pogramu A o 50% ač má vysokou prioritu, s vypnutym HT se tento problém nestane. O trochu ti klesne výkon ale jen o to že sdílej cache/RAM ne až o 50%.
Nevim jak linux ale vím že MAC používá HT jádra jinak a používá je jen když si o to soft řekne.
Má to vůbec smysl rozličovat "nonHT" a "HT" jádra? Asi nějakým spešl registrem by to jistě šlo, ale jaký by to mělo přínos, viz příklad: mám 1 Core CPU se 4ALUs a 2 FPU. Thread A mi zabere 3 ALUS a 1 FPU při běhu. Z celkových prostředků mi zbývá 1 ALU a 1FPU, kam mi SMT logika může hodit čekající thread B. 3 ALUs jsou tedy neHT jádro a macOS mi to ve svém processExploreru zobrazí? Má to vůbec nějaký výnam, když stejně pro thread B už bude aktuálně volná jen 1 ALU? Leda snad kdyby OS měl nějaké API pro procesy/thready, které by tímto API mohly OS říkat, že 3ALU neptřebují a tak je OS může šoupnout na ten zbytek. Kolik programátorů ve světě Windows by takhle programovalo svou apkku? Omylem se seknu při odhadu řeknu OS, že mi stačí 1 ALU a pak mi uživatelé mé appky budou nadávat, že píšu pomalou "neoptimalizovanou" hru....
To jen tak uvažuji nahlas, nekoumal jsem nikdy detaily
On je spis problem s "resource contention" - vsechny struktury v jadre, ktere jsou sdilene mezi thready se razem zmensi. Pak jsou nektere struktury sdilene 50:50 a nektere jsou delene na pomer dany FW CPU, aby nedochazelo k hladoveni jednoho z threadu.
Typicky druhy thread zacne ukusovat z branch prediction struktur, uop-cache, L1/L2/L3 cache, TLB, OoO struktur a bufferu, atd. To pak logicky muze byt znat. K tomu samozrejme dochazi k vytezovani exekucnich jednotek/blokovani sekvenceru. Jako tresnicka na dortu je sdileni I/O BW.
Jinak "SMT jadra" jsou soucasti viditelne CPU topologie. Lze je zobrazit napr. v Linuxu v sysfs pro kazde jadro: /sys/devices/system/cpu/cpu*/topology/thread_siblings_list
It will be amazing in case after 10GHz we will see 20GHz, 30GHz and so on, just like we witnessed the thorny way from 10MHz to 33MHz in the eighties. -xbitlabs.com
Bohužel kéž by to bylo tak jednoduché, kdyby u každého softu bylo známo kolik sežere FPU/ALU a pod byl by svět jednodušší, ale neni. Pokud to neni ultra specifická repetitivní úloha tak se tohle mění každou milisekundu a nedá se dle toho plánovat. Ostatně "nák tam vše nasoukat" to už je úloha HW a front-endu, on tam nakonec vše nasouká a obvykle s benefitem 10-20% oproti tomu kdyby jádrop mělo jen 1 thread, bohužel ale tím klesne výkon na thread, takže HT je dobré pokud jde o zvednutí celkového MT výkonu, ale v situacích kdy ti dojdou prostředky ala CPU je celkově více jak 50% loaded (se započtením HT threadů) tak už začínmá klesat výkon na thread.
Jsou ale situace kdy je HT k nezaplacení, jako případy kdy ti dojdou volný jádra ale tvůj soft potřebuje k plynulému chodu více threadů. Třeba hraní v moderních enginech na 4 jádrech. HT to tam nacpe a máš sice menší FPS ale zahraješ si, SW context switching je oproti HT ohavnej a s 4C4T to skončí nepoužitelnem stutter-festem.
Takže v low-endu je to velká záchrana, v high-endu ale kde máš dost jader aby jsi pokryl to co nechceš aby se zpomalovalo a během toho chceš dělat něco dalšího na pozadí je to spíš takovej danejskej dar.
Sice můžeš přes process lasso si to locknout tam kam chceš aby se ti to necpalo do těh jader kde běží třeba ta hra, a bude to fungovat ok, problém ale je v tom že OS stále vidí HT thready jako další volný jádra a i když fyzický jádro může bejt full loaded, tak onen HT thread hlásí 0% a win si myslej hej tady mam volný jádro a cokoliv co se spustí na pozadí či cokoliv jinýho co nemáš ošéfovaný se ti tam hned nasere. To je taky důsledek toho že oba thready na jádře jsou si rovný. Pokud na oba dorazí 100% load rozdělí se výkon 50/50, žádnej nemá prioritu nebo přednost. Na macu si nejsou rovný a OS k nim přistupuje jinak.
Ja mel za to, ze OS k nim uz delsi dobu nepristupuji stejne. Vlastne uz v dobe BD by melo platit, ze OS prirazuje nejdriv "fyzicka" jadra a az pak zacne obsazovat i jejich sdilene "SMT sourozence".
// Tim chci rict, ze je OS uz umi nejak rozlisovat.
It will be amazing in case after 10GHz we will see 20GHz, 30GHz and so on, just like we witnessed the thorny way from 10MHz to 33MHz in the eighties. -xbitlabs.com
V rámci API jako takového to určitě vidí, protože tato informace má potenciál se dostat i do obyč programů. Otázkou ovšem je jestli se podle toho chová a dle mých praktických zkušeností je odpověď bohužel ne.
Win co jsem vysledoval tak pokud program sám sebe (nebo to něco jiného udělá za něj) nezamkne na určitý thready tak win stále jedou onym stylem horkej brambor, tzn naustále házej thready tam kde je zrovna volno, proto když máš CPU co má 8 threradů a program co používá 4 obvykle bejvá CPU vyloadovanej chaoticky, neni to tak že určitý jádra jedou na 100% a jiný na 0. Stejně je to i s HT, on to tam prostě hodí a nezajímá ho to. Jakmile někde vidí že je thread co má menší load hned brambor letí tam, tzn ve finále se moc nestává že by třeba vyloadoval 2 thready na 1 jádru a zpomalil aplikaci, protože styl horkej brambor to hned začne házejt jinam a do stavu zpomalování se to obvykle dostane až když jinde neni místo.
Je to mizernej přístup kterej se nezměnil od NT5 a funguje to defakto jen se štěstim a za předpokladu že je jednotná cache a programu neuškodí to že je každou milisekundu na jinym jádru. Pokud neni víme co se stane viz starej threadripper. Nebo tyto multiCPU sestavy jako je ta moje, tam to musim hlídat a ručně věci lockovat jak je potřebuju, protože když se to nechá na win člověk přijde až o 1/4 výkonu protože win neustále hážou procesy tam a zpátky bez ohledu na to kde jsou numa bloky, cache a pod, což je retardované protože ten Os tuhle topologii vidí, v task manageru vidim že vidí že má 4 numa bloky, 4 L3 cache bloky, atd, ale řídí se tim? Ne. Musim to dělat za něj přes process lasso.
yuri.cs píše:Ja mel za to, ze OS k nim uz delsi dobu nepristupuji stejne. Vlastne uz v dobe BD by melo platit, ze OS prirazuje nejdriv "fyzicka" jadra a az pak zacne obsazovat i jejich sdilene "SMT sourozence".
// Tim chci rict, ze je OS uz umi nejak rozlisovat.
Tohle se řešilo onehdá u Core Parking, ne? Windows 7 už uměly rozeznat který thread je HT a který ne.
Tak jsem se podíval do WinAPI a jde to vyčíst https://docs.microsoft.com/en-us/window ... lationship zřejmě tedy x86 CPU na to nějaké stavové registry mít budou. Celkem by mě zajímala ta magie, co za tím v CPUčku je, ale to už asi bude vyšší dívčí
DOC_ZENITH píše:V rámci API jako takového to určitě vidí, protože tato informace má potenciál se dostat i do obyč programů. Otázkou ovšem je jestli se podle toho chová a dle mých praktických zkušeností je odpověď bohužel ne.
Win co jsem vysledoval tak pokud program sám sebe (nebo to něco jiného udělá za něj) nezamkne na určitý thready tak win stále jedou onym stylem horkej brambor, tzn naustále házej thready tam kde je zrovna volno, proto když máš CPU co má 8 threradů a program co používá 4 obvykle bejvá CPU vyloadovanej chaoticky, neni to tak že určitý jádra jedou na 100% a jiný na 0. Stejně je to i s HT, on to tam prostě hodí a nezajímá ho to. Jakmile někde vidí že je thread co má menší load hned brambor letí tam, tzn ve finále se moc nestává že by třeba vyloadoval 2 thready na 1 jádru a zpomalil aplikaci, protože styl horkej brambor to hned začne házejt jinam a do stavu zpomalování se to obvykle dostane až když jinde neni místo.
Je to mizernej přístup kterej se nezměnil od NT5 a funguje to defakto jen se štěstim a za předpokladu že je jednotná cache a programu neuškodí to že je každou milisekundu na jinym jádru. Pokud neni víme co se stane viz starej threadripper. Nebo tyto multiCPU sestavy jako je ta moje, tam to musim hlídat a ručně věci lockovat jak je potřebuju, protože když se to nechá na win člověk přijde až o 1/4 výkonu protože win neustále hážou procesy tam a zpátky bez ohledu na to kde jsou numa bloky, cache a pod, což je retardované protože ten Os tuhle topologii vidí, v task manageru vidim že vidí že má 4 numa bloky, 4 L3 cache bloky, atd, ale řídí se tim? Ne. Musim to dělat za něj přes process lasso.
Zatim jsem na nejake vetsi testovani nemel cas.
Jen jsem hodil 2 instance klasickeho 'stress' na muj 2c/4t stroj s 5.12 kernelem zkompilovanym jako SMP&SMT. Bylo videt, ze 100% vyloadovani se drzi na fyzickych jadrech - pary 0-1 a 2-3. Po cca 30sec z nejakeho duvodu (mel jsem pusteny browser a dalsi blbosti) probihaly migrace mezi pary virtualnich jader, ale ocividne ne mezi fyzickymi jadry.
Bud jsem mel stesti nebo stale plati hierarchicke schedulovaci domeny a skupiny z dob kernelu 2.6 - https://lwn.net/Articles/80911/. Tam je hezky videt rozdil uvazovany rozdil ceny za migraci mezi SMT jadry, SMP jadry a NUMA celky.
It will be amazing in case after 10GHz we will see 20GHz, 30GHz and so on, just like we witnessed the thorny way from 10MHz to 33MHz in the eighties. -xbitlabs.com
Provedl jsem pár změn. Dnes jsem upgradoval na E7-8891v4 ala ten samej model jen Broadwell nástupce. Upgrade je úspěšnej ale ne na 100%.
Je to divný ale CPU co jsem dostal nejsou identický. 3 kusy maj Tcasemax 104C a jeden 100??? Přitom stejnej stepping, takty, výkon, atd a Intel vůbec neeviduje že by mělo existovat více verzí ale evidentně ano. Tento CPU taky žere a topí cca o 10W více jak jeho soukmenovci. Jinak je ale ok. Horší je to s CPU 0 (0-3 ala systémové pořadí). 0 Je polomrtvá/má toho dost. S timhle už jsem se setkal u CPU co renderovaly dekádu v kuse při vysoký teplotě. Za normálních okolností funguje ok, ale jakmile jí necham přehřát a dojde na throttling začne bejt unstable. Ostatní kusy ani žádnej z V3 předchůdců tímto netrpí, budu ještě jednat s prodejcem na Ebayi ohledně tohodle, o tom "jinym kusu" kterej mi až tak nevadí dam ho na nejvíce chlazené místo, ale tenhle co je při přehřátí unstable mi vadí.
Nicméně systém jinak funguje ok. Výkon povyrostl cca o 10-15% ve všech situacích (cinebench R15 bez HT cca 5000 místo 4500, Final fantasy XIV CPU limited benchark 25136 místo 22516. Provedl jsem ještě pár dalších změn.
Dále, studoval jsem jak se chová GPU shared memory na WIN a bohužel zle. Ala vůbec neřeší numa a pod, jako max kapacitu si vždy určí polovinu RAM (mělo by bejt polovinu RAM na CPU ke kterému je grafika připojená), ale ne, prostě polovinu a tipuji že to nebude házet tam kde je zrovna volno, což bude na CPU 0, tak fajn, GPU necham připojenou na CPU 0 a ještě jsem mu narhnul více RAM. Mam teď 128GB na 0 a zbylý 3 jsou po 48GB.
Tu rošádu RAM jsem stejně musel udělat, jeden slot měl blbej kontakt a tohle plán ještě urychlilo.
Na co jsem ještě přišel je že win ač spoustu věcí podělaj, tak správu RAM obecně ne. Co tím myslim? S non numa-aware ramdiskem jsem si zkusil co se přesně stane když některá CPU nebudou mít žádnou volnou paměť a spustí se tam SW. No... zkusil jsem a průser. Věc se spustí, ale pokud jej MEM bottlenecked tak pojede klidně o 50% pomaleji. Win ale naštěstí primárně přiřazujou RAM threadům tam kde běžej, tzn tahle situace by default nenastává a když člověk přes process lasso třeba řekne aplikace xxx že se bude spouštět jen na CPU4, tak ona se i v RAM nacpe během spouštění na CPU4 tzn korektní chování. Tohle nejde nikde v TM sledovat, ale praktcké testy mi ukázaly že to funguje korektně.
A je tu ještě jedna, unrelated věc. Podařilo se mi levně shenat a rozject poškozenou RTX2070S (radiální, vhodnou do tohodle setupu). A cosi se změnilo. Tato změna se udála ještě před upgradem CPU a po přeházení RAM, ani jedna z těchto událostí na ní tedy nemá vliv. Ale z ňákého důvodu nyní všechno běží lépe. Resp, běží, test vyjde třeba stejně ale loaduje lépe. U Pascallu jsem během třeba loadování u open-world her měl mnohem větší škuby či to déle trvalo když byl loading screen, déle než na Ryzenu což jsem přisuzoval tomu že eghm o 1,5Ghz méně, ale jinak vše jelo ok tak jsem tomu nevěnoval moc pozornost, ale teď? Teď to loaduje stejně čí lépe jak na Ryzenu real-time a naopak mnohem rychleji když je loading screen, i "škuby" u doloadování open world věcí zmizely nebo jsou extra malé. Nevim co to má bejt, jestli novej 471.41 driver a něco s nim vs Turing co u Pascallu nebylo? Že by si Nv začala potichu testovat ňákou alpha formu direct storage eh? Nevim, prostě po změně GPU + driveru se nyní vše v hrách loaduje jak lusknutim prstu a nevim co stojí za touhle pozitivní změnou. Navíc by to mělo bejt naopak protože karta jede nyní jen na 8 linek (poškozené PCB).
Tak dneska jsem se konečně dokopal k instalaci náhradních CPU které mi prodejce poslal poté co jsem mu napsal o oněch "nesrovnalostech" a problémy skutečně byly u CPU. Ty nové kusy maj Tcasemax 104, tzn všechny jsou nyní identické a jsou rock-stable i během přehřátí/throttlingu.
Tak ten co nebyl stable během throttlingu vyhodim a ten s Tcasemax 100 si necham jako náhradní.
Teda tohle je fakt nádhera
Asi bych se zbláznil z konfliktu mezi chtěním to používat a nervováním se kvůli spotřebě, kdybych to měl, ale naprostá paráda. Tohle už by snad trumflo jenom Itanium, ale to by se pak nedalo moc rozumně používat
Nervování, eh, když neni výtop tak neni nic co by člověka nervovalo. Nevim jestli mam tentokrát štěstí na airflow pod novym stolem, nebo za to může to letošní léto neléto, ale vedrem pod stolem nebo vedle kompu netrpim, tzn easy se to přejde.
Co mě fascinuje asi nejvíc je že to prostě funguje. Já jsem prostě čekal více problémů, že se něco posere, že ten board někde z itálie vytaženej od bůh ví odkud nebude ok, že se něco podělá během té složité montáže a custom modifikace case, že se win podělaj z quad-numa, že to bude v něčem too slow (v hrách třeba) ale ono prostě neni, kor teď po tom CPU upgradu.
Zatim největší bolest byla že jsem měl vadnou RAM, jeden modul, a projevovalo se to tak že systém random (třeb jednou za X dní) se z ničeho nic zpomalil na úroveň slimáka, zpomalilo se vše tak 8x (i zvuk) ale nedošlo k výtuhu a vždy se to pak zas samovolně rozjelo bez ňákého zásahu, někdy za pár vteřin, někdy to trvalo déle, třeba minutu. Netušil jsem kde je problém protože v logách jak OS tak biosu nebyl žádnej problém. Protože občas pomohlo "mrdnout do case" myslel jsem si že blbej kontakt nebo studeňák. Původně jsem si i myslel že ten PCI-E switch vs dlouhý risery vs zvukovka nebo USB3.0 controller ale tyto teorie vzaly za své.
Nakonec jsem se teda uchýlil k závěru "studeňák či slot u RAM" a začal vše testovat včetně fyzického pohybu za chodu. Pár "blbejch slotů" jsem našel a když jsem vše přeházel a udělal si i novej layout kde primary CPU schválně nese více RAM, a myslel jsem si že vše je v pohodě, prásk, problém zpět a stále stejnej. Prostě ta RAM začala generovat tolik chyb že se ze systému stal slimák, ale necrashnul a pak se to zas samo uklidnilo.
Naštěstí jsem jednoho dne měl zrovna otevřenej TM a systém byl naprosto v idle, a viděl jsem během onoho "připosrání se" bezdůvodnej load na numa bloku 3, tentokrát to byla delší epizoda a díky tomu se onen modul nestihnul vzapamatovat když jsem prašitil do resetu a bios onen modul nenačetl. Aleluja, díky tomu že v biosu je krásně označené kde co je připojené a já jsem tam viděl kde onen modul neni reported ač tam fyzicky sedí, tak to sedělo na CPU3 dle toho co jsem viděl v TM, tak jsem jej vyndal a přehodil na CPU2. O pár dní později se to znova podělalo a load se přesunul na CPU2 přesně tam kam jsem přesunul tenhlke modul. Takže to bylo jasné, vyměnil jsem ho (a hned demonstrativně zlomil abych neměl tendence ho dát do šuplete) a od té doby klid. Tohle byl defakto můj jedinej HW problém.
Udělal jsem si boot menu kde mam 2 režimy, buďto systém nabootuje full nebo jen s jednim CPU a jeho RAM. Většinou bootuju full ta varianta B je tem jen pro "maximalizaci herního výkonu" ale upřímně řečeno full + process lasso na 90% her stačí. Některé RTS hry tak dokonce jedou i lépe (AOE2 DE ač je single threaded) a třeba They are billions což je hra co využile defakto kolik threadů máš a jede lépe přes všechny CPU (generuje load asi 40% na primárnim a 30% na každym ostatnim) a reálnej stav je že se neškubne ani na té největší mapě s tou největší popupací, kuddos takhle by se měly programovat RTS, ala když na to máš systém tak ať ho to sakra využije.
Prostě to funguje a vždy když jsem si myslel "tohle tomu nesedne tohle bude zlý, tady dojde na lámání chleba" tak to nakonec dopadlo "hele ono to jede docela pěkně". Prostě 60MB Ringbusu udělá svoje, i když to má jen 3,3Ghz.
Už to nepoužívám, běžely na tom ještě ňákej čas simulace z práce ale projekt je hotovej. V létě budu pravděpodobně stavět něco nového, doufám že už na bázi Sapphire-rapids. Po pár měsících s Alderem musim uznat že ten rodíl v IPC je tak zásadní že to bude stát za to.
Já jsem taky minulej tejden přešel na SSD only storage a můj komp se stal nádherně tichym a je to upřímně dost návikový. Už dlouho byl tichej ale teď bez disků je to komplet new level. To tohle, ani při velké snaze nikdy nebude. Spíš se to hodí na full throttle někam do serverovny s klimatizací.
