Da Vinci Machine, czyli nie tylko Java na Java Virtual Machine
- Dodano: 6 lutego 2008
- Wprowadził: incal
- Komentarze: 14
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.
Więcej informacji: http://webhosting.pl/kategorie/programow...al_machine
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
14 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
Ale natywnie byłoby chyba szybciej…
Pewnie tak, ale dzieki takiej maszynie najprawdopodobniej bedziesz mogl wykorzystac klasy javy.
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.
Java jest wolniejsza. To taki "zamulator", że używać się nie chce softu dla niej napisanego.
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.
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…
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.
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.
wklejenie 2 linkow powoduje to, ze komentarz musi byc zaakceptowany przez moderatora…
cholernie wkurza to czasami…
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.
Niezły ten LLVM, w online demo kompiluje algorytm rekurencyjny do liniowego i wstawia go inline do kodu, omijając wywołanie funkcji.
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.
W j2me bardziej się opłaca użyć sprzętowej Javy w prockach ARM.
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.