Proč je Java pomalá a problémová?

[Filip Jirsák]

Pokud nejaky program vyzaduje specificky runtime (a neni to jen rozdil mezi dejme tomu Javou 6 a 7), tak je to vetsinou prasacky napsana aplikace.

Nebo prasácky napsaná standardní runtime knihovna Javy. Např. některé zajímavé události při startu Java appletu jsou schované v package sun nebo podobném, takže pokud chcete informovat uživatele, že se něco děje, nezbývá než navázat kód na konkrétní runtime (i když zrovna v tomhle případě se to dá obejít a když ta třída není na classpath, prostě se nic nezobrazí a doufá se, že si uživatel počká).

Nebo třeba přístup do systémového úložiště certifikátů pod jmény KeychainStore, Windows-MY a Windows-ROOT je také záležitost Oracle Javy a ostatní implementace to mohou mít nazvané jinak nebo vůbec nemusí systémová úložiště certifikátů zpřístupňovat. A podobných příkladů by se našlo spousta. Ona totiž nestačí jen specifikace JVM plus standardní knihovna, ale musela by být specifikována i spousta věcí, které aplikaci ovlivňují zvenku.

[Reklama]

[Kolemjdoucí]

Pořád ještě chcete jazyky rozdělovat na interpretované a nativní a dělat z toho nějaké závěry?

Bez problémů ano, protože to co se děje uvnitř CPU není interpretace ani omylem, je tam pouze mapování nativní instrukcí na sérii mikroinstrukcí, takhle se interpretace nedělá.
Interpret čte a vykonává zdrojový program, nativní kód se vůbec negeneruje.
Java bytecode se neinterpretuje, ale emuluje se, podobně jako třeba nativní kód pro Amigu na PC.
Procesory vykonávající přímo 100 % java bytecode jsou bajky, nikdo to nikdy neviděl v obchodě.

Původně to tak mělo být, měla být jedna verze bytecode a ta měla běžet všude. Jenže nikdo nepředpokládal že se v tom budou dělat molochy jako Eclipse a protože se to ukázalo jako prakticky nemožné, vznikly různé pomocné nativní knihovny.
Různé verze Javy jsou především kvůli licencím.

[Pavel Tisnovsky]

Pokud nejaky program vyzaduje specificky runtime (a neni to jen rozdil mezi dejme tomu Javou 6 a 7), tak je to vetsinou prasacky napsana aplikace.

Nebo prasácky napsaná standardní runtime knihovna Javy. Např. některé zajímavé události při startu Java appletu jsou schované v package sun nebo podobném, takže pokud chcete informovat uživatele, že se něco děje, nezbývá než navázat kód na konkrétní runtime (i když zrovna v tomhle případě se to dá obejít a když ta třída není na classpath, prostě se nic nezobrazí a doufá se, že si uživatel počká).

Nebo třeba přístup do systémového úložiště certifikátů pod jmény KeychainStore, Windows-MY a Windows-ROOT je také záležitost Oracle Javy a ostatní implementace to mohou mít nazvané jinak nebo vůbec nemusí systémová úložiště certifikátů zpřístupňovat. A podobných příkladů by se našlo spousta. Ona totiž nestačí jen specifikace JVM plus standardní knihovna, ale musela by být specifikována i spousta věcí, které aplikaci ovlivňují zvenku.

No ale to neni dano prasacky napsanou standardni knihovnou, vzdycky tam bude neco chybet (viz zminene uloziste certifikatu, to je snad systemova vec ne?), ale z hlediska kompatibility mezi JVM toho Sun v dobe svych lepsich casu udelal skutecne hodne. Ja z mnoha veci v Java API skutecne nejsem nadseny, ale vzhledem k jejimu rozsahu se nedokonalosti prirozene musi najit (uz tady nekdo zminovat IO-NIO-NIO2 apod.) a co jsem mel moznost resit problemy, tak to byly skutecne prasacky napsane aplikace, typicky ruzne applety psane bez ohledu na specifikaci pro jednu konkretni JVM (uvidime, kdy applety konecne umrou :-), asi s odstranenim NPAPI).

