Ideálny programovací jazyk

[Filip Jirsák]

GraalVM nebude na enterprise nasadenie ready nikdy. Je to iba testbed project, ktory sluzi na to, aby sa ludia zacali hrat s buducimi technologiami a poskytli potrebny feedback.

Ak chcete vediet, kedy sa technologie, ktore sa na GraalVM prototypuju, stanu enterprise ready, tak to zavisi od kazdeho downstream projektu zvlast.

Je to přesně opačně. GraalVM je marketingové označení od Oraclu, který vzal několik souvisejících projektů a spojil je pod tímhle názvem, aby to mohl prodávat do enterprise sféry.

Ano, většina těch projektů je velmi mladých, ale mají našlápnuto velice dobře, správným směrem, a ukazuje to, že to Oracle s Javou myslí vážně. A že si s ní ví rady, na rozdíl od Sunu.

Pane Jirsak, me uz asi nepresvedcite.

Ano, to už jsem pochopil. Mně je to jedno, já vás přesvědčit nechci. Akorát bych byl velmi nerad, abych takhle jednou dopadl sám – že pro mne můj názor bude tak důležitý, že nebudu ochoten přijmout jakékoli argumenty proti.

[Reklama]

[Idris]

Když více polygonů vlastní jeden node, tak ho nemůžou mít přes unique, to je v rozporu.
Když tam budu dávat obyčejný pointer, tak si musím někde počítat reference, což je ještě horší než sharedptr.
GC to dělá mnohem efektivněji, v tom je ten vtip a to se tady už od včerejška snažím říci. Stručně řečeno, nepočítá reference, chodí jen po přeživších a má výraznou “množstevní slevu”.

Pokud více polygonů vlastní jeden node, tak už nejsou jeho, ale všech. Tj. to úplně neodpovídá tomu, co jsi na začátku psal. Takže ano, pak není shared_ptr od věci. Nebo se to taky dá udělat tak, jak jsem psal předtím - vlastnit to bude nějaká nadstruktura nad tím, která to v případě potřeby uklidí.
S tou efektivitou GC bych byl opatrný, protože hodně také záleží, jak funguje vevnitř. V čem přesně myslíš, že má "množstevní slevu"?

Když to bude vlastnit nadstruktura, tak jak pozná, že může vyhodit nepoužívané nody? Jasně, řešení známe, ptám se spíš proto aby sis rozmyslel, jestli to opravdu dovedeš řešit lépe než těmi sdílenými pointery.

Tak tam záleží, jak to bude navrhnuto. Ale typicky přes counter, nebo nějaký vektor. Myslím, že rychlostně by si člověk mohl pomoct.

Typický GC má "množstevní slevu" proto, že se nestará o nedosažitelné objekty, řeší jen živé. To znamená, že čím déle vydrží neběžet, tím víc bude těch mrtvých a tím víc na tom ušetří. V důsledku toho je velmi levné dělat krátce žijící objekty, což má spoustu dalších pozitivních důsledků. Naopak new/delete se poctivě stará o každý objekt, což je dost neefektivní a v důsledku nutí programátora, aby se krátkodobým objektům vyhnul.

Jak se stará jen o živé? Ten overhead u GC nevadí? A proč by v C++ mělo být velmi drahé dělat krátce žijící objekty? Copak si nemůžu naalokovat paměť, kterou pak budu předávat, abych nemusel pořád alokovat a dealokovat?

Kdysi jsem si potřeboval ověřit, jak moc v javě můžu prasit a bezohledně alokovat nové a vyšlo mi, že má asi desetinásobnou průchodnost proti MS C++. Čili za daný čas dokáže alokovat a zahodit 10x víc objektů než C++.

Tak zrovna MS C++ není úplně vypovídající. Také by mě zajímalo, jak jsi to měřil.

Pro lowlevel benchmark jsem si prostě udělal pole řádově tisíce pointerů a do toho jsem alokoval stále nové objekty. Ty něco triviálního počítaly a pak je přeplácnul nový objekt. Tohle samozřejmě GC chutná nejvíc, takže se tam projeví výhody proti delete.

