Co zpomaluje Javu? A co překlad do nativního kódu?

[kimec]

Psal jsem o konkrétním případě, kdy kód napsaný inteligentně pracuje s mnoha objekty alokovanými na zásobníku, což Java neumožňuje, pročež je řádově pomalejší. Už se to tu řešilo několikrát, kdysi dávno i s kódem, kterýžto byl důkazem, a naposledy tu jeden z mála inteligentních účastníků tohoto fóra s nekonečnou trpělivostí vysvětloval těm méně chápavým, proč tomu tak je (už nevím, jestli M.Prýmek nebo O.S.Nekola, ale to je fuk).

Vy ste asi mysleli tento prispevok. https://forum.root.cz/index.php?topic=13854.msg179201#msg179201

[...] V Javě NEJDE zaručit, že se alokátor bude chovat inkrementálně a objekty bude umísťovat za sebe. Defaultně se o to snaží, ale ne vždy to lze. Problém je to hlavně při fragmentaci haldy, pak si alokátor bude vytvářet objekty tam, kde je zrovna místo. Nelze to rozumně ovlivnit. Heap compaction nic moc neřeší, protože je to drahé.

Ale jasne, ze to ide aj v Jave, ved som to linkoval vyssie http://mechanical-sympathy.blogspot.sk/2012/10/compact-off-heap-structurestuples-in.html .
Je to blog samotneho Thomsona, na ktoreho odkazuje aj Ondra Satai Nekola v tom vlakne... Takze to islo to uz 4 roky pred tou septembrovou diskusiou, LOL...

Ten blog přesně potvrzuje, co tu psal O.S.Nekola a tuším že R.Miček.

Ach, chapem, ja som predpokladal, ze vas argument je, ze to Java neumoznuje. A moj protiargument bol, ze to umoznuje, za cenu, ze si musite alokovat blok pamate mimo heap cez Unsafe, inymi slovami presne to iste, co je v predmetnom algoritme napisane v C. Predpokladam, ze toto je ten algoritmus
https://forum.root.cz/index.php?topic=13854.msg179103#msg179103 . Cize cele to bolo o tom, ze si allocujete jeden suvisli blok pamate, teda pocet * velkost structov Point. Ja to chapem tak, ze presne to sa da urobit a presne to je predmetom toho blogu. C-cko ziadnu typesafety nema, takze porovnavat Javovsky ArrayList/array referenci nema zmysel. Porovnavat suvisli blok alokovanej pamate z Javy cez Unsafe a struct Point *points = malloc(ARR_LEN * sizeof(struct Point)) sa moze? Spravne to chapem?

Ne, to není ten algoritmus, a nešlo o souvislou alokaci, ale o použití objektů alokovaných na zásobníku v kolekcích, což v Javě nejde ani s použitím unsafe, jež se tu taky řešilo a místní Java bumboys ho nazvali prasárnou. Jinak univerzálně přenositelný kód - pokud někomu nevoní POSIX - lze psát v Go včetně jednoduché kroskompilace.

Vyborne. Konecne som sa zorientoval. Mate absolutnu pravdu.

[Reklama]

[balki]

Pokud ...  V Jave to byva skor vynimka, kdezto v C je to pravidlo. Vacsinou, ak je Java vyvojar aplikacie prasa a pouziva nejaku platformovo zavislu kniznicu, byva tak jedna v celom projekte. Kdezto programy zlozitejsie nez hello world v C sa zavislostami na platforme hemzia. Pri lenivom programatorovi to skonci pribalenim emulacie posix-u, alebo windows api do projektu. Pri menej lenivom programatorovi sialenymi ifdefmi.

Co když potřebuju třeba GPGPU? Jinak s C jsem nikdy problémy neměl, ale ono to je o zkušenostech, žádný učený z nebe nespadl a psát dobrý kód se člověk učí s časem (nicméně při dodržení POSIXu a nějakého toho BSD API by neměl být problém).

Pri takychto prasacinach treba zvazit, ci to ozaj clovek potrebuje. Ak ano, tak radsej treba zvazit, ci nepouzije fortran, brainfuck, C alebo cobol.

