To i owo
tags: android cuda dev google nvidia polish technology
29 Apr 2009 20:34
Tracę już powoli pomysły na sensowne tytuły notek, ale pisać coś trzeba. Zatem dzisiaj krótkie podsumowanie ostatnich kilku dni.
CUDA
Zaczynając od początku czyli od wczoraj: rano działy się niezłe CUDA. Konkretnie, chodzi o technologię firmy nVidia stosowaną w kartach graficznych, która nazywa się CUDA. Ogólny zamysł polega na wykorzystaniu jednostki GPU (procesor karty graficznej) do wykonywania napisanych w języku podobnym do C (i odpowiednio skompilowanych).
Procesory GPU różnią się znacznie od naszych CPU (centralnych procesorów). W procesorze CPU mamy zwykle 1, 2 lub 4 rdzenie. W procesorach graficznych kart nVidii mamy dziesiątki, czy nawet setki multiprocesorów (bliski procesorowi wielordzeniowemu).
Ogólnie, możemy uruchomić około 1000 i więcej "wątków" na jednej karcie graficznej. Daje to spore możliwości wykorzystania takiej architektury w obliczeniach równoległych. Przedtem taka architektura była tylko wykorzystywana przez zamknięte sterowniki karty graficznej w celu renderowania skomplikowanej grafiki 3D w czasie rzeczywistym (i nie tylko). Teraz moc obliczeniowa stoi przed zdolnymi programistami i czeka na wykorzystanie.
Oprócz niewątpliwej zalety jaką jest wysoka współbieżność, mamy również garść bardzo szybkiej pamięci do dyspozycji (tak szybka jak rejestry procesora). Po krótkiej analizie jednak okazało się, że konieczność współdzielenia jej przez wiele wątków redukuje nam średnią ilość tej szybkiej pamięci do kilku bajtów na wątek. Należy więc jednak trochę z tym uważać.
Odwołania do pamięci RAM karty graficznej są wolne, jednak procesor potrafi w czasie "czekania" na dane z RAM-u wykonywać inny wątek. Jest to również stosowane w zwykłych procesorach. Znane jest pod pojęciem wywłaszczenia procesu (np., gdy proces oczekuje na operację I/O na wolnym dysku na jego miejsce "wskakuje" inny proces). Jednak w odróżnieniu od zwykłego procesora, gdzie wywłaszczenie inicjuje system operacyjny, a samo przełączenie kontekstu jest dość kosztowne, w CUDA-ch wywłaszczenie jest częścią logiki realizowanej sprzętowo i jest bardzo bardzo szybkie. Zatem odpowiednio oprogramowując używanie pamięci globalnej, możemy uzyskać wykonywanie programu (złożonego z wielu — np. 256 — wątków) bez przerw w wykorzystywaniu mocy obliczeniowej GPU.
Oprócz zalet mamy oczywiście też wady. Jedną z nich (choć można to uznać za zaletę) jest brak mechanizmów cache'owania i stronicowania, co powoduje konieczność bardzo skrupulatnego zarządzania pamięcią.
Np. na moim laptopie nie udało się uruchomić prawie żadnej przykładowej aplikacji dołączonej do SDK CUDA-ów. Powód: za mało pamięci. Pamięci karty graficznej oczywiście. W przypadku tradycyjnego procesora pamięć zwykle nie stanowi problemu, ponieważ tak naprawdę nigdy nią nie zarządzamy. Jako podstawę mamy pamięć RAM. Gdy komórka pamięci jest często używana trafia (automatycznie) do keszu, który jest dużo szybszy. Z drugiej strony, jeśli pamięci brakuje, następuje przeniesienie nieużywanej pamięci do swapa, czyli na dysk, który z kolei jest bardzo wolny w porównaniu do pamięci RAM.
Efekt jest taki, że programując nie przejmujemy się gdzie będzie przechowywana zmienna. Na start trafia ona do RAM-u, ale może zostać skopiowana do szybkiego kesza, lub przeniesiona na wolny dysk. W CUDA-ch musimy sami zdecydować gdzie będą przechowywane poszczególne zmienne. Problem, który się pojawia, to nieznana ilość dostępnej pamięci. Każda karta ma inną dostępną pamięć każdego rodzaju, co więcej uruchomienie aplikacji graficznych (np. Compiz) zmniejsza ilość dostępnej pamięci.
Są zatem dwa wyjścia — albo programujemy na konkretną kartę grafiki i wymagamy, aby tylko nasz program był na niej uruchomiony (a nie np. jeszcze Quake ;) ), albo inwestujemy w jakiś system zarządzania pamięcią karty graficznej (czyli robimy kawałek systemu operacyjnego, tyle, że na GPU). Oczywiście druga rzecz jest trudna i zmniejsza wydajność całego systemu.
W praktyce pozostaje jeszcze jedno rozwiązanie. Zakupienie karty nVidia SPECJALNIE do obliczeń w technologii CUDA. Firma nVidia nie pozostawia nas w trudnej sytuacji i daje nam do dyspozycji kartę Tesla, która ma ze 4 GB RAM-u, dużo wszystkiego (wątków, multiprocesorów itd), za to w zasadzie ciężko ją nazwać graficzną, bo nie ma wyjścia wideo. Przewrotnie, co?
Android
Następny dzień, następna prezentacja. Dzisiaj dotyczyła ona systemu Android opierającego się na jądrze Linux przystosowanego dla telefonów komórkowych (takich jak HTC G1) i innych małych urządzeń. System, pomimo jądra Linuksa jest czymś zupełnie innym niż znane nam z desktopów Ubuntu, a nawet projekty uruchamiania Linuksa na telefonach (np. OpenMoko). Różnica polega na tym, że warstwa narzędzi GNU (shell, podstawowe programy, zarządzanie użytkownikami) zostaje zastąpiona przez warstwę bibliotek w C i w Javie.
Należy sobie jednak zdać sprawę z tego, że Java w Androidzie, to rzecz nieco inna niż Java używana na PC-tach, czy nawet w komórkach. Androidowa Java ma swoją implementację maszyny wirtualnej. Jest to DalvikVM, zoptymalizowany na maszyny o małej ilości RAM-u (64MB dla całego systemu) i wolnych procesorach (200-500 MHz i ARM). Z tej optymalizacji bierze się inny bytecode, który optymalizuje użycie CPU i RAM. Również w celu zwiększenia wydajności pracy z pakietami zmianie ulega sposób wewnętrznej organizacji pakietu.
Jednak wciąż pozostaje to Java i to dość niedaleko leżąca od tej Sunowej. W praktyce bowiem programowanie wygląda tak:
- programujemy w Javie (jednak mamy do dyspozycji mniej funkcji bibliotecznych)
- kompilujemy programy do bytecodu Sunowego (pliki class)
- tworzymy paczkę JAR
- korzystając z narzędzia dx konwertujemy plik JAR do pliku JAR, który zawiera bytecode przystosowany do maszyny DalvikVM. Otrzymany JAR jest zwykle ponad 2 razy mniejszy!
Poza zmianą formatu bytecode'u, czeka nas również zmiana w działaniu wszystkich istotnych części systemu. Odpowiednie klasy dostarczone w bibliotece Androida pozwalają nam na tworzenie "okien", zadań działających w tle, komunikowanie się z innymi procesami, dostęp do danych zapewnianych przez inne programy (np. książkę adresową), ustawień telefonu i sprzętu. Wszystko to jest opakowane przez zarządcę uprawnień, który przyznaje danej aplikacji prawa do różnych części systemu po uprzednim uzgodnieniu tego z użytkownikiem telefonu ;). W praktyce, wygląda to tak:
- twórca aplikacji definiuje w "opisie" aplikacji (plik AndroidManifest.xml) jakich uprawnień potrzebuje aplikacja (np. uprawnienie do wybierania numeru, uprawnienie do czytania z GPS-u, uprawnienie do uruchamiania aplikacji)
- użytkownik instalując aplikację przyznaje jej uprawnienia, o które aplikacja prosi. W przeciwnym razie instalacja nie dokonuje się
- aplikacja może robić cokolwiek zostało jej dozwolone, każde użycie niedozwolonej funkcji kończy się wyjątkiem
Dostęp do ograniczanych zasobów odbywa się przez specjalne Androidowe API. Dostęp w inny sposób nie jest możliwy, ponieważ każda aplikacja jest uruchamiana z innym numerem użytkownika i w zupełnym odizolowaniu (pewnie coś podobnego do chroota) od innych aplikacji.
Dostępna jest również komunikacja między aplikacjami. Ogólnie mówiąc jest to koncepcja podobna do D-BUS, jednak implementacja jest nieco inna.
Inną ciekawą funkcją aplikacji pracujących w systemie Android jest ich gotowość do bycia zabitym w każdym momencie. Z racji ograniczenia ilości pamięci dostępnej dla systemu i mimo wszystko (pomimo sporego postępu względem Javy Suna) wysokiego zużycia pamięci przez aplikacje Javove, system zawiera mechanizm zabijania procesów w przypadku, gdy zaczyna brakować zasobów (CPU lub RAM).
Każda aplikacja jednak może się przygotować na taką sytuację, ponieważ w momencie przykrycia aplikacji przez inną (kiedy to możliwe jest jej zabicie) wywołana jest metoda onStop (lub onPause w przypadku częściowego zakrycia), która umożliwia zrzut stanu aplikacji do systemowej bazy danych. Gdy użytkownik wraca do aplikacji (pomimo, że została w tle zabita, użytkownik wcale tego nie widzi), system ponownie uruchamia aplikację przywracając jej poprzedni stan. To jak aplikacja chce reprezentować swój stan zależy od samej aplikacji.
Problemem maszyny Dalvik, podobnie jak i maszyny wirtualnej Javy Suna, to długi czas uruchamiania się (mniej niż sekunda na Twoim Pentium4? Aparat G1 jest ~10 razy wolniejszy). DalvikVM na telefonie HTC G1 uruchamia się około 5 sekund. Jest to problem tym bardziej, że każda aplikacja uruchamiana jest w swojej własnej instancji tej maszyny (w celach zapewnienia wymaganej izolacji).
Tutaj do akcji wkracza specjalna usługa systemowa zygote, która jak tylko może przygotowuje proces maszyny wirtualnej Dalvik, który, gdy jest potrzeba zostaje oddany jakiemuś procesowi do natychmiastowego wykorzystania. Przez następne 5 sekund zygote znowu przygotowuje (kolejną) maszynę Dalvik i czeka aż jakiś proces o nią poprosi. Widać, że o ile nie uruchamiamy aplikacji częściej niż co pięć sekund, otrzymujemy złudzenie natychmiastowego uruchamiania aplikacji. Niezły trik.
Widać, że inżynierzy pracujący nad systemem Android stawali na głowie, żeby wszystko było naprawdę dopracowane. Nie inaczej jest z dopieszczeniem programistów. Każdy, kto chce napisać swoją aplikację dla systemu Android może sobie ściągnąć Android-SDK, które zawiera emulator (oparty o QEmu) i narzędzia potrzebne do budowania (dx, apkbuild), i debugowania aplikacji.
Dostępna jest również wtyczka do Eclipse'a o nazwie ADT (Android Developer Toolkit). Pozwala ona stworzyć aplikację dla Androida jednym kliknięciem, zbudować ją drugim, a uruchomić na wcześniej uruchomionym emulatorze trzecim :). Widziałem to w akcji i wygląda to naprawdę bardzo przyjemnie.
Minusem Androida są trudności jakie niesie przeportowanie istniejących nie-androidowych aplikacji:
- aplikacje w C trzeba dolinkować do Google'owego bionic — lekka wersja biblioteki standardowej C — coś w stylu uclibc
- aplikacje w Javie mogą nie działać, bo używają rzeczy niezaimplementowanych w bibliotece Javy Dalvika
- GUI Androida jest zupełnie inne od każdego innego (oparte o pliki XML - zatem może trochę podobne do XUL-a). Zatem GUI w przypadku każdej aplikacji trzeba przepisać
Naturalnym pytaniem, które się rodzi w czasie rozważań nad Androidem jest jego przyszłość. Choćby w porównaniu z iPhonem, którego w pierwszym miesiącu sprzedaży sprzedało się więcej niż wszystkich telefonów z Androidem na pokładzie. Zatem, co może przeważyć szalę zwycięstwa na stronę Androida? iPhone to jeden telefon (no konkretnie to dwa modele) i jeden software (no konkretnie to chyba trzy wersje). Android to otwarta platforma, która będzie stosowana nie tylko w telefonach firmowanych przez Google (póki co HTC G1 i G2), ale również przez inne telefony, takie jak FreeRunner (port i to całkiem dobrze działąjący na to urządzenie już dawno dostępny).
Czołowi producenci tacy jak Samsung, czy Motorola planują wprowadzić do swojej oferty po 2-3 modele z Androidem. Do tego dochodzą netbooki, samochody (ktoś już portuje Androida na samochód), również odtwarzacze MP3, a być może i komputery stacjonarne. Możliwość uruchomienia aplikacji Androidowej na komputerze pracującym pod kontrolą Linuksa byłaby bardzo miła (zwłaszcza, że nie ma żadnych technicznych przeszkód). No i najważniejsze, ogromny wkład w rozwój Androida na platformach innych niż wspierane komercyjnie ma rosnąca społeczność deweloperów i testerów.
Wiwat społeczność!
Podsumowanie
Ostatnie dwa dni w moim życiu pozwoliły na poszerzenie mojej wiedzy na temat technologii, które mogą w ciągu najbliższych 2 lat odmienić życie ludzi na naszej planecie. Oczywiście może się tak nie stać, ale samo poznawanie rzeczy, o których można powiedzieć "dobrze przemyślane, dopracowane, świeże, potrzebne i pomysłowe" przyprawia mnie o dreszczyk emocji.
Muszę powiedzieć, że choć początkowo byłem sceptyczny wobec Androida, myślę teraz, że ma spore szanse za szybki rozwój i wielki (również komercyjny) sukces. Jak pamiętamy na samym spodzie architektury, zaraz nad sprzętem znajduje się jądro Linuksa. Niektóre jego modyfikacje dokonane na potrzeby telefonu trafiły do głównej (lub testowej) gałęzi kernela, co świadczy o dobrej jakości tych zmian.
Pokazuje również, że praca nad tym systemem powoduje również szereg innych pożytecznych (choć pobocznych) zjawisk, co jest oczywiście bardzo budujące (i zupełnie nie występuje w przypadku zamkniętego oprogramowania).
Stop Cenzurze
Cały entuzjazm i moją ogólną radość mącą plany UE dotyczące ograniczenia dostępu do Internetu przez zmianę rozporządzeń europejskich, które są lobbowane przez duże firmy telekomunikacyjne, które prawdopodobnie mogą zwiększyć w ten sposób swoje zyski ze świadczenia usług internetowych i wykończyć małych providerów. Już raz Unia Europejska pokazała, że w sprawie informatycznej niezależności, potrafi się zachować w sposób rozsądny odrzucając propozycję wprowadzenia patentów na oprogramowanie. Miejmy nadzieję, że i tym razem nie zostanie ograniczona konkurencja w tym sektorze i kontrowersyjne rozwiązanie zostanie wyśmiane i zapomniane.
O szczegółach można przeczytać na specjalnej stronie poświęconej temu zagadnieniu: http://stopcenzurze.wikidot.com/ . Można tam również okazać swoje poparcie dla akcji przez wirtualne podpisanie petycji.
Comments: 1
Working On Mobile Webbrowser
tags: gentoo@ipaq ipaq python qt webkit
15 Apr 2009 18:42
As I noted before, I'm running Gentoo in chroot of my iPAQ H3870. As next step of fun with this PDA, I'm willing to create a mobile webbrowser for this (and other) Linux-powered mobile devices. Inspired by iPhone's Safari I want the browser to have the following features:
- fast
- easy to use
I want to use Qt and Webkit for this purpose. I will use PyQt for prototyping. As the interface will be minimal this should not add big overhead. For final version probably I'll compile C++ code statically (inserting the latest Qt library into the result program).
What features the browser should have and how I will implement them?
- fast — using Webkit engine — well integrated with Qt 4.4+
- fast — using fast JavaScript engine — one of newest Qt/Webkit's features using JIT
- easy to use — full page zooming — using Qt/Webkit zoomFactor property
- easy to use — kinetic scrolling — feature popular in iPhone GUI (already implemented by some Qt hackers)
- fast — some hacky-features should be implemented like weight(-and-number-of-connections)-reducing proxy (like in Opera browser) and some AdBlock-like features (probably non-configurable)
I'm planning VERY minimal interface. No long-history, no bookmark management. Only a button to "save" a page to the browser's dashboard. Also I think about some cool internal things to really make the browser usable and to make it as good as the iPhone's browser.
Comments: 1
Easter Time
tags: arm easter familiar gentoo gentoo@ipaq hobby ipaq portage
13 Apr 2009 09:59
Holidays is a time you can do more things you like and less things you are obliged to do.
In Poland it's now second Easter day and fifth day with no classes. Beside eating food and meeting my family I decided to make one big thing during this time.
I managed to run Gentoo on my Compaq iPAQ palmtop computer. First I installed Familiar Linux on it, then I created a chroot on CF card I plugged into it. I used a stage3 image of ARM Gentoo from 2007 year, which seems quite outdated (including non-working version of portage). I had to upgrade the portage tree to a snapshot from 2008.0 version, to start the fun. Then it turned out, that the stage3 does not contain C++ compiler (g++), so I tried installing it with portage (emerge gcc), but with no success (because it needed C++ compiler to build one of its dependencies). I have built it myself (from previously downloaded GCC sources). After a few hours (more like 10) I had working C and C++ compilers there. It was time to start the fun.
I decided to update portage tools (emerge and company) first, but no luck, some blocking package in updating Python. So I decided to update Python first. More problems arrived. tar.lzma archives was not recognized by portage and not unpacked. Having lzma tools installed I don't know what the problem with this is. Probably portage support for tar.lzma archives was added in later version of portage (and I'm upgrading portage, right?). But this was not a big deal for me. I manually unlzma-ed them to pure tars, reedited ebuilds, regenerate digests and things work. So I feel, I can finally update Python, then Portage, then update as much as I can and then try (with fingers crossed) to update portage tree to the current (2009 one). This long way would bring me to having the newest possible software installable on my old iPAQ running 2.4 kernel.
Next step would be creating ipkg-package builders for the software and maybe releasing a new version of Familiar for iPAQ 36**-38**.
So you may ask do I really need Gentoo for this? Gentoo really simplifies compiling things. I bet this is good way to do things in an optimal way.
Do I need to run Gentoo ON iPAQ (and not cross-compile things). Crosscompiling things for 2.4 kernel is a pain from my experience, you need many old tools for this. So native-compilation is better in this case.
But do I need to run old 2.4 kernel instead of new and shiny 2.6 one? I had problems with 2.6. The 2.4 kernel that was shipped with Familiar 0.8.3 Linux was the one that REALLY worked with all hardware I have now in my iPAQ including
- the iPAQ itself (featuring 64 MB RAM, 64 MB Flash Memory, 200 MHz CPU, backlit LCD display, audio
- SD memory card (1GB one)
- CF expansion sleeve
- CF 4GB card
- CF WLAN card (one of not-now-available Socket cards) — this one was tricky — I needed a firmware and some prying for this to get it work
At least one of the things in list above was not working with 2.6 kernels I tried (with hh-patches and more recent ones with no patches).
So, wish me luck, as this is certainly going to work out and you can expect a new working Familiar-Gentoo distribution for your old iPAQs in a few weeks probably (when all of these packages compiles).
What to do next? I plan to grab latest Qt and Webkit, build them for the iPAQ and prepare a cool browser (with overview-zoom) for Linux handhelds (and this won't be limited to my iPAQ).
Other that this geeky-Gentoo-ARM-hendheld-iPAQ-ish stuff I spent my Easter free time on playing Frets on Fire, UT2004, testing db4o and writing this blog post (all these with one eye looking at iPAQ compiling packages). So pretty productive holidays I guess.