Oprogramowanie

XobotOS: Android w C# i Mono działa kilka razy szybciej niż w Javie

Damian  | Redaktor serwisu benchmark.pl
Autor: Damian
56 komentarzy Dyskutuj z nami

Google zdecyduje się na zmiany?

Mimo iż Google odniosło ogromny sukces ze swoim mobilnym systemem operacyjnym Android, to istnieją kwestie wciąż uprzykrzające życie przeglądarkowemu gigantowi. Mowa o powolnym działaniu, czy rzekomym naruszeniu patentów Javy. Receptą na te przypadłości może być system XobotOS, czyli port Androida w C# przygotowany przez Xamarin.

xobotos android x# mono .net java oracle google xamarin novell szybkość patenty system kolejność kompilacjiNiegdyś deweloperzy obecnie najpopularniejszego mobilnego systemu operacyjnego jakim jest Android, rozważali możliwość zastosowania w swoim dziele projektów zgodnych z normami ISO, a więc platform językowych .NET i C#.

Była to o tyle ciekawa koncepcja, gdyż Microsoft udostępnił tą pierwszą opcję z gwarancjami braku roszczeń patentowych w przypadku jej wykorzystywania. Mimo wszystko ostatecznie pozostano przy obecnej do dzisiaj w zielonym robociku Javy.

Java za czasów kiedy za jej rozwój odpowiedzialna była firma Sun mogła być wykorzystywana niemalże w dowolnych zastosowaniach, jednak po przejęciu Sun przez Oracle sytuacja zmieniła się diametralnie. Oracle wytoczyło wielkie działa przeciwko Google, twierdząc, że w Androidzie doszło do złamania petentów Java.

Od jakiegoś czasu spory między Oracle i Google przeniosły się na wokandę sądową i obecnie przypominają prawie telewizyjnego "tasiemca" - od zakazu sprzedaży poprzez licencjonowanie po ogromne tantiemy ze sprzedaży.

Firmę Xamarin stworzyli deweloperzy projektu Mono powiązani z firmą Novell. Przedsięwzięcie mimo istnienia stworzonego przez Microsoft projektu .NET, nabiera tempa i popularności, a to głównie z powodu udostępnienia projektu Microsoftu na licencji shared source, co oznacza sprzeczność z ideą wolnego oprogramowania i zabrania wykorzystania do wielu celów komercyjnych.

android c# mono java logo robocik xobotos system koperta

Idea Mono zakłada stworzenie narzędzi w pełni kompatybilnych z .NET, działających pod kontrolą możliwie największej możliwej liczby systemów operacyjnych. Dlatego też ostatnio powstały nawet wersje Mono dla Androida i iOS a wiec Mono for Android oraz MonoTouch, ale nie to jest dzisiejszym tematem.

xobotos android system c# mono java dalvik szybkość lista smartfon

Twórcy Mono w wolnych chwilach zajęli się przygotowaniem portu systemu Android 4.0 do C# za pomocą Mono. Oficjalnie miało to pomóc w usprawnieniu Androidowej wersji Mono.

XobotOS, chociaż jest jeszcze w bardzo wczesnej fazie prac, to już jak informują jego twórcy cały kod Javy z Androida został przeportowany do C#, a jego źródła zostały udostępnione społeczności na zasadzie licencji Apache.

xobotos androud c# mono wyglad wstęp sustem obraz

Cały kod był tłumaczony maszynowo, za pomocą automatycznego narzędzia Sharpen, którego deweloperzy poddali licznym modyfikacjom aby poradził sobie z ogromem kodu zawartym w Androidzie. Jednak część kodu, niezrozumiała dla maszyny, bądź stwarzającej problemy logistyczne, składniowe bądź wydajnościowe została przetłumaczona ręcznie przez programistów.

xobotos android c# mono java dalvik dewelope twórcy system
Deweloperzy Mono i twórcy XobotOS

Po skompilowaniu przygotowanego kodu, okazało się, że przygotowana maszyna wirtualna z Mono jest znacznie wydajniejsza niż maszyna Java - Dalvik obecna w Androidzie. Sam system jest bowiem w takich warunkach w wielu środowiskach kilkakrotnie szybszy niż Android. Lepsza optymalizacja, większa responsywność oraz usprawnienia wprowadzone przez Microsoft do .NET pozwoliły zostawić w tyle Javę. Zdaniem deweloperów Java jest lata świetlne za C# i Google powinno nad tym się zastanowić.

Jeżeli Google odniosłoby porażkę w sporze z Oracle, to całkiem możliwe mogłoby być przeniesienie Androida właśnie do C# i Mono. Zarówno Google pozbyłoby się sporów patentowych, a system dostałby nagle przyśpieszenia. Jednak to wciąż tylko spekulacje, lecz nikt nie wyklucza, że pracami nad XobotOS może zająć się społeczność przenosząca system na smartfony z Androidem.

Jeśli interesuje was XobotOS to jego źródła możecie znaleźć na GitHubie.


Więcej o  Java i Android:

Źródło: Xamarin, GitHub, Engadget, ZDnet, Arstechnica, SlashGear, TechieBuzz, theinquirer

Komentarze