To je teda hodně debilní benchmark.

[KarelI KarelI]

Ano, můžeš zkoušet různé countery, vektory, předalokace, dealokace a věřit, že tím obejdeš nevýhody new/delete. Však si to někdy zkus. Můj první příspěvek byl právě o tom, že GC je v tomhle přinejmenším dobrý kompromis vzhledem k tomu, jak to usnadňuje práci programátora. Ano, namítáš, že C++ programátor si může vybrat, já říkám, že výkon tohoto mechanismu je tak mizerný, že u složitějších problémů je k tomu donucen.

Já si to zkoušel, ale přes unique_ptr. A nenamítám, že programátor v C++ si může vybrat, namítám, že GC není jednoznačnou výhodou a že ne-GC přístup má své nesporné výhody. Navíc nejprve by to chtělo specifikovat, co si představuješ pod pojmem "výkon".

GC má samozřejmě overhead, ale když na něj dojde, tak často existuje jen zlomek objektů, co prošly tím programem. Pořeší tento zlomek a je hotovo. Delete se poctivě stará o každých pár byte co si někde alokuješ, to je prostě ohromný rozdíl.
Dělal jsem spoustu měření na různě složitých algoritmech. Pro lowlevel benchmark jsem si prostě udělal pole řádově tisíce pointerů a do toho jsem alokoval stále nové objekty. Ty něco triviálního počítaly a pak je přeplácnul nový objekt. Tohle samozřejmě GC chutná nejvíc, takže se tam projeví výhody proti delete.

Obávám se, že tohle nechápu. Zaprvé pokud existuje zlomek objektů, co prošly programem, tak proč bych měl v ne-GC přístupu alokovat víc? Zadruhé ten GC se taky stará o každý byte, protože nechce mít memory-leaky (a ten delete volá taky) - hlavní rozdíl je "kdy" a "jak často".

Ad ten příklad - pokud sis udělal řádově tisíce pointerů a do nich alokoval stále nové objekty, které něco počítaly a pak je přeplácnul, tak nechápu, proč jsi volal delete. Delete voláš až na konci, proč bych dealokoval paměť, kterou budu vzápětí alokovat? To potom chápu, že to pro GC vyházelo lépe, ale v takovém případě je problém jinde...

Účelem toho benchmarku bylo simulovat alokace v běžném programu. Tam jsou různé třídy a dělají různé věci. Tedy dává smysl alokovat různé objekty, k něčemu je použít a zase je smazat. Pokud bych to dělal jinak, tak bych netestoval to co jsem testovat chtěl.

Když už se pouštíš do debaty o GC, tak předpokládám, že aspoň zhruba víš jak funguje. Pro představu co se běžně používá - je kus paměti vyhrazen pro nové objekty, když tam dochází místo, tak živé (ty na které existuje odkaz) se vykopírují jinam a paměť se může znovu použít. Všimni si, že jsem vůbec nezmínil mrtvé objekty, pro ty se totiž nemusí dělat vůbec nic, žádný delete. V běžném programu je těch mrtvých v každé iteraci třeba 95%, takže je to proti klasickému delete výrazná úspora za cenu toho, že se musí 5% dat kopírovat.

[KarelI KarelI]

Pro lowlevel benchmark jsem si prostě udělal pole řádově tisíce pointerů a do toho jsem alokoval stále nové objekty. Ty něco triviálního počítaly a pak je přeplácnul nový objekt. Tohle samozřejmě GC chutná nejvíc, takže se tam projeví výhody proti delete.

To je teda hodně debilní benchmark.

Chápu, že jsi nemusel pochopit motivaci k takovému lowlevel benchmarku, ale stačí se zeptat, nemusíš tady hned vylévat své frustrace.

[kimec]

Je to přesně opačně. GraalVM je marketingové označení od Oraclu, který vzal několik souvisejících projektů a spojil je pod tímhle názvem, aby to mohl prodávat do enterprise sféry.

