Vlákno názorů k článku
Bude příští kernel napsaný v Go? od oss - Tesim sa na jadro napisene v javascripte.

Kolik ze radku kodu ma kernel? Joaha, o par radu vic (cca 20M) , takze celkovej rozdil vykonu ... bude taky o par radu jinde.
Vy jste génius. Takže když kód na 30 000 řádků je o 10 % pomalejší než ekvivalentní kód v C, kód na 60 000 řádků bude pomalejší o 20 %? Toho přece můžete využít opačně – kód rozdělíte do menších programů, a ty budete spouštět postupně po sobě. Třeba ho rozdělíte na 2 programy po 15 000 řádků, takže ty programy budou pomalejší jen o 5 % – a když je pustíte po sobě, udělají stejnou práci, jako ten 30000řádkový, ale se snížením výkonu jenom 5 %. Tuhle teorii byste měl rozvinout, možná dostatečně krátké programy v Go budou dokonce výkonnější, než optimalizovaný assembler.

Ja by som predpoklad, ze vacsi software beziaci nad nejakym runtimom, ktory implementuje GC a nejaky netrivialny memory model bude oproti plne nativnemu kodu bez runtimu a s poctivym memory managementom pomalsi o viac % nez mensi hned tak nezatracoval. Predsalen skalovanie toho runtimu tak trocha z principu nemoze byt konstantne. GC ma nejaku reziu a ta obvykle narasta s poctom blokov. Ak sa budeme bavit o stromoch, tak niekde okolo logaritmickej zlozitosti pri hash tabulkach to bude lepsie, ale zasa treba zaplatit ich menezment.

Dalsia vec, ktoru treba zohladnit je, ze Linuxovy kernel je pomerne priamociary a riesi problemy od lesa. Velmi sa nesere so stabilnymi API, vrstvenim, izolaciou a pod. V podstate je to jedna velka guca kodu, ktora si stastne bezi na jednej hromade. To moze byt celkom lahko jeho najvacsia performance vyhoda. Aspon onoho casu (niekedy za cias OS X 10.5) niekto spustal performance testy na Linuxe a OS X a vysledok bol ten, ze mikrokernelova architektura Darwina bola totalne konkurencienes­chopna, ak doslo na silne (silne = zhruba 4 a viac paralelnych pristupov k jednemu stroju) paralelny pristup k zdrojom. Nebol by som prekvapeny, keby zhruba podobny vysledok podali aj Windowsy. Tam ale zasa bude skreslenie v tom, ze fork() nie je na Windowse zrovna efektivna cesta ako vytvorit proces, takze treba spravit hodne specificky test, ktory odizoluje tieto architektonicke rozdiely a niektoru z platforiem umelo neznevyhodni pouzitim neefektivneho algoritmu.

Ale nezameraval by som sa ani tak na ten vykon. Ved dnes si ludia pokojne pustaju systemy vo virtualkach, kde tych 10-15% stratia v pohode a nestazuju si. Skor je zaujimave zhodnotit pros & cons. Pre mna je jednoznacne con ak jazyk, resp. jeho standardna kniznica nie je zmrazena a sama o sebe ma celkom slusny pocet CVE. To je take... take korporatne. Ako vyhodu by som od jazyka cakal viac nez GC. Cakal by som napriklad aj ciastocne alebo uplne riesenie problemov s paralelizmov. A tu to ma mna sukromne lepsie naslapnute Rust. Go vnimam ako vec, ktora je si uz svojich 15 minut slavy vybrala a nie a nie zdochnut.

Mezi „neškáluje konstantně“ a „řádově větší program bude řádově pomalejší“ je ještě velmi široký prostor. Navíc ten příklad s GC není dobře zvolený, protože i program bez GC má typicky režii se správou paměti – i pro takový program je potřeba udržovat mapu zaplnění paměti (ať už jí pro větší bloky udržuje jádro, nebo pro menší bloky implementace malloc()). Režie GC bude oproti malloc() větší při zjišťování objektů, které je potřeba uvolnit, a to závisí na složitosti struktury objektů, která přímo nesouvisí s počtem řádků kódu.

Myslím, že v případě popsaném ve zprávičce se zdaleka neřeší jen GC. Automatické řešení paralelizace je podle mne stále ještě moc nákladné na výkon. Navíc v případě OS je to hodně závislé na tom, jak se např. chovají různé periferie, takže by se v podstatě dnešní kód OS musel přenést tam, kde by se řešil ten paralelizmus.