Da Vinci Machine, czyli nie tylko Java na Java Virtual Machine

6 lutego 2008

Firma Sun Microsystems opracowuje technologię, która ułatwi uruchamianie na wirtualnej maszynie Javy programów napisanych w językach innych, niż Java. Projekt nosi nazwę Da Vinci Machine i jest przez Suna określany mianem „wielojęzycznego renesansu dla architektury Java Virtual Machine”.

Charles Nutter, główny twórca JRuby (wersji Ruby na JVM) wskazuje, że Java jako język o silnej typizacji różni się od języków skryptowych takich, jak Ruby. Dzięki temu Java niesie ze sobą więcej informacji o tym, w jaki sposób kod powinien być wykonany. Dlatego przed twórcami Da Vinci Machine stoi zadanie znalezienia najlepszej drogi do prawidłowego wykonywania kodu dla innych języków.

Sun planuje umieścić część funkcjonalności Da Vinci Machine w najnowszym Java SE Development Kit 7. Nieznane są jednak żadne szczegóły i data publikacji tego JDK. Ważne jest to, że opinie deweloperów na temat pomysłu Suna są przychylne. Podkreślają oni, że dzięki temu praca programistów będzie wygodniejsza i łatwiejsza.

PODOBNE WPISY:

żadnych reklam, sama wiedza.

Zarejestruj się na BEZPŁATNY NEWSLETTER i raz w tygodniu otrzymuj najważniejsze wiadmości
ze świata IT, nowych technologii i kryptowalut.

Bez reklam.

Zarejestruj się za darmo

Technologie

14 odpowiedzi na „Da Vinci Machine, czyli nie tylko Java na Java Virtual Machine”

Livio

6 lutego 2008

Ale natywnie byłoby chyba szybciej…

Odpowiedz
1. Michal
  
  6 lutego 2008
  
  Pewnie tak, ale dzieki takiej maszynie najprawdopodobniej bedziesz mogl wykorzystac klasy javy.
  
  Odpowiedz
2. mario
  
  7 lutego 2008
  
  Nie było by szybciej, bo nie było by natywne (natywny jest tylko interpreter a nie sam program) – takie języki jak Ruby, czy Python są interpretowane. Program napisany w jakimś języku po skompilowaniu do byte-codeu Javy jest drugi raz kompilowany przy uruchomieniu do kodu natywnego. Zresztą programy napisane w Javie są niewiele wolniejsze od C/C++, kosztem jaki narzuca VM Javy jest pamięć – program uruchamiany pod VM Javy zużywa dużo więcej pamięci niż odpowiednik w C/C++, ale za to jest dużo szybszy od interpretowanego.
  
  Odpowiedz
  1. MDW
    
    8 lutego 2008
    
    Java jest wolniejsza. To taki "zamulator", że używać się nie chce softu dla niej napisanego.
    
    Odpowiedz
    1. mario
      
      8 lutego 2008
      
      Widać nie przetłumaczy wielu osobom. Problem Javy jest taki, że zjada ona dużo RAMu i jak masz go mało to Twój program w Javie zacznie być swapowany i wydawać się będzie, że działa wolniej. Drugi problem to programiści Javy – używają bibliotek gotowców i molochów, które pożerają spore ilości pamięci. Java jako język jest bardzo szybka, tutaj jest przykładowy test:
      :
      http://shootout.alioth.debian.org/gp4/benchmark.p…
      :
      Jak widać renderowanie mandelbrota w javie jest tylko o 0.1 raza wolniejsze od GCC C++ z maksymalnym poziomem optymalizacji i szybsze od GCC C/C++ z mniejszym poziomem optymalizacji. Python (język interpretowany) jest o 107 razy wolniejszy! Ale teraz poparzmy na zużycie pamięci, java 10,124 kB i python 2,412 kB – teraz rozumiesz? Java zużywa 4 razy więcej pamięci niż python ale jest 100 razy szybsza w renderowaniu fraktala mandelbrota.
      :
      Nie wiem kiedy ten mit o powolnej Javie minie, bo Java była kiedyś powolna, podobnie jak Linux był trudny w obsłudze i instalacji.
      
      Odpowiedz
    2. mario
      
      8 lutego 2008
      
      Właśnie tam popatrzyłem na źródła testów i okazało się, że ta najszybsze implementacje w C/C++ są specjalnie zoptymalizowane pod SSE:
      : http://shootout.alioth.debian.org/gp4/benchmark.p…
      :
      Kod nie jest niezależny od maszyny jak w przypadku Javy i wolniejszych implementacji C/C++, które w tym przypadku są nawet wolniejsze od Javy:
      :
      C++:
      http://shootout.alioth.debian.org/gp4/benchmark.p…
      :
      analogiczny kod w Javie:
      :
      http://shootout.alioth.debian.org/gp4/benchmark.p…
      
      Odpowiedz
    3. mario
      
      8 lutego 2008
      
      Popatrzyłem na źródła tych programów w Javie i wolniejszego i szybszego C/C++. Okazuje się, że w tym przypadku w analogicznym kodzie Java jest akutat szybsza. Ta szybsza od Javy implementacja w C/C++ jest specjalnie optymalizowana pod SSE (używa specjalnych bibliotek do SSE), a tym samym traci się przenaszalność tego kodu na inne platformy sprzętowe. Dopiero ta wolniejsza implementacja od Javy to kod analogiczny do tego w Javie.
      
      Odpowiedz
    4. mario
      
      8 lutego 2008
      
      Dziwne komentarza z godz. 8:49 początkowo mi nie dodało, a więc napisałem drugi raz o 9:02, a potem pojawił się ten z 8:49, ale dopiero kilkadziesiąt/kilkanaście minut później.
      
      Odpowiedz
    5. jellonek
      
      4 marca 2008
      
      wklejenie 2 linkow powoduje to, ze komentarz musi byc zaakceptowany przez moderatora…
      cholernie wkurza to czasami…
      
      Odpowiedz
Rsh

7 lutego 2008

Zaletą z pewnością byłoby usunięcie potrzeby wymyślania na nowo optymalizatora dla poszczególnych języków. Ten Javy jest prawdpodobnie bardzo dobry. Odpowiednikiem Da Vinci Machine dla języków kompilowanych jest projekt LLVM.

Odpowiedz
1. mario
  
  7 lutego 2008
  
  Niezły ten LLVM, w online demo kompiluje algorytm rekurencyjny do liniowego i wstawia go inline do kodu, omijając wywołanie funkcji.
  
  Odpowiedz
Gf

7 lutego 2008

gonią .NIET i dobrze. Podoba mi się ten pomysł. Jeśli jeszcze to kompilowanie do natywnego kodu będzie dobrze działać to będzie można wreszcie uzywać tego zupełnie przenośnie. Na maszynach j2me uzywac ruby i kompilowac wazne komponenty do natywnego kodu.

Odpowiedz
1. mario
  
  7 lutego 2008
  
  W j2me bardziej się opłaca użyć sprzętowej Javy w prockach ARM.
  
  Odpowiedz
2. sadi
  
  9 lutego 2008
  
  Też myślę, że to bardzo dobry pomysł. Umożliwia dodatkowo łatwe stosowanie wielu różnych języków przy jednym projekcie co, jeśli jest używane z głową, może dawać ogromne korzyści.
  
  Odpowiedz