Ruby 1.9 nie jest i (nie będzie) przeznaczony do użytku publicznego

Posted by Jarosław Zabiełło Sun, 16 Dec 2007 02:08:00 GMT

Wiele zamieszania i niezrozumienia panuje wokół mającej wkrótce być wydanej wersji Rubiego 1.9. Wiemy już teraz, że zawiera wbudowaną wirtualną maszynę YARV i jest w testach 3-10x szybszy od Rubiego 1.8.x. Wiele osób sobie ostrzy zęby na przyśpieszenie aplikacji Rubiego działających na Ruby 1.9, np. Rails. Nie bardziej błędnego.

Otóż Ruby 1.9 (z założenia) nie jest wersją do użytku publicznego (jako naturalne zastępstwo dla Rubiego 1.8.x). Ten numer wersji to tylko informacja kierowana tylko do developerów języka Rubiego, że zamrożono API wewnętrznych funkcji C i teraz trwa proces jego stabilizacji. Ten krok był niezbędny w związku w integracją wirtualnej maszyny YARV. Wprowadziła ona taką rewolucję w wewnętrznej implementacji Rubiego, że trzeba było zaprowadzić jak najszybciej porządek w API aby wszelkie rozszerzenia w C działaly spójnie i stabilnie.

Co to wszystko znaczy dla użytkowników Rubiego czy Railsów? Po pierwsze, należy zapomnieć o tym, że Rails będzie chodził na Ruby 1.9, trzeba zaczekać do Rubiego 2.0 a może i 2.1. Pewnie jakiś rok, trudno powiedzieć. Prawie na pewno, Ruby 2.0 nie będzie w pełni zgodny z 1.8. Ma za to być lepszy, szybszy, posiadać pełny Unicode itp. Trzeba więc będzie trochę popracować nad dopracowaniem zgodności Rails i innych aplikacji z Ruby 2.0.

Jeśli ktoś chce przyśpieszyć aplikacje webowe działające w Ruby to może popróbować użycia JRuby. Już teraz jest on szybszy od klasycznego Rubiego 1.8.x a prace optymalizacyjne dopiero nabierają tempa. JRuby 1.1 (ma wyjść w tym miesiącu) ma wejść w dalszą fazę optymalizacji i odchudzania. To, plus fakt, że wirtualna maszyna Javy (JVM) sama w sobie jest bardzo mocno zoptymalizowana wydajnościowo (tak że czasem bije na głowę C++) powoduje, że to jest obiecujący kierunek rozwoju.

Innym wyjściem jest pożegnanie się z Rails i spróbowanie konkurencyjnego frameworku – Merb. Generalnie jest bardzo podobny do Rails, więc migracja jest łatwa. Merb jest za to dużo szybszy, wielowątkowy i bardziej uporządkowany. Oczywiście Merb można też odpalać pod JRuby, choć tego jeszcze nie próbowałem.

Tags ,  | 10 comments

Comments

Leave a response

  1. Avatar coldpeer said about 9 hours later:

    >> wirtualna maszyna Javy (JVM) sama w sobie jest bardzo mocno zoptymalizowana wydajnościowo (tak że czasem bije na głowę C++)

    Nie no, bez przesady ;) Gdybyś to powiedział o LISPie, byłbym skłonny uwierzyć, no ale na pewno język kompilowany do bytecodu nie będzie szybszy od kompilowanego do kodu maszynowego.

  2. Avatar wijet said about 10 hours later:

    @coldpeer Jarkowi chyba chodzilo o technike JIT

    Co do Ruby 1.9 to troche szkoda, jeszcze 3 miesiace temu mialem nadzieje ze bedzie to wersja produkcyjna.

  3. Avatar lopex said about 17 hours later:

    @coldpeer, java bywa szybsza od superoptymalizujących kompilatorów c (nie mówiąc już o c++ i gcc bo to jest kompletna tragedia). Cały wypas opiera się na runtimowej analizie wołań wirtualnych a nawet gałęzi warunkowych (c ze swoimi wskaźnikami do funkcji czy c++ z funkcjami wirtualnymi mają po prostu zbyt mało informacji żeby je optymalizować w locie). Proponuję poczytać o global optimizers, template compilers, c1, c2. Java potrafi wygenerować dużo lepszy kod pod maszynę niż gcc: http://www.stefankrause.net/wp/?p=4 http://www.stefankrause.net/wp/?p=6 Kolejna bolączka c/c++ to ciągłe męczenie systemowego manager’a pamięci, java robi to w sposób dużo bardziej amortyzowany. Java potrafi też lepiej wykorzystać PICe, eliminować warunki w locie i pozbywać się wołań wirtualnych. Bardzo dużo optymalizaji wynika z tego że w Javie nie ma wskaźników do wskaźników (i innych ficzerów c/c++), dzięki temu kompilator może przyjąć więcej założeń i wygenerować wydajniejszy kod.

  4. Avatar rsz said 2 days later:

    W jakim sensie merb jest wielowątkowy, bo pytam tu i pytam cały czas i nie dostałem odpowiedzi? Czy to znaczy, że na procesorze czterordzeniowym mogę liczyć na 4x większą przepustowość?

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

    Wydaje mi się, że Merb odpalony pod JRuby używa wątków tak jak Java, czyli w pełni wykorzysta wiele rdzeni procesora. Zaś odpalony spod CRuby/Mongrela użyje wątków podobnie jak Pylons.

  6. Avatar Radarek said 10 days later:

    Powtórzę komentarz z innego wpisu na tym blogu (http://blog.zabiello.com/articles/2007/12/26/ruby19#comment-1324):

    Jest i potwierdzenie od samego mistrza: http://groups.google.com/group/ruby-talk-google/browse_thread/thread/cf2e6fd2cf8159ee#msg_7b402b23b39c6925

    W skrócie: 1.9.0 jest wersją przejściową, przeznaczoną dla developerów. Jednakże kolejne wersje 1.9.x (x >= 1) będą przeznaczone do środowisk produkcyjnych (oczywiście zmiany w 2.0 mogą zajść, ale to samo byłoby przy przejściu 1.8 -> 2.0). Na wersję 2.0 możemy czekać jeszcze całkiem sporo.

  7. Avatar Michal said 22 days later:

    Pokażcie mi ta Jave szybsza od c, c++

  8. Avatar iddqd said about 1 month later:

    Jestem programistą Python,Java, C++,Ruby. Pracuję w portalu z 1 000 000 000 odsłon miesięcznie. Java dyskwalifikuje tragiczna obsługa pamięci. Zobacz co się dzieje gdy zajmiesz około 6GB ram (treecache) zwolnisz i zaczniesz przypisywać dane od nowa. Przez 1-3 min JVM czyści pamięć, nie robi w tym czasie nic innego. To samo napisane w C nawet się nie zająknie.

  9. Avatar kaminskp said 2 months later:

    Jestem Ciekawy co mogę przy pomocy tego języka zdziałać. Jeśli można oczekuję odpowiedzi. kaminskp@tlen.pl Dziękuje.

  10. Avatar JCoder said 4 months later:

    @iddqd: Napisanie tego samego w C spowoduje, że te 3 minuty zamienią się w 20 minut rozłożonych mniej więcej po równo w czasie. Java po prostu kumuluje zwalnianie pamięci w jednym miejscu, co sumarycznie jest wydajniejsze niż zwalnianie po kawałku jak w C. Jeśli nie chcecie mieć opóźnienia, wystarczy użyć współbieżnego GC (ustawiane za pomocą którejś opcji -XX:)

RSS feed for this post

(leave url/email »)

   Comment Markup Help Preview comment