Názory k článku Příběhy z vývoje nejrychlejšího virtuálního stroje na světě
-
Zajímavá technologie. Díky za článek. Pár poznámek:
- Proč je v benchmarku požita zvláštní třída, jejímž jediným účelem je zvětšit číslo o jedničku? To mi přijde trochu overkill.
- Spojový seznam? Opravdu? Chtěl bych vidět, jaký by byl výkon benchmarku v C++ za použití std:: vector<int> namísto spojového seznamu. Respektive pro C také existuje implementace dynamicky rostoucího pole. Nejspíše v knihovně gLibC.
- Ten interpretr je napsaný v Javě. Proč byl zvolen tento jazyk? Jaké to má výhody / nevýhody oproti třeba C++?
Marek. -
n (neregistrovaný)
A neni tohle vsechno jedno? Ze to jde napsat ve vetsine tech jazyku i jinak, pravdepodobne lip, je samozrejme pravda, ale o tom tahle vec prece vubec neni.
Ze ten clanek je prinejmensim napsany stylem, ktery by si zaslouzil nahore nalepku "reklama" je pravda taky, ale narozdil od jine reklamy kde na me neco rve ruzne barevna animovana kreatura jsem skoro pripraven to nekdy, az nebudu mit nic lepsiho na praci, zkusit na nejake nasi vlastni korporatni prasarne kde taky nikdo uz nic nikdy mikrooptimalizovat nebude protoze na to uz nikdy nikdo nesezene budget a radsi rekneme ze silnejsi HW. -
Děkuji.
Ta speciální třída
Naturalumožňuje propojení dvou jazyků. Lze ji totiž naimplementovat ruby a pak použít v javascriptu.Je to samozřejmě hnané do extrému, ale ukazuje to, co GraalVM dokáže. Přestože je pro každé přičítání jedničky volá do jiného jazyka, je to stejně rychlé, jako když člověk v Cčku napíše
i++. -
Proč Java?
Tak snad nejdříve technická část: To, co kompilátory zpracovávají se nazývá moře uzlů (see of nodes) a jedná se vlastně o prohledávání grafů reprezentujících strukturu programu za účelem jejich změny a zrychlení. Taková struktura se mnohem lépe udržuje v jazyce s garbage kolektorem. V Céčku člověk skončí s tím, že si takovou automatickou správu paměti musí napsat sám. A to je opravdu trochu zbytečné. Viz. úvod k přednášce, kde autor současného C2 překladače (napsaného v C++), říká, že už by jej znovu v Céčku nepsal.
Nyní osobní část: myslíme si, že nástroje pro programování v Javě jsou mnohem pokročilejší než pro jiné jazyky. Dvacet let rivality mezi třemi vývojovými prostředími, jež jsem se měl tu čest účastnit, dostalo Javu úplně jinam, než ostatní jazyky. Navíc je pohodlné používat ty samé nástroje (jako debugger) pro psaní vlastního kódu a zkoumání toho, co kompilátor vlastně dělá. Vezmete si zdrojáky Graal překladače, dáte si někam breakpoint a pustíte svůj Java program, tak jak jste zvyklí. A hle, překlad se zastaví a lze zkoumat, co se tam děje. Podrobnější popis opět v Chrisově přednášce.
Na závěr historická část: GraalVM je založena na výzkumu MaxineVM, což je Java VM v Javě, prováděného v SunLabs kolem roku 2005. Je vcelku přirozené, že Sun upřednostňoval Javu před jinými systémy. Když jsem to tehdy poprvé zaslechl, tak jsem si myslel, že to je pěkná blbost, ale zdá se, že nám to začíná vcelku pěkně fungovat.
-
Jakub Valenta (neregistrovaný)
Neoptimální kód mi naopak přijde celkem realistický. Málokdo má v reálu čas ladit každý detail, stačí když to nějak funguje. Ani implementace v ostatních jazycích nevyužívá standardní nebo další knihovny, takže pro porovnání to není problém. Spíš mi přijde trochu nesmyslné porovnávat s C programem bez zapnutých optimalizací.
$ make
$ ./sieve
Hundred thousand prime numbers in 66 ms$ gcc -std=c99 -O3 main.c -lm
$ ./a.out
Hundred thousand prime numbers in 47 ms
-
Aaa (neregistrovaný)
GraalVM clanek o GraalVM, od GraalVM autora a GraalVM spoluautoru pro GraalVM uzivatele pripomina vlastnosti GraalVM v prostredi GraalVM tak, ze jazyk autora GraalVM clanku o GraalVM prilis casto pouziva nazev produktu GraalVM. Proto to pusobi jako pokus o SEO pro GraalVM, GraalVM prekladac, autory GraalVM nebo spoluautory GraalVM.
Jinak byl clanek o GraalVM alespon trochu uzitecny, jen by me zajimalo, jak si GraalVM povede v pomalych desktop / swing aplikacich s GraalVM. -
Statistika: v dnešním článku je název GraalVM zmíněn 56×. Ve včerejším článku o Vapory zmiňuje Pavel Tišnovský tento projekt 69×. To je teprv SEO, panečku.
-
xxxxx (neregistrovaný)
Nevšiml jsem si, že by tam Tišnovský měl JEDINÝ zvýrazněný (tučný) nápis Vapory (krom nadpisů, které jsou tučné jako celek).
A přitom tam Tišnovský zvýraznění běžně užívá, ale jen když potřebuje vypíchnout věc, kterou primárně probírá v následujícím odstavci (třeba třídy Camera, LightSource, Sphere a Plane, ...). To pan Tulach občas použil také, ale navíc k tomu marketingově vypíchl KAŽDÝ výskyt názvu projektu (krom popisu u nadpisu, použitého na hlavní straně).
Prostě to bodá do očí a odvádí pozornost od (jinak možná) hodnotného popisu. Člověk automaticky zpozorní a prostě nebere jeho slova vážně, přemýšlí, kde jaký další podraz se objevuje. Namísto aby se začetl.
P.S.: NEsouhlasím se zpracováním nepotřebných osobních údajů, zejména v rozsahu debilního checkboxu, který jde (v odkazovaném textu) nad rámec údajů nezbytných pro technické zpracování. Uveďte to do souladu s GDPR, takto to není.
-
xxxxx (neregistrovaný)
re: " Nakonec se ukázalo, že vlastně nešlo ani o to množství, ale o zvýraznění"
To zvýraznění byla pouze má poznámka, Já se ke kritice připojil až později, až když už toho tu byla kvanta. Co konkrétně chtěli říci předřečníci, to netuším.
Pokud chcete další "drobnosti", ode mne, konkrétně, tak jsem se neudržel a něco stručně popsal už zde:
https://www.root.cz/clanky/pribehy-z-vyvoje-nejrychlejsiho-virtualniho-stroje-na-svete/nazory/980039/Rozvitěji například:
- Zvýraznění (už bylo odstraněno).- Opakování názvu produktu je zbytečně příliš časté. Viz třeba sousloví ".. neopomenutelnou součástí GraalVM ekosystému je i podpora pro tvorbu jazykově nezávislých nástrojů. Standardní distribuce GraalVM nabízí debugger, ..." a jinde, kde druhá zmínka produktu tak blízko po sobě je zbytečně navíc, z kontextu v druhé větě naprosto jasně plyne, o čem je řeč.
- Svazácký styl plus PR: "pojďme budovat" ... "Ano, je to tak. GraalVM dokáže být ještě rychlejší.. " ... "Zvláštní pozornost byla věnována vytvoření efektivního mechanismu pro zpřístupnění " ... pokud netušíte co je tam v tom posledním nadbytečné, tak, v daném kontextu, nebudete přece věnovat zvláštní pozornost do něčeho nakonec neefektivního.. Takže nadbytečná PR věta jak jsme dobří. A podobně.
- Zbytečné řečnické otázky (na které je odpověď ano) . - Stylu: ANO. Dokážeme to ANO. JSME KINGOVÉ. Např. :"Jsou opravdu GraalVM jazyky tak rychlé, jak o sobě tvrdí...".
-- Nebo "Rychlé Ruby je sice hezká věc, ale kdo dnes píše v Ruby? Ten jazyk už je hezkých pár let za zenitem. Dnes přeci všichni píší v JavaScriptu, že!?
Ano, JavaScript je v současnosti vcelku populární a tudíž jej GraalVM také podporuje. " .. 4 PR souvětí namísto dostatečného, stručného a výstižného konstatování, že JS je také podporován.To vše, a mnoho více, plus celkový styl "developers" "developers "developers" sice funguje (jinak by se takové tajtrdlíčky nedělaly a nepsaly), ale z jinak odborného textu dělají marketingový plátek, kde _musím_ vynechávat PR plky, abych se dobral hodnotné informace.
P.S.: NEsouhlasím se zpracováním osobních údajů v rozsahu v odkazovaném textu u checkboxu, který jde NAD rámec údajů nezbytných pro technické zpracování
-
Pavel TišnovskýZlatý podporovatelJj, s autorem Vapory si rozdělíme zisk, který mu díky tomu článku vzroste :-)
-
unicode (neregistrovaný)
Zrovna ten zvolený příklad byl podle mě něšťastný. Oponoval bych asi takto:
1. Porovnání Ruby vs GraalVM není nic jiného než rozdíl interpretu a JIT. Interpretovat jakýkoliv kód bude o řád pomalejší než JIT a ten rozdíl tomu odpovídá. Tento příklad nám ukazuje hlavně to, jak by na tom Ruby výkonově mohl být, kdyby měl JIT.
2. Porovnání Node/V8 vs GraalVM jasně dementuje jakýkoliv "superiority" argument. Rozdíl je na hraně statistické chyby a ukazuje, že GraalVM žádný extra výkon nenabízí. Navíc je v testu použítá stará verze node v6.14.1.
3. Porovnání C vs GraalVM je podle mě asi nejhorší. Chápu, že autor chtěl zachovat přepis 1:1, ale zrovna v tomto případě bych udělal výjimku, protože psát v C jako v javě je podle mě nesmysl. Příklad je navíc udělaný tak, aby překladač neměl možnost ten kód jakkoliv optimalizovat. Pomocné funkce nejsou `static`, takže optimizér nemá šanci udělat ani inlining, a časté použití malloc() ve smyčkách tomu taky moc nepomáhá - toto by vyřešil jednoduchý arena allocator na 10 řádků.
Můj závěr je takový, že se rozhodně nejedná o objektivní článek.
-
Trollopata (neregistrovaný)
Porovnání Ruby vs GraalVM není nic jiného než rozdíl interpretu a JIT. Interpretovat jakýkoliv kód bude o řád pomalejší než JIT a ten rozdíl tomu odpovídá. Tento příklad nám ukazuje hlavně to, jak by na tom Ruby výkonově mohl být, kdyby měl JIT.
A jelikož Ruby samotné JIT nemá, je použití GraalVM pro Ruby co? Rychlejší.
Ale protože tento článek stejně není nic jiného než marketing a použití kompilátoru a VM napsaného ve zlé Javě by přeci nebylo morálně správné, tak raději zůstaneme na stromech a budeme dál interpretovat.
-
Ondra Satai NekolaZlatý podporovatel1. To se vzájemně nevylučuje.
2. Ne každý marketing je špatná věc. Šok? -
Obvykle říkám, že GraalVM EE může být tak o 10% rychlejší než CE.
Twitter přiznává, že díky GraalVM CE ušetří 11% oproti klasické JVM. Kdyby Twitter používal GraalVM EE, tak by byl určitě alespoň o 20% rychlejší než klasická JVM.
Nepletu-li se, tak hlavním rozdílem je inlinování. EE dokáže inlinovat lépe. Kromě toho se EE pro dynamické jazyky (JavaScript, Ruby, Python) liší ve správě paměti. Například pro interpretry LLVM jazyků chce EE nabízet bezpečný mód, kde nebude možno adresovat mimo alokované bloky.
-
Tento údaj mi v článku scházel. Protože testovat na jednom benchmarku je zavádějící a trochu to budí dojem že byl vybrán tak, aby bylo to zrychlení co nejbombastičtější :-) Schází mi tam představa, jak se pod GraalVM zrychlí běžný java projekt, resp. jaké bude mít běhové charakteristiky v porovnání s běžnou VM (paměť, cpu, doba spuštění, zahřátí jit). Pak mi tam schází porovnání s jinými metodami polyglotního programování - i bez GraalVM můžu přeci psát aplikaci ve více jazycích a chtěl bych mít představu, jaké je režie jednotlivých postupů v porovnání s GrallVM. Ohledně kompilace do nativního kódu mi tam schází představa o omezeních, které ta kompilace má (reflexe). Část o llvm budí dojem, že bych mohl libovolný kód llvm bitkód přiložit k vlastnímu java projektu a bude fungovat všude, což ale asi neplatí? Že je článek svého druhu PR mi nevadí, ale pokud to má být přesvědčivé, tak bych přidal trochu na akademické důkladnosti a nezávislosti.
Spousta otázek - chtělo by to seriál, klidně i ve formě polemiky od více autorů :-D To by mohlo být dost zajímavé.
Každopádně i kdyby GraalVM přinesl v praxi relativně malé zrychlení (uvádíte 10% až 20%), tak má potenciál mít dopad na celý ekosystém okolo, což je IMHO to nejdůležitější.
-
Potom si clovek v language shootoute vsimne pamat a zaplace. (Alebo zajasa, ak je vyrobca pamati.)
https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/java.html
Chrome je rychly, ale plati sa za to dvesto-tristomegovymi tabmi. A to uz je problem.
-
Ano, to je správné pozorování. V článku jsem napsal, že u dynamických jazyků již rychlost není problém. Ale ta paměť! Z principu toho, jak se překladače dynamických jazyků píší (můžu se o tom rozepsat v nějakém budoucím článku, bude-li zájem), je třeba udržovat neuvěřitelné množství metadat pro případ, že vygenerovaný assembler je příliš optimistický. Pak je třeba kód zahodit, přepnout se zpět do interpretru a to potřebuje ty meta-informace.
Pro případ Javy to umíme vyřešit. Součástí GraalVM je
native-image, který umí přeložit Java bytekód do EXE souboru a úplně eliminovat potřebu metadat. Startuje to pak rychle a paměťové nároky jsou malé. Asi by to také vydalo na samostatný článek. -
kimec (neregistrovaný)
Urcite sa prosim rozpiste. Zaujima ma:
1 ako je to s reflexiou a invoke dynamic pri AOT kompilacii cez native image
2 nejake quick teoreticke intro k partial escape analysis
3 ten magicky garbage collector v Substrate VM, ktory je noop a nic nerobi
4 separatne heapy a dropovanie heapov bez gc
5 AOT a pamatove bariery/JMM/volatile
dakujem!
-
faustcz (neregistrovaný)
Jen pro kompletnost. Omezení SubstrateVM jsou sepsaná zde https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md
-
Dostal jsem za úkol přečíst si Lukášovu dizertační práci, tak uvidíme, jestli se tam dozvím něco, co by stálo za překlad.
-
Filip JirsákStříbrný podporovatelZrovna včera jsem se na GraalVM díval a překvapilo mne, že už je to dotažené do první finální podoby – a chystal jsem se na něj o víkendu podívat víc. Článek přišel jak na zavolanou :-)
Trochu mne překvapilo, že je GraalVM dostupný jen pro Linux a enterprise verze ještě pro Mac.
native-imagetedy umí vytvořit i Winwods x64exe? Pro Linux umí překládat nativní kód pro x64, a i pro jiné platformy, třeba pro ARMy? Právě u zařízení s nízkým výkonem bych viděl větší výhodu kódu předem transformovaného do nativního kódu.Když GraalVM nemusí být součástí nativní aplikace, předpokládám, že výsledkem
native-imageuž je čistě jen nativní kód pro cílovou platformu. Je nějaký výhled, že by to místo toho byla jakási nultá iterace just-in-time překladu, s tím, že by za běhu byla stále přítomna GraalVM a na základě analýzy běhu programu by případně vytvářela just-in-time nové optimalizovanější verze nativního kódu? Ideálně kdyby pak zase uměla tyhle dodatečné optimalizace zase serializovat do spustitelné binárky, takže při ukončení procesu by se o ně nepřišlo. -
Primárně GraalVM vyvíjíme na Linuxech a Macích. Proto to na nich funguje nejlépe. To, že GraalVM CE není ke stažení pro Mac je spíše věc nedostatku času a testování.
Hlavní architekturou je
x64. Máme i verzi proSPARC(nejlepším způsob jak rozchoditnode.jsna Solarisu je právě GraalVM) a nedávno jsem se v Krakově na GeeCONu bavil s lidmi s ARMu, co je třeba udělat pro lepší (RedHat už na tom dost zapracoval) podporuARM64. Zdá se, že nejlepší je uchoditnative-imagenad JDK9+. To jsem odhadl tak na listopad 2018 +/- dvanáct měsíců. Tak uvidíme.Když jsem překládal "native image binary", tak jsem se rozhodl to nazvat "EXE soubor". Přišlo mi, že se to v češtině vcelku vžilo i pro jiné systémy než Windows. Pravdou však je, že
native-imagena Windows neběží. Problém není kód, ale emulace systémových volání. Máme jen POSIX - někdo by to musel přepsat na WIN32 API či co se tam používá. Avšak Graal kompilátor na Windows funguje - opět jsme jen nenašli dost času dát to všechno dohromady - ale je to open source, že!? -
Filip JirsákStříbrný podporovatel
Pro desktopové aplikace asi nemá
native-imagetakový význam, a pro ostatní už tu Posixovou vrstvu nad WIN32 API řeší Microsoft v Linux Subsystem on Windows 10 – tak ať se taky snaží Microsoft :-) GraalVM nabízí spoustu nových možností, je mi jasné, že si musíte vybrat některé z nich a na ostatních. -
fe (neregistrovaný)
Vzhledem k tomu, že node.js má podporu SPARC jen ve Feature Requestu a V8 NEMÁ podporu SPARC tak by bylo lepší dopsat podporu pro SPARC do V8 a následně do node.js.
Na to není čas/HW :( přitom je to na 99 % stejné jako Solaris na x64 (endianity jsou snad vyřešeny díky podpoře MIPS/PPC).
Ale vymýšlet workaroundy stylem 30 MB node.js vám na SPARC poběží, když si ještě nainstalujete 100 MB? GraalVM + X GB Java 8 na to čas je. Ale je to OpenSource, že? ;) -
Je nějaký plán na nultou iteraci JIT překladu?
Ano, takový plán existuje a kupodivu to není jen plán, ale realita. JDK9 přišla s verzí ahead-of-time překladu při "instalaci" modulu. Tento překlad je implementován pomocí Graal překladače. V podstatě vytvoří tu žádanou nultou iteraci a pokud se ukáže, že není dostatečná nakopne to normální JIT a přeloží se to znova.
Výše uvedené mimochodem znamená, že Graal překladač už je součastí JDK9. Jen je třeba znát ty správné přepínače, jak jej zapnout jako JDK9 JIT:
java -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI \ -XX:+UseJVMCICompiler -XX:-TieredCompilation -XX:+PrintCompilation \ -XX:CompileOnly=Demo::workload Demo
-
Filip JirsákStříbrný podporovatel
Perfektní, díky. To jsem zvědav, jestli tohle přežijí Go nebo Kotlin Native. Protože podle mne mají stejný cíl, zejména Go je asi o něco napřed co se týče připravenosti k produkčnímu nasazení, ale zase GraalVM má oproti Go obrovské možnosti a navíc může použít vše, co je teď dostupné pro Javu a dnes i JavaScript.
-
kraxna (neregistrovaný)
To je bozi, ja uz jsem to zkousel u JDK 9 (diky tomu jsem se vlastne o GraalVM dozvedel).
Jeste jsem se chtel zeptat, je nejaka sance na rozsireni native-image o dalsi funkcionalitu, ktera by umoznila beh rekneme Java enterprise aplikaci pomoci native-image?
Veci rekneme typu Spring Boot / Thorntail - v soucasne dobe to urcite mozne neni minimalne diky omezeni reflexi a hlavne dynamickeho class loadingu.
Nejsem si jisty, zda by to vubec melo smysl, spise me to zajima za zvedavosti, jake mate plany v native-image.
-
Filip JirsákStříbrný podporovatel
Myslím, že je snaha reflexi omezovat a nahradit to MethodHandle, a objevování bean by se dalo (mělo) řešit v době kompilace/linkování. Takže tady bych spíš viděl změny na straně Springu, které by pomohly i klasické JVM a GraalVM z nich pak může profitovat.
-
Nedávno jsem pracoval na integraci
native-images Fn Projektem (to by mohla být budoucnost oblačných technologií u Oraclu). AOT překlad by se tam hodil - rychleji to startuje a zabírá to méně paměti. Fn projekt používá Jackson na serializaci/deserializaci JSONu a zdá se, že to není problém uchodit. Jen je potřeba dopředu specifikovat, které třídy mají být dostupné pro reflektivní přístup - viz. dokumentace. O SpringBootu se u nás také mluvilo, ale zatím se nenašel nikdo, kdo by měl čas a chuť to uchodit, pokud vím. -
harrison314 (neregistrovaný)
Na jednej strane zaujimava technologia, ktora svoje uplatnenie najde v mikrosluzbach, ale urcite nie kvoli richlosti tych par desatim percentnaozaj ozeliem.
Mna skor zaraza, ako sa vymslaju tie benchmarky - tu konkretne javascript, nemozete merat richlost javascriptu na vypocte prvocisiel, lebo takto napisany program si V8 hned prelozi do nativneho kodu a vysledky vyzeraju ako keby to bolo napisane v Jave. Ale akonahle sa v JS zacnu pouzivat jeho dynamicke vlastnosti, polia, dictionary, pridavanie objektom properties a podobne vykon ide radovo dole.
Takze ak chcete merat benchmarky tak na realnych problemoch a na realnych prikladoch a na kodoch, ktory napisali ludia co sa v danom jazyku vyznaju no nerobia sialene optimalizacie.
IMHO ak som to pochopil spravne, cele zrychlenie je v tom, ze sa obmedzuje alokacia... to imho zvladal .Net Core 2.1 bez sialenych priplatkov za entrprise verziu a nie je tam java.
-
Omlouvám se, jestli z mého článku vyplynulo, že celé zrychlení je jen o omezení alokace objektů.
To by pro dynamické jazyky nefungovalo! Tam je třeba připravit se na dynamicke vlastnosti, polia, dictionary, pridavanie objektom properties a stále neztratit žádný výkon. To GraalVM umí a nabízí (relativně) snadné API, jež umožňuje interpretrům "mluvit" s JIT kompilátorem a dosáhnout rychlosti assembleru, i když se používají divoké dynamické vlastnosti jazyků (např. redefinice funkcí či
eval). -
harrison314 (neregistrovaný)
Na kriticke casti aplikacie predsa nepouzitejete taku blbost ako javascript.
PS nevyjadroval som sa konkretne sa ku GraalVM ale k javascriptu a V8. Ale samozrejme pokial nebudem mat banechmarky na realnom pouziti tak tomu neverim, kazda technologia slubuje uzasne veci, no relita je castokrat ina.
-
Kvůli pár řádkům kritické části přece nebudete psát celou aplikaci v low-level jazyce.
V8 je v realitě rychlý. Problémy webových aplikací s výkonem nebývají způsobeny Javascriptem, ale chybnou manipulací s DOM a vykreslováním. Stačí dodržet pravidla https://www.html5rocks.com/en/tutorials/speed/v8/ .
-
Filip JirsákStříbrný podporovatel
Na kriticke casti aplikacie predsa nepouzitejete taku blbost ako javascript.
Proč ne? A řekl bych, že GraalVM je právě odpovědí na tuhle otázku, která říká, že to klidně použít můžete. Protože u té výkonově kritické části aplikace přece nezáleží na tom, v jakém jazyce je napsaná, ale jak je napsaná. Jazyk mohl být omezením akorát z toho důvodu, že pro něj existoval jen pomalý interpret – ale to pro JavaScript neplatí minimálně od vzniku V8. -
Steve (neregistrovaný)
> zvladal .Net Core 2.1 bez sialenych priplatkov za entrprise verziu a nie je tam java
Myslim, ze zadna verze .NET nemela escape analyzu. Mate nejake reference? C# nabizi hodnotove typy (structs), a tak jde spis tou cestou, ze tuhle praci prenecha na programatora, coz muze byt nekdy vyhoda a jindy nevyhoda.
-
harrison314 (neregistrovaný)
Tu je o tom clanok https://blogs.msdn.microsoft.com/dotnet/2018/04/18/performance-improvements-in-net-core-2-1/
Nepouziva Escpe optimalizaciu, no umoznuje sa vyhnut alokacii na heape, co sa interne masivne vyuziva. -
Steve (neregistrovaný)
Clanek jsem jenom proletel, kdyztak me prosim odkazte na relevantni casti, ale v souvislosti se snizenim poctu alokaci se tam mluvi o
1) intrinsifikaci funkce HasFlags, coz typicky vede ke snizeni alokaci, ale samo o sobe to neni escape analyza a obecne to nesnizuje pocet alokaci v libovolnem kodu.
2) obstraneni boxovani ve specifickem pripadu, kdy je znamo, ze genericky parametr je konkretniho hodnotoveho typu, a tak neni treba ho pro interface volani boxovat. To opravdu snizuje obecne pocet alokaci. Zalezi na definicich, ale za me tohle je "odstraneni boxovani" a ne "escape analyza".
-
harrison314 (neregistrovaný)
To vykonu JS nepomoze, proste akonahle ho chces pouzit na nieco seriozne je to pomaly jazyk, kde musis robit plno optimlizacii rucne. Plus ani ES6 nie je jazyk v ktorom by sa dali pisat velke projekty (pre to sa v JS pisu mikrrosluzby, plus zivotnost kniznic,... a pritom JS neprinasa nic ine co by nemali ine jazyky pocnuc C#, javou, PHP-ckom).
Nahipovana modna vlna JS skonci tak ako kedysi PHP a potom RoR. -
Z pohledu turingovské rychlosti patří jazyk R k těm pomalejším. Také jeho dynamické vlastnosti jsou poněkud divočejší (nejen, že při vyhodnocování
a + bčlověk nezná typaab, ale zjišťování hodnotyaprý může změnit i význam+!). Ale je vcelku populární a matematici a statistici v něm dokáží divy.Takže to většinou funguje nějak takhle: skupina statistiků si sedne a sepíše funkce/rovnice v Rku a ověří je na nějakých testovacích datech. Pak se to zkusí pustit na celém balíku dat a GnuR to nedopočítá. Přijde banda programátorů a přepíší části toho algoritmu do Cčka. Pak už GnuR počítá jakžtakž snesitelně.
Naším cílem však je ten přepis úplně odstranit. Máme jednoho interního zákazníka, který udělal přesně to, co popisuji. Nakonec jim ten systém počítal tři dny. Spojili se s námi. My jsme vzali tu jejich původní verzi bez Cčkových částí, doimplementovali, co nefunguvalo, a pustili to na GraalVM. Dopočítalo to za osmnáct hodin.
-
K> (neregistrovaný)
aha, diky za zajimavou odpoved. Rko nemam tak dobre prozkousene, takze me tenhle problem Rka prekvapuje.
Osobne jedu v GNU Octave, a tam jsem malokdy ziskal prepisem do C vyznamne urcyhleni (ne natolik, aby to opodstatnilo cas straveny prepisem do C). ale taky to je dano oblasti kterou pouzivam, znam jine skripty, ktere v matlabu jedou radove rychleji nez v Octave, takze by prepis Octave do C asi dost pomohl (a zase znam jine, ktere jedou v Octave rychleji nez v Matlabu). -
Jarda (neregistrovaný)
Jen taková poznámka, ten vzorový program nepočítá prvočísla Eratosthenovým sítem, ale běžným algoritmem na prvočísla. Eratosthenovo síto funguje ve stručnosti tak, že si vezmu seznam prvních N čísel. Pak vezmu první prvočíslo (tj. 2) a v seznamu škrtnu všechny jeho násobky. Pak dělám postupně totéž pro další prvočísla. Nakonec mi zůstanou jen prvočísla. Mimochodem tento algoritmus, pokud se správně napíše, tak bude v normálním C mnohem rychlejší, než v čemkoliv jiném.
-
Je to tak. Složitost mé verze je určitě větší než té verze s polem. Víceméně se podobá funkcionálnímu řešení a tudíž to není to Eratosthenovo síto. Na druhou stranu, algoritmus je ve všech jazycích stejný. Proto by porovnání měla být férová.
S poslední větou si dovolím nesouhlasit. Nevidím důvod, proč by to tak mělo být. Ale uznávám, že by se to muselo zkusit.
-
Karel (neregistrovaný)
Ad poslední věta: ten algoritmus tráví drtivou většinu času v miniaturní smyčce. C se přeloží jen na několik velmi málo instrukcí assembleru, takže režie na "škrtnutí" jednoho čísla bude víceméně jen v přičtení, zápisu do paměti a skoku. C nemusí být nutně "mnohem rychlejší", ale rozhodně bude na hranici, kterou daný HW zvládne. Dokud je algoritmus založen na přičtení, zápisu (=škrtnutí) a opakování, tak sebelepší algoritmus strojové optimalizace nemůže dopadnout lépe.
Optimalizace nestrojová samozřejmě lépe dopadnout může a dopadne, kupříkladu při vyškrtávání čísla X > 2 stačí vyškrtat jen čísla (2*k+1)*X (čili nepřičítáme X, ale 2*X). Důvod? Protože sudé násobky X už vyškrtala dvojka. Obecně se pro každé X dá určit počáteční koeficient, od kterého má smysl začít škrtat. Kupříkladu u čísla 13 nemá smysl škrtat 26, 52, 78 atd. (už škrtla dvojka), ani 39 nebo 117 (škrtla trojka), ani 65 (škrtla pětka) atd. Stačí škrtat od čísla 13*13 a přičítat 2*13. Tohle ale žádné VM nedokáže odhalit.
-
C (neregistrovaný)
Technická poznámka, ta C verze se uvedeným postupem (make -C c) přeloží jako debug build bez optimalizací. Ne že by to v tomhle případě nějak vadilo, protože ten kód je tak jednoduchý, že na něm moc není co optimalizovat, nicméně přeloženo s optimalizacemi (-O3) je to u mě asi o 10% rychlejší.
-
Já jsem věděl, že se na to přijde! A proto jsem do článku napsal "Raději než úplně vyoptimalizovat C (což dokáže běh jednoho kola srazit na 75 ms)...". Ale uznávám, že to přiznání není na první pohled vidět.
Myslím si totiž, že to porovnání se zcela vyoptimalizovaným Cčkem není úplně správné. V případě GraalVM je totiž možné, aby všechny tři elementy toho algoritmu byly úplně nezávislé (dodané v samostatných souborech) či dokonce napsané v různých jazycích a výsledek bude pořád rychlý. Kdybych toho chtěl dosáhnout v Céčku, tak bych asi měl umístit každou z těch funkcí do vlastní dynamické knihovny. Při startu ty nezávislé
.sosoubory slinkovat a teprve pak měřit. Jsem přesvědčený, že výsledek by se více podobal tomu debug buildu, jež nedělá žádné inlinování. Asi bych to však měl opravdu zkusit a změřit (pull request by byl vítaný...).Celé by to mělo ukázat výhodu JIT překladu, kde i modulární aplikace mohou být stejně rychlé, jako nejvyoptimalizovanější monolitické.
-
C (neregistrovaný)
Ale pozor, tady se nebavíme o optimalizaci člověkem, ale překladačem. Můj argument je zcela validní, GraalVM optimalizace provádí, proč jsou tedy optimalizace vypnuté pro C překladač? Potom porovnáváte neporovnatelné věci.
Mimochodem zvolená ta úloha není moc vhodná pro porovnání rychlosti, protože více jak 80% času se stráví ve funkci acceptAndAdd, což je jeden jednoduchý cyklus. S tím si snadno poradí každý překladač i virtual machine, a proto jsou také výsledky všeho víceméně srovnatelné.
-
Martin (neregistrovaný)
Mluvíte o inliningu, nicméně překladače používají mnohem širší škálu optimalizací (namátkou loop inrolling, který se mi zdá že v tom příkladu by zrovna mohl dost pomoci). Inlining se skutečně se dá zkazit tím že funkce budou v různých modulech, nicméně inlining výrazně pomůže jen ve specifických případech. Obecně třeba transformacím cyklů nevadí jak jsou funkce organizovány.
Proto si myslím že to porovnání tak jak jste ho napsal není fér a je to spíše marketing. Ten výkonostní rozdíl bude cca 50% v případě tohoto examplu, což je stejně dost solidní, ale tvářit se že je to skoro nastejno imo neodpovídá realitě.
Pro lepší porovnání by byl stejně potřeba lepší benchmark s více různými programy, ale bez mlžení s vypnutými optimalizacemi.
-
Filip JirsákStříbrný podporovatel
Při srovnávání zjevně nešlo o to porovnávat extrémní příklady, ale pokusit se odhadnout rozdíly u běžného programu. Což samozřejmě přináší problém s definicí běžného programu. Stejně zavádějící by bylo i porovnávat kód, který může C kompilátor perfektně optimalizovat, protože takový kód zase není příliš častý.
Vždycky, když se něco porovnává, je vědět přesně co se porovnávalo – a to je myslím v článku splněné.
-
Martin (neregistrovaný)
Extrémní příklady? Článek je o tom že Graal VM je nejrychlejší VM na světě. Toho dosahuje pomocí agresivní optimalizace. Dále se v článku porovnávají časy běhu programů z nativních kompilátorů a při spuštění v Graal VM. Nicméně aby vyniklo že Graal VM je "skoro stejně výkonný" jako C, tak je při kompilaci C programu "zapomenuto" zapnout optimalizaci (která se běžně používá, není to nic exotického a kterou Graal u toho stejného programu použije). Argument proč nebyla optimalizace u C programu použita mi přijde slabý, proto jsem to napsal.
Chtěl jsem jen upozornit že to srovnání tak jak je postavené mi přijde zavádějící.
-
Jakési porovnání s LuaJITem existuje. Sám jsem to moc nezkoumal, ale zdá se, že očekávání byla větší než konečný výsledek.
-
Pavel TišnovskýZlatý podporovatel
dík za odkaz. No podle všeho to nechává běžet nad doubly a ne nad integery, takže těžko říct, co by to udělalo při přepisu.
-
Filip JirsákStříbrný podporovatel
Tak ještě jednou. Předpokládám, že snaha byla porovnat výkon u běžných programů. Aby bylo možné to nějak porovnávat, potřebujete srovnatelný kód ve více jazycích, a málokdo má čas na to psát aplikace pro benchmark, které budou mít desetitisíce řádek a budou dostatečně věrohodně simulovat častou činnost běžných programů, a zároveň to bude měřitelné. Takže ta aplikace pro benchmark bude spíš nějaký jednoduchý kód (jako v tomto případě). Takový kód se dá agresivně optimalizovat, ale pak už to ani vzdáleně nebude připomínat ten častý kód běžných programů, protože v nich bude minimum kódu, který by bylo možné takhle optimalizovat – i když ta optimalizace bude zapnutá.
Extrémním příkladem tedy není zapnutí optimalizací, ale kód, který jde optimalizovat výrazně více, než nejčastější kód běžných aplikací.
Agresivní optimalizace GraalVM podle mne není to samé, jako agresivní optimalizace C kompilátoru – v případě GraalVM jde zejména o optimalizace dynamických jazyků, v případě C jde o optimalizaci instrukcí CPU. Agresivní optimalizace GraalVM podle mne znamená, že prováděný kód je podobný, jako kdyby to byl kód napsaný v C – tedy např. bez několikanásobných referencí, s uložením dat v paměti příznivým pro CPU cache apod.
-
Filip JirsákStříbrný podporovatel
Je snad jasné, že „nejrychlejší virtuální stroj na světě“ není závěr testu ale hyperbola. Jaroslav Tulach velmi dobře ví, že je nesmysl porovnávat obecně rychlost virtuálních strojů – nikdy nebude jen virtuální stroj absolutní špička, která v čemkoli porazí ostatní. Myslím, že v článku je to jasně napsané.
při určitém počtu elementů začne hrát větši roli vliv cache-miss než jakýchkoliv optimalizací.
A o tom to právě je. Že jakýkoli „hloupý“ interpret dynamického jazyka prohraje kvůli cache-miss hned od začátku, a když se chce VM přiblížit rychlostí kódu psanému v C, musí umět cache-miss vyplývající z dynamické povahy jazyka eliminovat. Na druhou stranu běžné aplikace se s cache-miss běžně potkávají, takže zase nemá cenu dělat benchmark kdy se CPU točí nad jedním řádkem cache, protože to není úplně typický případ běžných aplikací. -
Mně se ten argument docela líbí. Ptal jsem se jednou šéfa, co vlastně to naše Truffle API, které používáme na psaní interpretrů, dělá. Dostal jsem odpověď, že: "se stará o to, aby JavaScriptový kód vypadal jako Java". Což mi zní skoro stejně jako "když se chce VM přiblížit rychlostí kódu psanému v C, musí umět cache-miss vyplývající z dynamické povahy jazyka eliminovat". Ano, skutečně je třeba eliminovat dynamickou povahu jazyka a tak nějak se přiblížit typovanému jazyku jako Java/C. Pak to lze přeložit do něčeho, co běží skoro stejně rychle jako C.
-
unicode (neregistrovaný)
Primární důvod "dedynamizace" je změnit asociativní pole v objekt, k jehož členům můžu přistupovat přes index. Tato samotná optimalizace nijak nesouvisí s cache miss. Na cache miss má vliv hlavně to, že takový objekt je obvykle MENŠÍ než asociativní pole, takže pokud jich potřebuji milión ve spojovém seznamu, tak už to pocítím.
-
Filip JirsákStříbrný podporovatel
V čem se liší nativní cyklus od interpretovaného cyklu? Proč by nemělo fungovat branch prediction? S tou dedynamizací jste na správné stopě. Napovím vám, že lepší termín by byl „deobjektizace“. To asociativní pole totiž typicky neobsahuje hodnoty, ale odkazy na objekty – dynamicky alokované na haldě, takže rozházené po paměti. A to s cache miss souvisí, a to tak že velmi. U dynamických interpretovaných jazyků navíc těch úrovní odkazů bude několik – máte objekty v dynamickém jazyce, a ty jsou zase reprezentovány objekty v interpretu.
-
unicode (neregistrovaný)
Některé VM jako např. V8 nedělají boxing primitivních typů určitého rozsahu, takže pokud mám něco jako { a: 1, b: 2, c: 3 } tak "a" nebude ukazatel na boxovanou 1 ale 1. Vaše argumenty vychází spíš z neznalosti některých technik, které moderní VM využívají. V8 team toho dost publikoval, takže jestli vás to zajímá tak materiálu online je dost.
<blockquote>U dynamických interpretovaných jazyků navíc těch úrovní odkazů bude několik – máte objekty v dynamickém jazyce, a ty jsou zase reprezentovány objekty v interpretu.</blockquote>
To nedává smysl. Interpret nepřidává extra indirekci, jen je neefektivní. Hlavní cyklus interpretu obvykle vypadá jako jeden velký switch kde každý case je nějaká instrukce (opcode/IR). Občas kontroluje vstup, atd, a toto je důvod pro branch misprediction, který jsem napsal, protože predikovat switch o 50 větvích rozumně ani nejde.
-
Filip JirsákStříbrný podporovatel
Argumenty o neznalost si nechte pro sebe. Netuším, jak jste přišel na to, že většina datových struktur v dynamicky typovaných jazycích jsou ploché mapy s primitivními typy malého rozsahu. Jistě že současné VM dělají optimalizaci některých speciálních případů – vtip nových VM (jako např. GraalVM) je v tom, že dělají optimalizaci většího množství případů nebo lépe. Po GraalVM nepochybně přijde ještě novější VM, která bude optimalizovat ještě více.
Interpret často přidává další odkaz, protože ve své interní struktuře odkazuje na strukturu používanou v interpretovaném jazyce. S branch misprediction jste úplně vedle, způsob zpracování instrukcí je úplně stejný v interpretu i na CPU – zpracovává se instrukce po instrukci, z předchozí instrukce nejde odhadnout, jaká instrukce bude následovat, zároveň ale procesor může zpracovávat víc instrukcí jdoucích za sebou. Navíc moderní VM opravdu nezpracovávají každou jednotlivou instrukci softwarovým interpretem, ale překládají posloupnost instrukcí na strojový kód. Způsob, jakým moderní VM dosahují výkonu srovnatelného s nativním kódem, je takový, že se snaží potlačit dynamičnost jazyka – tj. vygenerují strojový kód pro případ, kdy budou dynamické aspekty zafixované, a před něj dají kontrolu, zda ty zafixované podmínky platí. Díky tomu právě správně funguje branch prediction, protože procesor může spekulativně vykonávat kód pro případ, kdy je daný aspekt fixní, což je ve většině případů splněno. Jedině v případě, kdy se projeví dynamický aspekt jazyka, podmínka splněná není a musí se skočit do pomalé větve, která umí vyřešit tu dynamičnost.
-
unicode (neregistrovaný)
Dáváte mi do úst něco, co jsem neřekl, navíc tu mícháte interprety a JIT. Pokud nerozumíte tomu, co jsem napsal, tak si problematiku nastudujte - opravdu mi nestojí za to argumentovat se zabedněncem co nečte a jen musí mít vždycky pravdu. Podívejte se jak diskuze začala a kde jsme se dostali...
-
Filip JirsákStříbrný podporovatel
Celá diskuse začala mým konstatováním, že rozdíl výkonu mezi naivním interpretrem dynamického jazyka a VM s kompilací do strojového kódu a optimalizací je z nezanedbatelné části tvořen tím, že taková VM je schopná naservírovat procesoru kód, který redukuje cache miss. Když k tomu nemáte co říct, tak k tomu nic nepište, to je jednoduché.
-
unicode (neregistrovaný)
Protože to máte obráceně. Eliminace cache-miss je příznivý efekt některých optimalizací VM, ale není to jejich primární cíl. Cíl je obvykle snížení cyklů potřebných na vykonání dané části kódu nebo snížení jeho paměťové náročnosti. Např. SMI optimalizace ve V8 zabraňuje boxování integerů a tím snižuje paměťovou náročnost běžícího programu, ovšem jako bonus eliminuje možný cache-miss, který by mohl vzniknout při unboxingu. Existují i jiné optimalizace např. "NaN Tagging", které jsou podobné SMI (jen využívají jinou reprezentaci).
Na cache miss má mnohem větší vliv návrh programu (použité algoritmy a datové struktury) než mikrooptimalizace ve VM. Např. i v tom JS si můžu vybrat mezi TypedArray, kde boxing nikdy nenastane, a Array, kde boxing nastat za určitých okolností může.
A jinak nemáte pravdu ani s tím Interpret vs JIT. První verze V8 měli velmi jednoduchý JIT, který nedělal prakticky žádné optimalizace kromě kompilace do nativního kódu a tzv. "Hidden Classes". Zrychlení 10x, ale ne kvůli cache-miss, ale kvůli tomu, že se odstranil ten interpret, který musí běžně vykonat N strojových instrukcí na to, aby zpracoval 1 instrukci VM. A mezi těmi N instrukcemi je obvykle taky branch, ale o tom už jsem mluvil že jo... Další věc např. instruction scheduling, což je něco o čem se interpretu může jen zdát, ale zase to nemá s cache-miss nic společného.
Nechápu, co je tak těžkého na tom si přiznat, že jste se sekl a dané problematice se nevěnujete. Vždyť vaše argumentace je jen přešlapování na místě a neustálé opakování toho samého. Vy ani neznáte jména těch optimalizací, ale víte, že všechny jsou ultimátně zaměřené pouze na eliminaci cache-miss :)
-
Filip JirsákStříbrný podporovatel
Polemizujete s něčím, co jsem nikdy nenapsal. Já jsem nepsal, že všechny optimalizace se zaměřují jenom na cache-miss. Psal jsem, že eliminace cache-miss je jeden z cílů optimalizace. O cache-miss jsem psal proto, že jsem reagoval na komentář, který psal o cache-miss.
-
Filip JirsákStříbrný podporovatel
Když vám na tom tolik záleží, já vám to klidně přiznám. Ano, jistě, máte pravdu, když tvrdíte, že hloupý interpret dynamického jazyka bude mít stejné množství cache-miss jako nativní kód. Jak mne vůbec mohlo napadnout něco jiného. Tabulky virtuálních metod nebo hashtabulky s odkazy na další hashtabulky jsou z hlediska cache-miss stejně efektivní, jako Céčkové struct. Hlavně že už teď budete moci klidně spát.
-
unicode (neregistrovaný)
A co brání interpretu použít "Hidden Classes"? Vy máte zafixované nějaké předpoklady z minulého století, které absolutně nereflektujou současnou situaci v návhrhu VM a používáte je jako nějaký univerzální argument na všechno. Jestli VM použije hash table nebo přístup přes index nemá co dělat s tím, jestli je kód interpretovaný nebo zkompilovaný (viz např. V8 bytecode interpreter).
Takže si žijte dál v tom vašem imaginárním světě kde existujou pouze 2 možnosti, které tu popisujete, reálný svět je ale mnohem rozmanitější a zajímavější.
-
Filip JirsákStříbrný podporovatel
Interpretru vskutku nic nebrání ve vylepšování, aby se dostal na úroveň V8 nebo třeba až GraalVM. Akorát pak nebude mít smysl dělat porovnání rychlosti jednoduššího interpretru s něčím na pomezí interpretru a VM jako V8 nebo s pokročilou VM jako GraalVM, když budou existovat jen pokročilé VM. Ovšem v mém světě se nepoužívá všude GraalVM nebo něco podobného, v mém světě leckde ještě běží třeba Python 2.
Já jsem nikde nepsal o pouhých dvou možnostech, uváděl jsem to jako dva dostatečně vzdálené body na nějaké škále, takže má smysl porovnávat jejich rozdíly. Pořád ale i ty dva body jsou o jeden bod víc, než váš svět omezený jen na V8.
Jestli VM použije hash table nebo přístup přes index jsem vůbec neřešil. Stále nechápete, že ve světě dynamických jazyků jsou běžné zanořené struktury řešené pomocí odkazů. To je to podstatné, že standardně je to spousta dynamicky alokovaných objektů, a pokud je chce interpret/VM dostat na jedno místo v paměti, musí se o to nějak aktivně snažit.
Jestli je kód interpretovaný nebo zkompilovaný je jenom otázka toho, jak nadefinujeme ten který pojem. Je Java bajtkód zkompilovaný nebo interpretovaný? A je C kód zkompilovaný pro ARM64 spuštěný v emulátoru na x64 zkompilovaný nebo interpretovaný?
Nechápu, proč pořád musíte polemizovat s něčím, co jsem nenapsal.
-
Stačilo by porovnat nějaké aplikace z reálného světa. Mám aplikaci tu a tu a vím že mi pod GraalVM za daných okolností poběží o tolik % rychleji. To má výpovědní hodnotu. Nebo stačí říct, k jaké změně došlo pokud zákazník XY nasadil ten a ten provoz pod GraalVM. To má taky výpovědní hodnotu, ani není třeba psát komplikované syntetické testy.
-
Filip JirsákStříbrný podporovatel
A jak byste ty aplikace z reálného světa porovnával? Jak byste změřil, že prohlížeč, textový procesor, grafický editor, videopřehrávač nebo IDE běží o x % rychleji?
-
Podpora iOS by byla super! Mluví se o tom a mělo by to být možné, ale my v OracleLabs na tom přímo nepracujeme. Určitě upravíme
native-image, aby fungovala na JDK9+. Pak snad RedHat a ARM uchodí ARM(64). A pak to může Gluon vzít a použít na iOSu. Fungovat to může, ale bude to vyžadovat ještě spoustu (spolu)práce. -
oldfrog (neregistrovaný)
kdyz jsem v roce 1973 (to je fakt uz 45 let) psal prvni Fortran programy, tak jsem netusil, ze nekdy v roce 2010 nastratuje Oracle projekt, ktery po 8 letech skutecne vytvori system, ktery bude schopen provadet program skoro tak rychle jako v tom Fortranu.
Vyvoj proste nezastavis.
-
ava (neregistrovaný)
No jestli se chceš dozvědět něco o GraalVM, máš veliké štěstí, zrovna na to téma shodou okolností vyšel bezva článek na rootu, můžeš si ho přečíst tady: https://www.root.cz/clanky/pribehy-z-vyvoje-nejrychlejsiho-virtualniho-stroje-na-svete/
-
xxxxx (neregistrovaný)
Já myslím, že obdoba hotspot je tam popsána ...
".. provádí statickou analýzu kódu s cílem nalezení částí, které se skutečně mohou v průběhu běhu programu použít. Po té provede úplný ahead-of-time překlad a vytvoří samostatně použitelný soubor pro daný operační systém .."
Ale mohu se mýlit, GraalVM neznám, mám jen informace z článku.
P.S.: NEsouhlasím se zpracováním osobních údajů v rozsahu v odkazovaném textu u checkboxu, který jde NAD rámec údajů nezbytných pro technické zpracování
-
Někde uprostřed článku je část věnované čisté Javě. Nejprve se běží na standardní verzi Javy8:
$ mvn -f java/pom.xml install $ java -version java version "1.8.0_171" $ mvn -f java/algorithm/pom.xml exec:java Hundred thousand primes computed in 86 ms
a pak se ten samý kód spustí na GraalVM. Úplně stejným příkazem, jen s odkazem na jiný adresář, kde je nainstalována GraalVM (to je možné, protože rozložení souborů je vlastně úplně stejné):
$ JAVA_HOME=/graalvm-1.0.0-rc1/ mvn -f java/algorithm/pom.xml exec:java Hundred thousand primes computed in 79 ms
Z toho mělo vyplynout, že GraalVM je 100% kompatibilní náhražka oficiálního JDK. Prostě si GraalVM stáhnete a hned uvidíte, jestli vám váš Java výpočet poběží rychleji!
GraalVM = JDK8 - C2Kompilátor + GraalKompilátor + interpretry JS/Ruby/R/LLVM/Python + native-image
-
skybber (neregistrovaný)
Z pohledu ciste javy by se to dalo vyjadrit i jako: GrallVM = (Hotspot+JVMCI)+GraalKompilator(JIT)
Otestoval jsem to na našem větším projektu: 1.5MLOC, 5752 source files:
OpenJdk8:
skybber@skybber ~/workspace/project.prj $ java -version
openjdk version "1.8.0_162"
OpenJDK Runtime Environment (build 1.8.0_162-b12)
OpenJDK 64-Bit Server VM (build 25.162-b12, mixed mode)
skybber@skybber ~/workspace/project.prj $ time mvn -Dmaven.test.skip=true package
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:16 min
[INFO] Finished at: 2018-06-01T22:06:26+02:00
[INFO] Final Memory: 19M/410M
[INFO] ------------------------------------------------------------------------real 1m18.002s
user 3m50.231s
sys 0m5.159sGraalVM:
skybber@skybber ~/workspace/project.prj $ java -version
openjdk version "1.8.0_161"
OpenJDK Runtime Environment (build 1.8.0_161-12)
GraalVM 1.0.0-rc1 (build 25.71-b01-internal-jvmci-0.42, mixed mode)
skybber@skybber ~/workspace/project.prj $ time mvn -Dmaven.test.skip=true package
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:24 min
[INFO] Finished at: 2018-06-01T21:58:07+02:00
[INFO] Final Memory: 29M/471M
[INFO] ------------------------------------------------------------------------real 1m26.417s
user 4m20.092s
sys 0m5.753s -
xxxxx (neregistrovaný)
Ten článek si opravdu přečtěte, i podrobněji, stojí za to. Je sice psán stylem PR, ale má jinak i celkem zajímavé informace.
Takže, pokud GraalVM blížeji neznáte, musíte přeskočit úvodní marketingové žblepty, abyste se dozvěděl o čem je řeč. Musíte jít až na třetí odstavec (2-3 stránku) "GraalVM ... Univerzální virtuální stroj GraalVM vám umožní spouštět: .. GraalVM lze použít buď samostatně a nebo ji začlenit ...".
Už na té třetí straně začíná plnohodnotný (non PR) text, už psaný normálnějším slohem. A je docela přínosný.
P.S.: Občas si i pak musíte odmyslet angažované svazácké výkřiky typu "Pojďme budovat tuto revoluční technologii ..." či styl opakovaných a zbytečných řečnických otázek typu "Jsou opravdu GraalVM jazyky tak rychlé, jak o sobě tvrdí?", ale už je toho výrazně méně, než v úvodu. To už ignorujte, zbytek textu má svou informační hodnotu, která za přečtení stojí.
P.P.S.: NEsouhlasím se zpracováním nepotřebných osobních údajů, zejména v rozsahu v odkazovaném textu u checkboxu, který jde NAD rámec údajů nezbytných pro technické zpracování (např. II.2.2 ... je v rozporu s GDPR vynucovat takový souhlas, bez možnosti užít službu bez souhlasu).
-
> Překladače, správu paměti a vývojové či ladící nástroje je tedy třeba psát znovu a znovu téměř od začátku. To komplikuje život nejen tvůrcům virtuální strojů, ale i vývojářům, kteří je používají.
Jak v tomhle obstojí třeba ve srovnání s rpythonem (toolkit, ve kterém je psáno pypy). Dívám se na to optikou člověka, který má zájem psát vlastní jazyk. Jak mi v tomhle Graal usnadní život? Koukal jsem zběžně na dokumentaci, ale nebylo mi to jasné.
-
Chtěli bychom, aby Truffle API, bylo lepší volbou než RPython. Ale o RPythonu jsem jen četl. Nezkoušel jsem to.
Vím, že Štefan Marr má zkušenosti s oběma systémy, které i
sepsal. Mělo z toho vyjít, že s RPythonem je jednodušší začít, že s GraalVM/Trufflem to dá více práce, ale pak má člověk více věci pod kontrolou.Já k tomu mohu dodat, že RPython nikdy nezískal podporu nějaké velké firmy. Vždy to byl univerzitní projekt. V OracleLabs na GraalVM & spol. pracuje přes padesát lidí.
-
> Já k tomu mohu dodat, že RPython nikdy nezískal podporu nějaké velké firmy. Vždy to byl univerzitní projekt. V OracleLabs na GraalVM & spol. pracuje přes padesát lidí.
Jo, jasně. Ale ti pracují na VM a podpoře jazyků, ne na toolkitu pro psaní vlastních jazyků.
Čímž nemám nic proti, jen upozorňuji, že to není úplně faktor. Navíc to taky znamená, že je to závislé kam zrovna v Oracle fouká vítr. Krásná ukázka jak to může skončit je například Self, který byl Sunem kdysi defacto zabit, když se korporace rozhodovala mezi Javou, Selfem a TCL.
Pypy je oproti tomu projekt, na kterém se aktivně podílejí stovky lidí z OpenSource komunity, který dlouhodobě funguje a není důvod očekávat opak.
> Vím, že Štefan Marr má zkušenosti s oběma systémy, které i
sepsal. Mělo z toho vyjít, že s RPythonem je jednodušší začít, že s GraalVM/Trufflem to dá více práce, ale pak má člověk více věci pod kontrolou.Super, o tohle mi přesně šlo, když jsem ten dotaz pokládal. Přečtu si.
> Chtěli bychom, aby Truffle API, bylo lepší volbou než RPython. Ale o RPythonu jsem jen četl. Nezkoušel jsem to.
Já s ním mám momentálně nějaké zkušenosti. Je to velmi highlevel toolkit, který má ale dost mizernou dokumentaci a úplně vražedné chybové hlášky, které jsou naprosto nesouvisející a nepochopitelné (hezky o tom píše třeba v https://refi64.com/posts/the-magic-of-rpython.html).
RPython má výhodu v tom jak je high-level a že dělá hodně věcí za programátora analýzou flow grafů. Co jsem tak zběžně koukal na SimpleLanguage nad Graalem, tak mi přišlo, že toho člověk musí dělat hodně manuálně. Ale zatím jsou to jen pocity, proto se ostatně ptám.
-
martin (neregistrovaný)
Ďakujem za zaujímavý článok.
Viete odhadnúť, kedy budú aj spring-* aplikácie kompilovateľné s graalvm do bináriek?
Pred nejakým časom som to skúšal s jednoduchou spring-core appkou a nešlo to. Našiel som tento zoznam obmedzení: https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md ale už som nepátral ďalej, v čom konkrétne bol problém.
-
Někdo to musí vyzkoušet a rozchodit. Samo se to neuchodí. Nejdůležitější bude asi sepsat konfigurační soubor pro RTI. Pak se uvidí, co je třeba změnit. Změny pak mohou být na straně
native-imageči na straně Springu. Obojí je open source, takže komunitě jsou dveře otevřené... -
andy (neregistrovaný)
Iba chcem poďakovať celému tímu, skvelá práca. A native-image je podľa mňa game changer pre microservices a javové lambda funkcie, ale v princípe je teraz možné vďaka bleskovému štartu písať fcgi v jave, napr pre aplikácie s nízkou návštevnosťou (teda moja idea je, že sa pustia až pri prístupe a 1 malá VPS s 1G ramky postačí aj na väčšie veci). A ako bonus to bude napriek tomu stále mnohonásobne rýchlejšie ako skripty..
-
pho (neregistrovaný)
Lide z Oracle labs budou letos o Graalu a Truffle prednaset 15.zari v Brne na konferenci DISC (www.disccon.com).
-
Ja (neregistrovaný)
Je to fajn, trochu to pripomina ada dekompilator, ci ako sa to vola, ze ten tiez prevedie assembler do univerzalneho jazyka c. Tak tuto to rozsirili, ze vyberies aj ine uni jazyky, ale aj to uz existuje v dot net. Takze akoby to zlepili do jedneho produktu tie napady, co sa moze zist opensource komunite, ak to dovolia tvorcovia ;-) Ako vravia filozofovia, secko smeruje do suucna.. teda do graal vm :-D
-
Dundee (neregistrovaný)
Je to hodně early, v pythonu skoro nic nefunguje https://pybenchmarks.org/u64q/graal.php
