Názory k článku
Plánovač CPU v Rustu je lepší než ten výchozí v linuxovém jádře
-
FíkZlatý podporovatelTo mě napadlo hned, prostě změřit, jak dlouho trvala kompilace. Ale nenašel jsem to.
-
Jo takhle to bylo myšleno.
A není to tak, že kompilace je víc náročná na IO operace včetně těch blokujících a byť by výsledek mohl být podobný, tak stejný není?
Příklad:
Mám dvě osoby, A a B a mám taxík.
Snížení priority je rovné tomu "Hele B, taxíkem můžeš jen JEN když jím zrovna nechce jet A"Tedy, pro dvě osoby je výsledek totožný.
Ale jak to zařídíš pro 2300 osob? Osobo C, ty taxíkem můžeš jet dřív než osoba XY, ale až po osobě AAC...
Pokud "ad-hoc napsaný" plánovač dokáže lépe rozhodit zátěž, tak jestli to není o tom, že prostě dokáže lépe využít dostupné prostředky CPU. Možná byt místo 100 VPS mohl provozovat 110 per server a při podobné spotřebě energie... -
Sorry, ZMÁTL MĚ NADPIS!!
"Plánovač CPU v Rustu je lepší než ten výchozí v linuxovém jádře."
...kua...Root by se mohl přejmenovat na Clickbait.root :-(2 FiK ...to nám pomalejším prosím nedělej. Jak vidím Ježek, dávám si pozor, ale u tebe jsem clickbait nečekal...
23. 1. 2024, 00:34 editováno autorem komentáře
-
Blokujici operace je idealni pro scheduler, protoze se tim CPU uvolni pro dalsi task.
Moje pointa byla v tom, ze kdyz mas 2 tasky se stejnou prioritou, tak obe pobezi stejne pomalu (male fps ve hre).
Ale pokud kompilaci presunes pres nice nize, aby bezela jenom kdyz je cpu fakt volne, tak hra ma k dispozici tolik cpu vykonu kolik si uraci. To jest - bude bezet hra a kompilace dobehne nekdy v daleke budoucnosti, podle toho, zda hra necha vubec nejake volne cpu (coz pri vsync na 60fps kvuli monitoru by mohla).
A nepotrebuji na to frikulinsky scheduler, staci vedet jak nastavit priority - kdyz me v prvni rade jde o to, aby hra dostala prioritu. Mechanismy jadro davno na tohle ma.
Ad kompilace jadra: typicky bezi na CPU+1 vlaknech, zadne tisice. Hra ma taky nizsi jednotky vlaken, takze nevymyslej blbosti zas - bavime se o konkretni situaci kdy autor tvrdi, ze jeho scheduler je lepsi.
Ad2: takove schedulery, co brali do uvahy interaktivitu procesu jsme meli uz v minulosti a moc se to neosvedcilo jestli si dobre vzpominam.
-
Ale pokud kompilaci presunes pres nice nize, aby bezela jenom kdyz je cpu fakt volne, tak hra ma k dispozici tolik cpu vykonu kolik si uraci. To jest - bude bezet hra a kompilace dobehne nekdy v daleke budoucnosti, podle toho, zda hra necha vubec nejake volne cpu (coz pri vsync na 60fps kvuli monitoru by mohla).
Jenze takhle nice hodnota nefunguje, nice hodnota rozdeluje CPU cas proporcialne mezi jedntlive ulohy, kdy jeden bod nice prida nebo ubere 25% CPU casu. To, co jste popsal je priorita, ktera se pouziva v planovacich tridach RR a FIFO.
-
Podle me se jedna o trestuhodne nepochopeni elementarnich rozdilu mezi planovacimi tridami, protoze stale bezici proces s nejnizsi nice nezablokuje system, kdezto stale bezici proces ve tride FIFO nebo RR system kompletne zablokuje a system se casem stane nepouzitelnym nebo zpanikari (castecne se tomu da branit snizenim sched_rt_runtime_us, ale to pomuze jen ve specifickych situacich).
-
Jistě v tom máte pravdu, ale diskutovaná otázka není o implementaci RR, ale je "bude nice -n 19 xxx fungovat tak, že xxx dostane CPU jen, pokud je volné", což je v aproximaci pravda.
Dukaz: Komp ma 4 CPU, bezej tam 4 procesy, co delaj while (1) i++;, a poustim patej.
ja@pc:~/B$ time ./nic
^Creal 0m11.301s
user 0m8.882s
sys 0m0.000s
ja@pc:~/B$ nice -n 19 bash
ja@pc:~/B$ time ./nic
^Creal 0m12.512s
user 0m0.180s
sys 0m0.000s -
V tomdle pripade jde exactne rozhodnout, jestli neco pravda je a nebo neni a v tomdle pripade neni pravda, ze proces s vyssi hodnotou nice bezi jen tehdy, pokud proces s nizsi hodnotou nice nepotrebuje CPU. To jestli ten proces dostane 50%, 1% nebo 0,1% casu CPU na tom nic nezmeni. Kdyby to tak nebylo, tak by ten bash, co jste spustil s nice 19, ani nevypsal prompt.
-
Srovnání s hrou Terraria může nést ovoce, protože to je nízkonákladová hra jak po hw stránce tak sw stránce. Zapnout třeba War Thunder, Insurgency či jiné náročné hry, tak místo onoho výkonu je drop...
Co jsem četl celé řešení toho plánovače, tak vlastně tu hru dává na první místo a zbytek jde do pozadí, to ovšem umí ale i linux jádro, když ho tak nastavíš.
Takže to neni o jazyku, ale o tom jak to nastavíš. A jak jsem dával příklad náročnějších her, tak je to o tom, že být první neznamená pro hru všechno...
Je to stejné jako BENZÍN vs NAFTA....
-
Citace z odkazovaného githubu:
This doesn't mean that scx_rustland is a better scheduler but does demonstrate how safe and easy it is to implement a scheduler which is generally usable and can outperform the default scheduler in certain scenarios.
Pak se nelze divit, že autor zprávičky působí jako by byl poněkud mdlého rozumu nebo se nesmyslně snaží o senzaci, aby ve výsledku působil spíš jako <výraz doplňte libovolně>
-
Na obranu autora, vzdyt tam pise, ze "Ten je kupodivu pro některé zátěže (například hry) lepší než ten výchozí v linuxovém jádře", coz me celkem sedi na "a scheduler which is generally usable and can outperform the default scheduler in certain scenarios."
Pokud narazite na nadpis, ktery je ponekud clickbait-oidni, tak neni uplne jiste, jestli jej spachal autor, nebo az editor. Ja kdyz jsem posledne napsal zpravicku, tak jsem se divil, ze byla uverejnena s uplne jinym nazvem. A pokud si pamatuju dobre, tak i text byl pozmenen.
22. 1. 2024, 20:21 editováno autorem komentáře
-
A pak můžete totéž zkusit třeba s různýma jinýma hrama, pro které ten test nebude vůbec relevantní. Nebo jen nekompikovat na pozadí jádro.
On ten experiment nebyl o vytvoření úžasného scheduleru, a pokud se to náhodou povedlo jako vedlejší produkt, jen test s jednou hrou spuštěnou paralelně s kompilací je příliš málo na závěry. Scheduler se mohl trefit i celkem náhodou, a v jiném scénáři (i u her) může být zcela mimo.
ČLÁNKY DO MAILU