Category Archives: Počítače

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í”.

 

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! 🙂

HP logic

Dnes som sa v práci zase niečo nové naučil. Veľké životné ponaučenie: ak si kúpite počítač, neverte jeho recovery partition. Po dnešnej skúsenosti s počítačom od firmy HP mi slovo “recovery partition” príde mimoriadne ironické.

Začnem ale od začiatku. Jeden náš klient, keďže narába s nemalými finančnými obnosmi, nás požiadal, aby sme im vymysleli, ako zašifrovať ich firemné počítače a ochrániť tak citlivé dáta v prípade krádeže.

Na prvý pohľad jednoduchá úloha – keďže tam majú Windows 7, použijeme palubný BitLocker a bude vymaľované. Problém: vo firme majú počítače s Windows 7 Professional, ktorý BitLocker neobsahuje. Alternatíva: použijeme TrueCrypt, ktorý je zdarma a rokmi odskúšaný.

Problém: HP (výrobca daných počítačov) sa rozhodol, že vo svetle modernizácie budú disky v týchto all-in-one počítačoch vybavené partition tabuľkou typu GPT (GUID partition table). Čo je relatívne nový formát a OS Windows ho podporujú cca od roku 2010. A TrueCrypt ho samozrejme nepodporuje, rovnako ako ostatné známe hard drive encryption utility.

Takže čo? Potrebujeme sa zbaviť GPT a nahradiť ju klasickým dosovským MBR záznamom. A to sa samozrejme nedá spraviť bez preformátovania disku. Riešenie: zazálohujeme dáta, nabootujeme v recovery a disk prekonfigurujeme.

Vysvitlo, že HP recovery prostredie sa pred recovery operáciou na nič moc nepýta a rovno preformátuje disk. To mi moc nepomohlo, tak som operáciu zastavil. Myšlienka bola, že pomocou Linux Live CD nabootujem, odstránim GPT a následne znovu pustím recovery.

Pomocou GParted live USB sa mi GPT nakoniec podarilo odstrániť, ani to nebolo tak zložité. Celkom som sa ale naštval, keď som zistil, že sformátovaním partition s Windows a bootloaderom už (UEFI) BIOS odmieta sputiť recovery prostredie. Rozumné, nie? HP recovery partícia jednoducho nie je samostatne bootovateľná. Great job, HP!

Po troche hľadania som zistil, že v takýchto prípadoch je nutné spustiť recovery prostredie z CD. Ktoré k počítačom pribalené nebolo. A ktoré je možné si ZAKÚPIŤ od HP (alebo vyrobiť manuálne, čo ale nebolo v tomto prípade už možné, že?).

Nakoniec som sa, po tlmených programátorských nadávkach, rozhodol proste vziať image z iného funkčného počítača a prekopírovať ho na ten, na ktorom som pracoval, a s dôsledkami si poradiť potom. Toto riešenie nakoniec fungovalo rozumne, GPT bola preč, OS bežal hladko a bez problémov a TrueCrypt šifrovanie sa spustilo.

Bottom line: ak máte na počítači recovery partíciu (väčšina ich má) a nepatríte medzi tých, čo ju pri prvom spustení premažú a nahradia vlastnou inštaláciou OS, pripravte si pre istotu aj recovery CD – pretože recovery partícia je síce pekná vec, ale ako vidno, nie vždy vám to bude stačiť.

Tento článok spomína konkrétne HP počítače, pretože práve na nich som sa dnes mordoval. Je ale dosť dobre možné, že podobná situácia vládne aj u iných výrobcov.

Google Music v Čechách

Pred nejakým (dlhým) časom som sa na stránkach tohto blogu vyjadroval k problematike legálnej hudby na internete a kde ju zohnať. Odvtedy sa časy zmenili a na náš (v tomto prípade rozumej: český) trh vstúpil Google so svojou služou Play Music a Play Music All Access (v češtine Naplno).

Play Music je klasický internetový MP3 obchod (priama konkurencia iTunes Store) – človek si môže kúpiť jednotlivé skladby alebo celé albumy, typicky za veľmi rozumný peniaz. Ponuka je podľa všetkého široká, aj keď je pravda, že som ju nejak veľmi neskúmal – v každom prípade som tam zatial našiel všetko, čo som hľadal a pár vecí, ktoré som nehľadal 🙂 Ceny sú v priemernom prípade, čo som videl, niekde medzi 90 a 250 českými korunami za album. A čo v hudobnej zbierke Googlu nenájdete, môžete si nauploadovať zo svojej súkromnej kolekcie do vášho vlastného priestoru – Google Music prichádza s miestom pre 20 000 MP3 súborov zdarma.

Ešte o niečo lepšia (podľa mňa) je služba All Access, ktorá funguje na spôsob Spotify alebo Pandory – za mesačný poplatok máte k dispozícii všetku hudbu v Google Music, ktorú môžete (takmer) ľubovoľne streamovať, či už cez webový prehliadač alebo pomocou aplikáciu pre mobilné zariadenie (telefón, tablet – podporované sú platformy Android a iOS). Svoju hudbu si tak môžete vychutnať odkiaľkoľvek, kde je k dispozícii internetové pripojenie.

Mesačný poplatok za All Access je 149 českých korún a potrebujete platobnú kartu vydanú v českej banke. Službu osobne používam od jej prvého dňa v Čechách a môžem povedať, že som s ňou veľmi spokojný. STREAM ALL THE MUSIC.

Za zmienku ešte stojí fakt, že Google Music All Access máte k dispozícii aj keď sa nachádzate mimo územia Českej republiky, bez obmedzení.

Osobne som čakal veľmi dlho na to, kúm príde Google s Music aj na náš lokálny trh a nakoniec som sa dočkal – teraz už zostáva len otázka, kedy sa ponuka rozšíri aj na Slovensko. Snáď to nebude trvať príliš dlho. Ak ale náhodou poznáte niekoho, kto vlastní českú kreditku, máte vyhraté – a prvých 30 dní máte na otestovanie zdarma.