Systémové programování

Často slyšíme, učíme se, a dokonce používáme termíny nebo fráze, kterým ne zcela rozumíme. V komunitě vývojářů softwaru to považuji za poměrně častý jev, ať už se jedná o webové rozhraní API RESTful, agilní metodiku, strojové učení nebo jiný termín. Nemusí to být nutně špatně, ale je důležité si uvědomit, kdy něco opravdu znáte a kdy znáte jen název pro danou věc.

Pro mě je jedním z takových termínů systémové programování. Rád bych se pokusil jednoduchým jazykem vysvětlit, co to znamená.

Než pochopíme, co Systémové programování obnáší, musíme nejprve pochopit, co je to Systém. Software se obvykle dělí na jeden ze dvou táborů, systémový a aplikační software.

Systémový software je počítačový software určený k tomu, aby poskytoval platformu jinému softwaru. Mezi příklady systémového softwaru patří operační systémy, výpočetní vědecký software, herní enginy, průmyslová automatizace a aplikace typu software jako služba.
… Takový software se nepovažuje za systémový, pokud jej lze obvykle odinstalovat, aniž by to ovlivnilo fungování jiného softwaru.
– wikipedia.org

Systémový software je platforma tvořená programy a službami operačního systému (OS), včetně nastavení a předvoleb, knihoven souborů a funkcí používaných pro systémové aplikace. Systémový software zahrnuje také ovladače zařízení, které zajišťují provoz základního hardwaru počítače a periferních zařízení.
– techopedia.com

Systémový software označuje soubory a programy, které tvoří operační systém počítače. Systémové soubory zahrnují knihovny funkcí, systémové služby, ovladače pro tiskárny a další hardware, předvolby systému a další konfigurační soubory. Programy, které jsou součástí systémového softwaru, zahrnují assemblery, kompilátory, nástroje pro správu souborů, systémové nástroje a ladicí programy.
– techterms.com

Definice Wikipedie je velmi vágní v tom, co se považuje za systémový software, pokud poskytuje služby jiným aplikacím. Další dvě definice se však zaměřují čistě na operační systém – ovladače, jádra, knihovny a funkce (myslím hlavičkové soubory jádra/libc a sdílené objekty). Z toho vyplývá úzký vztah k hardwaru. Pokud se podíváme na jiný článek Wikipedie o systémovém programování, vidíme:

Systémové programování vyžaduje velkou míru povědomí o hardwaru.

Článek dále naznačuje, že hlavní součástí systémového programování je potřeba, aby věci byly velmi rychlé. To dává smysl, proč bychom měli o hardwaru hodně vědět. Dává také smysl, že rychlost (výkon) by byla hlavní součástí systémového programování, pokud je platformou pro další software.

Pokud je nejstřednější část aplikace („platforma“ systémového softwaru) pomalá, pak je pomalá celá aplikace. Pro mnoho aplikací, zejména v měřítku, by to byl deal-breaker.

Systémový software v kostce

Výše uvedené citace a další zdroje mě přivedly k následujícím kritériím pro definici systémového softwaru:

• Poskytuje platformu pro další software, na kterém je možné stavět.
• Přímo nebo úzce spolupracuje s počítačovým hardwarem za účelem získání potřebného výkonu a vystavení abstrakcí (jako součást platformy).

Co je a co není systémový software

Příklady toho, co je systémový software:

• Jádra operačních systémů
• Ovladače
• Hypervizory typu bare metal (např.g. Hyper-V a VM Ware ESXi)
• Kompilátory (které vytvářejí nativní binární soubory) a ladicí programy

Příklad toho, co není systémový software:

• GUI Chatovací aplikace (Slack, Discord atd.)
• Webová aplikace v JavaScriptu
• Web Service API

Všimněte si, že zatímco Web Service API poskytují službu jinému softwaru, neinteragují (obvykle) s hardwarem, aby nad ním vystavily abstrakce. Existují však aplikace, které spadají do střední šedé zóny. Ty, které mě napadají, jsou aplikace pro vysoce výkonné výpočty a vestavěný software.

Aplikace pro vysoce výkonné výpočty (HPC), jako je obchodování v reálném čase na burzách, obvykle nevystavují platformu, ale je pro ně běžné psát kód, který přímo komunikuje s hardwarem. Příkladem může být obcházení síťového zásobníku nabízeného jádrem a implementace vlastního síťového zásobníku komunikujícího přímo s NIC(y). Tímto způsobem můžeme vidět, jak HPC software sdílí mnoho podobností se systémovým softwarem tím, že komunikuje přímo s hardwarem, aby zajistil potřebné zvýšení výkonu.

Vývoj vestavěného softwaru má také mnoho podobností se systémovým softwarem v tom, že kód je psán tak, aby přímo komunikoval s hardwarem. Veškeré poskytované abstrakce jsou však obvykle spotřebovávány stejným softwarem a nelze je považovat za platformu.

Je důležité si všimnout aplikací, které sdílejí podobnosti s naší definicí systémového softwaru, protože se pravděpodobně setkáte s popisem těchto aplikací/pracovních míst těmito termíny (systémový software, systémoví inženýři atd.)

Systémové programování (+ jazyky)

Po definování systémů můžeme nyní definovat systémové programování jako činnost vytváření systémového softwaru pomocí systémových programovacích jazyků. Dost jednoduché, že?“