Fakt? ja hovorim o Community Edition. A vy? Nikde som nevidel, ze by sa nu od Oraclu dal ziskat plateny support. vy snad ano? Nehovoriac o tom, ze cielom projektov ako MLE je, ze ziaden GraalVM treba neni.
Kudne si mozete kupit aj Oracle Linux, ale neviem ako to meni fakt na tom, ze Fedora pren sluzi ako bleeding edge testbed prostredie.

[Reklama]

[Kit]

Ad ten příklad - pokud sis udělal řádově tisíce pointerů a do nich alokoval stále nové objekty, které něco počítaly a pak je přeplácnul, tak nechápu, proč jsi volal delete. Delete voláš až na konci, proč bych dealokoval paměť, kterou budu vzápětí alokovat? To potom chápu, že to pro GC vyházelo lépe, ale v takovém případě je problém jinde...

Účelem toho benchmarku bylo simulovat alokace v běžném programu. Tam jsou různé třídy a dělají různé věci. Tedy dává smysl alokovat různé objekty, k něčemu je použít a zase je smazat. Pokud bych to dělal jinak, tak bych netestoval to co jsem testovat chtěl.

Když už se pouštíš do debaty o GC, tak předpokládám, že aspoň zhruba víš jak funguje. Pro představu co se běžně používá - je kus paměti vyhrazen pro nové objekty, když tam dochází místo, tak živé (ty na které existuje odkaz) se vykopírují jinam a paměť se může znovu použít. Všimni si, že jsem vůbec nezmínil mrtvé objekty, pro ty se totiž nemusí dělat vůbec nic, žádný delete. V běžném programu je těch mrtvých v každé iteraci třeba 95%, takže je to proti klasickému delete výrazná úspora za cenu toho, že se musí 5% dat kopírovat.

Cikáda totiž neustále recykluje již alokované objekty, což je u strukturovaného programování běžnou záležitostí. GC by v takovém případě nebyl nikdy aktivován, benchmark by nezaznamenal rozdíl.

Významný rozdíl však zjistíme při požadavku na immutable objekty, což je zejména u vícevláknových aplikací žádoucí. Zde bude mít GC výkonově jasně navrch za cenu občasných latencí.

[Filip Jirsák]

Fakt?

Ano.

ja hovorim o Community Edition. A vy?

Já píšu o GraalVM EE. Ptal jste se na enterprise nasazení.

Nikde som nevidel, ze by sa nu od Oraclu dal ziskat plateny support. vy snad ano?

Tak proč diskutujete o něčem, o čem nic nevíte? Ve středu byla oznámena GraalVM 19.0, první produkční verze GraalVM. Vydána byla ve dvou edicích, jak bylo celou dobu plánováno, v edice Community Edition a v edici Enterprise Edition. Na Enterprise Editionposkytuje Oracle komerční podporu.

Nehovoriac o tom, ze cielom projektov ako MLE je, ze ziaden GraalVM treba neni.

Nenašel jsem, co je projekt MLE. GraalVM je virtuální stroj nové generace, podporuje běh více jazyků, AOT kompilaci do nativního kódu – mně osobně to připadá dost užitečné, nejen pro Javu.

[kimec]

ja hovorim o Community Edition. A vy?

Já píšu o GraalVM EE. Ptal jste se na enterprise nasazení.

Ja som sa konkretne vas na ziadne enterprise nasadenie nepytal. Napisal som, ze GraalVM sluzi ako testbed, aby sa technologie dostali co najskor medzi developerov.

 

Nenašel jsem, co je projekt MLE. GraalVM je virtuální stroj nové generace, podporuje běh více jazyků, AOT kompilaci do nativního kódu – mně osobně to připadá dost užitečné, nejen pro Javu.

Vy ste co? Predavac s teplou vodou od Oracle?
Nechcem vam kazit den, ale ziadna generacna zmena sa v GraalVM nekona. Je to klasicky 8ckovy HotSpot rozsireny o JVMCI. JVMCI je sucastou OpenJDK od 9ny. O Jave 9, 10, 11 aj 12 preco potom nepisete, ze je to "vm novej generacie"? Tie si to nezasluzia?

[Idris]

