Author Archives: Mar3ek

About Mar3ek

Been there, done that... Hlavne študent informačných technológií, softwarový inžinier a all-round tech junkie.

Tento raz o Androide

A) Zase raz technický článok (ale sľubujem, že onedlho sa dokopem aj k niečomu, čo nie je samý bit a byte). B) Neviem, do akej miery som s týmto názorom v menšine, ale čo je moc, to je moc.

Včera večer mi píše šéf, že sa mu na stôl dostala taká drobnosť. IT oddelenie jednej firmy chce vyvíjať aplikáciu pre Android, ale z nejakých dôvodov sa im to nejak nedarí rozchodiť, tak či by som sa na to nepozrel. Aplikácia má vziať súbor vybraný používateľom a zašifrovať ho pomocou AES. Je v tom ale drobný háčik – z nejakých dôvodov chcú použiť na šifrovanie natívny kód, nie Javu. A že keď im s tým pomôžeme, urobíme si očko

Tak som sa do toho, aj cez nechuť (fakt nemám rád Javu a pri pohľade na Eclipse IDE sa mi dvíha žalúdok), pustil. Stiahol som JDK, Android SDK a Android NDK. Rozbalil, nastavil cestu, rozbalil dodané zdrojáky a začal písať.

So far, so good. A potom som chcel ten kód spustiť. Nastavil som emulátor a spustil ho. A čakal. A čakal viac. A čakal ešte trochu. Už som z toho mal pocit, že sa snáď nedočkám, keď mi naskočil home screen. Prečo to ale muselo trvať pomaly 5 minút? A nie, nebolo to mojím hardwareom – pracujem na workstation, čo má v sebe Intel i7-3770k (4 + 4 jadrá), 24 GB RAM (na frekvencii 2133 MHz) a grafický čip GeForce GTX 680.

A keď sa potom spustila mnou debugovaná aplikácia, skoro ma zhodilo zo stoličky, jak to bolo pomalé. Kliknutie na tlačidlo malo lag snáď pol sekundy. WTF, Google? Ja uznávam, že emulátor a všetko, ale AŽ TAK?

Keď som sa v tom začal hrabať, našiel som krásne malé zaškrtávatko “Use host GPU” v nastaveniach emulátora. Ktoré bolo samozrejme defaultne vypnuté, takže sa všetko renderovanie v tom virtuálnom strori robilo v software. Opäť – prečo? Máme rok 2014, väčšina developerov má procesory Intel alebo AMD so vstavanou grafikou, ktorá zvláda kde čo. A niektorí majú aj grafiky diskrétne. Tak PREČO je GPU rendering defaultne vypnutý?

Prepnutím na GPU rendering sa použitie emulátora zlepšilo – z nepoužiteľného sa stalo len neznesiteľným. Príklad – načítanie cca 4kB súboru trvalo v Jave cca 15 sekúnd. Trochu moc, nie? Keď si človek uvedomí, že emulátor beží lokálne a s IDE je spojený TCP spojením.

A to ani nebudem zabiehať do interoperability managed/native v podaní Android NDK. V momente, keď má signatúra metódy v sebe 4 podtržítka a je dlhá cez 150 znakov, niečo bude asi zle, povedal by som. Plus, kompilácia native kódu neprebieha ako build step v IDE, človek si to musí skompilovať manuálne pomocou command line.

Áno, Android je Linux-based platforma. Áno, je to založené na Jave. A áno, nástroje pre Windows sú pravdepodobne cross kompilované z Linuxovej verzie. Ale na takto pomalom a otravnom dev stacku sa fakt nedá poriadne programovať. Ak by som sa mal niečím podobným živiť, asi by ma čoskoro vystrelo.

Bottom line: môj názor na Android dev stack pre Windows je, že Android dev stack pre Windows je prudko neadekvátny. Rozhodne nekonečne zaostáva za štandardmi, na ktoré som v našej brandži zvyknutý a ktoré očakávam.

Pre zaujímavosť, nedávno som programoval pre Windows Phone 8.1 a to bol zážitok veľmi pozitívny – virtuálne stroje (manažované pomocou skutočného Hyper-V) štartovali v sekundách, odozva emulátora bola takmer okamžitá a deploy debug verzie bol okamžitý.

Nedá mi to nepovedať jedno – Visual Studio a spol. sa naďalej ukazuje ako najpokročilejšie IDE na planéte. Screw Eclipse.

Reklamy

Prvá Windows Phone aplikácia

