Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Nikdy jsem 1. start neměřil, ale u java apletů v browseru to docela trvá.Když tu unixovou utilitu budete před startem ještě stahovat (ehm, dokonce dvakrát, jestli ten uleželý bug stále neopravili) z internetu, také to bude docela trvat.
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.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.
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ř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.
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.
Platforma s tenkou vrstvou pro JVM se neujala protoPíšete o Androidu, že? Takže proč že se to neujal?
Například dneska se do každé ledničky tahá web browser a nikdo nebude platit za hardware pro případného bumbrlíčka v Javě, když může mít nativní Operu a ušetřit tak USD.A proto je ve spoustě těch zařízení Android. Aha.
Mně právě přesně takový přišel: "I cizí "velké" java aplikace mi dělají problémy více, než jiné (jdownloader, eclipse, android) pády, záseky, lagy... "Tohle je ale přece přesně o tom „hrubém výkonu“. Co chcete masivně paralelizovat na JDownloaderu, eclipse, Androidu? Pokud chcete porovnávat celkový uživatelský dojem – má někdo tyhle zkušenosti (pády, záseky, lagy) třeba s GMailem?
já jsem to pochopil jako "proč když vidím, že je něco napsané v javě, očekávám, že to bude obrovský moloch s velkými nároky na paměť, nevyrovnaným výkonem atd.?"Na to je jednoduchá odpověď – protože to takhle na internetových diskusních fórech lidé píšou. Co na tom, že to nemají podložené vlastními zkušenostmi, ale jen to navzájem opisují jeden od druhého…
Aniž bych do javy viděl, předpokládám, že JVM je taková obdoba cpu instrukční sady a java je prostě jazyk nad tou sadou. Takže jazyk je určitě limitovaný sadou, ale ne naopak - tj. pokud by byla pravda, že aplikace v javě jsou naprd, neplyne z toho, že je naprd JVM, protože můžou (aspoň teoreticky) existovat jazyky, které nad JVM budou v celkovém dojmu pracovat líp.Java je assembler nad tou instrukční sadou, překládá se vpodstatě přímočaře do Java bajtkódu. Nějaký prostor, co by bylo možné s JVM dělat lépe ale v Javě to nešlo, tam prakticky není. Jiné jazyky mohou přidat svou runtime knihovnu a přidat do svého jazyka konstrukce, které tohle budou používat, takže to programátora povede k psaní lepšího kódu. Ale není to nic, co by v samotné Javě nešlo napsat. Záleží tedy na tom, zda se bavíme o tom, co je možné, nebo co je běžné.
Samoztnýho by mě tohle zajímalo - jestli existují nějaká solidní data ohledně _průměrné_ efektivity, stability, bezpečnosti atd. atd. javových aplikací versus průměrných aplikací postavených na něčem jiném.Obávám se, že by to stejně nebylo porovnatelné – protože průměrná javovská aplikace bude něco jiného, než průměrná aplikace napsaná v něčem jiném. Jedině si vzít nějakou kategorii aplikací, kde se vyskytují aplikace obojího druhu – samozřejmě s tou výhradou, že závěry nebude možné aplikovat na jiné druhy aplikací. Třeba by se takhle mohly porovnat webové servery – Apache, Nginx, IIS, Jetty, Tomcat, něco postaveného na Netty (třeba server Avastu). I v téhle kategorii je každý určený na něco jiného, ale určité srovnání by se udělat dalo.
To je dobrá připomínka - proč vlastně všchny "JVM-only" operační systémy zkrachovaly.Záleží na tom, čemu říkáte operační systém. Pokud myslíte systém ovládající hardware jednoho počítače, pak máte pravdu. Pokud myslíte základní prostředí, ve kterém běží aplikace, nějakou platformu – tam je to přesně opačně. Existují platformy pro Javu, Python, .NET, PHP (to je vlastně průkopníkem tohoto směru), ale pro C nebo C++ byste hledal těžko. Jistě že ty PaaS jsou provozovány na nějakém skutečném operačním systému, který běží na fyzickém hardwaru. Ale o tom aplikace vůbec neví.
Úvodní dotaz takový určitě nebyl. A pokud by se o tom diskutovalo, tak se přece nediskutuje o programovacím jazyce, ale o platformách a architekturách. Celkový dojem z aplikace GMail přece vůbec nezávisí na tom, že backend je napsaný v Javě, ani na tom, v čem je napsaný GWS.Jenže tenhle typ výkonu je úplně něco jiného, než o čem se tu celou dobu diskutujeJá jsem tu diskusi pochopil tak, že lidi zajímá celkový "dojem z aplikace" a ne srovnávání nějakých abstraktních algoritmů v ideálních podmínkách...
Myslíte jako že vezmu C/C++ kód a nasadím ho do nějaké PaaS jako Google App Engine, Microsoft Azure Platform, Heroku? Byl by příklad takové platformy?Tenhle výkon se dnes často řeší cloudy, kde naopak vládnou jazyky používající virtuální stroje a C/C++ prohrává na celé čáře.you wish... https://news.ycombinator.com/item?id=5118070
Výkon aplikací ale není jenom o hrubém výkonu, ale taky o tom, jak je to napsané. Např. proto, že se to dá líp nebo hůř paralelizovat. A to už s jazykem souvisí setsakramentsky...Jenže tenhle typ výkonu je úplně něco jiného, než o čem se tu celou dobu diskutuje (i když je to – na rozdíl od toho diskutovaného – výkon, kterým se má smysl zabývat). Navíc tenhle výkon závisí hodně na architektuře aplikace, na tom, jak je naprogramovaná… Tenhle výkon se dnes často řeší cloudy, kde naopak vládnou jazyky používající virtuální stroje a C/C++ prohrává na celé čáře.
Tahle teze se velmi lehce vyvrátí - stačí porovnat tyhle parametry u různých jazyků nad JVM.Všechny jsou stejně rychlé nebo pomalejší, než Java, a všechny jsou paměťově stejně náročné nebo náročnější než Java. Ono opravdu těžko vykouzlíte něco rychlejšího než assembler pro danou instrukční sadu. Jediná instrukce JVM, která nemá obraz v Javě, je invokedynamic, která se objevila až ve verzi 7. Jinak veškerý kód z těch jiných jazyků nad JVM můžete přeložit zpět do Javy – a tím se těžko zpomalí.
JVM určitě je jeden z nejvyladěnějších VM. Ale jednak JVM =/= javaVýtky k rychlosti nebo paměťové náročnosti se ovšem mohou týkat výhradně JVM, nikoli Javy jako jazyka. Ostatně Java jako jazyk je vlastně jen assembler pro JVM, takže tam výkonnostně proti samotnému JVM není co zkazit.
jednak to bude určitě do velké míry marketingové rozhodnutí spíš než technické (proč by nabízeli engine pro jazyky, které nikdo nepoužívá?)Stejně ale platí, proč nabízet engine pro prostředí (JVM), které nakonec bude neefektivní a nikdo to nebude používat?
Díky, Filipe. Ale žádná z těch zmíněných věcí není v té oblasti majoritní hráč, ne?V případě Jabber serverů jsou myslím tři nejpoužívanější – ejabberd, jabberd a OpenFire (v tomto pořadí). Ty javovské relační databáze se používají hlavně s java aplikacemi, často jako embedded databáze, čímž trochu tvoří svou vlastní oblast. Možná by se daly srovnávat s SQLite. Samozřejmě je to jiná liga, než velké databáze typu Oracle nebo PostgreSQL – ale tam je to do jisté míry dané také tím, že ty databáze jsou starší, než Java, a lidé, kteří tyhle databáze programují, se najednou nerozhodnou, že začnou s novou databází na zelené louce a v jazyce, který do teď neznali.
RDBMSH2, Derby
nosqlNeo4j, Voldemort, HBase
jabber serveruOpenFire
no kazdopadne je zatim ten dojem z vykladnich skrini ponekud rozpacity...par utilit a klientu,jedna sice prulomova (ale ne po technicke strance) hra, par request/response serveru co spis zatizi I/O a ne CPU...zatim byste me panove nepresvedcili ze se v jave da napsat neco velkeho a vykonneho:-)Asi byste měl nejprve sám vyjmenovat pár takových aplikací napsaných v C++ nebo čemkoli jiném. Ať víme, kam míříte. Zatím je to totiž takové „uhodněte, na co myslím“, vůbec není jasné, co myslíte tím „velké a výkonné“.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.