Příspěvky

16

Vývoj / Re:Naučení se asynchronnímu programování

« kdy: 08. 10. 2019, 10:51:26 »

Po tisicateprve, ti lidi co to takhle ten synchronni design v historii pocitacu vymysleli, nebyli debilove nebo idioti.

Ano, tento problem je prinajmensom znamy uz od polovice minuleho storocia 1963 Timesharing: A Solution to Computer Bottlenecks. (zvyraznene zamerne).

Ide v podstate iba o dve veci:

• ergonomia abstrakcie, s ktorou naraba programator
• efektivita z pohladu vyuzitia procesora

Najprv stacili programy/procesy, potom prisli vlakna, potom prisli callbacky a lahke vlakna. Uz len samotne kontinuacie boli znovuvynajdene niekolko krat od 60tych rokov... Kazde riesnie ma svoje vyhody a nevyhody. Ale v podstate sa zongluje iba s ergonomiou a efektivitou.

Ci riesim dany problem callbackmi, Promismi, event loopom, co mi poskytuje moj OS (BSD, Linux, Windows), ci ma moj languge runtime userspace scheduler, ktory vytazi CPU bez context switchov a pouziva krajsiu abstrakciu v podobe kontinuacie delimitovanej alebo inej, ci za mna kompiler urobi CPS transformaciu alebo nie, problem je stale ten isty... co robit, ked CPU nema co robit, lebo caka na IO.

Zmrsene odkazy:

https://www.youtube.com/watch?v=Q07PhW5sCEk

https://homepages.inf.ed.ac.uk/wadler/papers/papers-we-love/reynolds-discoveries.pdf

17

Vývoj / Re:Naučení se asynchronnímu programování

« kdy: 08. 10. 2019, 10:33:49 »

Po tisicateprve, ti lidi co to takhle ten synchronni design v historii pocitacu vymysleli, nebyli debilove nebo idioti.

Ano, tento problem je prinajmensom znamy uz od polovice minuleho storocia 1963 Timesharing: A Solution to Computer Bottlenecks. (zvyraznene zamerne).

Ide v podstate iba o dve veci:

• ergonomia abstrakcie, s ktorou naraba programator
• efektivita z pohladu vyuzitia procesora

Najprv stacili programy/procesy, potom prisli vlakna, potom prisli callbacky a lahke vlakna. Uz len samotne kontinuacie boli znovuvynajdene niekolko krat od 60tych rokov... Kazde riesnie ma svoje vyhody a nevyhody. Ale v podstate sa zongluje iba s ergonomiou a efektivitou.

Ci riesim dany problem callbackmi, Promismi, event loopom, co mi poskytuje moj OS (BSD, Linux, Windows), ci ma moj languge runtime userspace scheduler, ktory vytazi CPU bez context switchov a pouziva krajsiu abstrakciu v podobe kontinuacie delimitovanej alebo inej, ci za mna kompiler urobi CPS transformaciu alebo nie, problem je stale ten isty... co robit, ked CPU nema co robit, lebo caka na IO.

18

Vývoj / Re:Ideálny programovací jazyk

« kdy: 12. 05. 2019, 15:58:21 »

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.

19

Vývoj / Re:Ideálny programovací jazyk

« kdy: 12. 05. 2019, 15:03:43 »

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?

20

Vývoj / Re:Ideálny programovací jazyk

« kdy: 12. 05. 2019, 13:46:44 »

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.

21

Vývoj / Re:Ideálny programovací jazyk

« kdy: 12. 05. 2019, 11:47:54 »

Proc to vubec resime toto. Kazdy proste vime, ze Java je pomala a nenazrana, pomalu startuje, v provnani treba s Go, nebo Swift, nebo Objective-C.

Ne, to „víte“ jenom vy. A řešíme to proto, abyste se dozvěděl, jak je to doopravdy. Když provedení aplikace v Go trvá průměrně 260 ms a doba běhu aplikace (s tím samým algoritmem) v Javě trvá průměrně 166 ms, nevypadá to, že by Java byla v porovnání s Go pomalejší. Spíš to vypadá opačně.

