Jarosław Zabiełło - BLOG: Sun zatrudnił programistów JRuby

Sun zatrudnił programistów JRuby

Jarosław Zabiełło — Fri, 08 Sep 2006 10:33:00 +0200

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.

"Sun zatrudnił programistów JRuby" by stforek

Fri, 02 Mar 2007 14:24:15 +0100

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.

"Sun zatrudnił programistów JRuby" by kelahcim

Wed, 27 Sep 2006 09:54:50 +0200

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

"Sun zatrudnił programistów JRuby" by rsz

Thu, 14 Sep 2006 13:54:52 +0200

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…

"Sun zatrudnił programistów JRuby" by Jarosław Zabiełło

Thu, 14 Sep 2006 13:50:12 +0200

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

"Sun zatrudnił programistów JRuby" by lopex

Thu, 14 Sep 2006 12:22:34 +0200

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…

"Sun zatrudnił programistów JRuby" by rsz

Thu, 14 Sep 2006 09:58:52 +0200

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ść.

"Sun zatrudnił programistów JRuby" by rsz

Thu, 14 Sep 2006 09:47:51 +0200

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.

"Sun zatrudnił programistów JRuby" by rsz

Thu, 14 Sep 2006 09:44:32 +0200

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.

"Sun zatrudnił programistów JRuby" by lopex

Wed, 13 Sep 2006 19:25:09 +0200

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

"Sun zatrudnił programistów JRuby" by lopex

Wed, 13 Sep 2006 18:36:43 +0200

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

"Sun zatrudnił programistów JRuby" by lopex

Wed, 13 Sep 2006 18:35:21 +0200

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ą ;)

"Sun zatrudnił programistów JRuby" by rsz

Wed, 13 Sep 2006 15:17:20 +0200

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).

"Sun zatrudnił programistów JRuby" by Jarosław Zabiełło

Wed, 13 Sep 2006 15:04:03 +0200

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!

"Sun zatrudnił programistów JRuby" by rsz

Wed, 13 Sep 2006 14:52:48 +0200

a’propos wydajności IronPythona polecam:

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

"Sun zatrudnił programistów JRuby" by rsz

Wed, 13 Sep 2006 14:43:41 +0200

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

"Sun zatrudnił programistów JRuby" by Jarosław Zabiełło

Wed, 13 Sep 2006 14:37:04 +0200

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.

"Sun zatrudnił programistów JRuby" by rsz

Wed, 13 Sep 2006 14:31:59 +0200

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.

"Sun zatrudnił programistów JRuby" by rsz

Wed, 13 Sep 2006 14:28:53 +0200

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.

"Sun zatrudnił programistów JRuby" by Jarosław Zabiełło

Wed, 13 Sep 2006 13:50:47 +0200

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

"Sun zatrudnił programistów JRuby" by Wołek

Wed, 13 Sep 2006 13:20:21 +0200

czemu moj komentarz musi byc zatwierdzony przez moderatora?

"Sun zatrudnił programistów JRuby" by Wołek

Wed, 13 Sep 2006 13:19:32 +0200

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.

"Sun zatrudnił programistów JRuby" by lopex

Tue, 12 Sep 2006 23:05:19 +0200

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

"Sun zatrudnił programistów JRuby" by lopex

Tue, 12 Sep 2006 23:02:24 +0200

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

"Sun zatrudnił programistów JRuby" by Wołek

Tue, 12 Sep 2006 22:51:01 +0200

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

"Sun zatrudnił programistów JRuby" by lopex

Tue, 12 Sep 2006 22:41:08 +0200

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…