Ano, můžeš zkoušet různé countery, vektory, předalokace, dealokace a věřit, že tím obejdeš nevýhody new/delete. Však si to někdy zkus. Můj první příspěvek byl právě o tom, že GC je v tomhle přinejmenším dobrý kompromis vzhledem k tomu, jak to usnadňuje práci programátora. Ano, namítáš, že C++ programátor si může vybrat, já říkám, že výkon tohoto mechanismu je tak mizerný, že u složitějších problémů je k tomu donucen.

Já si to zkoušel, ale přes unique_ptr. A nenamítám, že programátor v C++ si může vybrat, namítám, že GC není jednoznačnou výhodou a že ne-GC přístup má své nesporné výhody. Navíc nejprve by to chtělo specifikovat, co si představuješ pod pojmem "výkon".

GC má samozřejmě overhead, ale když na něj dojde, tak často existuje jen zlomek objektů, co prošly tím programem. Pořeší tento zlomek a je hotovo. Delete se poctivě stará o každých pár byte co si někde alokuješ, to je prostě ohromný rozdíl.
Dělal jsem spoustu měření na různě složitých algoritmech. Pro lowlevel benchmark jsem si prostě udělal pole řádově tisíce pointerů a do toho jsem alokoval stále nové objekty. Ty něco triviálního počítaly a pak je přeplácnul nový objekt. Tohle samozřejmě GC chutná nejvíc, takže se tam projeví výhody proti delete.

Obávám se, že tohle nechápu. Zaprvé pokud existuje zlomek objektů, co prošly programem, tak proč bych měl v ne-GC přístupu alokovat víc? Zadruhé ten GC se taky stará o každý byte, protože nechce mít memory-leaky (a ten delete volá taky) - hlavní rozdíl je "kdy" a "jak často".

Ad ten příklad - pokud sis udělal řádově tisíce pointerů a do nich alokoval stále nové objekty, které něco počítaly a pak je přeplácnul, tak nechápu, proč jsi volal delete. Delete voláš až na konci, proč bych dealokoval paměť, kterou budu vzápětí alokovat? To potom chápu, že to pro GC vyházelo lépe, ale v takovém případě je problém jinde...

Účelem toho benchmarku bylo simulovat alokace v běžném programu. Tam jsou různé třídy a dělají různé věci. Tedy dává smysl alokovat různé objekty, k něčemu je použít a zase je smazat. Pokud bych to dělal jinak, tak bych netestoval to co jsem testovat chtěl.

Když už se pouštíš do debaty o GC, tak předpokládám, že aspoň zhruba víš jak funguje. Pro představu co se běžně používá - je kus paměti vyhrazen pro nové objekty, když tam dochází místo, tak živé (ty na které existuje odkaz) se vykopírují jinam a paměť se může znovu použít. Všimni si, že jsem vůbec nezmínil mrtvé objekty, pro ty se totiž nemusí dělat vůbec nic, žádný delete. V běžném programu je těch mrtvých v každé iteraci třeba 95%, takže je to proti klasickému delete výrazná úspora za cenu toho, že se musí 5% dat kopírovat.

Ne každý tracing GC kopíruje, třeba v Go je normální alokátor a GC (tricolor) běží na pozadí a barví si objekty. A světe div se, je efektivnější než ten kopírující v Javě nebo .NET.

[Filip Jirsák]

Ja som sa konkretne vas na ziadne enterprise nasadenie nepytal.

Máte pravdu, nebyla to otázka. Bylo to tvrzení, které bylo fakticky špatně. Proto jsem ho opravoval. Konkrétně jste napsal: „GraalVM nebude na enterprise nasadenie ready nikdy.“

Napisal som, ze GraalVM sluzi ako testbed, aby sa technologie dostali co najskor medzi developerov.

Ano, to jste napsal, a už jsem vám to vyvracel, že jste to napsal špatně. Vývojáři používají jednotlivé technologie (SubstrateVM, native-image, Truffle), GraalVM je naopak marketingový název Oraclu, aby to mohl propagovat jako balík a nabídnout k tomu placený support.