1. Oracle - kolik bude GraalVM stat, jake bude srani s licencemi?
2. Kompilace - jak dlouho se to kompiluje v porovnani s Go?
3. GraalVM a Spring - nedari se mi vyrobit image - uz se s tim zase seru, hodina a pul zabita.
4. Konfigurace - neni to lusknutim prstu, s Go dam 1x download a mam vse.
5. Kdy bude GraalVM pripraven pro produkcni nasazeni v enterprise?

Tvl ta Java to je takova hydra, a ted ji akorat zase narostla dalsi hlava 

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.

Osobne si myslim, ze taky zasadny milnik pre bezneho Frantu bude vtedy, ked vyjde stabilny release MySQL a Oracle DB s MLE. Predpokladam, ze na roote bude nejaky clanok.

Co sa tyka Javy, tak kompilacna infrastruktura z Graalu je sucastou referencnej implementacie uz od 9ny.

22

Vývoj / Re:Ideálny programovací jazyk

« kdy: 11. 05. 2019, 23:37:48 »

Dost dlouho, na to ze je to jenom takovy psouk :-) A kdyz je tech psouku 1000 (Spring), tak uz to jde i dost videt. Proc to vubec resime toto. Kazdy proste vime, ze Java je pomala a nenazrana, pomalu startuje, v provnani treba s Go, nebo Swift, nebo Objective-C.

Zrovna Spring nie je dokazom toho, ze Java je pomala. Keby bolo mozne Spring sprasit aj s tym masivnym znasilnovanim reflexie, ako to len on vie, v akomkolvek jazyku, bolo by to rovnako pomale...a nenazrane.

Mne sa napriklad dost paci novy hybridny pamatovy model, ktory do Javy pribudol. Zneuzitie TLABov na region based memory model, z toho plynuce znizenie pamatovych narokov, z toho plynuca GC-less dealokacia, nezavisle heapy, automaticka multitenancy, milisekundovy startup time... lahka integracia s C/C++. ved to je vsetko super, nie? Nechapem preco sa ludia z toho netesia.

23

Vývoj / Re:Ako komplikovane programujete?

« kdy: 26. 03. 2019, 23:50:03 »

Jako skoro vsechno jde snad prepsat na "for", potiz ale je v tom, poznat, co ten optimalizovanej "for" loop dela. For-loop vs foreach s lambdou, to je imho presne ta vec, co by mel delat kompilator, ne programator. Taky programator v C nedela rucne loop-unwind a udela to za nej prekladac

Rozumiem vam, ale zrovna tento pripad je znamy fakt. Je to nestastna kombinacia viacerych faktorov.

Inak, rychly google search ponukol clanok Better Java Streams performance with GraalVM. Myslim, ze som ten clanok aj cital, ale uz si nepamatam presne. Kazdopadne, povedal by som, ze pri Java streamoch Graal doslova pletie z h*vna bic.

24

Vývoj / Re:Ako komplikovane programujete?

« kdy: 26. 03. 2019, 22:50:05 »

Je to podmiene implementaciou a pouzitim invokedynamic.

K čemu se v implementaci Java Stream API používá invokedynamic? A kde je to implementováno? Podle mne je celé Stream API implementováno v Javě a nevyžaduje žádnou magii na straně kompilátoru.

Hovorim o pomalosti streamov v Jave. Ta je sposobena samotnou implementaciou, ktora vyzaduje alokacie podpornych instancii s kratkodobou zivnotnostou, ktore je nasledne nutne dealokovat a teda zvysuje tlak na garbage collector. Kvoli charakteru implementacie streamov, kde referencie na podporne instancie unikaju mimo metody, kde boli alokovane, tu nezafunguje ani Escape Analysis tak ako je dostupny vo vanilla HotSpote.
Dalsim zdrojom pomalosti su lambdy, ktore sa v streamoch bezne pouzivaju, a ktore su implementovane cez invokedynamic. Prvotna warmup faza bude vzdy draha kvoli generovaniu anonymnej triedy, ktora bude sluzit ako factory pre lambdy daneho typu - toto sposobi spomalnie iba pri prvotnom pouziti. Avsak horsie je, ze lambdy, ktore referencuju premenene metody alebo fieldy instancie, kde je lambda zadeklarovana, vyzaduju rovnako alokacie na heape a nasledne dealokacie.

