To i owo

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.


More posts on this topic

Comments

Add a New Comment
or Sign in as Wikidot user
(will not be published)
- +
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License