Vícevláknové aplikace

S nástupem dvou a čtyřjádrovych procesorů se vícevláknové programovaní stalo jakýmsi zaklínadlem, kterým se bohužel ohánějí právě ti, kteří tomu nejméně rozumí. Velice často se můžeme na odborných serverech setkat s kritikou programátorů, kteří prý nejsou schopni držet krok s technologií a začít psát svoje aplikace vícevláknově. Většinou tyto komentáře zaznívají od osob, které samy nikdy nic nenaprogramovaly a programovaní si představují jako hurvínek valku. Protože mě tyto rádoby chytré poznámky už unavují, pokusím se vysvětlit, proč programátoři nepíší svoje aplikace vícevláknově a zaměřím se převážně na hry u kterých je porovnávání nárůstu výkonu na vícejádrovych procesorech a spílání programátorům nejčastější.

Důvod první

Nejčastější problém, který si lide jaksi neuvědomují, je ten, že některé věci prostě nelze paralelizovat. Názory jako, že jedno jádro procesoru přece může počítat fyziku, druhé umělou inteligenci a třetí vykreslování jsou směšné. Nemůže. Aby se mohlo vykreslovat, je třeba nejprve spočítat, kde se co nachází. K tomu musí nejprve proběhnout fyzikální engine. Jenže ten potřebuje vědět, kdo se co snaží udělat a proto před ním musí nejprve proběhnout výpočty AI. Je zřejmé, že tyto úrovně výpočtu musí proběhnout sekvenčně a nelze je provést paralelně. Více jádrový procesor je vám v tomto okamžiku k ničemu. Typický postup je v tomto případě neparalelizovat celou herní smyčku, ale pouze její části. Například vykreslovaní (rendering), probíhající na grafické kartě, je úlohou, která se paralelizuje velmi snadno a také se tak dnes děje. Podobně můžete postupovat i u fyzikálního enginu a AI, i když zde už je díky vzájemným interakcím problém o dost složitější. Tímto postupem tedy dosáhneme určitého zrychlení, ale většinou značně omezeného. U her nelze očekávat zrychlení jakého dosahují např. aplikace pro zpracování videa nebo raytracing, což jsou snadno paralelizovatelné úlohy, kde může být škálování výkonu na vícejádrových procesorech téměř lineární. To ovšem není problém pouze her, ale i spousty jiných aplikací.

Důvod druhý

Když už se tedy odhodláme paralelizovat aspoň určité části herní smyčky narazíme na další úskalí a tím je obtížnost vícevláknového programování. Kdo nezkusil neuvěří, ale je to opravdu zcela jiná liga. Největším problémem je to, že celý systém se najednou začína chovat značně nedeterministicky a je třeba mít vše opravdu dobře ošetřené. Na řadu přicházejí různé semafory, monitory či kritické sekce. Ale ani v případě, že jsou dobře umístěné nemáme vyhráno a stále nám hrozí problémy jako uváznutí a další na které v jednovláknové aplikaci nemůžete narazit. Taková aplikace je mnohem více náchylná ke vzniku různých skrytých bugů (nezávisle na schopnostech programátora) a co je horší je opravdu hodně hodně těžké tyto bugy v paralelně běžících vláknech vůbec najít. Jednovláknovou aplikaci si programátor v debuggeru odkrokuje a snadno zjistí kde je co špatně. U vícevláknové to udělat nemůže, protože systém se bude chvat pokaždé jinak. U her s velmi složitým virtuálním světem a velkou spoustou vzájemných interakcí se nám vše posouvá do ještě vyšší dimenze obtížnosti. Z tohoto důvodu se vývojáří, abych tak řekl, nepouští do žádných větších akcí a většinou se uchylují k paralelizaci pouze snadno oddělitelných částí. Typicky to může být například výpočet pohybu oblohy, či publika u sportovních her, který nijak nesouvisí s ničím ostatním.

Důvod třetí

Žádný z programovacích jazyků, které se dnes běžně k vývoji her používají neposkytuje dostatečně příjemné nástroje pro vývoj vícevláknových aplikací. Tím myslím nástroje předcházející chybám programátora a umožňující snadné označení kritických sdílených datových bloků. Programátor je jen člověk a množství problémů, které mohou nastat, začíná občas překračovat únosnou mez. Všechny programovací jazyky jako C/C++/Java/C# ale zaujímají postoj „já nic já muzikant“ či „udělej si sám“. Veškerá odpovědnost leží na programátorovi, který si musí veškerou synchronizaci a vše ostatní ohlídat sám pomocí již zmíněných semaforů, monitorů, vyjímek a dalších nástrojů. A to opravdu není jednoduché. Důkazem budiž prezentace Tima Sweeneyho, vedoucího vývoje společnosti Epic (výrobce hry Unreal Tournament 3) a jednoho z nejlepších vývojářů současnosti, kde si právě na tyto problémy stěžuje. Odkaz na prezentaci můžete najít níže.

Důvod čtvrtý

Souvisí úzce s předchozím. Když uvážíme o kolik je naprogramování hry čí jiné více vláknové aplikace náročnější ať už na znalosti programátorů, čast nutný k nalezení chyb, apod. dostáváme se k otázce, zda se nám to vůbec vyplatí. Zrovna u her je odpověď často NE. Je tomu z toho důvodu, že pro dnešní hry je limitujícím faktorem spíše grafická karta. Na výkonu procesoru už téměř nezáleží (viz. například současná marketingová akce firmy nVidia ve stylu „CPU is dead“). Úzké hrdlo tedy leží zcela mimo CPU a je zbytečné ztrácet čas a peníze nějakou optimalizací v tomto místě. Podobná úzká hrdla můžeme ale najít i u jiných aplikací než her, ve většině případů to bude, snad nejpomalejší součást dnešních počítačů, pevný disk.

Není ovšem třeba házet flintu do žita. Vícejádrové procesory jistě smysl mají, ať už pro běh více aplikací současně nebo pro úlohy, které dokáží jejich potenciál využít. A takových existuje dost. Hry mezi ně ale nepatří a asi ještě chvíli patřit nebudou, stejně tak spousta dalších aplikací. S tím je třeba se smířit a pochopit, že ne vždy to je jen kvůli lenosti nebo neschopnosti programátora.

Zdroje:

• Game Programming in a Multi Core World
• The next mainstream programming language