[standa11111]

Proc je Java priblizne 3x pomalejsi nez C++, cim je ta aplikace tak bzdena? A jde Javovska aplikace prelozit do nativniho kodu s rozumnymi vykonostnimi vysledky?

Pokud Javu brzdi nejvic garbage c., je mozne psat aplikaci s manualnim uvolnovanim zdroju jako v c++? Je k tomu nejaka dobra literatura?

Pane Mysteriozni, muzes doplnit dotaz?

Predpokladam, ze zakladni problem je - neco je 3x pomalejsi nez neco jineho. Pak uz jen resis proc to prvni neco je tak pomale a jak to zrychlit.

Muzes uvest jak jsi dosel k tomu '3x pomalejsi'? Co je to za aplikaci, jak jsi meril rychlost,... Proste muzes dat dohromady nejaky smysluplny dotaz, aby melo vubec smysl na to rozumne reagovat?

Napada me treba situace, kdy obe aplikace spoustis pomoci shell scriptu, ale shell script, ktery spousti javu je blbe napsany, na necem se zadrhne/zacykli a to je vlastne duvod toho 3x pomalejsi. ;-)

Bez upresneni nema smysl se tim dotazem vubec zabyvat. Prevkapuje me, ze ostatni tak udelali.

[čumil]

GC zabíjí málo paměti.

JIT a platforma kolem něho žere výkon.

Preferování bezpečnosti před rychlostí. Opět ztráta výkonu.

Takže výsledek zhruba 300% pomalejší než C++. Alespoň podle benchmarks game.

[Kit]

Když jsem počítal integrály metodou Runge-Kutta 4. řádu, tak jazyky Java a C vyšly výkonově téměř nastejno. Fortran byl kousek před nimi.

[Reklama]

[noef]

Hm, C bezi vsude, argument jako prase proc mit binarni/cizojazycnou zasivlost v JavaScriptu, ktery take bezi skoro vsude (a tam, kde nebezi, tam mi je bezici knihovna v C na prd, kdyz hlavni aplikaci nespustim ). U vykonostne nekriticke knihovny to muze jen idiot takto roztrkat. C bych i chapal, pokud je opravdu narust ve vykonu v nasobcich a pokud bottleneck vetsiny aplikaci prave stoji na teto knihovne. Pokud knihovna zavisi na vylozene pomalejsich vecech  jako Python nebo Ruby, tak je to vzdycky na facku. Pokud existuje alternativa, tak nasleduje instantni zahozeni tohoto odpadniho baliku a nainstalovani normalniho. Kdyz totiz mate takhle "genialne" resene zavislosti (spise neresene), tak nestaci mit nainstalovany node a npm, ale musite instalovat Python, build veci pro C, dalsi ne-npm knihovny (dll/so), laborovat s verzemi Pythonu a zjistovat, jakymi workaroundy se ma predavat node-gyp cesta k pythoni binarce, protoze pozaduje prirozene nejakou archaickou verzi (dvojkova vetev). Takze si instalujete knihovnu pres balickovac - npm, ktery bezne resi zasislovi, pokud ale pouzivate takoveto veci mimo platformu, tak tam si musite cast zavislosti resit sami.

Jestli je to stejne polamane i v Jave, tj. ze se knihovna distribuuje napr. treba jen binarkami pro linuxu x64 a vse ostatni "pores si sam", tak se vubec nedivim, ze to nekdo prepsal do Javy. Jen opravdu ve vypocetne kriticke situaci bych sahl po kockopsovi (napr. knihovna pro nejake obecne mat. vypocty). Pokud je to knihovna, ktera i kdyby byla 100x pomalejsi nez verze napr. v C, ale aplikace stravi 0.01% casu vykonavanim kodu knihovny, tak to pridava akorat zbytecne starosti.

[Filip Jirsák]

GC zabíjí málo paměti.

JIT a platforma kolem něho žere výkon.

Preferování bezpečnosti před rychlostí. Opět ztráta výkonu.

Takže výsledek zhruba 300% pomalejší než C++. Alespoň podle benchmarks game.