56
Zaloguj się, aby skomentować
avatar
Komentowanie dostępne jest tylko dla zarejestrowanych użytkowników serwisu.
  • avatar
    Konto usunięte
    21
    Nie dziwota, java jest najbardziej zmulona dlatego android jest zmulony i trzeba 1GHz procka zeby mniej sie cielo w ogole.
  • avatar
    steelek
    13
    Google nie pojdzie na Mono. Producenci telefonow by ich pozabijali jakby sie okazalo ze stare modele z 512 ramu i jednojajecznym procesorem taktowanym 1,2GHz by smigalo bez niczego na najnowszym androidzie. To by byly ogromne straty dla producentow smartphonow, ktory stal sie prawie jak rynek komputerow. Wypuscmy wiecej taktowania i wiecej rdzeni ludzie sie beda chwalic naszymi telefonami ze maja lepsze cyferki od innych.
  • avatar
    zapp88
    3
    Po pierwsze należy rozgraniczyć różnice pomiędzy Javą jako językiem i JVM jako maszyną wirtualną. Java jako język jest już faktycznie lekko przestarzała. Maszyna wirtualna jav'y zwana dalej JVM to już zupełnie inna sprawa. Maszyna wirtualna .net CLI jest już dużo bardziej niewydajna od JVM. To o czym jest mowa w tym artykule to DalvikVM czyli googlowska implementacja JVM. Która w javowym JVM znanym z x86 nie ma zbyt wiele wspólnego. Po pierwsze jest ona oparta o rejestr a nie o stos tak jak ma to miejsce w przypadku .Net i JVM. Co skutkuje istotnym spadkiem wydajności. Żeby to sprawdzić zrobiłem prosty benchmark by porównać szybkość działa (obiektywność takiego benchmarka może być dyskusyjna ,aczkolwiek jego wyniki już dają do myślenia)

    Kod testowy :
    int c = 102030405;
    int[] i = new int[c];
    for (int j = 0; j < c; j++) {
    i[j] = j;
    }
    long time = System.currentTimeMillis();
    int w=0;
    for (int j = c-1; j > 0; j--) {
    if(i[j] < 0){
    i[j] = w;
    }
    w = i[j];
    }
    time = (System.currentTimeMillis() - time);
    System.out.println("Time : " + time);
  • avatar
    Konto usunięte
    2
    Dobrze dla Androida i Google by było, dołączenie tego projektu do Androida może nie 5 bo już nie zdążą, ale do jego następcy.
  • avatar
    Konto usunięte
    2
    Pamiętam te czasy kiedy ktoś się chwalił że ma dzwonki polifoniczne... i kolorowy wyświetlacz ;p a teraz słowo "telefon" nabiera zupełnie innego znaczenia.
  • avatar
    zapp88
    2
    Oraz wynik powyższego testu :

    Język Czas wykonania
    C++ 2 ms
    Java 60 ms
    Scala 132 ms
    C# 160 ms
    Haskell 480 ms
  • avatar
    Konto usunięte
    1
    jak wyglada sprawa z grami w androidze? czy mala ilosc fps zalezy glownie od javy czy od slabego chipu graficznego?
  • avatar
    Konto usunięte
    1
    Literówka zamiast petentów ma być chyba patentów.
  • avatar
    zapp88
    1
    No i wiadomo wydajność nie zawsze jest najważniejsza, bo jakby tak było to dzisiaj wszyscy pisalibyśmy w Fortranie :-) albo czystym ASM.
  • avatar
    Konto usunięte
    -1
    Java to gooowno było, jest i będzie
  • avatar
    Konto usunięte
    -1
    To artykuł sponsorowany przez Microsoft! Przecież jasne jest że Java miażdży c# http://reverseblade.blogspot.com/2009/02/c-versus-c-versus-java-performance.html
  • avatar
    DevilNest
    -2
    Można się kłócić, który język da bardziej optymalną szybkość działania, bo użycie kompilatora A i kompilatora B może dać ogromną przepaść. Wiem z opowiadań, że np programy wielowątkowe lepiej komplikować kompilatorem od Intela ;-)
    Poza tym nie tylko kompilator odgrywa tu role, więc jeszcze sporo testów nad nami by w ogóle można by myśleć o zmianie języka, bo to, że te parę testów wyszło na plus dla MONO to za dużego znaczenia nie ma.
  • avatar
    Konto usunięte
    0
    Po co się produkować, jak benchmarki już są: http://shootout.alioth.debian.org/

    Z Twoim kodem jest taki problem, że niektóre kompilatory go w ogóle nie wykonają (zawartość tablicy nie jest nigdzie wykorzystywana). Podejrzewam, że kompilator C++ właśnie tak zrobił. Mógłbyś pokazać kod Haskella? Trochę mnie dziwi wynik, bo GHC jest bardzo szybki. Zresztą z powodu leniwej ewaluacji to wynik powinien wynosić góra kilka milisekund, a nie 480.
  • avatar
    zapp88
    0
    Przypuszczam że masz racje co do bardzo dobrego wyniku C++.
    Z drugiej strony kod w haskellu faktycznie musiał się bardzo różnić bardzo mocno bo tam niestety/stety (zbędne skreślić) kod musi być całkowicie funkcyjny więc nie ręcze za jego obiektywność. Znalazł się tam jako punkt odniesienia. Gdyż podobnie jak C++ jest natywny lecz jest bardziej funkcyjny niż nawet Scala (Monady !) - więc dość dobrze oddaje jak wiele rzeczy możne mieć wpływ na wydajność.
  • avatar
    zapp88
    0
    No i muszę przyznać że faktycznie :
    http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=java&lang2=gpp
    http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=java&lang2=csharp
    http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=java&lang2=scala
    http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=java&lang2=ghc
    Dość dobrze to ilustruje generalną zasadę.
  • avatar
    Konto usunięte
    0
    A test w czystym C i C-Objective od Apple?