Vy ste co? Predavac s teplou vodou od Oracle?

Nikoli, pouze vyvraceč nesprávných tvrzení.

Nechcem vam kazit den, ale ziadna generacna zmena sa v GraalVM nekona. Je to klasicky 8ckovy HotSpot rozsireny o JVMCI. JVMCI je sucastou OpenJDK od 9ny. O Jave 9, 10, 11 aj 12 preco potom nepisete, ze je to "vm novej generacie"? Tie si to nezasluzia?

Jedna z komponent GraalVM je SubstrateVM, což je JVM s AOT kompilací (na rozdíl od HotSpotu, který má JIT kompilaci). Součástí GraalVM je je úplně nový kompilátor z bajtkódu do nativního kódu, je napsaný v Javě a umí ho používat jak HotSpot tak SubstrateVM. Pod GraalVM také patří Truffle, který umožňuje přidávat do VM podporu dalších jazyků (vedle Java bytecode). GraalVM pak umožňuje i současný běh různých jazyků pod jednou VM, takže můžete aplikaci napsanou v Javě nakonfigurovat v JavaScriptu a pak spustit nějaký výpočet v R. Pro Truffle existuje i implementace pro LLVM bajtkód, takže pod GraalVM můžete spouštět i programy napsané v některém z jazyků, které podporuje LLVM.

To všechno jsou věci, o kterých se původnímu HotSpotu ani nesnilo. Že je to vše udělané tak, aby se to dalo používat z původního HotSpotu, je plus, pomáhá to překonat problémy se zpětnou kompatibilitou.

[kimec]

Ne každý tracing GC kopíruje, třeba v Go je normální alokátor a GC (tricolor) běží na pozadí a barví si objekty. A světe div se, je efektivnější než ten kopírující v Javě nebo .NET.

V jave sa barvi konkurentne tiez, ci? Navyse sa aj kopirovanie deje konkurentne a aplikacne thready pomahaju s kopirovanim.
Navyse sa kopirovane objekty mozu aj subezne mutovat. dobre nie? Jeden by povedal, ze v tom je cierna magia a to je len klasicky trancing GC, teda hned dva.

[Idris]

Ne každý tracing GC kopíruje, třeba v Go je normální alokátor a GC (tricolor) běží na pozadí a barví si objekty. A světe div se, je efektivnější než ten kopírující v Javě nebo .NET.

V jave sa barvi konkurentne tiez, ci? Navyse sa aj kopirovanie deje konkurentne a aplikacne thready pomahaju s kopirovanim.
Navyse sa kopirovane objekty mozu aj subezne mutovat. dobre nie? Jeden by povedal, ze v tom je cierna magia a to je len klasicky trancing GC, teda hned dva.

V Javě jsou těch GC tři p....e, ovšem to nemění nic na tom, že to kopírování je v praxi zbytečné.

[Zabanovaný Anonymní Troll]

No tak jsem zvedavy jak to s tim GraalVM dopadne. Ja bych byl v soucasnosti mohem radeji, kdyby v Jave slo konecne nejak normalne pouzivat Await Async. Protoze to co umi CompletableFuture nahrada neni ani nahodou, uz treba proto, ze clovek u toho musi resit problemy se soubehem vicero vlaken. To by se u normalniho stavoveho stroje s await async nemelo stat, protoze tam bezi jenom jeden thread. Sice existuje ten projekt Quasar, ale kdyz jsem se dival na ukozakovy kod, tak jsem moc nadseny nebyl. Chtel bych neco jednoducheho, kde muzu udelat:

CompletableFuture.supplyAsync(() -> doSomething());

A cus. Protoze na tom, jak se neco pouziva a jak slozite je to nakonfigurovat, setsakramentsky zalezi. To ma problem pochopit Jirsak. Protoze pokud se neco nepouziva dobre, tak to v praxi pro 9 z 10 javistu v enterprise znamena, ze se k tomu nikdy nedostane, protoze ta technologie pak do enterprise enviromentu nikdy neprobubla.

