GraalVM - High-Performance Polyglot Runtime

Odpowiedz Nowy wątek
2017-07-23 18:19
4

Zespół badawczy od Oracle'a pracuje nad nowym kompilatorem (z AST do kodu natywnego) oraz odpowiadającym mu frameworkiem (o nazwie Truffle) do szybkiej implementacji języków programowania. Dzięki frameworkowi implementator nowego języka musi jedynie napisać w Javie tłumacza z własnego języka na Truffle AST, a optymalizacją zajmie się tandem Truffle + Graal.

Artykuł: Graal & Truffle

We would want something, some kind of tool or technique, that gave us the following:

  • A way to create a new language in just a few weeks
  • That ran as fast as the fastest other languages, automatically
  • That had high quality debugging support, automatically (ideally without any kind of slowdown)
  • That had profiling support, automatically
  • That had a high quality garbage collector, automatically … but only if we wanted one
  • That could use all the existing code that was out there, no matter what language it was written in
  • That supported any style of language, from low level C or FORTRAN to Java to Haskell to extremely dynamic scripting languages like Python and Ruby
  • And which could be either just-in-time or ahead-of-time compiled
  • And heck, why not, that supports hotswap of code into a running program
  • Oh, and we’d want this magic tool to be open source of course. And, er, it should come with a pony. I think that’s it.

Being a smart reader, you of course already guessed that I wouldn’t be writing this article unless such a tool actually did exist. It goes by the bizarre name of Graal & Truffle. Despite sounding like it should be a pretentious hipster restaurant, it is actually a vast research project with over 40 computer scientists from across industry and academia. Together they are building a new set of compiler and virtual machine technologies that implements our wishlist above.

Lista publikacji na stronie projektu: https://github.com/graalvm/gr[...]b/master/docs/Publications.md

W prezentacji https://lafo.ssw.uni-linz.ac.[...]/papers/2016_PLDI_Truffle.pdf jest taki slajd o porównaniu wydajności GraalVMa w stosunku do najszybszych alternatyw (w sensie: jak szybko dany język chodzi na Graalu w porównaniu do najszybszej konkurencyjnej VMki dla tego języka):
screenshot-20170723180632.png
Wyniki są chyba jednak trochę przestarzałe, bo powtarzają się w wielu prezentacjach. Mimo wszystko już jest nieźle.

Graala można ściągnąć stąd: http://www.oracle.com/technet[...]languages/overview/index.html
Zawiera nawet taką funkcjonalność jak: node - Drop-in replacement for node.js with Graal.js as the executing JavaScript engine.

Moim zdaniem projekt ma mega potencjał. Nie wiadomo jednak kiedy będzie miał oficjalny status (obecnie jest w fazie rozwoju). Java 9 (która wychodzi za niecałe dwa miesiące) będzie mieć ukrytą pod przełącznikami nową funkcjonalność - możliwość podpięcia Graala jako wtyczki dla HotSpota. Prawdopodobnie w którejś kolejnej wersji Javy GraalVM zostanie zintegrowany z HotSpotem jako kolejny poziom optymalizacji.

Aktualizacja:
Nowa strona GraalVM'a jest pod adresem: https://www.graalvm.org/


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 2x, ostatnio: Wibowit, 2018-04-18 10:19

Pozostało 580 znaków

2017-07-24 10:38
0

Wygląda bardzo obiecująco, szczególnie biorąc pod uwagę, że pozwoli, to na integrowanie dowolnego języka bezpośrednio z VMką jedynie za pomocą odpowiedniego transpilera język-> truffle AST. Zastanawiam się jedynie jak będzie wyglądać dostęp do API z poziomu czystej Javy, bo jeżeli to jakoś rozwiążą (nazewnictwo produkowane przez Gralla), to w sumie platforma Java będzie miała jeszcze ze stulecie przed sobą.

Pozostało 580 znaków

2017-07-24 10:47
0

Macie jakieś badania / raporty na temat tego gdzie wykorzystuje się języki JVM-owe (nie Java i nie Scala) na szeroką skalę?
Bo mam wrażenie że głównie jako support do Javy (typu Jython w WebSphere).
A jeśli by tak było to w zasadzie nie ma się czym ekscytować.


Szacuje się, że w Polsce brakuje 50 tys. programistów
Badania to za duzo powiedziane ale wiem ze troche osob uzywa Groovy przy wsparciu automatyzacji testow, skryptowaniu JMeter'a itp. - WhiteLightning 2017-07-24 10:51

Pozostało 580 znaków

2017-07-24 11:03
0

Groovy jako język testowy i budowania:

  • gradle
  • pipeline w Jenkinsie
  • spock
  • jmeter

