Vlákno názorů k článku HelenOS nikdy nebude dokončený, říká jeho autor Jakub Jermář od faha - Mel bych par dotazu ... Netrpi mikrokernel vykonove oproti...

Netrpi mikrokernel vykonove oproti monolitickemu jadru?

Ano, komunikační overhead IPC bude vždy v principu o něco větší než běžné volání funkce. Většina vývoje kolem mikrojader v 80. a 90. letech se právě točila kolem toho zoptimalizovat tento overhead co nejvíce.

Myslím si ovšem, že v dnešní době už ten fyzický overhead nehraje takovou roli. Koupit si o 10 % rychlejší procesor kvůli overheadu mikdrojádrové architektury je triviální a je to rozumná investice, protože za odměnu můžeme získat modulární, snadno udržovatelný a bezpečný kód. Údržba složitého monolitického softwaru, kde drobná chybka v málo podstatném modulu může způsobit pád celého systému, se jeví jako mnohem dražší a dlouhodobá investice.

musi dochazet mnohonasobne vicekrat ke "context switch"

Tohle je tak trochu nepochopení. V dobře navrženém mikrojádrovém systému dochází (za předpokladu asynchronní komunikace) ke zhruba stejnému počtu přepnutí kontextu jako v monolitickém systému — především z důvodu preempce nebo blokování.

Mikrojádrové systémy se zkrátka nesmí programovat tak, že se vezme "monolitický" sekvenční kód s funkčními voláními a ten se mechanicky převede na synchronní zasílání zpráv. Když se vhodně využije asynchronicita komunikace, koncepty jako future a promise a rozumný způsob předávání dat, tak se převážná část overheadu redukuje na nutné minimum.

jedna komponenta "zblazni" dokaze saturovat cely system jen rezii zprav

Počet zpráv, které může mít jedna komponenta v jeden okamžik "ve vzduchu", je omezen. Další zprávy si frontuje ve vlastní režii a tudíž ne více času, než je naplánována plánovačem. Takže jedna komponenta nikdy nezasaturuje celý systém.

Jistě se může stát, že nějaký proces bude soustavně "vyžírat" veškery procesorový čas, který mu plánovač dá, ale to se pochopitelně může stát i v monolitickém systému.

ji je treba napr. restartovat

Jak jsem už psal někde výše, restart podle mě nic neřeší :)

Jak se vlastne takovy system debuguje pri programovani, myslim tim kdyz se vse odehrava dost asynchrone?

Souhlasím, že debuggování asynchronní komunikace je složitější než debuggování sekvenčního kódu. Je potřeba sledovat komunikaci a všechny komunikující strany. V principu to dost připomíná ladění síťové komunikace ..

Na druhou stranu, v dohledné době budou mít procesory asi jen víc a víc jader a hardwarových vláken, takže luxusu přehledného sekvenčního kódu si stejně asi moc neužijeme :)

"Myslím si ovšem, že v dnešní době už ten fyzický overhead nehraje takovou roli. Koupit si o 10 % rychlejší procesor kvůli overheadu mikdrojádrové architektury je triviální a je to rozumná investice, protože za odměnu můžeme získat modulární, snadno udržovatelný a bezpečný kód. Údržba složitého monolitického softwaru, kde drobná chybka v málo podstatném modulu může způsobit pád celého systému, se jeví jako mnohem dražší a dlouhodobá investice."

Matematická poznámka: cena za upgrade hardware ale roste lineárně s počtem strojů, zatímco cena údržby software obecně nikoliv. Takže když jich máte opravdu hodně...

cena za upgrade hardware ale roste lineárně s počtem strojů

Cena za údržbu software zase roste s jeho velikostí. A dokonce bych se nebál tvrdit, že rychleji než lineárně.

Jestli vyjde ten trade-off v konkrétním případě lépe pro monolitický nebo modulární systém, to se skutečně nedá obecně a univerzálně rozhodnout. Netvrdím, že můj MP3 přehrávač musí řídit mikrojádrový operační systém složený z 25 komponent. Ale v případě jaderné elektrárny bych zase usínal hůře, kdybych věděl, že ji řídí program napsaný v jediném modulu :)

"Cena za údržbu software zase roste s jeho velikostí. A dokonce bych se nebál tvrdit, že rychleji než lineárně."

To je dost možné, ale software je jeden, zatímco strojů na kterých běží můžou být statisíce. Chtěl jsem tím podotknout, že ta skutečnost, že se to jádro lépe udržuje a vyvíjí, by se nakonec měla odrazit na nějaké produktivní vlastnosti - vyšší rychlost, vyšší spolehlivost, menší paměťová náročnost, spotřeba proudu nebo já nevím co ještě (tipoval bych, že spolehlivost bude horký kandidát). Pokud ne, tak na velkém počtu strojů vždycky "asymptoticky" prohraje.

> Jak se vlastne takovy system debuguje pri programovani
Debugovani takovych systemu ma sva specifika, na prvni pohled to mozna vypada zahadne, ale v praxi to muze byt i pohodlnejsi nez treba desktop monolyticka aplikace. Tady muzete mit porad spustene procesy, ktere komunikuji s tim debugovanym, muzete je behem toho ovladat, nejsou zamrzly a kdyz objevite v jedne komponente chybu, tak ji opravite a restartujete. Kdyz vam pak dobre funguje vyhledavani komponent a obnovovani spojeni, tak je z ladeni radost :-)