Jak šel čas

Kompilace předevčírem

V dávných dobách byla kompilace postrachem počítačového lidu. Internet nebyl zdaleka tím, čím je dnes. Bylo nutné vynaložit značné úsilí a program vyhledat a stáhnout. Portabilita neexistovala a bylo téměř vždy nutné program pro místní verzi Unixu mírně upravit, dnes bychom to nazvali portací.

Počítače byly pomalé, paměti bylo málo a uživatelů mnoho. Na stroji typu 386SX/25 s 8MB RAM pracovalo najednou zhruba šest uživatelů. Pokud se administrátor rozhodl něco překládat, byl proklínán uživateli jak jen to šlo, jelikož systém získal odezvu, která by příslušela spíš 2400 BPS lince než Ethernetu. Jen velcí hrdinové úspěšně zdolali nástrahy zlých linek, úprav pro místní UNIX, neexistující dokumentace, malého místa na disku, a brblajících uživatelů...

Kompilace byla také výborné strašidlo začínajících administrátorů: To FreeBSD není systém pro slabé stroje - kompiluje se celý týden! Pochopitelně jsme začátečníky strašili, dalo se to stihnout během pěti dnů normálního provozu.

Kompilace včera

Kompilace pozvolna přestávala býti doménou hrdinů. Výrobci začali pozvolna implementovat normu POSIX a GNU dodalo balík autoconf. Spolu s rostoucím počtem opensource programů taky zapracoval trh a nekompatibilní Unixy vyhynuly. Nikdo je nekupoval, protože na nich nešlo nic pořádně přeložit a výrobcem dodaný software přestával již stačit.

Pro uživatele, kteří si nic kompilovat nechtěli, začali vznikat různé snadno instalovatelné distribuce OS Linux vybavené vším potřebným. Ne všichni vítali tyto technické novinky s nadšením. Kompilace X-Windows sloužila jako vhodná záminka pro zakoupení většího disku, více paměti, rychlejšího CPU, ...

Kompilace dnes

Trend postupného snižování mystéria kompilace pokračoval. S postupně vzrůstající rychlostí počítačů se začaly množit tzv. Linux source distributions (Gentoo, Source Mage), kde je kompilace softwaru ze zdrojových textů nejen zpřístupněna uživatelům, ale je to preferovaná metoda administrace. Kompilace ze zdrojových textů je též tradiční u operačních systémů z rodiny BSD, kde je běžné používat binární soubory jen pro prvotní instalaci systému.

---

Distcc

Nejčastější námitkou proti kompilování ze zdrojových textů oproti použití binárních balíčků je čas strávený kompilací. Ten může být u větších projektů značný, zejména pokud se jedná o programy napsané v C++. GNU C++ překladač totiž nepatří zrovna k těm nejrychlejším. Jednou z tradičních možností jak zrychlit kompilaci je využití více počítačů k čemuž právě složí výše zmiňovaný program distcc.

Distcc je navržen jednoduše. Této technice návrhu se říká "Worse is Better" -- jednoduchost návrhu a implementace je prioritou. Osobně se mi tato metodika návrhu velmi líbí, byla použita například při návrhu protokolu HTTP.

Překlad programu v jazyce C/C++ se skládá ze tří hlavních částí: preprocesor, kompilátor a assembler. Distcc spouští preprocesor lokálně a pro zbylé dvě fáze použije jeden z přednastavených strojů. Takto sice ztratíme možnost distribuce všech fází kompilace, ale nebudeme muset synchronizovat hlavičkové soubory mezi jednotlivými systémy, což sníží nutnou administraci našeho clusteru na minimum.

Instalace distccd

Pokud naše distro distcc neobsahuje stáhneme, přeložíme a nainstalujeme výsledné binárky. Na každém ze strojů, které chceme používat jako distcc server, je nutné zajistit spuštění distccd démona. Toho je možné dosáhnout několika způsoby: standalone daemon, spouštění z inetd, spouštění z programů pro správu procesů jako je init, daemontools, supervise. Autoři doporučují standalone démona z důvodu možnosti kontroly počtu současně připojených klientů.

Jelikož většina moderních inetd umí totéž, rozhodl jsem se z důvodu snazší správy pro inetd. Základní inetd konfigurace je následující:

Protokol neobsahuje autentifikaci, proto je nutné k blokaci nežádoucích klientů použít externí metody (tcpwrapers, inetd, xinetd, firewall, ...) nebo přepínač --alllow distccd, který pracuje v standalone verzi. Ještě bych jen dodal, že distcc umí používat i ssh jako transport, což sice řeší problémy s autentifikací, ale je to značně pomalé.

