reklama

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

Pavel Tisnovsky

Re:Proč je Java pomalá a problémová?
« Odpověď #135 kdy: 18. 12. 2013, 16:36:13 »

Měl bych takový možná hloupý příklad, do vnitřností JVM opravdu nevidím... V Erlangu jsou afaik všechny odkazy v paměti z principu věci vždycky jednosměrné (vždycky odkaz jenom na starší data) -> neexistují cykly -> GC může být podstatně jednodušší, rychlejší a nemá takový dopad na latenci.
Takový nějaký podobný efekt by v JVM nastat nemohl? Že by prostě z nějakého principu jazyka došlo k tomu, že by celkově ta aplikace měla "hezčí chování"? 


V JVM se nejvice pouzivaji GC zalozene na kopirovani zivych objektu z jedne casti heapu do jine (ted zjednodusuji). Tim dostavame zadarmo i to, ze heap je vzdy kompaktni a alokace pameti spociva jen v posunu ukazatele, nic jineho - alokace je tedy rychlejsi nez v cecku :), navic se v heapu delaji regiony pro kazde vlakno, takze i bez nutnosti syncu. Samotne GC ale samozrejme musi provadet presuny dat, markovani zivych objektu atd., coz ve vetsine typu GC vede k nutnosti pozastavovani vlaken a tady se muze GC negativne projevit (resp. se projevi hlavne na deskopu, na serverech nas vetsinou zajima hlavne celkovy vykon). Resenim pravepodobne budou pauseless GC, jeden se ted prave vyviji, uvidime pristi rok.

Erlang ma tedy GC zalozeny na pocitani referenci? Ale musi resit fragmentaci heapu ne? nebo to nechava "konovi" jako dalsi jazyky?

reklama


Re:Proč je Java pomalá a problémová?
« Odpověď #136 kdy: 18. 12. 2013, 16:43:15 »
GMail je špatný příklad, protože tam fakt netušíme, jak co a proč má Google udělané, co je rychlé jenom díky cachování atd. atd.
Ale vždyť to je právě ten celkový uživatelský dojem. Jaký v tomto kontextu rozdíl mezi kešováním a paralelizací, kterou jste uváděl vy?

Já to ale slýchám i od adminů, kteří javové aplikace reálně spravují.
S čím to porovnávají?

Měl bych takový možná hloupý příklad, do vnitřností JVM opravdu nevidím... V Erlangu jsou afaik všechny odkazy v paměti z principu věci vždycky jednosměrné (vždycky odkaz jenom na starší data) -> neexistují cykly -> GC může být podstatně jednodušší, rychlejší a nemá takový dopad na latenci.
Takový nějaký podobný efekt by v JVM nastat nemohl? Že by prostě z nějakého principu jazyka došlo k tomu, že by celkově ta aplikace měla "hezčí chování"? 
Připadá mi to velmi nepravděpodobné, protože Java (jazyk) je velmi blízko JVM, a to oboustranně – v jazyce prakticky neexistují konstrukce, které by neměly obraz v instrukční sadě JVM, a JVM zase neumí prakticky nic navíc, co nepotřebuje Java.

Přesně tam myslím ta debata předtím směřovala: "ukažte mi aplikace v oblasti XY, které se prosadily".
Bylo zmíněné Eclipse. Tak můžeme vzít čtveřici Eclipse, IntelliJ Idea, NetBeans, Visual Studio. Nevím, zda je to komplet – možná ještě něco od Borlandu? Pokud jsem na něco nezapomněl, je tedy zajímavý i ten počet. Ale nás zajímá uživatelská zkušenost s výkonem těch aplikací. Je mezi nimi evidentní rozdíl v rychlosti, paměťové náročnosti? Neřekl bych.