Predpokladam, ze Graal so svojou Partial Escape Analysis pomoze streamom prave oddalovanim materializacie instancii na heape... ale snad nebudem upgradovat VM na 3 urovnovi JIT kompiler, aby som zrychlil jednu forEach() slucku, ktoru dokazem zrychlit jednoduchym prepisom na for.

Uz rozumiete ako som to myslel?
 

25

Vývoj / Re:Ako komplikovane programujete?

« kdy: 26. 03. 2019, 19:33:38 »

Jeste jsem chtel rict, ze hodne lidi vidi budoucnost v tom, ze se do jazyku pridavaji nove featury (treba streamy) a ze to je ten svaty gral, jak se to pohne dopredu a bude lip. Ja s tim zasadne nesouhlasim, myslim si, ze budoucnost je praveze jinde, je v osekavani zbytecnych veci, tak jak to dela Go. Myslim si, ze tento pristup do budoucna vyhraje.

To iste sa predsa deje aj v Jave - modularizacia JDK - project Jigsaw.
So streamami nemate pravdu. Kazdy Javista, ktory za nieco stoji, predsa vie, ze streamy svojou pomalostou nikdy nenahradia iteraciu cez for slucku. Je to podmiene implementaciou a pouzitim invokedynamic. Nikdo predsa nikdy nepovedal, ze streamy musite bezpodmienecne pouzivat na vsetko a ze je to buducnost jazyka. To by bolo trochu stupidne, nie? Alokacie v tesnej slucke vytvaraju zbytocny tlak na garbage collector a vo vysledku spomaluju iteraciu. Ked robite IO nemusi to vadit, ale ked iterujete pole v pamati, naco streamy? Snad si vyberam nastroj podla charakteru problemu, ktory riesim, nie?

26

Vývoj / Re:Ako komplikovane programujete?

« kdy: 26. 03. 2019, 15:59:04 »

Jak to udelas v Jave nativne?

Uplne normalne. Zoberiem Java bytecode, prezeniem ho AOT kompilerom a vybuildujem nativny binar pre Linux ci Mac. Binar bude obsahovat nativny kod mojej aplikacie a malinkaty runtime SubstrateVM s garbage collectorom. Je to nieco ako go, ale Java.

27

Vývoj / Re:Ako komplikovane programujete?

« kdy: 26. 03. 2019, 11:05:24 »

A ty externi knihovny zpusobi, ze musite pouzivat Maven. A ze se musi pouzivat Maven zpusobi, ze se musi pouzivat i Gradle. A ze se musi pouzivat Gradle zpusobi, ze se bude pouzivat i Ant. Vsechno se na sebe vrstvi a pak toho je hromada.

Ja se ptam, kdyz nekomu prijde Spring moc velky overhead pro jeho aplikaci, tak v cem jinem to ma potom fidlat? (Doufam ze tu nejaky debil nenapise ze mam zkusit Play Framework a Scalu) O cehokoliv jineho nez Springu si uz budu klast otazku, jestli si ten backend nemam rovnou udelat v Node.js - protoze frontend uz asi dneska tezko budu fidlat na backendu a tak proste rovnou udelam i ten backend javascriptovy. A u veci slozitejsich uz se zase dobre hodi ten Spring, protoze ten overhead se ztrati.

Za me, Java se proste bohuzel nehodi na mensi veci, nez na ktere uz je vhodny Spring. Si myslim. Schvalne uvedte nejaky jiny priklad z praxe.

Jo a mluvim o vyvoji inf. systemu, stejne se dneska skoro nic jineho nedela.

Uvediem dva aktualne prilady z mojej praxe:
1) vyvoj nativnych rychlych command line toolov s minimom zavislosti na dynamickych knizniciach tretich stran v systeme
2) vyvoj nativnych mockovanych REST serverov s okamzitym startom a sub milisekundovym response time

