Sun zatrudnił programistów JRuby

Opublikowane przez Jarosław Zabiełło Fri, 08 Sep 2006 08:33:00 GMT

W środowisku javowców Ruby jest językiem który robi trochę zamieszania (jakoś tak się składa, że Ruby bardziej przemawia do programistów Javy niż Python). Cieszy zatem, że firma Sun podjęła decyzję o wsparciu projektu JRuby zatrudniając jego czołowych developerów. Powinno to znacznie przyśpieszyć prace nad tym projektem podobnie jak stało się z IronPythonem, gdy Microsoft zatrudnił jego twórcę.

Jestem ciekaw jak długo programiści zachowają entuzjazm dla swego języka, gdy będzie można generować taki sam bytecode Javy lecz w niezrównanie prostszy sposób. :)

Przykładowy kod Javy:

public class Filter {
  public static void main(String[] args) {
    List list = new java.util.ArrayList();
    list.add("Tim"); list.add("Ike"); list.add("Tina");
    Filter filter = new Filter();
    for (String item : filter.filterLongerThan(list, 3)) { 
      System.out.println( item ); 
    }
  }
  public List filterLongerThan(List list, int length) {
    List result = new ArrayList();
    for (String item : list) {
      if (item.length() <= length) { result.add( item ); }
    }
    return result;
  }
}

A oto odpowiadający mu kod w Ruby:

list = ['Tim', 'Ike', 'Tina']
list.select {|n| n.length > 3}.each {|n| puts n}

Oczywiście to nie wszystko. Dzięki JRuby można uzyskać efekty kompletnie nieosiągalne w standardowej Javie – np. można pracować z biblioteką Swing w sposób interaktywny, z poziomu interpretera zmieniając na żywo jej obiekty.

Wkrótce ma także być gotowa wersja Railsów działająca z JRuby (Zobacz prezentację w PowerPoint). Tym samym odeszłyby wszelkie uwagi co do wydajności Railsów, bo współczesna wirtualna maszyna Javy jest tak silnie zoptymalizowna że dorównuje językowi C++. Oczywiście model wątkowy JRuby jest zgodny z wydajnym i dojrzałym modelem wątkowym Javy – po prostu z niego korzysta.

Posted in ,  | Tagi , ,  | 32 comments

