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