Vlákno názorů k článku
Plánovač CPU v Rustu je lepší než ten výchozí v linuxovém jádře od RDa - A nedosahneme stejneho vysledku kdyz se kompilace proste...

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.

No ale fakticky je původní tvrzení víceméně správně. 0.75^20 dá tři promile času, což se v klidu dá už nazvat poor man idle class.

(Já vím, je to složitější, prio není nice ale jen se podne ní dolaďuje atd, ale na meritu že s dostatečně velkým nice to dostane CPU jen když je volné to nic nemění.)

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_runti­me_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
^C

real 0m11.301s
user 0m8.882s
sys 0m0.000s
ja@pc:~/B$ nice -n 19 bash
ja@pc:~/B$ time ./nic
^C

real 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.

Nejsme ve při, říkám jen, že pro popsaný use case (sníženi FPS hry, která se musí dělit o jádra s kompilací kernelu) je to jedno procento času úplně jedno, jestli dostane nebo ne.