Java proste doted await async neumi a je to podle me velka ostuda. My co delame v enterprise tak nevim jestli nam k necemu je GraalVM, ale sakra bych vyuzili v nasich komponentach await async. Ale to proste je techbologie, ktera musi byt pripravena a musi se dat pouzit lusknutum prstu.

[Zabanovaný Anonymní Troll]

Nicmene co me tesi na GraalVM a kompilaci do nativniho kodu je to, ze to zmeni design Javovskych frameworku k lepsimu. Ale to potrva leta. Protoze ta kompilaci na native ma nejake problemy s reflexi, a ja si myslim, ze Spring pouziva reflexi az presprilis. Takze treba ten Micronaut je v tomhle vice odlehceny a mozna je to castecne zasluha toho GraalVM. Akorat nevim jak se tam treba resi anotace typu @Transactional, asi nijak. Snad se jednou dockam jazyka, kde se @Transactonal a podobne veci poresi uz v prubehu kompilace, protoze se mi nelibi, kdyz se porad vsechno musi volat pres proxy beany.

[Filip Jirsák]

Vidím, že se specializujete na komentování věcí, o kterých nic nevíte.

ze to zmeni design Javovskych frameworku k lepsimu.

Je pozoruhodné, jak často na Javu nadávají lidé, kteří předpokládají, že Java == Spring.

Protoze ta kompilaci na native ma nejake problemy s reflexi

Ve skutečnosti se akorát musí pro reflexi při kompilaci přibalit další informace. Nedivil bych se, kdyby to v budoucnosti nebylo potřeba. Ostatně kdyby se spojila AOT a JIT kompilace (aplikace by nastartovala z nativního kódu, ale dál by se v při běhu uměla optimalizovat pomocí JIT), byl by to další krok vpřed.

ja si myslim, ze Spring pouziva reflexi az presprilis

Podle mne Spring vůbec nesmyslně vše řeší až za běhu, přitom většina věcí, co dělá Spring, se dá řešit v době kompilace. Podle mne málokdo používá modularitu až v době běhu. Ale vzhledem k době vzniku je to pochopitelné.

Takze treba ten Micronaut je v tomhle vice odlehceny a mozna je to castecne zasluha toho GraalVM.

Nemyslím si, že je to zásluha GraalVM. Podpora pro GraalVM byla do Micronautu dodána až později. Udělat něco jako Spring, ale anotace použít tak, jak byly původně především zamýšlené – tj. využít je při překladu – vyselo ve vzduchu, byla jen otázka času, kdy se do toho někdo pustí.

Akorat nevim jak se tam treba resi anotace typu @Transactional, asi nijak. Snad se jednou dockam jazyka, kde se @Transactonal a podobne veci poresi uz v prubehu kompilace, protoze se mi nelibi, kdyz se porad vsechno musi volat pres proxy beany.

Micronaut anotaci @Transactional umí používat a řeší ji přesně tak, jako řeší vše ostatní – už v průběhu kompilace.

To by se u normalniho stavoveho stroje s await async nemelo stat, protoze tam bezi jenom jeden thread.

Jistě, použít jediné vlákno je na dnešních mnohojádrových procesorech výborný nápad.

Protoze na tom, jak se neco pouziva a jak slozite je to nakonfigurovat, setsakramentsky zalezi. To ma problem pochopit Jirsak.

Naopak, já tohle chápu velice dobře. Mimochodem, v tom je právě jedna z předností Javy, že je prostředí kolem už tak bohaté, že se spousta i poměrně složitých věcí používá velmi jednoduše. GraalVM je mladá technologie, takže to samozřejmě bude chvíli trvat, než bude také tak snadno použitelná, ale to je problém všech nových technologií, včetně třeba toho Go. Navíc Oracle se dost snaží GraalVM nedělat jako revoluci ale jako evoluci současných nástrojů, takže některé vlastnosti můžete používat tak, že OpenJDK spustíte s určitým parametrem a do projektu si přidáte závislost na normálním jarku dostupném v Maven repository. Vás to dokonce zmátlo tak, že jste si myslel, že to ani nepřináší podstatné nové možnosti.