Přesně tam myslím ta debata předtím Android je pořád klasický stack. Já jsem myslel podstatně tenčí vrstvu pod JVM, opravdu jenom ve stylu nějakého speciálního mikrokernelu... (něco ala L4Linux)
To by znamenalo nový OS. A nových OS vzniká málo tak nějak obecně. Naopak se počet OS snižuje – různá spotřební elektronika jako televize (dnes už i hodinky hodinky) měla dříve vlastní řídící software, který byl sám sobě i OS. Dnes se místo toho používá Linux nebo Linux/Android. Apple použil jádro FreeBSD.

Je na tom také vidět, že přidávání vrstev do toho „klasického stacku“ má vzhledem k celku čím dál menší režii. Dnes už nevadí provozovat nad HW operační systém, nad ním virtuální počítač typu VMware, nad ním virtuální stroj typu JVM a z toho všeho provozovat aplikaci přes internet. Důvod, proč se to nesloučí do jednoho, je podle mne čistě v tom, že ušetřený výkon by byl zanedbatelný (a čím dál menší), ale náklady na vývoj a následnou údržbu obrovské.

Citace: Kolemjdoucí
V cloudech se přesunuje celý běžící VM mezi fyzickými stroji, mají na to udělátor třeba ve VMWare.
A nebo tam právě běží nějaký virtuální stroj jako JVM, a v něm se podle potřeby startují a zastavují jednotlivé aplikace – takhle funguje třeba Google App Engine.

omg

Re:Proč je Java pomalá a problémová?
« Odpověď #137 kdy: 18. 12. 2013, 16:47:07 »
A jak dlouho se bude jeste vyvijet nez bude pouzitelny?

google. nastroje vyhledavani. a nastavit datum "do". nechce se mi hledat prvni datum, ale vsadil bych si snad uz nekde okolo 1996

1. 2. 2001 - The Java HotSpot VM provides a garbage collector that .....

omg

Re:Proč je Java pomalá a problémová?
« Odpověď #138 kdy: 18. 12. 2013, 16:47:45 »
1. 2. 2001 - The Java HotSpot VM provides a garbage collector that ..... The pauseless collector works by using an incremental old space collection scheme referred to ...

Pavel Tisnovsky

Re:Proč je Java pomalá a problémová?
« Odpověď #139 kdy: 18. 12. 2013, 16:55:03 »
A jak dlouho se bude jeste vyvijet nez bude pouzitelny?

google. nastroje vyhledavani. a nastavit datum "do". nechce se mi hledat prvni datum, ale vsadil bych si snad uz nekde okolo 1996

1. 2. 2001 - The Java HotSpot VM provides a garbage collector that .....

Vyvoj zacal vloni, az se objevil HW, kde to ma smysl, proc se ptas? GC v Jave a vlastne i vsechny GC jsou tady s nami dele nez dnes mainstreamove jazyky, neustale se vsak upravuji tak, aby reflektovaly vlastnosti noveho HW.

reklama


Re:Proč je Java pomalá a problémová?
« Odpověď #140 kdy: 18. 12. 2013, 20:21:49 »
Bylo zmíněné Eclipse. Tak můžeme vzít čtveřici Eclipse, IntelliJ Idea, NetBeans, Visual Studio. Nevím, zda je to komplet – možná ještě něco od Borlandu? Pokud jsem na něco nezapomněl, je tedy zajímavý i ten počet. Ale nás zajímá uživatelská zkušenost s výkonem těch aplikací. Je mezi nimi evidentní rozdíl v rychlosti, paměťové náročnosti? Neřekl bych.