Kotlin obecnie język drugiego wyboru dla Androida. Google dodał go do listy oficjalnie wspieranych języków.
I to chyba na tyle. Szukałem już pewien czas temu takiego raportu i nic nie ma :(

Pozostało 580 znaków

2017-07-24 11:10
0

To w zasadzie potwierdza to co napisałem. Może z wyjątkiem Kotlina, ale nie wiadomo czy on przyspiesza na GraalVM, bo nie jest skryptowy.
Groovy jest wykorzystywany w Grails, ale nie wiem ile firm go stosuje, ja spotkałem jedną poważną firmę, ale szczególnie się tym nie interesowałem (zwłaszcza po wyskokach autora Groovy).

Cytuję:
"I can honestly say if someone had shown me the Programming Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy."
(był jeszcze gdzieś cytat że Scala też mu się przejadła - ale nie wiem czy prawdziwy)


Szacuje się, że w Polsce brakuje 50 tys. programistów
edytowany 2x, ostatnio: vpiotr, 2017-07-24 11:19
No i co że miał jakieś "wyskoki"? Autor Groovy'ego od ponad 10 lat już nad nim nie pracuje, więc jego opinie nie mają żadnego wpływu na język. Poczytaj sobie jaki cyrk był jak wyszło, że autor JavaScriptu dotował California Proposition 8: https://en.wikipedia.org/wiki/Brendan_Eich - Wibowit 2017-07-24 21:42
Nie wiem, dla mnie ten facet ośmieszył swój własny projekt. Może z zawiści (bo np. stracił nad nim kontrolę) a może ten język rzeczywiście jest słaby - skoro nawet jego autor nie potrafi się profesjonalnie zachować? Fajny jest wywiad w Programiście z autorem PHP - facet przynajmniej jest skromny i stabilny emocjonalnie. - vpiotr 2017-07-25 09:30
Groovy dobrze się sprawdza jako język skryptowy - nie wymaga kompilacji, ma dostęp do biblioteki javy, można go używać bez kontroli typów. Groovy jako narzędzie do wszystkiego, zamiast basha. - jarekczek 2017-07-25 21:41

Pozostało 580 znaków

2017-07-24 21:35
1

@vpiotr
Absolutnie nie rozumiem co mało używane języki JVMowe mają wspólnego z Graal VM. Graal opiera się o AST, pomija całkowicie konwersję do Javowego bajtkodu. Nie ma też w planach robienia specjalnego backendu dla Scali, Kotlina czy Groovy'ego skoro są to języki wprost przeznaczone do kompilacji do Javowego bajtkodu.

Myślę, że nie ma sensu powtarzać tego co jest w linkach które podałem w pierwszym poście (czytaliście to w ogóle?), więc może podam jakiś przykład.

Załóżmy, że chcemy z poziomu Javy (np w odpowiedzi na zapytanie RESTowe) wywołać jakiś kod Pythonowy, który z kolei korzysta z kodu napisanego w C.

Obecne opcje są takie:

  1. Odpalenie rzeczywistego Pythona. Zalety są takie, że nie trzeba się martwić kompatybilnością (używamy przecież standardowego interpretera). Wadą jest bardzo niska prędkość, zarówno przez to, że startujemy Pythona w kółko od nowa jak i przez to, że Python jest bardzo powolnym interpreterem.
  2. Użycie Jythona, który jest generalnie równie wolny jak standardowy Python w wykonywaniu kodu czysto Pythonowego, ale nawet wolniejszy jeśli używamy JNI do uruchamiania kodu natywnego. Jython w obecnej postaci jest więc mało atrakcyjny. Zyskujemy jedynie na tym, że nie trzeba ładować Pythona w kółko od nowa.

W przypadku Graala możliwości są takie (obecnie jest implementacja Pythona dla Graala https://github.com/securesystemslab/zippy ale nie wiem które funkcjonalności obsługuje):

  • kod Pythonowy i C są tłumaczone na wspólne AST (leniwie, tzn linijki kodu są tłumaczone na AST w momencie pierwszego wykonania)
  • Graal VM interpretuje, a następnie JITuje powstały AST, przez co narzut na przeplatanie się języków jest zredukowany do minimum
  • dostajemy kod, który jest bardzo szybki, bo użyliśmy zaawansowanego JITa, zaawansowane GC i ominęliśmy powolne interfejsy typu JNI

Myślę, że najwięcej szumu może narobić implementacja Node.js oparta o Graala. Dzięki użyciu Graala można odpalać JavaScriptowe wstawki z prędkością oferowaną przez Google'owe V8 bez narzutu na start tegoż V8. Odpalanie wstawek JavaScriptowych w JVMce pociąga za sobą mocne zalety:

  • redukcja duplikacji kodu - możemy tę samą walidację odpalić zarówno po stronie klienta jak i serwera
  • renderowanie kodu HTML po stronie serwera - w przypadku takiego Reacta czy Angulara mamy możliwość wyrenderowania statycznego HTMLa, który służy do szybkiego wyświetlenia początkowej postaci strony zanim załaduje się ów React czy Angular, podepną się pod DOMa i zaczną obsługiwać zdarzenia

Obecnie mamy w Javie do dyspozycji silniki JavaScript jak Mozilla Rhino czy Nashorn, ale oba są powolne (Rhino to już w ogóle) oraz mają spore ograniczenia (na rozmiar kodu, który mogą wykonać).

Ponadto są jeszcze inne miejsca, gdzie Graal VM może dać niezłego kopa. Mam na myśli Apache Spark. Spark jest napisany w Scali, ale oferuje interfejsy dla Javy, Scali, Pythona i R. Wykorzystanie Graala sprawiłoby, że kod w Pythonie czy R wykonywałby się znacznie szybciej, a to zwiększyłoby atrakcyjność Sparka dla analityków danych.

Obecnie jest sporo języków, którym brakuje wydajnej VMki: Python, Perl, PHP, Ruby, R, itd Wszystkie korzystają z bibliotek napisanych w C. Stąd pisanie dla nich implementacji, które opierają się na Javowym bajtkodzie i wywołaniach JNI jest dość mało atrakcyjne, bo rewolucji się tak nie zrobi. Dopiero Graal da tutaj dużego kopa i to wszystkim tym językom naraz.

Czysto natywnego kodu jak na razie Graal nie przyspiesza - w sensie LLVM IR jest JITowany przez Graala do zwykle trochę wolniejszego kodu niż ten który jest wypluwany przez kompilator LLVM AOT. Graal jest jednak dość młodym projektem w porównaniu do LLVM, więc jeszcze dużo może się zdarzyć. Najwcześniejsze commity w Graalu jakie wypatrzyłem były z 2012 roku, natomiast LLVM miał pierwsze wydanie w 2003 roku (tak podaje Wikipedia).


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
Ja jeszcze dorzucę jedną rzecz – może okazać się, że łatwiej jest skompilować coś (domyślnie scalę, bo ona jest chyba najbardziej zagmatwana) do AST i zdać się na optymalizator niż kompilować do bytecodu. - Koziołek 2017-07-24 21:52

Pozostało 580 znaków

2017-07-25 08:31
0

@Wibowit: dzieki za wyjasnienie. Z tego co opisales to JavaScript dla mnie ma najwiekszy sens jako najbardziej popularny dodatek do Javy. Python - moze dla Javovcow na jvm ma sens, ale to zbyt popularny jezyk zeby sie nagle wszyscy przerzucili z wersji C (free w znaczeniu GNU) na kontrolowana przez Wielka Czerwona Wrozke jvmke.


Szacuje się, że w Polsce brakuje 50 tys. programistów

Pozostało 580 znaków

2017-07-25 21:40
0

byłem tamtym roku na geeconie razem z @jarekr000000 i na żywo fajnie prezentowało się to ustrojstwo


Hate the sin, love the sinner

Pozostało 580 znaków

2017-07-27 01:03
2

Nie wiem, dla mnie ten facet ośmieszył swój własny projekt. Może z zawiści (bo np. stracił nad nim kontrolę) a może ten język rzeczywiście jest słaby - skoro nawet jego autor nie potrafi się profesjonalnie zachować? Fajny jest wywiad w Programiście z autorem PHP - facet przynajmniej jest skromny i stabilny emocjonalnie. - vpiotr wczoraj, 09:30

Nie widzę absolutnie nic nieprofesjonalnego w stwierdzeniu "I can honestly say if someone had shown me the Programming Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy." Programowanie to nie polityka - tutaj nie musisz iść w zaparte i przekonywać wszystkich, że jesteś nieomylny i najlepszy. James Strachan przestał zajmować się Groovy'm, ale schedę po nim przejęli inni i projekt był cały czas stabilny i bardzo funkcjonalny.

Podniecasz się autorem PHP, a sytuacja jest taka, że autor PHP sam się przyznał do wielu kompromitujących rzeczy ( https://en.wikiquote.org/wiki/Rasmus_Lerdorf ):

  • I did not develop the PHP we know today. Dozens, if not hundreds of people, developed PHP. I was simply the first developer.
  • I actually hate programming, but I love solving problems.
  • I was really, really bad at writing parsers. I still am really bad at writing parsers.
  • I've never thought of PHP as more than a simple tool to solve problems.
  • I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way.

To ostatnie jest szczególnie kompromitujące, ale oddaje istotę PHP - to coś zaczynało jako pseudo-język ze zlepków luźnych pomysłów, bez świadomości tego jak tworzy się dobrze ustrukturyzowane języki programowania.

@Wibowit: dzieki za wyjasnienie. Z tego co opisales to JavaScript dla mnie ma najwiekszy sens jako najbardziej popularny dodatek do Javy. Python - moze dla Javovcow na jvm ma sens, ale to zbyt popularny jezyk zeby sie nagle wszyscy przerzucili z wersji C (free w znaczeniu GNU) na kontrolowana przez Wielka Czerwona Wrozke jvmke.

Pewnie nie zajrzałeś po te linki które podałem. Podam więc jeszcze raz http://www.oracle.com/technet[...]languages/overview/index.html
Jest tam taka wyliczanka:

  • node - Drop-in replacement for node.js with Graal.js as the executing JavaScript engine.
  • ruby - Drop-in replacement for MRI Ruby with TruffleRuby as the executing Ruby engine.
  • R - Drop-in replacement for GNU R with FastR as the executing R engine.

Jak widać, jest mocny nacisk na kompatybilność z oficjalnymi implementacjami. Jeżeli użycie GraalVMa dla naszego ulubionego języka będzie wiązało się tylko i wyłącznie z podmianą ścieżki do środowiska uruchomieniowego, a zysk będzie namacalny (w stylu kilka lub kilkadziesiąt razy wyższa wydajność) to wybór będzie oczywisty.

Dla zysku wydajnościowego ludzie są nawet w stanie poświęcić trochę kompatybilności. Tak było z PHP przed wersją 7 (gdzie we współpracy z Intelem mocno poprawiono wydajność interpretera) i HHVM'em od Facebooka. HHVM nie był w 100% kompatybilny z PHP (chyba nawet dość daleko było do tego), ale miał sporą bazę użytkowników, bo pod HHVM'em programy napisane w PHP działały kilkakrotnie szybciej.

Implementacje GraalVM'owe będą moim zdaniem (tzn wg mnie wszystko na to wskazuje) znacznie bardziej kompatybilne z oficjalnymi interpreterami niż HHVM od Facebooka, a zarazem będą dawać bardziej wymierne korzyści, więc Graalowi wróżę znacznie lepszy los niż ten który ma HHVM.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 1x, ostatnio: Wibowit, 2017-07-27 01:05

Pozostało 580 znaków

2018-04-18 13:22
1

Oracle wypuściło wersję 1.0 (RC?) GraalVMa wraz z konkretną stronką: https://www.graalvm.org/

Z nowości jest osadzenie GraalVMa w eksperymentalnych wersjach MySQL czy Oracle Database. Można dzięki temu pisać procedury składowane w JavaScripcie (ale wstrętny język wybrali na start, mam nadzieję, że szybko dorzucą chociaż Pythona).

Aktualizacja:
Jest opcja by przepisać .NETa do Javy. Ktoś chętny? :D
https://github.com/oracle/graal/issues/349


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 3x, ostatnio: Wibowit, 2018-04-19 00:18
Znowu. Już to przerabiałem w 2001 (wtedy z procedurami w Javie). Mam nadzieje, że zemrze (razem z oboma wymienionymi bazami danych - ale to chyba by było zbyt piękne). - jarekr000000 2018-04-18 13:36
Jak dla mnie pomysł pisania procedur składowanych w Javie/Pythonie brzmi fajnie, przynajmniej tych procedur które robią jakieś I/O- pliki, raporty, webserwisy. Może Oracle widzi przyszłość Graala właśnie w ich bazie danych - student pro 2018-04-18 23:28
GraalVM jest takim JITem do wszystkiego a'la LLVM napisany w Javie (tyle, że prawdopodobnie GraalVM lepiej radzi sobie z językami zarządzanymi niż LLVM). Stąd przyszłość Graala może być wszędzie. - Wibowit 2018-04-18 23:31

Pozostało 580 znaków

2018-11-19 13:32
0

Robi ktoś w Polsce jakieś projekty w tym? Bo w USA Graal jest bardzo na topie

Otrzymujesz specjalizacje: nekromanta. - vpiotr 2018-11-19 14:24
@vpiotr: dlaczego taka specke? - byku123 2018-11-19 14:31
@vpiotr bez przesady, przecież wątek jest z tego roku. @byku123 bardziej mnie ciekawi skąd Ty to na topie bierzesz. Masz dostęp do listy przebojów IT w USA? ja znam tylko case Twittera ... i tyle. - jarekr000000 2018-11-19 14:47

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0