28

Vývoj / Re:Ako komplikovane programujete?

« kdy: 25. 03. 2019, 21:46:41 »

Este by som rad reagoval na "sub thread" o Jave, ktory sa tiez rozbehol v tomto trheade.

Myslim si, ze aktualne sa ma Java velmi dobre.

Co sa tyka technologickej stranky, Java pravdepodobne zaziva najvacsi rozvoj za poslednu dekadu. Znacne tomu pomohol aj novy release model.
Nova funkcionalita moze pribudat iba vtedy, ked su veci v pohybe, ale dramaticke zmeny so sebou prinasaju aj rozbijanie rozhrani a starej funkcionality.

Osobne si myslim, ze treba este chvilu pockat, kym sa cely ekosystem stabilizuje, ale uz sa viac menej crta cesta:
a) staticky kompilovana depdency injection
b) nativne kompilovane binarky a la go
c) neblokujuce IO a korutiny
d) structy ako z C

Skratka, pritiahnute za vlasy, ked prach usadne, nebude treba ani Go ani node.js a trapna servletova aplikacia bude mat rovnake performance charakteristiky.

Treba si uvedomit, ze Java ma nadalej velke memomentum, samozrejem aj vdaka korportanemu svetu. Akykolvek technologicky refresh Javy ma dopad na velku cast biznis sveta.

29

Vývoj / Re:Ako komplikovane programujete?

« kdy: 25. 03. 2019, 21:19:08 »

Najprv som sa bal ze to nebude vela vediet ale cuduj sa svete, ono to ani nie je treba. Co zacinam nove projekty tak zamerne programujem uplne jednoducho v cistej Jave takze som zavisly na minime externych veci a ono to na pocudovanie aj celkom funguje. Zahodil som cely Spring a zacal som pouzivat Guice a Javalin. Na JWT tokeny java-jwt z com.auth0 a tiez to uplne v pohode fici jak ma ... raketovo sa v tom programuje.[
...] vsetky tie frameworky su vela krat len uplne zbytocne nadstavby.

Nahradili ste jeden framework za druhy a pouzivate viac prostrdiekov, ktore ponuka JDK. Ci to skomplikovalo programovanie, ukaze cas, ked vas kod prejde do "maintenance modu", popripade pribudne uplne nova funkcionalita (ktora nebola sucastou provodneho zadania), projekt bude treba nadalej udrziavat funkcny a pripadne ho preberie niekto iny.

Jeden z dovodov, preco sa v korporatnom svete pouziva Spring je ten, ze su viac menej zname "naklady" na jednotlive fazy zivota projektu. Inymi slovami, ked toho jedneho cloveka, ktory Javalin vyvyja, prejde autobus, alebo ho prestane bavit vyvyjat, mozete mat problem.

Toto samozrejme neplati pre prostriedky pochadzajuce z JDK. Tam robite velmi dobre, ked pouzivate to, co mate dostupne. Problem s vecami z JDK je casto krat casovanie, kedy tato funkcionalita do JDK pribudne. Mnohe frameworky nemohli cakat X rokov, kym vyjde JDK a preto prisli s vlastnymi rieseniami. Do JDK bola funkcionalita pridana ex post, no uzus nastoleny frameworkami sa uz nevykorenil.
Narozdiel od vyvojara, frameworky maju jasnu predstavu o zavislostiach na knizniciach 3tich stran a ocakavaju nejake konkretne prostredie - niekedy moze byt paradoxne jednoduchsie pouzivat neJDK veci, bohuzial.

30

Vývoj / Používáte OpenJ9 JVM v produkci?

« kdy: 26. 02. 2019, 08:36:24 »

Zdravim,

rad by som sa spytal, ci niekto pouziva OpenJ9 JVM v produkcii.

Ak ano:

• ake mate skusenosti (v zmysle pozitivne/negativne)?
• ako sledujete stav VM - stacia tie IBMcke tooly? VisualVM ma problem s niektorymi metrikami na OpenJ9.
• bolo v produkcii treba tunit nieco pekuliarne?

Dakujem.