V tejto kategorii u mna vyhrava QtCreator (napisany v C++), potom Visual Studio (kombinacia C++ a C# ), Android Studio/IntelliJ a az nakoniec Eclipse (sice je to silny nastroj, ale aj naviac sa seka). NetBeans nepouzivam, tak neviem zhodnotit.

ferren

Re:Proč je Java pomalá a problémová?
« Odpověď #141 kdy: 18. 12. 2013, 21:02:48 »
vidim ze tady toho nejak pribylo, padly otazky jaky sw jsem si teda predstavoval ze dostanu do te "vykladni skrine" ,tak jsem myslel nejake opravdu high performance aplikace, co vytizi/pretizi system a opravdu proveri sw i hw. treba ruzne simulacni, vizualizacni, numericke aplikace.
ja jsem vetsinu sveho profesniho casu pusobil ve vizualizacni/simulacni sfere a tam proste temer vyhradne frci c/c++ tak jsem se chtel dozvedet jestli mi neco zajimaveho napsaneho v jave neuniklo, ale muze to byt podstate cokoliv z hpc sfery, a nebo cokoli na vykon orientovaneho.
za sebe nedokazu posoudit vykovou narocnost request/response serverovych aplikaci, ktere podle me spis proveri vykon I/O a OS jak schopnost prekladace/interpretru generovat kvalitni rychly kod...

Re:Proč je Java pomalá a problémová?
« Odpověď #142 kdy: 18. 12. 2013, 21:07:22 »
V tejto kategorii u mna vyhrava QtCreator
Patří opravdu do téhle kategorie?

Já osobně bych Visual Studio na první místo nedával, a to toho podle mne ještě umí méně, než ty zbývající tři. Taky je zajímavé, že IntelliJ Idea je ten zlý pomalý Swing, zatímco Eclipse je to úžasné nativní SWT.

eMko

  • ****
  • 456
    • Zobrazit profil
    • E-mail
Re:Proč je Java pomalá a problémová?
« Odpověď #143 kdy: 19. 12. 2013, 07:59:54 »
Používat Visual Studio bez pluginu jménem ReSharper (od tvůrců prostředí IntelliJ IDEA) je celkem nesmysl, protože neumí ani desetinu toho, co vývojová prostředí pro Javu. S ReSharperem už je to jiné kafe, nicméně je velmi znát, že s tímto pluginem je VS pomalejší - podobně jako IDEA nebo Eclipse (drží-li se počet pluginů na rozumné úrovni). Paměťově je taky na zhruba stejné úrovni. Visual Studio+ReSharper má celkem dobrou podporu pro C# (a prý ještě Visual Basic, ale na ten jsem od doby VB6 nesáhl, tak nevím). Podpora pro C++ je ve VS celkem ostuda.

QtCreator je "lightweight" na tvorbu uživatelských rozhraní. V oblasti GUI sice exceluje, ale udržovat v něm celý netriviální projekt už bude dost o držku.

Ideu/Eclipse nelze po stránce pomalosti či paměťové náročnosti srovnávat ani moc s Visual Studiem, natožpak s QtCreatorem.

Re:Proč je Java pomalá a problémová?
« Odpověď #144 kdy: 19. 12. 2013, 08:59:56 »
QtCreator je "lightweight" na tvorbu uživatelských rozhraní. V oblasti GUI sice exceluje, ale udržovat v něm celý netriviální projekt už bude dost o držku.
Nemozem suhlasit. QtCreator je normalne IDE, a nie len "lightweight" na GUI. Sam ho pouzivam na GUI aj ne-GUI projekty, male (20k riadkov) aj velke (2m riadkov).

Re:Proč je Java pomalá a problémová?
« Odpověď #145 kdy: 19. 12. 2013, 09:04:35 »
Nemozem suhlasit. QtCreator je normalne IDE, a nie len "lightweight" na GUI.
Co je to „normální IDE“? Když porovnám Borland Delphi 3 s IntelliJ Idea 13, nebo Visual Studio bez ReSharperu a s ReSharperem, jsou to  vždy obě normální IDE, ale porovnávat jejich náročnost na zdroje nemá moc smysl, vzhledem ke zcela rozdílným výsledkům.

Re:Proč je Java pomalá a problémová?
« Odpověď #146 kdy: 19. 12. 2013, 09:10:57 »
V JVM se nejvice pouzivaji GC zalozene na kopirovani zivych objektu z jedne casti heapu do jine (ted zjednodusuji). [...] Resenim pravepodobne budou pauseless GC, jeden se ted prave vyviji, uvidime pristi rok.
To měl být opravdu jenom ilustrační příklad, jak vlastnosti jazyka můžou mít dalekosáhlé důsledky pro VM. Jestli by něco principielně podobného mohlo nastat u nějakého jazyka nad JVM (změna oproti javě), to neumím posoudit. Jenom jsem chtěl říct, že čistě hypoteticky si to představit umím.

P.S. nedávno jsem se díval na špičkovou přednášku na téma JVM, to by někoho mohlo zajímat: http://www.youtube.com/watch?v=d2XcO8LQe_s

Erlang ma tedy GC zalozeny na pocitani referenci?
Pokud vím, tak v principu ano. Asi s nějakými vychytávkami navíc, nevím, nikdy jsem to nepotřeboval řešit.

Ale musi resit fragmentaci heapu ne? nebo to nechava "konovi" jako dalsi jazyky?
No tak hlavně heap je per-proces a velká část erlang-procesů má v typickém programu krátký život. Takže spousta heapů se prostě zahodí s koncem života procesu. Víc řešit je potřeba jenom dlouhotrvající procesy, které alokují větší množství paměti. Jak přesně to probíhá, nevím, určitě to půjde vygooglit. A pokud jde o alokaci paměti pro jednotlivé procesy z celkového poolu, tak to taky nevím :) Ten příklad jsem dal jako fakt jenom ilustraci principu, GC jsem v Erlangu nikdy řešit nepotřeboval, protože mi prostě nikdy klacek pod nohy nehodil (jediná výjimka jsou nebezpečné memory leaky přes substringy, podobně jako v javě, ale to se mi taky nikdy osobně nestalo, jen jsem o tom četl, že je potřeba si na to dát pozor...)