To jsou akorát kecy někoho, kdo vůbec netuší, o čem je řeč. Když řešíte overhead GC, měl byste také dodat, že i aplikace napsaná v C má automatickou správu paměti a něco stojí i ten luxus, že si naalokujete 10 bajtů, pak je zase vrátíte a neznamená to alokaci celé nové stránky od jádra.

JIT platforma žere levný výkon v době běhu programu výměnou za ušetření drahého výkonu při vývoji programu. Navíc umožňuje optimalizovat nativní kód podle aktuální platformy, na které program běží, a podle skutečného způsobu použití. Takže i čistý výkon na CPU může být ve výsledku pod JVM vyšší, než když stejný kód napíšete v C.

Preferování bezpečnosti před rychlostí odpovídá požadavkům na IT. Rychlost totiž snadno vyřešíte přidáním dalšího levného stroje, bezpečnost takhle vyřešit nejde. Navíc k čemu vám je teoretická rychlost aplikace, když vám ta aplikace kvůli nějaké triviální chybě neběží, nebo když vedle ní běží hackerův kód, který je součástí nějakého botnetu.

Když interpretujete výsledky nějakého měření, musíte také vědět, co se měřilo. Což evidentně Mysteriozni ani čumil nevědí, protože jinak by nemohli napsat nicneříkající blábol o tom, že je něco 3× rychlejší nebo pomalejší. V čem je to rychlejší? Tiskárna rychleji vytiskne papír, rychleji se zapíšou data na disk, u kvízu běží čas 3× rychleji? Mimochodem, i když byste chtěli porovnávat výkon na (C)PU, zaspali jste dobu, protože takovéhle věci se dnes neřeší zrychlováním algoritmu o drobná procenta, ale řeší se paralelizací.

[Radek Miček]

GC zabíjí málo paměti.

JIT a platforma kolem něho žere výkon.

Preferování bezpečnosti před rychlostí. Opět ztráta výkonu.

Takže výsledek zhruba 300% pomalejší než C++. Alespoň podle benchmarks game.

To jsou akorát kecy někoho, kdo vůbec netuší, o čem je řeč. Když řešíte overhead GC, měl byste také dodat, že i aplikace napsaná v C má automatickou správu paměti a něco stojí i ten luxus, že si naalokujete 10 bajtů, pak je zase vrátíte a neznamená to alokaci celé nové stránky od jádra.

On řeší to, že overhead GC roste, když je méně paměti - což se u klasického mallocu tolik neděje.

Takže i čistý výkon na CPU může být ve výsledku pod JVM vyšší, než když stejný kód napíšete v C.

Jak často se to děje v praxi?

Rychlost totiž snadno vyřešíte přidáním dalšího levného stroje

To nemusí být vůbec pravda: Třeba v případě mobilního telefonu. Nebo, když máte výpočetní cluster, tak abyste dosáhl znatelného zrychlení, musíte přidat třeba desítky ne zrovna levných strojů - proto některé společnosti přešly od Cloudery k MapR, protože v MapR přepsali část Hadoopu do C++ a výkonostní rozdíl je znatelný - viz Is it significant to rewrite HDFS, Hadoop/Spark or HBase in C/C++ to improve computational efficiency?.

[Filip Jirsák]

On řeší to, že overhead GC roste, když je méně paměti - což se u klasického mallocu tolik neděje.

Ne, neřeší, to je daleko za jeho znalostmi. On jenom papouškuje, co četl někde v diskusích. Člověk, který aspoň tuší, jak funguje GC, nebude psát „jazyk X je 300% rychlejší než jazyk Y“.

Takže i čistý výkon na CPU může být ve výsledku pod JVM vyšší, než když stejný kód napíšete v C.

Jak často se to děje v praxi?

