JRuby 1.0

Posted by Jarosław Zabiełło Wed, 13 Jun 2007 09:24:00 GMT

Ukazała się finalna wersja JRuby 1.0 – implementacji języka Ruby w czystej Javie. Zespół JRuby zachęca do testowania Railsów na JRuby. Z tego co pamiętam, to wersji finalnej JRuby zapowiadano włączenie optymalizacji kodu. Zanim zatem wyjdzie w końcu Ruby 2.0, JRuby on Rails ma już teraz szansę przełamać stereotyp o słabszej wydajności Rubiego. Szczególnie może to mieć duże znaczenie dla platformy Windows, bo Ruby na systemach POSIX (Linux, BSD, Mac OS X) pracuje znacznie wydajniej.

Dla miłośników Mac OS X jest dostępny artykuł pokazujący jak skonfigurować całe środowisko Javy dla Rail. Ale do pracy z Rails, najprościej użyć Netbeans 6 który od jakiegoś czasu pozwala1 na uruchamianie Railsów na JRuby (można wybrać sobie opcję JRuby lub klasyczny CRuby).

Zobacz też artykuł “JRuby and the Java Platform” jaki ukazał się wczoraj na stronie firmy Sun.

1 Szkoda, że NB6 nie ma jeszcze zaimplementowanego kolorowania i podpowiadania helperów dla Haml. Jak ktoś ma siły i czas to tu jest opis jak dodać kolorowanie dla jakiegoś innego języka.

Tags , , ,  | 14 comments

Comments

Leave a response

  1. Avatar obserwator said 1 day later:

    Szkoda, że Jython/DJANGO nie posiada wsparcia Sun—byłoby miło :)

  2. Avatar Radarek said 1 day later:

    Tak, to bardzo dobre wieści, przede wszystkim dla społeczności Rubiego. Do tej pory byliśmy (a często nadal jesteśmy) traktowani jak jacyś odmieńcy, a Rubiego uważano za niszowy język. Tym bardziej w Polsce, gdzie poza Javę, .Net i PHP się nie wychodzi (w jednej z dyskusji na forum.php.pl niektórzy nawet stwierdzili, że gdyby porównać czyste PHP z czystym Rubym to PHP kładzie go na łopatki – pozostawię to bez komentarza). Cieszę się, że tak wielkie firmy jak Sun, a nawet Microsoft zauważają potęgę tego języka i nie przechodzą obok niego obojętnie.

    Jestem bardzo ciekaw wydajności JRubiego. Czy ktoś testował go pod tym względem?

    Jarosław, wspomniałeś o słabej wydajności Rubiego pod Windowsem. Z moich obserwacji wynika przede wszystkim, że bardzo wolno działa start Rubiego i ładowanie dużej ilości bilbiotek. Przykładowo start konsoli Railsowej trwa kilka (sic!) razy dłużej niż pd linuksem. Czy ktoś wie, czy da się to jakoś naprawiać/poprawić?:)

  3. Avatar lopex said 1 day later:

    Dopiero teraz zaczynają się prawdziwe prace nad wydajnością (w 1.0 najważniejsza była kompatybilność). Kompilator obsługuje na razie ok 50% węzłów AST, dużo pracy zostało przy framing/scoping – planowane jest jak najlepsze wykorzystanie stosu javy. Dużą bolączką jest zbyt częste użycie ThreadLocali (już niedługo). Wreszcie, nadal wąskim gardłem z klas wbudowanych jest współpraca String/Regexp – rozważamy tu port onigurumy 5.x. Z drugiej strony paradoksalnie szybki jest np, Fixnum: http://cyfrowydom.idg.pl/ocena/ocena.asp?dzial=news&;id=112853&akcja=komentarze

  4. Avatar Jarosław Zabiełło said 1 day later:

    Jestem ciekaw czy JRuby cokolwiek wniesie w zakresie lepszej obsługi Unicode czy trzeba czekać do Ruby 2.0…

    Radarek: Ruby jest ogólnie wolniejszy pod windozą. To chyba problem implementacji.

  5. Avatar Radarek said 1 day later:

    lopex, dla przytoczonego przez Ciebie przykładowego testu u mnie lepiej sobie radzi oryginalny interpreter Rubiego

    ruby -v
ruby 1.8.5 (2006-12-04 patchlevel 2) [i686-linux]

jruby -v
ruby 1.8.5 (2007-06-07 rev 3841) [i386-jruby1.0]

    czasy:

    ruby test2.rb
      user     system      total        real
  5.790000   0.080000   5.870000 (  5.983195)
      user     system      total        real
  5.820000   0.080000   5.900000 (  6.220249)
      user     system      total        real
  5.780000   0.100000   5.880000 (  6.138611)