omg

Re:Proč je Java pomalá a problémová?
« Odpověď #147 kdy: 19. 12. 2013, 09:21:34 »
A jak dlouho se bude jeste vyvijet nez bude pouzitelny?

google. nastroje vyhledavani. a nastavit datum "do". nechce se mi hledat prvni datum, ale vsadil bych si snad uz nekde okolo 1996

1. 2. 2001 - The Java HotSpot VM provides a garbage collector that .....

Vyvoj zacal vloni, az se objevil HW, kde to ma smysl, proc se ptas? GC v Jave a vlastne i vsechny GC jsou tady s nami dele nez dnes mainstreamove jazyky, neustale se vsak upravuji tak, aby reflektovaly vlastnosti noveho HW.

ptam se proto, ze myty o funkcnim pausless garbage collectoru jsou na poradu dne snad vic jak 15 let. existoval and uz od prvni verze jvm jenze byl v experimentalnim stavu, takze na produkcni nasazeni nepouzitelny - mem corruption asi kvuli spatnemu zamykani, cekem caste pady a zridka kdy i nejaky ten livelock nebo deadlock.

mimo to, kdyz uz nahodou mel svetlou chvilku a fungoval, tak mel ze vsech GC nejhorsi skalovatelnost. s lineranim rustem vytizeni aplikace vytezoval HW exponencialne, takze byl naprosto neplanovatelne nepredvidatelny.

Re:Proč je Java pomalá a problémová?
« Odpověď #148 kdy: 19. 12. 2013, 09:23:08 »
Ale vždyť to je právě ten celkový uživatelský dojem. Jaký v tomto kontextu rozdíl mezi kešováním a paralelizací, kterou jste uváděl vy?
Paralelizovatelnost je vlastnost algoritmu a jeho konkrétní implementace, která je zase závislá na možnostech jazyka. Cachování je jenom berlička, jak dosáhnout toho, aby špatné chování aplikace zvenku nebylo vidět. Ale to je fuk, to fakt není důležitý, nechme to být.