Jeste mam jednu zkusenost - znam vyvojare, co se fixovali na jednoho konkretniho dodavatele JVM a testovali jen na nem, a pri prechodu na novejsi JVM od *stejneho dodavatele* se najednou objevilo milion ruznych problemu. Pritom pridat dalsi JVM do Hudsonu/Jenkinse jiz na zacatku vyvoje je otazka minut a automaticky se tim najde spousta prohresku oproti RI.

[Vít Šesták (v6ak)]

No tak taketo cisla som nasiel a hovorim, ze som neveril . Provozovat nic neplanujem, len som si tak rozsiroval obzory...

Po Play1, kde jsem na ne až tak dobrý výsledek musel vynaložit více práce, se mi to taky moc nechtělo věřit. Ale je to skutečně tak. V Play2 bylo odstraněno Groovy, v production mode se nespouští žádný kompilátor, jehož třídy by pak zůstávaly v paměti (to v Play1 šlo vyřešit, ale bojoval jsem s tím). Dokonce i soubor routes se přeloží do zdrojáků Javy/Scaly a následně do bytecode. Nebo parsery JSONu se (aspoň ve Scale) řeší makrem, ne (relativně pomalou) reflexí. Ono je spousta důvodů, proč Play2 může být rychlý a nenáročný a současně se v tom dá dobře psát. Je to někdy i otázka návrhu - třeba asynchronnost, což se ale asi nedá vysvětlit na dvou řádcích.

Celý framework je taky relativně jednoduchý - ve srovnání s aplikacemi jako Eclipse. Je také určitě jednoduchý ve srovnání s prakticky celým světem J2EE . Například sessions řeší přes cookies podepsané pomocí HMAC. Má to svá omezení (zejména velikost session a nutnost některé věci timestampovat proti replay attacku), ale i výhody (škálování a nepotřeba úložiště sessions).


xfasdf: To IMHO nic nedokazuje. Quake2 jelo dobře i na starém 750MHz Duronu s 256MB RAM. Jake2 může být (ale třeba není) mnohem náročnější a nemusí to jít na dnešních CPU poznat.

Kolemjdoucí: Tak především bychom neměli mluvit o jazycích, ale o jejich implementacích. Existuje interpretované C, stejně jako Java kompilovaná do nativního kódu (GCJ, Avian, některé J2ME telefony, libart v Androidu 4.4). Procesor vykonávající Java bytecode je pak jiná věc, ale něco takového umožňovalo Jazelle, nicméně jeho detaily moc neznám.

[Kolemjdoucí]

Kolemjdoucí: Tak především bychom neměli mluvit o jazycích, ale o jejich implementacích. Existuje interpretované C, stejně jako Java kompilovaná do nativního kódu (GCJ, Avian, některé J2ME telefony, libart v Androidu 4.4). Procesor vykonávající Java bytecode je pak jiná věc, ale něco takového umožňovalo Jazelle, nicméně jeho detaily moc neznám.

S tím by se dalo souhlasit, kromě toho CPU kde je to zadrátováno.
Jazelle rozhodně neumí 100 % java bytecode.

[Reklama]

[Pavel Tisnovsky]

Kolemjdoucí: Tak především bychom neměli mluvit o jazycích, ale o jejich implementacích. Existuje interpretované C, stejně jako Java kompilovaná do nativního kódu (GCJ, Avian, některé J2ME telefony, libart v Androidu 4.4). Procesor vykonávající Java bytecode je pak jiná věc, ale něco takového umožňovalo Jazelle, nicméně jeho detaily moc neznám.

S tím by se dalo souhlasit, kromě toho CPU kde je to zadrátováno.
Jazelle rozhodně neumí 100 % java bytecode.