Comments

  1. Avatar Eluś powiedział 2 days later:

    To nie będzie ten sam bytecode.

    W sposób interaktywny z biblioteką Swing można pracować praktycznie w każdym języku posiadającym implementacje w Javie i posiadającym tryb interaktywny (np. w JavaScript – projekt Rhino).

  2. Avatar splatch powiedział 2 days later:

    Java ma już język skryptowy – jest nim Groovy.

  3. Avatar Jarosław Zabiełło powiedział 2 days later:

    Eluś: to będzie taki sam bytecode. Splatch: Jest też (lepszy) Jython (gdzieś kiedyś czytałem że ma większe wsparcie od Grooviego)

  4. Avatar hauser powiedział 3 days later:

    Ktos kto robil by to samo w javie napisalby juz raczej takie cos:

    import java.util.*;
    public class Filter {
        public static void main(String[] args) {
            List<String> names = Arrays.asList( new String[]{ "Tim", "Ike", "Tina" } );
    
            for( String item : names ) {
                if( item.length() > 3 ) {
                    System.out.println( item );
                }
            }
        }
    }
    
  5. Avatar Wołek powiedział 3 days later:

    Jak to jest ze ja jakos nie widze tej porownywalnej wydajnosci c++ i javy?

  6. Avatar lopex powiedział 4 days later:

    bywa że java jest duuuużo bardziej wydajna niż C++

  7. Avatar Wołek powiedział 4 days later:

    lopex podaj jakis konkretny przyklad, bo ja jakos nigdy na oczy takiego programu nie widzialem(oczywiscie nalezy porownywac te same algorytmy bo nie ma sensu prownywac buble sorta napisanego w c do quicksorta napisanego w javie).

  8. Avatar lopex powiedział 4 days later:

    Sparsuj jakiegos dużego głębokiego xmla xercesem w Javie i C++ bez własnego menadżera pamięci – zobaczysz jak C++ kwiczy bez amortyzacji…

  9. Avatar Wołek powiedział 4 days later:

    To so najprawdopodobniej blendy implementacji bo nie ma zadnego powodu dla ktorych c++ ma byc wolniejszy.

  10. Avatar lopex powiedział 4 days later:

    Są, właśnie amortyzacja zwalniania pamięci

  11. Avatar lopex powiedział 4 days later:

    W Javie problem fragmentacji pamięci i męczenia systemowego memory managera nie jest tak widoczny jak w C++

  12. Avatar Wołek powiedział 5 days later:

    Moze i jest mniejsza fragmentacja, ale za to dochodza dodatkowe cykle zwiazane z garbage collectorem no i zzera wiecej pamieci bo nie jest ona odrazu zwalniana. Wiec nie widze tu jakiegos wzrostu wydajnosci, a nawet jego spadek Skoro w tej bibliotece co podales tyle cykli zegara traci sie na czeste zwalnianie pamieci, powinna ona uzywac jakiegos menagera pamieci i zwalniac ja co jakis czas, to juz jest blad projektowy, ale nie da sie ukryc ze przemawia to na korzysc modelu pamieci dostepnego w javie.

  13. Avatar Wołek powiedział 5 days later:

    czemu moj komentarz musi byc zatwierdzony przez moderatora?

  14. Avatar Jarosław Zabiełło powiedział 5 days later:

    Mam tu dziś atak debilnych spamerów z jakimiś kasynami online i co chwilę wrzucają śmieci do róznych artykułów.

  15. Avatar rsz powiedział 5 days later:

    Kompilacja rubiego do bajtkodu javy nie poprawi jego wydajności ze względu na różnice semantyczne między tymi językami (głównie brak możliwości ekstrakcji informacji o typach i przepływie kontroli z kodu w językach dynam. typu Ruby). Podobnie, jak założenie opon Pirelli do małego fiata nie sprawi, że będzie on popylał jak Ferrari.

    Pisanie takich wprowadzających ludzi w błąd rzeczy (że JRuby dopali w stos. do normalnego) świadczy o ignorancji w kwestii implementacji języków i maszyn wirtualnych.

    Jedynym (i bardzo ważnym) celem tego projektu jest integracja z bardzo bogatą (no, przyznajcie to Rubiści) infrastrukturą i bibliotekami już dostępnymi w Javie.

  16. Avatar rsz powiedział 5 days later:

    Acha, no i wygenerowanie tego samego bajtkodu z Rubiego co z Javy nie jest możliwe, bo Ruby w sensie semantyki operacyjnej maszyny wirtualnej jest Javy podzbiorem. Zawsze więc będą sekwencje bajtkodu, które można wygenerować z Javy, a nie można z Ruby’ego.

  17. Avatar Jarosław Zabiełło powiedział 5 days later:

    Fakty są takie, że np. Ruby na YARV popyla do 10x szybciej niż klasycznie. A to m.in. znaczy, ze Ruby2 na swej maszynie wirtualnej ma szansę spokojnie pobić wydajnościowo Pythona. IronPython też niby nie powinien być szybszy od swej standardowej (w C) implementacji, a jest szybszy.

  18. Avatar rsz powiedział 5 days later:

    Ale co ma IronPython i YARV do wydajności JRubiego? I skąd masz te informacje o wydajności IronPythona i YARV’a?

  19. Avatar rsz powiedział 5 days later:

    a’propos wydajności IronPythona polecam:

    http://lists.ironpython.com/pipermail/users-ironpython.com/2006-July/002954.html

  20. Avatar Jarosław Zabiełło powiedział 5 days later:

    To żadna tajemnica, że z wydajnością IronPythona było bardzo dobrze. Jak pokazuje standardowy bechmark PyStone – IronPython jest ponad półtora razy szybszy od Pythona 2.4.

    Zaś co do YARV to jest sporo info w necie. Ostatnio była dyskusja na comp.lang.ruby (wątek “Pros/Cons of Turbogears/Rails”) Zobacz ten link. Artykuł jest po hiszpańsku ale da się odczytać liczby. W porywach YARV daje przyśpieszenie nawet do 20 razy!

  21. Avatar rsz powiedział 5 days later:

    Przy odpowiednio wybranym przykładzie też mogę wykazać dowolnie duże różnice wydajności pomiędzy dowolnymi dwoma językami/platformami ;) Liczby, z którymi się ja spotkałem, są zgodne z tym, co piszesz odnośnie IronPythona i to nie jest żaden duży wzrost wydajności. Natomiast jeśli chodzi o yarv’a spotkałem się raczej z ostrożnymi szacowaniami 2-3x wzrostu wydajności (są np. gdzieś w sieci wyniki z language shootout), ale uwaga: przy założeniu, że dany kod W OGÓLE DZIAŁA. Jak osiągnięcie poprawności YARV’a odbije się na wydajności, pozostaje pytaniem otwartym, a wnioskując po doświadczeniach twórcy IronPythona można przypuszczać, że niepozytywnie.

    Z drugiej strony patrząc, wydaje się, że twórcy yarv’a są dość kompetentni, skoro zaimplementowali direct threading (stara dobra technika z Fortha którą ignorują developerzy CPythona) i inline method cache (tudzież stara technika, chyba ze smalltalków).

  22. Avatar lopex powiedział 5 days later:

    rs: “Kompilacja rubiego do bajtkodu javy nie poprawi jego wydajności ze względu na różnice semantyczne między tymi językami”

    http://smallthought.com/avi/?p=16

    tak samo się mylisz jak Joel z którego się teraz wszyscy śmieją ;)

  23. Avatar lopex powiedział 5 days later:

    aaaa… i: http://www.codinghorror.com/blog/archives/000679.html

  24. Avatar lopex powiedział 5 days later:

    Piers też się wypowiedział:

    http://www.bofh.org.uk/articles/2006/09/13/what-we-have-here-is-an-opportunity-to-accelerate

    a propos Yarva – na shootout nie było w nim włączonych dwóch ważnych rzeczy - specialized instruction optimization, to dopala metody takie jak Finxum#*,+ - peephole optimization – http://en.wikipedia.org/wiki/Peephole_optimization

    Z każdym snapshotem YARV jest coraz szybszy a o e.w. niepoprawności ciężko tu mowić, bo parser + runtime + core to jest po prostu ruby 1.9

  25. Avatar rsz powiedział 5 days later:

    lopex: cóż za zbieg okoliczności, materiał o strongtalku zacząłem czytać równo z Twoim komentarzem :)

    Co do meritum sprawy: nie twierdzę, że nie można poprawić wydajności maszyny wirtualnej rubiego (czy np. CPythona). Można to zrobić w pewnym zakresie przez optymalizacje natury peephole np. lepszy mechanizm interpretacji bajtkodu, poprawki w gc, bibliotekach itp. Natomiast wykonanie ogólno-funkcyjnej, ogólno-modułowej czy ogólno-programowej analizy i optymalizacji w takich językach jest nieprawdopodobnie trudne i skomplikowane (o czym wiesz doskonale, jeśli czytałeś artkuły twórców Selfa nt optymalizacji) a w ostateczności i tak zawsze czai się za rogiem Turing pit i nierozstrzygalność. Problem jest znacznie bardziej jaskrawy w Rubym, gdzie absolutną normą w designie jest wysoce nielokalne (rozrzucone po modułach) konstruowanie klas (co nb uważam za bad design i spaghetti code). Zauważ, że zarówno Self, jak i Smalltalk w tej kwestii są bardziej poukładane, przez co dopuszczają nieco prostszą i dalej idącą analizę przepływu kontroli.

    Natomiast niektóre podstawowe optymalizacje, normalne dla kompilatorów jęz. statycznie typowanych z normalną kontrolą przepływu, jak np. analiza ucieczki czy k-CFA są w ogóle niewykonalne dla języków z duck typing, przynajmniej nigdzie nie widziałem jakichkolwiek opublikowanych prób zrobienia czegoś takiego i nie wyobrażam tego sobie.

    Jeszcze jedna sprawa, Avi Bryant nie wygląda na kogoś wybitnie kompetentego w tych kwestiach. W arcie z jego bloga, który podlinkowałeś, jest masa machania rękami (np. że w 95% przypadków wywołanie metody sprowadza się do CMP+CALL – skąd on ma takie informacje??? albo komentarz o eliminacji vtable – no normalnie zasługuje chyba na nagrodę Turinga z takimi pomysłami) i żadnych konkretów, a w przypadku kompilatorów i maszyn wirt. wszystko rozbija się o małe, upierdliwe szczegóły, które trzeba z ogromną dbałością o poprawność i np. zachowanie warunku stopu połączyć w działającą całość. Na ten temat dość ciekawe doświadczenia z pierwszej ręki przedstawia autor IronPythona.

    Ostatecznym jednak argumentem w tej debacie jest prosta konstatacja – ekstremalnie wyrafinowanych (np. w językach funkcyjnych – samo pomyślenie o karczowaniu lasów przyprawia mnie o dreszcz emocji), optymalizujących kompilatorów dla języków “statycznych” jest na pęczki, dynamicznych – no… Strongtalk, może trochę Self optymalizują… ale gdzie im do konkurencji?

    Oczywiście moje stwierdzenie “nie poprawi” było naciągnięte, powinno być “nie poprawi w znaczącym/rzucającym na kolana stopniu”.

    A’propos Joela ja to widzę tak, że śmieją się z niego ludzie, którzy nie mają dostatecznie dużo wiedzy i inteligencji, żeby napisać cokolwiek bardziej wyrafinowanego, niż kolejny badziew w PHP/J2EE. Co jest smutne, bo cała ta “społeczność”, “ekosystem” powstały wokół języków dynamicznych tak się chełpi(ł) swoją niezależnością i trzeźwym, adogmatycznym patrzeniem na świat. Sorry, nie każdy potrafi napisać kompilator targetujący do tego kilka skrajnie różnych architektur, więc po prostu może powinni się STFU jak nie mają o tym pojęcia. Banda idiotów z klapkami na oczach. A większość klapek oczywiście koloru rubinowego, co potwierdza moje przypuszczenia o poziomie tej “społeczności”. Do tego jeszcze każdy z nich broni wydajność skrajnie niewydajnego runtime’a, jakim jest maszyna ruby’ego, przez unikanie ucziwych porównań i rzucanie masy nic nie znaczących sloganów martketingowych, pół-prawd i ataków ad-hominem.

    Żałosne.

  26. Avatar rsz powiedział 5 days later:

    Acha, no i przede wszystkim odboxowywanie typów (type erasure) jest absolutnie niemożliwe w językach typu Python/Ruby, a samo to sprawia, że wydajność tych runtime’ów będzie zawsze kilkakrotnie niższa, niż optymalizowanego kodu z języków statycznie typowanych.

  27. Avatar rsz powiedział 5 days later:

    Acha, no i wszystkie komentarze (ile tam lania wody!) odnośnie PIC i analizy “najczęstszych ścieżek” są w podlinkowanych artykułach pisane przez ludzi na prawdę mających blade pojęcie o tym np., że tego rodzaju CFA jest albo wysoce niedokładne, albo zużywa niewyobrażalne ilości pamięci. Nie można jednocześnie mieć ciasteczka i go zjeść.

  28. Avatar lopex powiedział 6 days later:

    rsz: Aj… to już zakrawa na dyskusję na usenecie.. Nie wiem od czego zacząć a muszę się streszczać .. ;) - Smalltalk umożliwia tak samo porozrzucane definicje – zawsze możesz: SomeClasss methodsFor: ’...’. - Za daleko wybiegasz z CFA i optymalizacją przepływu, Turingiem i problemem stopu, może jeszcze Omega Chaitin ? Chodzi o zwykłe cachowanie wołań. - Nigdy nie twierdziłem że można zrobić więcej bez informacji o typach. - nie CMP+CALL tylko CALL+CMP, dochodzą jeszcze wołania polimorficzne i megamorficzne – to, liczby i eliminacja vtable są wzięte z artykułu o Selfie – polecam, dlaczego tu biednego Turinga znowu wciągasz? - Ehhh… kompilator generujący kod VB, rewelacja… - Po raz drugi: nigdy nie twierdziłem że można zrobić więcej bez informacji o typach. - Cała dyskucja sprowadza się do tego że twierdzę że można zrobić więcej niż Ty twierdzisz. Nie znaczy to, że musisz się miotać i obrażać ludzi. Jeszcze raz polecam artykuł o Selfie…

  29. Avatar Jarosław Zabiełło powiedział 6 days later:

    Panowie, może faktycznie przenieście kontynuację dyskusji na grupę pl.comp.lang.ruby

  30. Avatar rsz powiedział 6 days later:

    Art o Selfie czytałem nie raz :) Zasadniczo się z Tobą więc zgadzam, a nie zgadzam z JZ; nie wiem, czy zauważasz, że jego pianie jest trochę na wyrost. A mimo wszystko podtrzymuję, że PIC jest przereklamowany, bo to run-timeowa forma CFA, a tu potrzebujesz dużo info o typach i np. o niezmienności funkcji przyczepionych do obiektów/klas, żeby coś pożądnie zoptymalizować.

    W dalszym ciągu uważam natomiast, że plucie na Joela przez ludzi, którzy nigdy nie zaimplementowali jakiegokolwiek software’u zahaczającego o przetwarzanie języków programowania jest po prostu żenujące. To nie ja obrażam ludzi, to oni obrażają, nie dość, że Joela, to jeszcze zdrowy rozsądek, który każe siedzieć cicho jak się o czymś (a szczególnie o złożoności czegoś) nie ma pojęcia. A może po prostu zazdroszczą mu $? Historia jest tu analogiczna z Grahamem – z niego też się śmieli, jak wymyślał te łamańce z DSLami w lispie, a potem sprzedał viaweb za parę milionów dol, hehe…

  31. Avatar kelahcim powiedział 18 days later:

    Na dzien dzisiejszy rowniez mozna “interaktywnie” obslugiwac obiekty Swinga – to sie nazywa refleksja

  32. Avatar stforek powiedział 5 months later:

    Wołek, w C++ nie tylko zwalnianie pamięci obniża wydajność, ale też jej alokacja. Niewiele więc poradzisz przez zwalnianie pamięci większymi porcjami. Mógłbyś poradzić robiąc alokator bazujący na puli obiektów, ale implementacja wydajnej puli obiektów jest trudna i większośc programistów tego nie potrafi.

    Standardowa alokacja pamięci w C++ jest kilkaktrotnie wolniejsza od alokacji w Java lub .NET.

(leave url/email »)

   Pomoc języka formatowania Obejrzyj komentarz