jruby test2.rb
      user     system      total        real
  8.770000   0.000000   8.770000 (  8.769000)
      user     system      total        real
  8.445000   0.000000   8.445000 (  8.445000)
      user     system      total        real
  8.406000   0.000000   8.406000 (  8.407000)

    “Nie jest to może zbyt obiektywny benchmark, ale powinien dać do myślenia. Głównym celem 1.0 była kompatybilność z MRI, dopiero teraz skupiać się będziemy na wydajności.”

    Rozumiem, że Ty jesteś tym jednym z Polaków, który został dodany do zespołu commitującego?:) Gratulacje. Jak wyglądają więc dalsze plany? Kiedy można spodziewać się pierwszych efektów pracy nad wydajnością? Myślę, że to jedna z tych kwestii w Rubym, którą ciągle jest nierozwiązana. Wszyscy zapewne czekają z niecierpliwością na YARV, ale póki co ciągle jesteśmy skazani na obecną implementację. Niestety szybkość (a raczej powolność) to najczęstszy argument używany by udowodnić, że Ruby do czegoś większego się nie nadaje.

  6. Avatar lopex said 1 day later:

    W tej chwili String w JRubym to jak w MRI tablica bajtów. Dla przykładu, podczas wyszukiwania regexpem ta tablica jest konwertowana to java.lang.String i z powrotem – tutaj nie powinno być żadnych problemów w kodowaniami. Dużo łatwiej byłoby trzymać wszystko z char[], niestety sam Ruby jest mocno popsuty po tym względem i pełne wsparcie dla JRubiego (w zasadzie łatwiejsze do wykonania) spowodowałoby niedziałanie bibliotek Rubiego które na tym zepsuciu polegają. Wszystko zależy od dezycji w jaki sposób realizowana będzie obsługa kodowań w Ruby 2.0. Jeśli będzie już znana to i tak wcześniej pojawi sie w JRuby niż w Ruby 2.0 (głównie z powodu lepszych narzędzi do refactoringu w javie i łatwiejszego wprowadzania dużych zmian w kodzie) I wreszcie, nie zapominajmy, że jedynymi platformami z pełnym wsparciem dla kodowań są Java i .NET, cała reszta to tylko namiastki.

  7. Avatar Jarosław Zabiełło said 1 day later:

    lopex: nie przesadzaj. Python ma także pełne wsparcie dla kodowań w niczym nie ustępujące Javie. Jedna z pierwszych rzeczy która mnie zachwyciła w Pythonie to jakość jego biblioteki Unicode.

  8. Avatar lopex said 1 day later:

    Jarosław: “w niczym nie ustępujące Javie” Przykro mi, ale nie do końca, w javie unicode był od samego początku i jest bardziej zintegrowany z całą platformą, w pythonie jest bolted on…, zważ że String w javie jest zaimplementwany w samej javie, nie będziej więc nigdy żadnych problemów z bibliotekami, w bindingach dla pythona to już może być problem. Druga sprawa, jeśli porównasz bebechy pythona i javy zobaczysz gdzie łatwiej ewoluować implementację (choć zwykłemu użytkownikowi języka przeszkadzać to prawdopodobnie nie będzie) Radarek: czy uruchamiałeś test na jdk6 i maszynę w trybie server ? (jak napisałem w tamtym poście), jeśli będziesz używać dużo obiektów nonimmediate – warto też wyłączyć ObjectSpace, opcja -O.

  9. Avatar lopex said 1 day later:

    Radarek: kontynuując sprawę wydajności, w javie optymalizacje nie są tak oczywiste i intuicyjne jak w c/c++. Java z jednej strony traci na analizie gorących miejsc (stąd HotSpot), przez to też rosną wymagania pamięciowe, startup itd…, z drugiej strony nie wiem który kompilator c++ potrafi dokonać analizy ucieczki i czy potrafi tak agresywnie inlinować metody wirtualne. Jeśli analogiczny program napiszesz w c za pomocą wskaźników do funkcji (co np MRI robi nagminnie), c przegra z javą z kretesem. BTW, na moim working copy powyższy benchmark jeszcze bardziej ucieka MRI :D

  10. Avatar Radarek said 1 day later:

    Z niecierpliwością czekam więc na kolejne wersje JRubiego, gdzie zostanie poprawiona wydajność :). Czekam także na YARV, ale coś ostatnio nic nie słychać (cisza przed burzą?;)).

  11. Avatar Radarek said 1 day later:

    lopex, czyżbyś testował pod windowsem? Bo pod linuxem MRI jest szybsze od jrubiego, ale pod windowsem benchmarki wychodzą mi bardzo podobne do Twoich.

  12. Avatar Jarosław Zabiełło said 2 days later:

    lopex: Nie rozumiem logiki twojej wypowiedzi. Z tego, że Unicode dodano do Pythona później (a nie od początku) nie wynika, że działa on w jakiś sposób gorzej od Javy. Wręcz przeciwnie. Działa bardzo dobrze i jest dobrze zintegrowany z bibliotekami standardowymi. Wyrażenia regularne, operacje na stringach itp działają poprawnie. Nie spotkałem się z jakimiś problemami. Wypada tylko życzyć aby Ruby doczekał się też prawdziwych obiektów Unicode zamiast prymitywnej obsługi UTF-8 jaką na razie się podpiera.

  13. Avatar Filip said about 1 month later:

    Microsoft również bierze się za Ruby – niedawno ukazała się wersja pre-alpha IronRuby, czy Ruby dla środowiska .NET (wg zapowiedzi projekt trafi na Rubyforge). Oby nie skończyło się to jakimś Ruby# w stylu J#...

  14. Avatar Gf said 3 months later:

    A ja szukam sposobu by zaszyfrowac dane na komorce. Czy jest jakis jezyk skryptowy ale nie na java ale j2ee. Chodzi o to by udalo sie. zaszyfrowac jakims znanym algorytmem np. rsa

RSS feed for this post

(leave url/email »)

   Comment Markup Help Preview comment