Je to tak - neumi 100% vsech instrukci JVM bytecode. To by totiz bylo silene komplikovane, treba instrukce invokevirtual atd. (nemluvim uz ani radeji o nove invokedynamic), tableswitche a lookupswitche atd., takze se to resilo fallbackem do podprogramu. Jazelle byl zajimavy pokus, ale podle me jsou casy optimalizace CPU na konkretni jazyk uz pryc. V kazdem pripade je dneska JIT i pro ARMy, takze Jazelle uz neni tak kriticka cast cipu.

Btw ani ten puvodni cip od Sunu (Pico Java a Micro Java nebo jak se to melo jmenovat) neumel 100% vsech instrukci, taky tam byly fallbacky na podprogramy.

[xfasdf]

xfasdf: To IMHO nic nedokazuje. Quake2 jelo dobře i na starém 750MHz Duronu s 256MB RAM. Jake2 může být (ale třeba není) mnohem náročnější a nemusí to jít na dnešních CPU poznat.

Quake2 isiel dobre aj na starom Pentiu 120 MHz s Voodoo 1 a 64 (a menej) MB RAM, ale vy mate IMHO asi problem drzat sa povodnej temy. "citaci" som pouzil preto, aby bol jasny kontext mojej odpovede, ale teraz vidim, ze to bolo zbytocne.

Pomozem vam s vykladom: Autor ma o Jave nejaky subjektivny nazor. Ja som mu ponukol moznost ako subjektivne porovnat navonok identicke aplikacie - jednu napisanu C/ASM a druhu v Jave.

[Kolemjdoucí]

Je to tak - neumi 100% vsech instrukci JVM bytecode. To by totiz bylo silene komplikovane, treba instrukce invokevirtual atd. (nemluvim uz ani radeji o nove invokedynamic), tableswitche a lookupswitche atd., takze se to resilo fallbackem do podprogramu. Jazelle byl zajimavy pokus, ale podle me jsou casy optimalizace CPU na konkretni jazyk uz pryc. V kazdem pripade je dneska JIT i pro ARMy, takze Jazelle uz neni tak kriticka cast cipu.

Skončilo to na správě paměti, to se zatím nikomu úspěšně nepodařilo dostat do mikrokódu a už se tím asi nikdo nikdy zabývat nebude. JIT nepochybně funguje ale je to popření principu Javy, tedy jeden bytecode běžící všude.

Naopak, třeba ARM/AVR má CPU přímo optimalizovaný pro C/C++, například je tam HW podpora na x=*y++; a x=*--yy; v jiném jazyku to takhle moc nejde napsat.

[Pavel Tisnovsky]

Je to tak - neumi 100% vsech instrukci JVM bytecode. To by totiz bylo silene komplikovane, treba instrukce invokevirtual atd. (nemluvim uz ani radeji o nove invokedynamic), tableswitche a lookupswitche atd., takze se to resilo fallbackem do podprogramu. Jazelle byl zajimavy pokus, ale podle me jsou casy optimalizace CPU na konkretni jazyk uz pryc. V kazdem pripade je dneska JIT i pro ARMy, takze Jazelle uz neni tak kriticka cast cipu.

Skončilo to na správě paměti, to se zatím nikomu úspěšně nepodařilo dostat do mikrokódu a už se tím asi nikdo nikdy zabývat nebude. JIT nepochybně funguje ale je to popření principu Javy, tedy jeden bytecode běžící všude.

Naopak, třeba ARM/AVR má CPU přímo optimalizovaný pro C/C++, například je tam HW podpora na x=*y++; a x=*--yy; v jiném jazyku to takhle moc nejde napsat.

Na GC delaji kolegove z Azulu, ale jak jsou daleko nikdo moc nevi, maji okolo toho same tajnosti :-)

Tak iterace pres pole je skoro v kazdem jazyku. Konkretne by mohl procesor optimalizovany pro C++ zvladat napriklad volani virtualnich metod (castecne to jde i dnes, ale pres ruku) nebo zvladat praci s ASCIIZ lip nez i8086, ale to asi fakt dneska nema smysl resit.

[JS]