Zhruba tak stejně často, jako je potřeba řešit výkon tím, že se nějaká aplikace celá napíše v C. Jinak JVM kód za běhu optimalizuje včetně optimalizace skoků, třeba JRockit dělá při optimalizacích evidentně i docela divoké kousky. Takže je dost pravděpodobné, že některé části nativního kódu jsou za běhu v JVM optimalizované lépe, než jak je dokáže optimalizovat překladač na základě statické analýzy kódu. Akorát že na těch dílčích optimalizacích nikdo nezávisí, takže se nijak neměří a nezjišťují. Nemám tedy kód, na který bych ukázal a napsal „JRockit to při takovéhle profilu používání optimalizuje na tenhle nativní kód“.

Rychlost totiž snadno vyřešíte přidáním dalšího levného stroje

To nemusí být vůbec pravda: Třeba v případě mobilního telefonu. Nebo, když máte výpočetní cluster, tak abyste dosáhl znatelného zrychlení, musíte přidat třeba desítky ne zrovna levných strojů - proto některé společnosti přešly od Cloudery k MapR, protože v MapR přepsali část Hadoopu do C++ a výkonostní rozdíl je znatelný - viz Is it significant to rewrite HDFS, Hadoop/Spark or HBase in C/C++ to improve computational efficiency?.

Bavíme se ale (asi) o rychlosti vykonávání aplikace na CPU. Aplikace, pro které je tohle kritické, nebudete provozovat na mobilním telefonu. V případě clusteru pouhým přepsáním z Javy do C++ zvýšíte výkon minimálně, přidat ne zrovna levné stroje do clusteru je pořád levnější. Výkon můžete podstatně zvýšit tím, že změníte algoritmus zpracování. Pak se může ukázat, že ten algoritmus nejde efektivně implementovat s prostředky JVM (a implementovat to přímým přístupem do paměti nedává pod JVM moc smysl, protože pak ztrácíte výhody JVM). Také je pravda, že clusterová řešení jdou proti výhodám JIT kompilace, protože u levných hloupých procesorů ztrácíte tu výhodu kódu optimalizovaného pro spekulativní provádění kódu. Nebo-li i když se jedná o výpočetně náročnou aplikaci, zvolený jazyk (nebo spíš prostředí) je spíš podružná záležitost, výkon mnohem víc ovlivňují jiné věci – na prvních třech místech jsou možnost paralelizace, použité algoritmy a schopnost využít vysokého výkonu procesoru (aby procesor minimálně čekal – tj. aby měl data v cache, nemusel se synchronizovat s jinými vlákny, aby mohl kód provádět paralelně a aby využil výsledky spekulativního provádění kódu).

[Lama]

Co když potřebuju třeba GPGPU?

JOCL?

[gll]

Co když potřebuju třeba GPGPU?

JOCL?

To je nativní knihovna.

[zboj]

Co když potřebuju třeba GPGPU?

JOCL?

Znám, nicméně kód využívající OpenCL bude vždy záviset na nativním kódu. A zrovna v nyní se rozmáhajícím machine learning (a obecně v AI) se GPGPU používá hodně, čímž je Java z této domény kompletně vyloučena.

[čumil]

Co když potřebuju třeba GPGPU?

JOCL?

Znám, nicméně kód využívající OpenCL bude vždy záviset na nativním kódu. A zrovna v nyní se rozmáhajícím machine learning (a obecně v AI) se GPGPU používá hodně, čímž je Java z této domény kompletně vyloučena.

False, big data (takže AI) se chroupou na Jave v hadoop clusterech. Když už jsou třeba sítě, tak tensorflow a podobný kokotiny krerý jdou z javy taky použít.

[javaman ((]

Filip to napsal správně a nevím, co se vám na tom nezdá. Alespoň se právě nesnaží psát hovadiny jako ostatní.

[Ondra Satai Nekola]

Co když potřebuju třeba GPGPU?

JOCL?

Znám, nicméně kód využívající OpenCL bude vždy záviset na nativním kódu. A zrovna v nyní se rozmáhajícím machine learning (a obecně v AI) se GPGPU používá hodně, čímž je Java z této domény kompletně vyloučena.

False, big data (takže AI) se chroupou na Jave v hadoop clusterech. Když už jsou třeba sítě, tak tensorflow a podobný kokotiny krerý jdou z javy taky použít.

BigData a AI jsou mimoběžné věci.