Toto bude opäť jeden z tých technickejších (ako tak pozerám, mení sa to tu na tech-blog 🙂 ).

Keď Microsoft prvý krát predstavil platformu Windows Phone (verzie 7), nebol som z nej práve nadšený. Zariadení bolo málo a aj keď bol vývojársky toolset veľmi pokročilý, platforma ako taká bola dosť obmedzená vo svojich možnostiach.

Časy sa ale zmenili a približne týždeň testujem na svojej Lumii 520 systém Windows Phone 8.1 (Dev Preview). Konečne sa z Windows Phone stala platforma, ktorú som na telefóne vždy chcel mať – prehľadná, rýchla, mocná a s podporou programovania v .NETe a Visual Studiu.

Ponuka aplikácií je ale stále relatívne malá (aj keď každým dňom rastie). Jedna z vecí, čo mi pre WinPho 8.1 chýba, je aplikácia, ktorá by dokázala otvoriť môj KeePass trezor.

KeePass je open-source nástroj na uchovávanie hesiel – človek si uloží heslo do služby X do trezoru, trezor zašifruje heslom a keď ho potrebuje, otvorí si trezor a heslo si prečíta. Stačí si tak pamätať len heslo k trezoru a všetky ostatné heslá máte na dosah ruky.

Existujú neoficiálne porty KeePass-u pre WinPho, ale len verzie 7. Tieto verzie stále na najnovšej verzii fungujú, ale často buď nie sú zdarma, alebo obsahujú reklamy. Tak som si povedal, že toto im trpieť nebudem a napíšem si port vlastný.

Ani to dlho netrvalo – od myšlienky k publikácii presne 7 dní. Dnes som moju aplikáciu (menom WinKee) odoslal do Windows Phone Store. Do pol hodiny mi prišiel mail o tom, že moja aplikácia úspešne prešla certifikáciou a bude do niekoľkých hodín zverejnená. Už sa neviem dočkať 😀

Pocity z vývoja a celého toho procesu mám celkom dobré – toolset pre WinPho 8.1 je skvelý, emulátory zariadení fungujú bezchybne a nie je problém ladiť ani na skutočnom telefóne. Proces certifikácie a publikovania je dobre zdokumentovaný a relatívne priamočiary.

Celkovo vzaté, s takto malou aplikáciou určite neurobím dieru do sveta, ale bolo príjemné si to vyskúšať a pridať tak ďalšiu položku do životopisu – “Vývoj pre Windows Phone, vrátane publikovaných aplikácií”.

 

Človek aby pomaly začal veriť na zázraky

Nijak inak sa to asi povedať nedá. Situácia: máme v práci projekt, na ktorom stoja celkom veľké peniaze a prestíž, ak by sa nám ho podarilo dodať a predať. Deadline bol nastavený na dnes. Kvôli iným projektom sa to ale tak celkom nestíhalo a tak sme to posunuli na piatok.

Dnes ráno bolo jasné, že to aj tak nestíhame úplne bezproblémovo a bude treba asi potiahnuť dlhé nočné hodiny. A ráno dorazí e-mail od klienta, pre ktorého to vyrábame, že majú momentálne plné ruky práce a či by sme to mohli posunúť na nejaký dátum o tri týždne.

Nasleduje veľké odfúknutie. A tak sme získali čas, aby sme projekt nie len dokončili v takej podobe, ako sme pôvodne zamýšľali, ale potiahli ho ešte o dva kroky ďalej. Hlavne to musíme celé nepremrhať.

Ale toto sú práve momenty, keď si človek v našej brandži povie, že sa stal zázrak 😀

OpenCL, nVidia a rozuzlenie

Tak nakoniec to vyzerá, že celá tá šaškáreň s OpenCL (viď môj predchádzajúci článok) sa oplatila. Zabil som s tým síce neskutočné množstvo času, ale nakoniec som v hodnotení skončil prvý v skupine 🙂

Za náročnosť úlohy vraví aj fakt, že z 35 študentov, čo na tento predmet chodia, odovzdalo úlohu len 13. A z týchto trinástich riešení správne fungovalo len sedem. Teda rovných 20%. Nič moc, keď si vezmete, že to bola úplne obyčajná úloha pre študentov magisterského štúdia informatiky.

Moje riešenie dopadlo v teste najlepšie – s priemerným zrýchlením (na troch rôzne veľkých vstupoch) 44,536x. Vzorové riešenie, ktoré vypracoval zadávateľ úlohy, dosiahlo priemerné zrýchlenie 43,852, to moje riešenie teda bolo ešte o čosi lepšie, ale povedal by som, že to bolo spôsobené len nedostatkom času zo strany cvičiaceho.