Minecraft! To je myslím velmi dobrý příklad správně napsané aplikace v javě. Rychlá, bezrpoblémová, paměťově nenáročná. Vrchol optimalizace v javě!

Ja myslim, ze zrovna Minecraft (jakkoli ho mam rad) je priklad dost diskutabilni. Nezkousel jsem to, ale tvrdi se, ze Minetest (ktery je napsany v C++) je podstatne rychlejsi a mene narocny. I kdyz je to samozrejme tezke porovnat, protoze nejsou totozne co do vlastnosti a jako u kazde simulace sveta, konkretni detaily to mohou hodne ovlivnit (aspon podle meho debug vypisu travi Minecraft jen asi tretinu casu renderovanim, vetsinu zabira simulace herniho tiku).

[Kolemjdoucí]

Volání virtuálních metod funguje jednou instrukcí již 25 let :-) Hrátky se stringy se samozřejmě také řeší, viz SSE 4.2.

[Jakub Galgonek]

JIT nepochybně funguje ale je to popření principu Javy, tedy jeden bytecode běžící všude.

Teď jsem se asi trochu ztratil. V čem spočívá to popření?

[eMko]

JIT nepochybně funguje ale je to popření principu Javy, tedy jeden bytecode běžící všude.

JIT neodporuje principu "jeden bytecode běží všude". Při spuštění se bytecode překompiluje do nativního kódu a pak se spustí, to ano, ale obsah původního jar balíčku/class souborů (tedy původní bytecode) zůstanou nezměněny. To znamená, že lze vzít jar/class, spustit ho na Windows na amd64 procesoru, pak jej zkopírovat na SPARC a znovu spustit - znovu se JIT zkompiluje do nativního kódu a spustí, aniž by se bytecode aplikace změnil.

Naopak, třeba ARM/AVR má CPU přímo optimalizovaný pro C/C++, například je tam HW podpora na x=*y++; a x=*--yy; v jiném jazyku to takhle moc nejde napsat.

Pokud píšeš aplikaci, pro kterou je stěžejní hardwarová optimalizace těchto věcí, pak ta aplikace stejně není v Javě/C#/jakémkoliv_jiném_jazyku_s_(polo-)automatickou_správou_paměti. Toto vidím jak trochu zcestný argument.

[Filip Jirsák]

Já neříkám, že toho Sun udělal pro kompatibilitu málo. Specifikace JVM a standardní knihovna jsou z tohoto pohledu výborné a je spousta aplikací, které opravdu poběží na libovolném existujícím runtime, který specifikace splňuje. Upozorňoval jsem jenom na to, že ani tohle nestačí, pro 100% přenositelnost by ty specifikace musely jít ještě mnohem dál. Ale v současné chvíli by mi to nepřipadalo užitečné, lepší je, když si ty aplikace, které to potřebují, předepíší konkrétní runtime. Ostatně, spousta javovských aplikací jsou na míru psané "podnikové" systémy, a tam bývá přesně předepsaná i verze runtime a verze aplikačního serveru.

[ohlol]

vvv:
Java rychlejší než C, netuším na čem jedeš ale chci to taky.

Tak třeba http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=java&lang2=gcc&data=u64q.
Uznávám, že to jsou jen 2 případy z 11, ale chtěl jsem hlavně říct, že to není až takové scifi jak by se zdálo.

na CPU seconds je to jen jeden. (fasta)

to, ze realna doba behu ukazuje dva... jenze to bud cekalo ne prepnuti kontextu nebo na disk I/O nebo cokoliv jineho co nikdo nedohleda.
takze ne 2, ale 1 z 11

a ted jeste k tomu jedinemu "fasta" narozdil od javy vola fwrite_unlocked / puts_unlocked pro kazdou cast retezce samostatne. konkretne
repeat_fasta()
...
        fwrite_unlocked (s2 + pos,1,line,stdout);
        putchar_unlocked ('\n');

mi z toho vychazi akorat to, ze napsat mizerny kod jde v obou jazycich.