No, jednu věc jsme přeskočili, a to jazyky. Lidé často mluví o jazycích pro systémové programování ve smyslu „X je skvělý, je rychlý, kompilovaný a je to systémový programovací jazyk“. Ale jsou všichni zajedno v tom, co je to systémový programovací jazyk?

Podle našich definic systémů bych definoval kritéria pro systémový programovací jazyk takto:

• Kompilovaný do nativní binární podoby
• Může být sestaven bez závislostí na jiném softwaru (včetně jádra)
• Výkonnostní charakteristiky podobné jiným systémovým programovacím jazykům

Odmítnutí odpovědnosti: Toto je moje definice. Protože neexistují žádná stanovená kritéria, odvozuji definici z toho, co mi dává smysl vzhledem ke kontextu, v němž jsem systémový software definoval.

Kompilovat do nativní binární podoby

Pokud jazyk nelze zkompilovat do spustitelného souboru, který je přímo interpretovatelný procesorem, pak z definice běží na platformě (např. JVM, Ruby VM, Python VM atd.). Zde by se možná dalo argumentovat, ale pro jednoduchost si myslím, že toto je vhodné kritérium.

Žádné závislosti

Argument je podobný jako u kompilace do nativní binárky. Pokud jazyk ke svému spuštění vždy vyžaduje přítomnost nějakého dalšího softwaru, pak běží na platformě. Příkladem je jazyk Go a jeho přiložená standardní knihovna. Ta vyžaduje podporu operačního systému pro provádění základních činností, jako je alokace paměti, spawnování vláken (pro běh goroutin), pro svůj vestavěný síťový poller a další činnosti. I když je možné tyto základní funkce reimplementovat, vytváří to v tomto kontextu překážku pro použití a je snadné si představit, proč ne všechny jazyky, dokonce ani ty, které se kompilují do statických binárních souborů, jsou určeny jako systémové programovací jazyky.

Podobné výkonnostní charakteristiky

Tohle je tak trochu výmluva. Chce však říci, že v rámci systému jazyků typicky klasifikovaných jako systémové programovací jazyky by neměly být velké (řádově) rozdíly ve výkonnostních charakteristikách. Charakteristikami mám výslovně na mysli rychlost provádění a paměťovou efektivitu.

Zlatým standardem pro srovnání je jazyk C a/nebo C++, jak je často znázorněno ve srovnávacích benchmarcích, které měří rychlost provádění v tom, o kolik řádů jsou jazyky pomalejší než C/C++.

Jmenuji několik

Jazyky, které mě při výše uvedené definici okamžitě napadnou, jsou C a C++. Existují však i novější jazyky jako Rust a Nim, které tuto mezeru také vyplňují. Ve skutečnosti již existuje operační systém napsaný výhradně v jazyce Rust (RedoxOS) a jádro v jazyce Nim (nimkernel).

Povídejme si o jazyce Go

Již dříve jsem naznačil, že Go nemusí spadat do rodiny „systémových programovacích jazyků“. Nicméně stejně jako se všechny aplikace nedají pěkně rozdělit na aplikační a systémový software, ani jazyky se nedají rozdělit.

Často lidé Go označují za systémový programovací jazyk a dokonce na stránkách golang.org se uvádí:

Go je univerzální jazyk navržený s ohledem na systémové programování.

Nicméně ani toto není přímé tvrzení, že Go je systémový programovací jazyk, pouze to, že je s ohledem na něj navržen. Podle mého názoru stojí spíše někde uprostřed.

Ačkoli se Go kompiluje do nativních binárních souborů, obsahuje užitečné nízkoúrovňové koncepty (raw/unsafe ukazatele, nativní typy jako bytes a int32 a podporu inline assembleru) a je relativně výkonný; stále má některé problémy, které je třeba překonat. Go se dodává s runtime a garbage collectorem.

Runtime znamená, že pro běh v prostředích bez jádra bude nutné zavádění/nadřazování runtime. Tím se dostáváme spíše k vnitřní implementaci jazyka, která se může v budoucích vydáních změnit. Změny vyžadují další práci na zavádění s tím, jak se jazyk vyvíjí.

Kolektor odpadků (garbage collector, GC) buď znamená, že Go je omezeno v tom, v jakých aplikačních doménách jej lze používat, nebo že GC musí být vypnut a nahrazen ruční správou paměti. V případě, že GC nelze nahradit, doména reálného času (definovaná operacemi, které musí být dokončeny v daných časových mezích a/nebo se výkon měří v nanosekundách) by nemohla riskovat nedeterministické doby pauzy GC.

Software pro distribuované systémy

S rostoucím množstvím řečí o distribuovaných systémech a aplikacích, jako je Kubernetes, které se stávají velmi populární, slyšíme spoustu nových slovíček, kterým (pokud máme být upřímní) většina z nás plně nerozumí.

Do této chvíle jsem se setkal s používáním termínů systémové programování a systémový inženýr v kontextech, kde se ve skutečnosti myslelo distribuované systémové programování a distribuovaný systémový inženýr.

V tomto příspěvku jsme definovali systémový software, systémové jazyky a systémové programování. Když však mluvíme o distribuovaných systémech, význam slova systém se mění. A i když se zde nebudu nořit do konkrétních rozdílů (hlavně proto, že je sám ještě potřebuji lépe pochopit), je důležité, abychom tyto myšlenkové rozdíly dělali a používali přesnější řeč, když můžeme, abychom předešli zmatení těch, kteří se v tomto prostoru teprve učí.