K experimentům jsem použil Clarktech ET9000. Ten má procesor MIPS (na 400 MHz), 128MB úložiště na desce (flash) a 512MB operační paměti (a ještě 8 MB pro bootloader). Operačním systémem je upravený Linux a nad ním Enigma.

Samotný systém (aspoň ten, co tam byl původně) není příliš stabilní. Po několika počátečních experimentech se přijímač zaseknul a po restartu už nenabootoval. Po rutinním flashnutí nového bootloaderu (přes USB) taky nenabootoval, tak nezbylo než flashnout celý nový image. Takto jsem poněkud nedobrovolně updatoval na nejnovější verzi Enigmy a mohl začít s vývojem.

Enigma je napsaná v C++ a původně se v něm psaly i pluginy. Jenže kompilovat pro MIPS je neskutečný vopruz, a tak se vývojáři rozhodli (ve verzi Enigma2) poskytnout pro pluginy jen nativní rozhraní a psát jen v nějakém (interpretovaném) jazyce na vyšší úrovni. Volba padla na Python.

O Pythonu jsem do té doby nevěděl téměř nic. Naštěstí je snadný na naučení a navíc dost dobře navržený. Jedná se o dynamický jazyk výrazně inspirovaný Smalltalkem, ovšem s několika vychytávkami navíc. Předně má něco na způsob doesNotUnderstand, takže v něm snadno napíšete proxy. Má generátory (yield), iterátory a "správu kontextů" (tím je myšleno něco na způsob using a IDisposable v C# pro korektní správu nepaměťových zdrojů). Python, ač primárně objektově orientovaný, podporuje také funkcionální styl programování. A v neposlední řadě moderní překladače podporují JIT.

Zajímavě je řešena správa paměti. Používá se čítač referencí a navíc klasický mark-and-sweep GC pro cykly referencí. Pokud jste dobří a referenčním cyklům se umíte vyhnout, můžete GC vypnout. Toto chování bylo důležité pro volbu Pythonu jako jazyka pro pluginy v Enigmě, protože tehdy byla operační paměť v běžných přístrojích opravdu malá a latence byla znát.

Celé řešení tak trochu připomíná Windows Phone 7 posazený na prastarém Windows Mobile. Aplikace sice píšete ve verzi Silverlightu, ale ten jen obaluje staré dobré (nebo špatné?) COM objekty. V Enigmě máte jádro v C++ a nad ním Python. Vzhledem k tomu, že typický plugin tak nanejvýš zobrazí seznam programů, umožní vám přidat časovač pro nahrávání, případně zobrazí obraz v obraze, není nic výkonnějšího potřeba. Navíc pro Python existuje množství knihoven, takže nic vám nebrání v pár řádcích načíst data, např. předpověď počasí, z nějaké webové služby a zobrazit je na obrazovce přes právě běžící program.

Lidé mají různé koníčky. Někdo sbírá známky, někdo brouky, někdo jezdí po práci na zahrádce s bagrem a někdo se soudí, kudy chodí. Nevím, jestli Larry Ellison vlastní kromě několika jachet také bagry, ale soudy jsou evidentně jeho vášní. V poslední době budí pozornost proces Oracle vs. Google. Android se prostě hlavně díky nízkým cenám rychle rozšířil a každý chce svůj kus koláče. Microsoft na to šel lstivě a místo frontálního útoku zaútočil na mnohem slabší soupeře, tj. výrobce hardwaru, což mu vynáší několikanásobně více než vlastní Windows Phone 7 (nemluvě o štědrých dotacích pro Nokii). Oraclu něco takového asi připadalo nedůstojné, protože zažaloval přímo Google. Obě obří firmy se hádají o použití Javy v Androidu, již Oracle převzal společně se Sunem.

Sázka na patenty Oraclu nevyšla (soud některé nepřipustil a patentový úřad jich několik dokonce zneplatnil) a běžný objekt chráněný autorským zákonem, tedy kód, používá Google pouze svůj. A zde se situace začíná podobat výše zmíněnému sporu mapučských indiánů s Microsoftem. Oracle začal tvrdit, že vlastní API Javy a Google mu musí platit, i když kromě zmíněného API je vše ostatní jeho vlastní produkce, tedy zejména knihovny a virtuální stroj (VM). Ano, je tu jeden podstatný rozdíl, mapudungun je přirozený jazyk, zatímco API Javy je uměle vytvořené. Nicméně celé to je stejné, jako kdyby Ústav pro jazyk český (nebo nějaká jiná hypotetická autorita) prohlásil, že cizinci sice mohou mluvit česky, ale nesmí přitom používat česká slova.

Výsledek procesu bude, narozdíl od mapučské frašky, zásadní pro celé odvětví IT. Rozhodovat bude porota, v níž sedí například řidič autobusu, sekretářka nebo listonoš (ne, to není vtip).

std::function<void()> lambda = ^{ /* neco */ };

(Při překladu je nutné použít volbu -stdlib=libc++, se standardním libstdc++ se kód nepřeloží.)

Člověk by přitom naivně předpokládal, že vzhledem k explicitní deklaraci se už o správu paměti nemusí starat. Jenže pokud proměnnou lambda například vrátíte z funkce, blok zanikne (protože je na zásobníku). Zdá se, že pro vývojáře clangu je více než bezpečnost důležitější maximální výkon (a proto nechávají blok na zásobníku). Dokud tedy nebude clang podporovat lambda výrazy podle C++11, zůstaneme odkázáni na vlastní wrapper, jenž korektně (a transparentně) překopíruje blok v případě potřeby ze zásobníku na haldu.

Sám tvůrce C++ Bjarne Stroustrup vysvětluje, jak správa paměti vzhledem k objektům funguje, nemá cenu vše opakovat. Stručně shrnuto, díky RAII se paměť uvolňuje automaticky, jakmile se proměnná dostane mimo lexikální rozsah platnosti, čímž je zajištěna korektkní správa paměti i v případě výjimek nebo jiného typu opuštění funkce někde zprostředka. Pokud se instance objektu nepředává referencí, typicky se použije move konstruktor (jeho použití si lze vynutit v případech, kdy by ho překladač nepoužil explicitně). Celá STL tyto konstruktury používá. Kdo se chce vyhnout move sémantice úplně, použije shared_ptr (nebo nějaký jiný xxx_ptr podle toho, co vlastně potřebuje) a k tomu make_shared, čímž opět přenechá správu paměti překladači a STL.

Výhoda GC spočívá v deterministické alokaci (v C++ můžete mít svůj alokátor, ale ten standardní deterministický není). Platíte za to ovšem nedeterministickým uvolňováním paměti (a hlavně vyšším footprintem). Opět lze namítnout, že existují deterministické GC, jenže ty se používají jen ve speciálních případech (typicky real-time systémech, i když tam se většinou GC nepoužívá vůbec), neboť mají spoustu jiných nevýhod.

Kdo stále ještě nechápe, nechť se prosím nevěnuje programování.

P.S. Některá rozšíření C(++) jdou ještě dále, co se týká činnosti překladače. V Objective-C(++) se díky ARC nemusíte starat o uvolňování, prostě jen alokujete. Navíc překladač inteligentně vyhazuje instrukce pro aktualizace čítače referencí všude tam, kde nejsou potřeba, a takových případů je většina (pokud to řeší knihovna bez podpory překladače, jako např. STL, není taková optimalizace možná). Velice podobnou optimalizaci ma C++/CX ve Windows 8, také jen alokujete (pomocí ref new) a instrukce pro správu čítače referencí generuje překladač jen tam, kde jsou nezbytné.

P.P.S. Je vhodné doplnit (v reakci na diskusi), že použití operátoru new se lze prakticky vždy vyhnout. Je-li z nějakého důvodu žádoucí použít explicitní ukazatel, nahradí jej make_shared. Jedinou výjimkou, která mě napadá, je použití nativní třídy v řizené třídě v C++/CLI. Tam překladač vyžaduje raw pointer. K uvolnění paměti se na první pohled nabízí metoda !Trida (finalizér). Správné je ovšem použití řízeného destruktoru ~Trida.

Mějme například tento vstup:

NSString* text = @"The girl reads books.";

Obvyklým způsobem můžeme získat instanci taggeru:

NSLinguisticTagger* tagger = [[[NSLinguisticTagger alloc] initWithTagSchemes: [NSArray arrayWithObject: NSLinguisticTagSchemeNameTypeOrLexicalClass] options: 0] autorelease];

Použití je velmi jednoduché:

[tagger setString: text];
[tagger enumerateTagsInRange: NSMakeRange(0, [text length])
scheme: NSLinguisticTagSchemeNameTypeOrLexicalClass
options: 0
usingBlock: ^(NSString* tag, NSRange tokenRange, NSRange sentenceRange, BOOL* stop) {
if ([tag isEqualToString: NSLinguisticTagWhitespace] == NO) {
NSLog(@"%@ %@", [text substringWithRange: tokenRange], tag);
}
}];

Výsledkem bude toto:

The Determiner
girl Noun
reads Verb
books Noun
. SentenceTerminator

Samotné POS tagy (POS=part of speech, tedy slovní druh) pocházejí z primitivní databáze. Mnohem složitější je ale zjednoznačnění. Zkuste například tento text:

NSString* text = @"The flight he books.";

Zcela v souladu s anglickou gramatikou dostaneme pro slovo books nyní "books Verb". Možná vám to přijde samozřejmé, ale algoritmy pro tagger jsou velmi složité, buď jde o nějaký typ unifikační gramatiky, nebo o HMM (Hidden Markov Model) založený obvykle na trigramech vzatých z ručně anotovaného korpusu. Obvyklejší je asi použití HMM, neboť se dá vyvinout rychleji (stačí nějaký dostatečně velký anotovaný korpus). Přiřazení tagů slovům se provede Viterbiho algoritmem.

Pro většinu úloh je sice tato třída nedostatečná (dává jen POS, ne další většinou nezbytné informace o morfologii), ale pro základní hraní třeba s bezkontextovými gramatikami postačuje.

NB: Pokud vás zajímají všechny možné tagy pro dané slovo, můžete použít metodu possibleTagsAtIndex.

Porovnání není úplně košer (o to ani nešlo), na G4 jsem použil GCC 4.8 (clang by tam šel dost těžko), naopak pro ARM jsem kód přeložil clangem (z GCC bych na ARM nedostal novou standardní knihovnu). Výsledky jsou nepříliš překvapivé.

"Stará" gé-čtyřka je zhruba stejně rychlá jako A4 (procesor ve starých iPadech a iPhonech 4). Procesor A5 (stejně jako ona A4 na 1 GHz) je o 30-40% rychlejší (kód běžel na jednom jádře). Jinými slovy, na čem mi před pár lety běžel javovský server s rozsáhlým podnikovým systémem, teď nosím v kapse (a současné počítače jsou pochopitelně mnohem rychlejší, i5 na 1,7 GHz cca. pětkrát, opět pouze na jednom jádře). Jsem velice zvědavý na výkon nové generace ARM procesorů, které se snad už brzy dočkáme (ne že by to v mobilu k něčemu bylo...).

Připomeňme, že Apple, ať už s ARC nebo bez, automaticky zvyšuje čítač referencí (pokud se nepoužije __block, __weak nebo podobný modifikátor), přičemž bloky (obdoba lambda výrazů podle normy) včetně kontextu (closure) kopíruje ze zásobníku na haldu automaticky. Dokud nevytvoříte referenční cyklus (což je u bloků poměrně časté, aniž by si toho člověk všimnul, vzhledem k implicitnímu self u instančních proměnných), vše šlape hladce (blok samotný se chová jako ObjC objekt a má svůj čítač referencí).

V říjnu jsem na tento problém ve WinRT upozornil (na fóru a následně v bug trackingu), reakce byla (po řadě) skepse ("to je tak jednoduchý koncept, tam nemůže být bug"), údiv, uznání a nakonec slíbení nápravy v beta verzi. Schválně si to zkuste teď, co myslíte, došlo k opravě?

Vzhledem k velké výpočetní i prostorové složitosti algoritmu se používá pro parsing dynamické programování. Speciální datová struktura chart reprezentuje dílčí zpracované podřetězce, čímž výrazně zvyšuje rychlost parsingu (omezením backtrackingu, algoritmus ovšem i nadále zůstane exponenciální).

Chart parsing je typu bottom-up, takže nemá problém s levou rekurzí a v případě zkracujících pravidel vždy skončí (takové gramatiky ovšem nejsou v praxi běžné). Časová náročnost algoritmu není u reálných gramatik až tak strašná, vzhledem k používání dalších omezujících podmínek (subkategorizace) je parsing většinou polynomiální. Spolehnout se na to ale nelze.

Koho problematika zajímá, snadno na internetu najde články k tématu např. od Hanse Uszkoreita.

Jak je to s těmi procesory

Panu redaktorovi asi uniklo, že Microsoft právě toto už nějakou dobu dělá. Podle dosud známých informací víme, že Windows 8 na procesorech ARM nebude podporovat jiný typ aplikací než Metro (tyto aplikace poběží nad novým WinRT), a také víme, že nová verze OS pro Windows Phone bude také využívat WinRT (jen zatím nevíme, jak se bude jmenovat). Jinými slovy, pokud napíšete aplikaci pro Metro, poběží na desktopu, tabletu i telefonu bez sebemenšího zásahu do kódu (krom přízpůsobení GUI pro různou velikost displejů). Jen ji musíte přeložit pro Intel i ARM.

Zpětně se ukazuje, že systém Windows Phone 7 měl jen vyplnit mezeru mezi zoufale zastaralým předchůdcem a zcela novým WinRT ve Windows 8. Současné aplikace pro WP7 pochopitelně na novém systému poběží (snal lépe než androidí aplikace na Blackberry) a vývojářům konečně nikdo nebude diktovat, jak a v čem můžou psát své aplikace. Je příznačné, že ze všech velkých mobilních OS pouze pro WP7 nelze psát v C++, což je možná jedno pro GUI, ale ne pro složité knihovny, jejichž vývoj stál pár člověkolet.

Moderní OS, moderní vývoj

Řízený kód se všemi vymoženostmi od snadné přenositelnosti přez bajtkód až po primitivní (z hlediska programátora) správu paměti je možná vhodný pro serverové aplikace, ovšem už méně pro mobilní zařízení. Byť dnešní slušné tablety už vesměs mají 1GB RAM, výkonnou grafiku a dvoujádrový procesor ARMv7 je pekelně rychlý (i pro většinu výpočetně náročnějších algoritmů), stále je ale nutné kód (OS i aplikací) psát s ohledem na cílové zařízení, což v první řadě znamená brát ohled na výdrž baterie. První to pochopil Apple, nicméně i vyjádření S. Sinofského na jeho blogu se nesou ve stejném duchu: zpět k nativnímu kódu, minimalizovat spotřebu RAM (čím více RAM, tím větší spotřeba energie), omezit multitasking.

Klíčem k vývoji pro Windows (Phone) 8 je nová verze C++ - C++11 (dříve C++0X). Nebyl by to Microsoft, aby si ho nepřiohnul k obrazu svému (ano, mám na mysli C++/CX), to je ovšem jen trošku modernější (a implementačně podařený) klon Objective-C a jeho rozsáhlých knihoven (Cocoa a spol.).

Úspěch?

O tom, zda bude Windows 8, ať už na tabletech či telefonech, komerčním úspěchem, rozhodne nikoliv technologická vyspělost systému, ale - ne, překvapení se nekoná - prodejní strategie. Pokud pominu vizuální vzhled Metra (ten nijak nehodnotím, je to subjektivní záležitost), jde o to mít kvalitní hardware za rozumnou cenu. Microsoft si se svou pověstí a historií těžko může dovolit prodávat průměrný tablet za 500 dolarů nebo dokonce ještě více. Dobrý hardware (něco à la Playbook, tedy dvoujádro, 1GB RAM, kvalitní zpracování) s Windows 8 za cenu tabletu Amazon Fire by si svůj trh snad najít mohl.