S čím to porovnávají?
Nemluvím o žádných metrikách, čistě o tom, že admini, kteří se o javové aplikace starají, na to docela nadávají. Ale je to čistě subjektivní a vzorek lidí, který jsem slyšel, je samozřejmě malý. Právě proto by mě zajímalo, jestli třeba neproběhl nějaký výzkum ala "spokojenost adminů s provozováním javových aplikací" ;)

Bylo zmíněné Eclipse. Tak můžeme vzít čtveřici Eclipse, IntelliJ Idea, NetBeans, Visual Studio. [...] Ale nás zajímá uživatelská zkušenost s výkonem těch aplikací. Je mezi nimi evidentní rozdíl v rychlosti, paměťové náročnosti? Neřekl bych.
Před několika lety jsem trochu v javě něco dělal a čistě subjektivně mi NetBeans přišly daleko svižnější než Eclipse, který na mě působil jako děsný moloch. Ale to nám o javě jako takové nic moc neříká :)

Přesně tam myslím ta debata předtím Android je To by znamenalo nový OS. A nových OS vzniká málo tak nějak obecně. Naopak se počet OS snižuje
Podle mě nové OS nevznikají, protože je to složité, nic moc to nepřinese a v nejhorším případě je to i nekompatibilní s dosavadními aplikacemi. Až na to první by to pro "JVM OS" neplatilo.

Je na tom také vidět, že přidávání vrstev do toho „klasického stacku“ má vzhledem k celku čím dál menší režii. Dnes už nevadí provozovat nad HW operační systém, nad ním virtuální počítač typu VMware, nad ním virtuální stroj typu JVM a z toho všeho provozovat aplikaci přes internet. Důvod, proč se to nesloučí do jednoho, je podle mne čistě v tom, že ušetřený výkon by byl zanedbatelný (a čím dál menší), ale náklady na vývoj a následnou údržbu obrovské.
To je pravda.

Pavel Tisnovsky

Re:Proč je Java pomalá a problémová?
« Odpověď #149 kdy: 19. 12. 2013, 09:29:25 »
No tak hlavně heap je per-proces a velká část erlang-procesů má v typickém programu krátký život. Takže spousta heapů se prostě zahodí s koncem života procesu. Víc řešit je potřeba jenom dlouhotrvající procesy, které alokují větší množství paměti. Jak přesně to probíhá, nevím, určitě to půjde vygooglit. A pokud jde o alokaci paměti pro jednotlivé procesy z celkového poolu, tak to taky nevím :) Ten příklad jsem dal jako fakt jenom ilustraci principu, GC jsem v Erlangu nikdy řešit nepotřeboval, protože mi prostě nikdy klacek pod nohy nehodil (jediná výjimka jsou nebezpečné memory leaky přes substringy, podobně jako v javě, ale to se mi taky nikdy osobně nestalo, jen jsem o tom četl, že je potřeba si na to dát pozor...)

Aha jasny, ono to asi pro kratkodobe procesy je jednodussi, hlavne kdyz neni zapotrebi resit cyklicke reference (ani ne tak jednoduche smycky typu A->B, B->A, ale slozitejsi struktury). Ja jsem taky pomerne dlouho myslel, ze GC v JVM jsou zbytecne slozite (+ se nechava prace na GC i u objektu, jejichz zivotnost je evidentne jen mala - blok, metoda), ale ono je to tak prave z tech tri zminenych duvodu: 1) rychla alokace pameti posunem pointeru, 2) alokace per thread, 3) kompaktni heap, takze tam nastupuje to problematicke kopirovani objektu + zastavovani aplikacnich threadu v dobe GC. Pauseless GC se ted vyviji hlavne z toho duvodu, aby se eliminovalo reseni typu stop-the-world u GC, coz je cim dal tim vice problematicke v dobe rekneme >4 jader.

 

reklama