V každom prípade, týmto pádom mám už teraz istú známku z tohto predmetu, nemusím sa teda ďalej znervózňovať, čo je pozitívne. Kicking back and enjoying the feeling… 🙂

nVidia, OpenCL a frustrácia

Toto bude jeden z tých technickejších článkov, takže ak nepatríte k tým, ktorých tieto veci zaujímajú, môžete to tu pokojne preskočiť – alebo čítať ďalej pre náhľad do sveta, ktorý tak často nevidíte 🙂

Stručný úvod: na jednom predmete v škole (programovanie v paralelnom prostredí) sme dostali za úlohu napísať jednoduchý algoritmus pre výpočet fyzikálneho modelu pohybu častí. V podstate sa jednalo o veľmi primitívny model “gravitačného” rozmiestnenia vrcholov grafu. Mali sme použiť technológiu OpenCL 1.1 pre akcelerovanie výpočtov na grafickom HW.

So far, so good. Po iniciálnom zoznámení s technológiou som strávil netriviálne množstvo času (= cca 14 hodín) implementáciou prvotného návrhu riešenia. Čo sa nakoniec aj podarilo – môj kód bežal (nie práve super efektívne, ale predsa) a testy prechádzali pre prvý zo vzorových vstupov.

Nasledujúci deň som ešte vyoptimalizoval jeden z kernelov pre spracovanie hrán grafu a tešil som sa, že mám hotovo. Aké veľké bolo moje prekvapenie, keď sam zistil, že aj keď moje riešenie funguje správne na prvom vzorovom vstupe, na druhom a treťom má problém.

Prekvapujúce to bolo hlavne z toho dôvodu, že sme k úlohe dostali aj vzorové sériové CPU-bound riešenie, voči ktorému sa potom naše OpenCL riešenie bude porovnávať. A môj kód pre OpenCL kernely vychádzal z veľkej časti práve z tohto vzorového kódu. A napriek tomu dával iné výsledky. Nie o veľa, ale dosť na to, aby prekročil toleranciu 1% nastavenú vo validátore výsledkov.

Po troche diskusie s cvičiacim a experimentovania sa mi podarilo upraviť moje kernely tak, aby validácia prešla aj na vstupe číslo dva. Vysvitlo, že pow(x, 2) a pown(x, 2) != x * x, ak je x typu float. Použitie pow bolo samozrejme zbytočné – chybne som usudzoval, že intrinsická funkcia pow bude efektívnejčia ako násobenie. Well, nie je. A to bol jeden zo zdrojov nepresnosti v mojich kerneloch. Po nahradení obyčajným násobením moje riešenie prešlo validáciou aj na druhom vstupe.

Na treťom vstupe sa tiež zlepšilo – namiesto zlyhania v prvej iterácii výpočtu zlyhalo až v tretej. Sill not good enough, keďže pri validácii musí prejsť aspoň 50 iterácií bez chyby. Po ďalšom ladení som usúdil, že môj kód už nie je možné viac priblížiť k dodanému vzoru pre CPU. Vzal som teda kód kernelu a namiesto na GPU som ho vykonal na CPU (PRESNE rovnaký kód). Výsledok? Rozdielne hodnoty za ôsmym desatinným miestom.

Vysvitlo, že intrinsická funkcia sqrt v OpenCL počíta trochu inak ako std::sqrt. V OpenCL 1.1 implementácii od nVidie totiž nie je v súlade s IEEE 754, zatiaľ čo std::sqrt je. A toto je problém, pretože, na rozdiel od prípadu s pow, sqrt nie je možné jednoducho nahradiť. A navyše je vo výpočte táto funkcia nutná.

Človek by si povedal, že taký malý rozdiel (8 signifikantných desatinných miest) je zanedbateľný. To je ale pravda len pre prípady, keď sa táto nepresnosť nezačne kumulovať. Čo, nanešťastie, v tomto prípade nastane. Počítam v podstate intertakcie častíc “každá s každou”, takže keď máme desiatky tisíc bodov, nepresnosti sa začnú sčítavať a nakoniec prekročia povolené hranice. Preto moje riešenie fungovalo pre vstupy 1 a 2 – majú len 1k a 4k bodov. Vstup 3 ich má 16k.

Uvidíme, čo z toho vylezie. Som v kontakte so zadávateľom úlohy, možno bude mať nejaký usefull insight. Ak nie cez mail, asi si dohodnem konzultáciu, aby som mu mohol môj kód predviesť a zverifikovať, že nie je chybný v nejakom obskurnom aspekte.