Na klientech budeme potřebovat binárku klientské části - distcc. Jen tak pro zajímavost distribuční balík obsahuje ještě monitorovací program distccmon, který pracuje v textovém i grafickém (GTK) módu.

Kompilátory

Pozornost je třeba věnovat také kompilátorům nainstalovaným na distcc serverech. Všechny kompilátory musí mít jednotnou architekturu a ABI. Nemusí se vždy jednat o stejné verze kompilátorů. Lze použít například mix GCC 3.4 a 3.3, nikoliv však už g++ 3.4 a g++ 3.3, protože zde došlo ke změně ABI. Použití stejných operačních systémů není potřeba, používal jsem bez problémů ke kompilaci GCC z různých operačních systémů (FreeBSD, Linux, NetBSD). Patchované GCC, které je například součástí OpenBSD jsem nezkoušel.

Nastavení klientů

Nastavení klientů se skládá ze dvou částí: konfigurace seznamu distccd severů a konfigurace build systémů. Tento seznam lze uložit do proměnné prostředí DISTCC_HOSTS nebo do konfiguračních souborů ~/.distcc/hosts případně /usr/local/etc/distcc/hosts. Použití proměnné prostředí se příliš nedoporučuje, protože některé build frameworky například SCons neimportují automaticky všechny proměnné do build systému.

Běžně používaný formát konfiguračního souboru či proměnné je jednoduchý. Jedná se o seznam stroj/počet procesů oddělený mezerami. Při konfiguraci počtu procesů pro jednotlivé stroje zodhledněte nejen jejich rychlost a vytížení, ale také fakt, že přenos souboru po síti také něco trvá a pokud například nakonfigurujete 4 procesy, budou běžet zhruba 2.5 procesu, zbytek bude blokován síťovými operacemi.

Distcc postupuje při distribuci procesů mezi jednotlivé stroje zleva doprava. Pokud je potřeba spustit další proces, najde se první stroj s volným slotem. Proto se doporučuje dávat nejrychlejší stroje na čelní místa seznamu.

Další věcí, kterou je třeba zohlednit, je taktické umístění serveru localhost do seznamu. Kompilace na lokálním stroji je rychlejší, protože není potřeba data nikam přenášet, na lokálním stroji také běží preprocesor pro všechny stroje, což spotřebuje jistý výpočetní výkon.

Pokud je lokální systém srovnatelně rychlý se vzdálenými systémy doručuje se konfigurace localhost/2 vzdálený server/4, pokud je localhost pomalejší doporučuje se localhost/1 a pokud je hodně pomalý například 120MHz notebook vs. 2GHz servery, doporučuje se localhost do seznamu nedávat. Na druhé straně i pokud je localhost rychlý nedoporučuje se více procesů než 2, pokud se zrovna nejedná o SMP stroj.

Nastavení build systému

Konfigurace build systému je velmi jednoduchá. Jediné co musíme udělat, je nastavit distcc jako překladač a povolit více překladů současně. Obvykle se to dělá pomocí make -j10 CC=distcc. U systému SCons se oproti make projeví vliv distcc více, jelikož make překládá po adresářích, zatímco SCons globálně.

Pro správnou funkci distcc je nutné, aby měl build systém k dispozici správné závislosti, což není problém u SCons a většiny projektů používajících automake. Pokud jsou závislosti chybně uvedeny nebo zcela chybí, doporučuji použití make -j10 -k a až přeložíme vše, co projde, tak se pokusit dopřeložit zbytek pomocí klasického make.

Praxe

Budeme překládat balík FSP s využitím build systému SCons. Překlad probíhal na 150MHz počítači s využitím 1.5GHz distcc serveru. Na pomalém počítači běžel jen preprocesor a linker, ale i to jej zdržovalo natolik, že na něj musel rychlejší počítač většinu doby čekat.

Overhead build systému	14.1 sec
Lokální build	85.0 sec
Distribuovaná kompilace	52.7 sec

Z tabulky vidíme, že jsme dosáhli zhruba dvojnásobného zrychlení. U C++ projektu, např. Blender, bychom dosáhli zrychlení mnohem většího. Místo Blenderu jsem použil pro ukázku FSP jelikož CVS verze Blenderu zrovna nešla přeložit. V každém případě lze distcc jen doporučit, instalace je snadná, údržba nulová a kompilace tak dostanou nový rozměr.