Nech je to ako chce (a ak ste vydržali čítať až sem 🙂 ), veľmi som na kombináciu OpenCL 1.1 a nVidia HW nadával (nemám k dispozícii HW od AMD, takže neviem povedať, či je situácia lepšia tam). Naše riešenia sa budú po odovzdaní vyhodnocovať na kartách Tesla K20, takže opať nVidia. Taká hlúposť, ale stojí to človeka nekonečné množstvo času. Víkend zabitý, damn it.

Ale aspoň som sa naučil niečo, čo som vždy chcel, ale nenašiel dosť času a odhodlania ísť do toho – programovanie high-performance kódu pre GPU 🙂

UPDATE 8.4.2014

Tak sa nakoniec ukázalo, že som vo svojom zápase s presnosťou nebol sám. Minulý vikend nám všetkým prišiel e-mail od zadávateľa, že sa mu ozvalo hneď niekoľko ďalších ľudí, ktorí mali problémy. Nakoniec bol nútený upraviť systém vyhodnocovania presnosti riešenia a zvýšiť toleranciu.

Mal som teda v konečnom dôsledku pravdu – vyhodnocovanie bolo dosť prísne. V každom prípade, moje riešenie je odladené, funguje out-of-the-box aj s novým vyhodnocovačom a mám teda po starostiach. Screw it! 🙂

Within Temptation v Bratislave!

Hydra is on the road.

Už o pár hodín. Koncert, na ktorý sme sa s kamarátmi tešili už od momentu ohlásenia nového albumu. A to sme ani nečakali, že sa WT ukážu priamo v Bratislave.

Lístky kúpené 5 minút po tom, ako sa zahájil ich predaj. A potom sme pol roka čakali 😀 Ale dočkali sme sa, dnes o ôsmej v Incheba Aréne (pôvodná venue sa pre velký záujem presunula zo Slovnaftskej Rafinérie). This is gonna be fun (fun, fun!, FUN!, FUN!!, FUN!!!).

Snáď sa mi podarí zaobstarať aj nejaké decentné fotky, ale aj keby nie, rozhodne bude na čo spomínať. Ich posledný koncert (v Prahe, k albumu The Unforgiving) bol absolútne epický, Hydra bude podľa všetkého rovnaká.

A pred tým samozreme ešte “before-party”, pár pív a možno nejaká tá whiskey 🙂

Navyše je pre mňa tento koncert aj dôvodom urobiť si týždenné prázdniny a dovaliť sa z Prahy do Bratislavy, čo sú body navyše…

Bring the beast on!

Téma na diplomku schválená

Už je to tak, konečne, po prakticky roku vymýšľania, hľadania a zvažovania, sa mi dnes podarilo prísť s témou diplomovej práce, ktorá by ma bavila a zároveň by bola dostatočne komplexná.

Nebudem tu zabiehať do zbytočných technikálií, poviem len, že sa jedná o projekt, ktorý riešime v práci už nejaký čas. Zadanie má momentálne niečo cez 150 strán, ak si správne pamätám. Referenčná implementácia existuje, ale po troch rokoch vývoja štýlom “patchwork” je jej stav absolútne neudržateľný.

A keďže sa jedná o komerčný projekt európskeho významu, v tomto stave ho rozhodne nemôžme nechať ležať (a hniť). Bude teda na mne, aby som existujúcu verziu vzal, rozpitval (keďže je táto verzia nasadená v praxi, pôjde technicky o vivisekciu 😀 ), vybral z nej tých niekoľko kúskov, ktoré sa dajú zachrániť, a zvyšok komplet od podlahy prepísal.

Práce to bude neúrekom, ale mám na to prakticky rok. Zase TAK veľký projekt to nie je. Dúfam. Ale aspoň si pri tom prejdem celý tzv. “software-ový proces” od začiatku až po koniec – analýzu, návrh, architektúru, programovanie, testovanie, nasadenie aj údržbu.

A na jednu vec sa neskonale teším – konečne budeme mať v tej veci regresné testy. Už sa nikdy viac nestane, že opravíme jeden bug, aby sme touto opravou zaniesli dva ďalšie! Woohooo, prestaneme tápať v tmách!

Normálne sa už neviem dočkať. (Áno, je mi jasné, že toto nadšenie ma prejde prakticky okamžite, keď sa začne pracovať, ale na teraz si ho užívam 😀 ).