Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: JardaRN 14. 12. 2013, 16:02:30
-
Chápu, že interpretovaný jazyk bude vždy pomlejší. Ale subjektivně mi přišlo, že java, i když už je s námi velmi dlouho, je stále nejnefektivnější a nejproblémovější prostředí vůbec. Kdysi jsem v tom něco i programoval, ale vždycky to bylo takové divné. Jinak dělám C a ASM na železe, v poslední době C# na pc (ať už .net nebo mono). Poslední jmenovaný mě nadchnul, vzhledem k tomu že je v principu podobný javě, zdá se mi daleko lépe funkční a rychlejší.
I cizí "velké" java aplikace mi dělají problémy více, než jiné (jdownloader, eclipse, android) pády, záseky, lagy... všude se to chová stejně "divně". Zdá se i zvláštní, že tyhle problémy jsou i po letech existence. Je snad nějaký zásadní problém už v konstrukci jazyka? Do hloubky tomu nerozuním, ale rád bych se dozvěděl více.
-
Mas pravdu, nerozumis tomu. Pro jedno uziti je Java rychlejsi nez C, pro jine naopak. Flame muze zacit.
-
vvv:
Java rychlejší než C, netuším na čem jedeš ale chci to taky.
-
Není ani pomalejší ani problémovější. Jako jazyk je z mainstreamu jeden z nejlepších na obecné problémy, takže nečekej, že ti tu bude někdo psát, jak je špatný a nikde se nepoužívá. Že dneska programuje kdejaký lempl a tobě padají jeho aplikace? I to se stává.
-
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.
-
Mícháš hrušky s jabkama. To, že standardní toolkit pro GUI aplikace (Swing použitý Downloaderu) stojí za houby, nebo že konkrétní aplikace je pomalá a zabugovaná (Eclipse), rozhodně neznamená, že je špatný samotný jazyk. A Android bych do toho nemíchal, to je kapitola sama pro sebe.
-
Ok, a příklad nějaké aplikace která je rychlá a bezproblémová? Tohle není jenom můj postřeh, ale spousty dalších lidí. Takře asi to nejaký základ má, ne?
-
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ě!
-
Nebo třeba IntelliJ Idea a jejích klony pro jiné jazyky se mi zdají také jako velmi dobré aplikace. Že by byla paměťově úspornější a rychlejší při psaní v C? Jistě, ale také by by byl vývoj výrazně pomalejší/dražší/...
Ale Java má velké zastoupení podle mě hlavně při psaní aplikací na míru (různé bankovní systémy, informační systémy firem apod.). Tam jednoznačně převáží rychlejší vývoj (a výhody plynoucí z GC apod.) nad potřebou dokoupení více RAM nebo rychlejšího CPU, protože počet běžících instancí takové aplikace je poměrně malý.
-
Ja to skôr vidím na pokus o flame prameniaci z frustrácie kvôli nedostatočnému, respektíve s Java programátormi neporovnateľnému finančnému ohodnoteniu. Lepíš nejaké Céčko za 15 v hrubom mesačne?
-
java se podle mejch zkusenosti taky dobre ladi (spoustu beznych bugu uz nepusti prekladac)
a imho taky jako vyvojar se nemusis zabejvat optimalizaci pro kazdou platformu - todle za tebe udela JVM
-
Ja to skôr vidím na pokus o flame prameniaci z frustrácie kvôli nedostatočnému, respektíve s Java programátormi neporovnateľnému finančnému ohodnoteniu. Lepíš nejaké Céčko za 15 v hrubom mesačne?
To je docela trapný útok na autora. Třeba kolem JEE je plno hloupých lepičů za obrovské peníze. Z toho pak plynou i ty prasárny, které se vyčítají často PHP. U Javy je to ale schované pod kapotou, jen to funguje hodně příšerně.
-
Ok, a příklad nějaké aplikace která je rychlá a bezproblémová? Tohle není jenom můj postřeh, ale spousty dalších lidí. Takře asi to nejaký základ má, ne?
Java se používá především pro rozsáhlé serverové aplikace jako jsou bankovní a informační systémy, u kterých ty jako uživatel nemáš moc šanci poznat, v čem jsou vlastně napsané.
Desktopové aplikace jsou u Javy minoritní záležitost, právě z toho důvodu, že javovské GUI frameworky nejsou moc dobré.
-
"Kdysi jsem v tom něco i programoval", ale vím, že to je na hovno.
... to asi nemá ani cenu komentovat, ne ?
-
I cizí "velké" java aplikace mi dělají problémy více, než jiné (jdownloader, eclipse, android) pády, záseky, lagy... všude se to chová stejně "divně". Zdá se i zvláštní, že tyhle problémy jsou i po letech existence. Je snad nějaký zásadní problém už v konstrukci jazyka? Do hloubky tomu nerozuním, ale rád bych se dozvěděl více.
Zásadní problém je ten, že se Java používá na účely pro které nikdy nebyla určena a není na to vhodná. Hlavní motivace ke vzniku Javy bylo mít drobné aplikace v bytecode přenositelném beze změny mezi malými počítači, nebylo to zamýšleno na desktopové aplikace a už vůbec ne na molochy jako Eclipse.
Co se týká výběru, tak volba nástroje se provádí podle toho co chceš vyvíjet, například v C+ASM asi nebudeš dělat webové stránky.
-
len jeden priklad http://www.opencloud.com/products/rhino-application-server/jslee-application-server/objectives-of-jain/
-
I cizí "velké" java aplikace mi dělají problémy více, než jiné (jdownloader, eclipse, android) pády, záseky, lagy... všude se to chová stejně "divně". Zdá se i zvláštní, že tyhle problémy jsou i po letech existence. Je snad nějaký zásadní problém už v konstrukci jazyka? Do hloubky tomu nerozuním, ale rád bych se dozvěděl více.
Zásadní problém je ten, že se Java používá na účely pro které nikdy nebyla určena a není na to vhodná. Hlavní motivace ke vzniku Javy bylo mít drobné aplikace v bytecode přenositelném beze změny mezi malými počítači, nebylo to zamýšleno na desktopové aplikace a už vůbec ne na molochy jako Eclipse.
Co se týká výběru, tak volba nástroje se provádí podle toho co chceš vyvíjet, například v C+ASM asi nebudeš dělat webové stránky.
No nevím, v roce 1995, vyvinutá Sun Microsystems... jaká přesně "malá zařízení" - možná tenké klienty? Je pravda že přenositelnost bytecode byla od začátku zásadním požadavkem. Ale nesalo se (protože se ty tenké klienty před tablety vůbec neujaly) Pokus udělat z toho univerzální jazyk pro programování mobilních aplikací taky ztroskotal - samotná myšleka profilů není špatná, ale problém je že je to přesně něco o co velcí hráči nemají skutečný (nemluvím o verbálním) zájem... stejně jako o HTML 5 a webové aplikace, mimochodem.
-
Chápu, že interpretovaný jazyk bude vždy pomlejší. Ale subjektivně mi přišlo, že java, i když už je s námi velmi dlouho, je stále nejnefektivnější a nejproblémovější prostředí vůbec.
To je naštěstí pouze Tvůj subjektivní dojem. Zkus si něco o té platformě zjistit, Java není interpretovaný jazyk (kód se zkompiluje před zpuštěním aplikace, když se některá funkce provádí častokrát, tak se po čase zkompiluje s brutálními optimalizacemi a hot-swapne - sorry, ale tohle není interpretace).
Kdysi jsem v tom něco i programoval, ale vždycky to bylo takové divné.
Tato platforma (stejně jako každá jiná) má svá specifika (viz třeba kniha Java Puzzlers). Stejně tak fakt, že díky zpětné kompatibilitě jsou přístupná i zastaralá API (např. java.io -> java.nio -> java.nio2 pro práci se souborovým systémem), se v ní může ze začátku těžko orientovat. Pokud ta specifka neznáš nebo nevíš, která API jsou moderní a která ne a která spolu vycházejí dobře a která ne, může Tě to pěkně vyliskat a to se taky asi stalo :-) . Smutná zpráva je, že nejsi sám, naopak, znám armádu lidí, kteří jsou _placení_ za to, že je JVM/.Net vyliskává za jejich neschopnost a neznalost, čímž vytvářejí šílené prasárny a berou za to těžký prachy.
Např. nedávno jsem viděl, že architektovi přišlo, že třída mající 50.000 řádků C# kódu je příliš velká (byla to nějaká Utils třída - univerzální třída na všechno, anglicky se tomuto architektonickému vzoru říká "fucking big bucket of shit"), tak ji rozdělil do asi 10 partial class. Tohle je bohužel realita běžného korporátníhho života a dokud budou ze strany manažerů tlaky na co nejnižší cenu a manažeři nebudou problematice dostatečně rozumět (minulý týden jsem slyšel projekťáka z jiného oddělení, že "přímé přístupy do databáze ze zobrazovací vrstvy jeho týmu nikdy nepřinesly zvýšené náklady na údržbu, naopak zavedení návrhových vzorů jako MVC nesmyslně prodražilo projekt, protože developeří se museli s těmito vzory seznamovat a obcházet jejich nedokonalosti"), nebudou mít lidi motivaci se učit psát dobře a budou vznikat prasárny. A právě prasečiny jsou hlavním důvodem, proč jsou v případě Javy aplikace ze strany uživatele naprd.
-
No nevím, v roce 1995, vyvinutá Sun Microsystems... jaká přesně "malá zařízení" - možná tenké klienty? Je pravda že přenositelnost bytecode byla od začátku zásadním požadavkem.
Java (neúspěšně) existovala již několik let před tím a teprve s myšlenkou užití na PC se dostala do širší známosti. Hlavní myšlenka použití Javy na PC bylo skriptování v prohlížeči, tam kde je dneska Javascript, ovšem bylo to fiasko nevídaných rozměrů.
-
Proč je Java pomalá?
Nie je.
Proč je Java problémová?
Nie je.
--
Aspon nie viac, ako C alebo C++, kde treba robit optimalizacie a zmeny pre kazdu platformu.
-
Chápu, že interpretovaný jazyk bude vždy pomlejší. Ale subjektivně mi přišlo, že java, i když už je s námi velmi dlouho, je stále nejnefektivnější a nejproblémovější prostředí vůbec.
To je naštěstí pouze Tvůj subjektivní dojem. Zkus si něco o té platformě zjistit, Java není interpretovaný jazyk (kód se zkompiluje před zpuštěním aplikace, když se některá funkce provádí častokrát, tak se po čase zkompiluje s brutálními optimalizacemi a hot-swapne - sorry, ale tohle není interpretace).
Nechci se plést do flame, ale tohle mi nedalo. Vždy jsem všude četl, že je Java interpretovaný jazyk a překládá se do tzv. bytekódu, podíval jsem se na Wikipedii a ta se mnou souhlasí. Na druhou stranu také popisuje technologii JIT (o které jsem dosud nevěděl), která trošku odpovídá tomu co říkáte, ale ne vždy na Wikipedii bývá vše správně. Můžete fakt, že Java není interpretovaný jazyk trošku rozvést? Tohle by mě konkrétně docela zajímalo, protože jsem si vždy myslel pravý opak. Děkuji předem.
-
Program v Javě je v přenositelném bytekódu (nejen co se týče OS, ale i co se týče HW platformy - architektury CPU). Nicméně moderní JVM si za běhu exponované části kódu optimalizují a kompilují do nativního kódu.
-
Neřekl bych, že existuje vyloženě špatnej programovací jazyk. Každý má svoje výhody a nevýhody.
Nevýhoda Javy určitě bude poměrně velká náročnost na systémové zdroje. Velká výhoda snadná přenositelnost kódu.
Co existuje zcela jistě jsou špatný frameworky, hotové komponenty a programátoři.
Já osobně bych se přiklonil k jazyku C, jenže to má smysl jen na core věci (protože není efektivní na vývoj).
Čím méně se část kódu používá - tím spíš může být v nějakém vysokoúrovňovém jazyce.
-
Co se týká výběru, tak volba nástroje se provádí podle toho co chceš vyvíjet, například v C+ASM asi nebudeš dělat webové stránky.
Kámoš robí web v C++ http://cppcms.com/wikipp/en/page/main a mongodb, lebo táto kombinácia zvláda 3000 requestov sa sekundu a vývoj je iba 2x pomalší ako v Nette.
Pre autora. Skúsil si IntelliIdea namiesto Eclipse? :)
-
Vždy jsem všude četl, že je Java interpretovaný jazyk a překládá se do tzv. bytekódu
Zjednodušeně: soubory s příponou .class, tedy to, co vyleze z kompilátoru, jsou bytecode. Je možné, že některé JVM se k něm chovají jinak, ale ta od Oraclu vždy při spuštění programu překládá bytecode do nativního kódu (JIT) dané platformy (proto trvá déle, než se program spustí) a také při běhu programu kritická místa optimalizuje.
Srovnej to PHP - tam se při každém spuštění probíhá celá kompilace znovu, u Javy je většina práce již hotová překladem do bytecodu.
-
Protože je špína zažraná!!! ;D
-
Java bude pomalá a náročná, když se na ní budou provozovat věci, které jsou napsané nevhodným způsobem (Swing). I v takovém případě může být vhodnější než C. Nedávno jsem si kupoval IntelliJ IDEA Ultimate. Ano, je to aplikace ve Swingu a žere nějakou RAM. Ale kolik by stálo srovnatelné IDE v jazyce C?
Java bude pomalá, když se bude špatně používat. Například časté starty a ukončení v režimu server. (Na Oracle Javě pod x86_64 fakticky jediná možnost.) V režimu client bude taky pomalu startovat, když nebude fungovat Class Data Sharing (otázka jednoho příkazu po instalaci, ale na některých Linuxových distribucích to není/nebylo automatické). Ale start Javy, jakkoli se s tím dá bojovat, nebude asi nikdy rychlý. Leda na speciálních JVM (JamVM, Avian, na Androidu nově libart), ale je potřeba mít představu, kde jsou přednosti/slabiny těchto JVM. Někdy pro rychlost startu pomůže vynutit režim interpretu. Pokud jde o výkon, hlavní oblast Javy je v dlouho běžících aplikacích.
Například JRuby je pomalé, pokud jen na aplikaci zavoláme --help. U dlouhodobě běžících aplikací je ale prý typická optimalizace použít JRuby místo Ruby MRI.
Java bude žrát hodně RAM, pokud je ta RAM k dispozici a pokud se nenastaví velikost heapu. Měl jsem malou aplikaci, která hledala nějaké řešení nějakého problému. Potřebovala O(sqrt(n)) RAM vzhledem k době běhu (čistě vlastnost algoritmu). Doma mi po několika hodinách nežrala ani 100MiB. Na školním serveru to velmi rychle šlo do gigabajtů. Řešení bylo velmi jednoduché - nastavit pravidla pro heap. Na stroji se 128GiB RAM si totiž Java vzala velký heap...
Napsal jsem aplikaci s použitím Play frameworku a jako server jsem dočasně použil Raspberry Pi. (Starší verze s 256MiB RAM.) Prvně se odmítla spustit, protože výchozí heap byl asi 384MiB RAM. No co, nastavil jsem tomu 64MiB (s velkou rezervou, jak jsem zjistil později) a jelo to výborně. Nepoznal jsem subjektivně na výkonu, jestli to běží na notebooku, nebo na Raspberry Pi v místní síti. (Sice místo Javy byla použita z velké části Scala, ale pořád to je na JVM a výkonově je to velmi blízko.)
Naopak Owncloud s PHP-FPM a APC jel na Raspberry Pi dost pomalu. Pravda, zavání to hruškojablkem a je taky fakt, že PHP je prakticky univerzální odpověď na "Znáte něco pomalejšího?". Ale jako jeden z mnoha způsobů, jak ukázat, že Raspberry Pi není zrovna nejvýkonnější (jinde byl Owncloud OK, i na levné VPS), to stačí.
-
Můžete fakt, že Java není interpretovaný jazyk trošku rozvést? Tohle by mě konkrétně docela zajímalo, protože jsem si vždy myslel pravý opak.
Java je interpretovana, protoze ke svemu behu potrebuje interpretr. Tento samotny fakt je ovsem na urovni diskuse zde zcela nepodstatny, protoze vetsina diskutujicich ma o jave v nejlepsim mlhave predstavy. Pomalost javy oproti C je v nekterych pripadech objektivni (napr. nelze pracovat v takove mire primo s alokovanou pameti) a v nekterych subjektivni - v jave je totiz schopny napsat fungujici program i programator, ktery by v C stezi sesmolil hello world a takovi obvykle nepisi efektivni algoritmy (a pak zadna JIT kompilace nepomuze). V neposledni rade jsou zde bumbrlicci typu Swing, s tim mam zkusenost minimalni, tak to nebudu hodnotit.
-
Java ma oproti nejakemu big ass kompilovanemu programu (office a pod) jednu nevyhodu - nedaju sa pamatovo mapovat .dll. Samotny microsoft ma tooly na optimalizaciu rozmiestnenia kodu, ked mozes napr. kod pouzivany pri starte umiestnit pri linkovani co najblizsie k sebe. Pri starte sa namapuje sice cele dll, ale vypadok nastane len pre par stranok. Su tam este ine optimalizacie na systemovej urovni.
Java naproti tomu musi otvorit jar a nacitat z neho triedu do pamate a zJITovat to. Toto sa myslim snazi riesit class sharing, ale je to podla mna polovicate riesenie, lebo tam nie su automaticky vsetky triedy vsetkych java aplikacii co pouzivas.
Dalsia vec je nastavenie pamate - zere to vela, ale stacilo by menej? Obmedzis heap, no problemo. Ale az to fakt bude potrebovat viac, tak sa to zacne zasekavat z castych behov GC, alebo to rovno padne.
Co sa tyka C/C++ -plati to co odznelo. Napr. chrome ma uz par rokov memory leak (vidiet to na notebooku ktory restartujem tak raz za 2 mesiace), openoffice sa pomaly startuje a oproti ms officu je celkovo molochovejsi, okrem toho tie aplikacie tiez obcas padaju. Pisat webserver v C? Preco nie. Pisat web aplikaciu v C? Koledujes si o memory leaky, buffer overflow chyby atd, bude ti to trvat dlhsie a kolko ludi skutocne potrebuje napisat web co zvlada 3000req/s?
Vit kolko si zhltne ten play? Nasiel som nejake cisla ktorym sa mi celkom nechcelo verit..
kuka: je rozdiel medzi interpretom a VM. VM je sw CPU. Zjavne mas o jave mlhave predstavy ty.
-
Soubory *.class/*.jar (příp. *.dex/*.apk, princip je podobný) potřebují k běhu nějakou JVM, to ano. Ale to zdaleka nemusí být interpret. Jsou jiné možnosti:
* JIT - za běhu se to kompiluje do nativního kódu (běžně podporované v Oracle Javě)
* AOT - před spuštěním se to zkompiluje do nativního kódu (umí např. Avian, případně u "Androidí Javy" zmíněný experimentální libart na KitKatu, používají to také některé starší mobily s J2ME)
* nějaká kombinace (používá se na Oracle Javě)
K omezení heapu: dá se to nastavit i trošku dynamicky, kdy si aplikace v případě potřeby vezme víc. Je s tím rozšiřováním heapu sice nějaký overhead a na serveru bych spíš doporučil napevno, ale možné to je.
K Play2: V production mode výrazně méně. Záleží samozřejmě, co na tom chceš provozovat a s kolika uživateli. Mám ale pocit, že jsem to dostal i někam do řádově 10-15MB.
Na druhou stranu, v development mode (kde jsou v paměti i kompilátory, Rhino apod.) to může být třeba 1GB. Což na dnešních strojích nemusí být problém, ale píšu to, aby to nebylo nějaké překvapení.
Jinak i na Play1, které IMHO žere víc, mi žere víc MySQL než Play.
-
[kuka] ne, Java nepotrebuje ke svemu behu interpret, dokaze primo prekladat volbou -Xcomp, ale vetsinou je lepsi ponechat toto rozhodnuti na Hotspotu - zalezi na nastaveni provedene programatorem a administratorem (to za vas nikdo neudela, stejna jako v jinych programovacich jazycich ;). Jak uz tady nekolikrat zaznelo, velky promblem Javy je v tom, ze v ni prasi spousta takyprogramatoru a potom z toho vychazi pomale aplikace. Sice me prekvapuje zrovna problem s Eclipse, ja to hodne dlouho poustel na pocitaci 256 MB, ted upgrade na 512 MB a uplne bez problemu, ale samozrejme pokud tam nekdo naseka dalsich 20 pluginu, tak neco muze byt spatne (zakladni Eclipse JDT je vsak v poradku, vsak to denodenne pouzivaji desetitisice lidi, spis jeste vic).
-
No tak taketo cisla som nasiel a hovorim, ze som neveril :). Provozovat nic neplanujem, len som si tak rozsiroval obzory...
Inak AOT ma aj mono.
-
Ono je to vůbec špatně položená otázka, abych citoval klasika. Co je to pomalá Java? Pomalý JVM, pomalý (špatně napsaný) program, pomalý komp?
-
https://github.com/flatland/drip
-
ne, Java nepotrebuje ke svemu behu interpret, dokaze primo prekladat volbou -Xcomp
To je ovsem prave volba az toho interpretru - JVM kod interpretuje, zda ho v ramci toho prelozi a na co neni az tak podstatne, podstatne je, ze bez JVM se to neobejde.
-
Vacsina programov v Jave je pomala pretoze su neoptimalizovane. Keby sa optimalizovali tak ako napr. Minecraft, tak by sa rovno mohli napisat v C/C++. Inak aj v Jave sa daju jednoducho vytvorit memory leaky, a nezabrani tomu ani GC.
-
ne, Java nepotrebuje ke svemu behu interpret, dokaze primo prekladat volbou -Xcomp
To je ovsem prave volba az toho interpretru - JVM kod interpretuje, zda ho v ramci toho prelozi a na co neni az tak podstatne, podstatne je, ze bez JVM se to neobejde.
Prave ze ne :-) JVM nacita bajtkod a ihned ho v tomto pripade transformuje na nativni kod, v rezimu interpretace se vubec nenachazi, dokonce bych rekl, ze by se dal cely interpret z libjvm.so/jvm.dll vyhodit (ale to musim napred vyzkouset).
Ale myslim ze uz chapu jak to myslite: ze z Javovskeho programu nikdy neni samostatna binarka, ale .class/.jar zavisly na JVM zejo? Ano obecne je to tak, ono JVM toho dela o dost vic nez jen interpretaci/JITovani/transformaci bajtkodu, takze to uplne odriznout obecne nepujde. Na druhou stranu JE mozne prekladat .java primo do objektovych souboru (.o/.obj) a slinkovat to do spustitelne binarky, ale to plati jen pro subset vlastnosti JVM. Prikladem je gcj nebo predkompilace v Androidu (ovsem Hotspot na x86 je dneska uz tak daleko, ze zrovna tady vykon aplikaci asi nenazeneme :-)
-
aj v Jave sa daju jednoducho vytvorit memory leaky, a nezabrani tomu ani GC.
To je pravda, ale zásadní výhoda Javy je že v paměti je pořádek - jsou tam jasně identifikované konkrétní objekty a reference mezi nimi, takže mohou existovat nástroje jako například Eclipse Memory Analyzer které umožní rychlou analýzu a opravu memory leaků, a to i v cizím kódu. V klasickém C je memory leak ve velkém projektu díky typickému chaosu v paměti často téměř neřešitelný.
-
Pokud je Java pomalá, je špatně napsaný software, který nejspíš ani v Javě být neměl.
Znám na Javě mraky aplikací, který jedou jak po másle. Nemyslím aplikace na desktop, ale např. DMS Alfresco, na to že je to Java, je to dost rychlý.
-
To je ovsem prave volba az toho interpretru - JVM kod interpretuje, zda ho v ramci toho prelozi a na co neni az tak podstatne, podstatne je, ze bez JVM se to neobejde.
Na platformě AMD64 (a dalších) vezme procesor výstup kompilátoru C a přeloží jej do vnitřní instrukční sady, kterou používá výkonná část procesoru. Bez toho překladu se to také neobejde. V různých emulátorech (třeba i JavaScriptových) můžete spouštět "nativní" kód pro jiné platformy, který je emulátorem interpretován. Budeme proto nazývat C interpretovaným jazykem? Existovaly i nějaké procesory, které uměly vykonávat přímo javovský bajtkód. Pořád ještě chcete jazyky rozdělovat na interpretované a nativní a dělat z toho nějaké závěry?
-
Zajimalo by me, jak je to s tou prenositelnosti. Proc je teda ruzna verze java programu pro Linux, windouz, Mac? Proc to neni jeden program, ktery spustim kdekoliv? Dale existuje spousty java runtime - open java, Sun, IBM, Oracle, SAP... ruzne programy v java vyzaduji specificke runtime, na jinych nejedou. Take jsou vazany na konkretni knihovny v systemu. Takze z meho pohledu admina je to totalni chaos.
-
Zajimalo by me, jak je to s tou prenositelnosti. Proc je teda ruzna verze java programu pro Linux, windouz, Mac? Proc to neni jeden program, ktery spustim kdekoliv? Dale existuje spousty java runtime - open java, Sun, IBM, Oracle, SAP... ruzne programy v java vyzaduji specificke runtime, na jinych nejedou. Take jsou vazany na konkretni knihovny v systemu. Takze z meho pohledu admina je to totalni chaos.
Pokud program vyuziva JNI (rozhrani pro nativni knihovny), tak jsou ruzne verze pochopitelne. Prikladem je Eclipse, kde je nutne pouzit nativni SWT, zbytek Eclipse je vsak multiplatformni. 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. Napadaji me asi dva SW, jeden od *velmi velke firmy* na tri znaky, druhy od *taktez velke firmy* na dva znaky (no ta pomalu a uspesne zabiji sama sebe...), ale to neni vlastnost Javy, ale par prasatek...
-
Zajimalo by me, jak je to s tou prenositelnosti. Proc je teda ruzna verze java programu pro Linux, windouz, Mac? Proc to neni jeden program, ktery spustim kdekoliv? Dale existuje spousty java runtime - open java, Sun, IBM, Oracle, SAP... ruzne programy v java vyzaduji specificke runtime, na jinych nejedou. Take jsou vazany na konkretni knihovny v systemu. Takze z meho pohledu admina je to totalni chaos.
Pokud program vyuziva JNI (rozhrani pro nativni knihovny), tak jsou ruzne verze pochopitelne. Prikladem je Eclipse, kde je nutne pouzit nativni SWT, zbytek Eclipse je vsak multiplatformni. 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. Napadaji me asi dva SW, jeden od *velmi velke firmy* na tri znaky, druhy od *taktez velke firmy* na dva znaky (no ta pomalu a uspesne zabiji sama sebe...), ale to neni vlastnost Javy, ale par prasatek...
Myslite tu firmu, ktora umoznila vznik Eclipse?
-
Zajimalo by me, jak je to s tou prenositelnosti. Proc je teda ruzna verze java programu pro Linux, windouz, Mac? Proc to neni jeden program, ktery spustim kdekoliv? Dale existuje spousty java runtime - open java, Sun, IBM, Oracle, SAP... ruzne programy v java vyzaduji specificke runtime, na jinych nejedou. Take jsou vazany na konkretni knihovny v systemu. Takze z meho pohledu admina je to totalni chaos.
Pokud program vyuziva JNI (rozhrani pro nativni knihovny), tak jsou ruzne verze pochopitelne. Prikladem je Eclipse, kde je nutne pouzit nativni SWT, zbytek Eclipse je vsak multiplatformni. 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. Napadaji me asi dva SW, jeden od *velmi velke firmy* na tri znaky, druhy od *taktez velke firmy* na dva znaky (no ta pomalu a uspesne zabiji sama sebe...), ale to neni vlastnost Javy, ale par prasatek...
Myslite tu firmu, ktora umoznila vznik Eclipse?
Presne tu :-) To jsou ty paradoxy velkych korporaci - nektere divize vytvori neco opravdu prelomoveho, dalsi zase dokazou (nejenom) SW totalne zmrsit...
-
Chápu, že interpretovaný jazyk bude vždy pomlejší. Ale subjektivně mi přišlo, že java, i když už je s námi velmi dlouho, je stále nejnefektivnější a nejproblémovější prostředí vůbec. Kdysi jsem v tom něco i programoval, ale vždycky to bylo takové divné. Jinak dělám C a ASM na železe, v poslední době C# na pc (ať už .net nebo mono). Poslední jmenovaný mě nadchnul, vzhledem k tomu že je v principu podobný javě, zdá se mi daleko lépe funkční a rychlejší.
I cizí "velké" java aplikace mi dělají problémy více, než jiné (jdownloader, eclipse, android) pády, záseky, lagy... všude se to chová stejně "divně". Zdá se i zvláštní, že tyhle problémy jsou i po letech existence. Je snad nějaký zásadní problém už v konstrukci jazyka? Do hloubky tomu nerozuním, ale rád bych se dozvěděl více.
Asi si este nehral http://www.bytonic.de/html/jake2.html, ze? Zahraj si original, Jake2 a potom subjektivne napis, ktory sa sprava divnejsie.
Keby si v tom nemal jasno, tak Quake2 je v C a Jake2 je v Jave.
-
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.
-
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.
-
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.
-
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í: 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.
-
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: 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.
-
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.
-
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.
-
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).
-
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.
-
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í?
-
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.
-
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.
-
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.
-
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.
Tak ted nevim, copak je to za instrukci, ktera nacte vtable, spocita offset a skoci na adresu ulozenou na vtable+offset?
-
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.
Tak ted nevim, copak je to za instrukci, ktera nacte vtable, spocita offset a skoci na adresu ulozenou na vtable+offset?
CALL, pokud máte (pravděpodobně emulovaný) CONS, CADR, TI Explorer, cokoli od Symbolics atd. :) LISP má na neidiotských architekturách volání virtuálních method už od roku 1973, heč ;)
-
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.
Tak ted nevim, copak je to za instrukci, ktera nacte vtable, spocita offset a skoci na adresu ulozenou na vtable+offset?
CALL, pokud máte (pravděpodobně emulovaný) CONS, CADR, TI Explorer, cokoli od Symbolics atd. :) LISP má na neidiotských architekturách volání virtuálních method už od roku 1973, heč ;)
cekal jsem kdo vytahne procesory od Symbolicsu, takze za toto ++ :)
Ja spis cekam, kdy konecne zacnou vyssi programovaci jazyky nabizet programove konstrukce, ktere zvlada procesor pod nimi, ale k tomu asi nedojde :/
-
Ja spis cekam, kdy konecne zacnou vyssi programovaci jazyky nabizet programove konstrukce, ktere zvlada procesor pod nimi, ale k tomu asi nedojde :/
Tak to do konce roku nekdo tezko trumfne. Recyklovat programatory v cele firme a vyvojarske nastroje kazde 2 roky nebo jak casto se pridavaji nove instrukce na Intel/AMD
-
Ja spis cekam, kdy konecne zacnou vyssi programovaci jazyky nabizet programove konstrukce, ktere zvlada procesor pod nimi, ale k tomu asi nedojde :/
Tak to do konce roku nekdo tezko trumfne. Recyklovat programatory v cele firme a vyvojarske nastroje kazde 2 roky nebo jak casto se pridavaji nove instrukce na Intel/AMD
he, nekde se recykluji programatori kdyz prijde nova ficura? :) Ono se to samozrejme deje, ale docela pomalu a jak tak vidim ne mainstreamove. Napriklad http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html, Parallel.For/Parallel.ForEach, v minulosti s tim docela pohnuly Craye, v Jave 8 zase lambda vyrazy (s implicitni paralelizaci) atd. Ale pobavilo, jestli je na tom obecne IT tak spatne, ze nestaci vstrebavat nove technologie, tak snad jeste chvilku budu mit zajimavou praci :-)
-
cekal jsem kdo vytahne procesory od Symbolicsu, takze za toto ++ :)
Ja spis cekam, kdy konecne zacnou vyssi programovaci jazyky nabizet programove konstrukce, ktere zvlada procesor pod nimi, ale k tomu asi nedojde :/
Opět musím odkázat na LISP machines, hle, dva způsoby volání funkce (bráno na CADRu):
(DEFUN FOO (X)
(BAR X 2))
(DEFUN FOO (X)
(%OPEN-CALL-BLOCK #'BAR 0 4)
(%PUSH X)
(%PUSH 2)
(%ACTIVATE-OPEN-CALL-BLOCK))
(Téměř) každá makroinstrukce na této nádherné architektuře měla odpovídající funkci. Doporučuji shlédnout toto (http://trac.common-lisp.net/mit-cadr/browser/trunk/lisp/sys/defmic.lisp?rev=292) a cítit ohromení a smutek nad tím, co jsme ztratili.
-
cekal jsem kdo vytahne procesory od Symbolicsu, takze za toto ++ :)
Ja spis cekam, kdy konecne zacnou vyssi programovaci jazyky nabizet programove konstrukce, ktere zvlada procesor pod nimi, ale k tomu asi nedojde :/
Opět musím odkázat na LISP machines, hle, dva způsoby volání funkce (bráno na CADRu):
(DEFUN FOO (X)
(BAR X 2))
(DEFUN FOO (X)
(%OPEN-CALL-BLOCK #'BAR 0 4)
(%PUSH X)
(%PUSH 2)
(%ACTIVATE-OPEN-CALL-BLOCK))
(Téměř) každá makroinstrukce na této nádherné architektuře měla odpovídající funkci. Doporučuji shlédnout toto (http://trac.common-lisp.net/mit-cadr/browser/trunk/lisp/sys/defmic.lisp?rev=292) a cítit ohromení a smutek nad tím, co jsme ztratili.
jj kolegyne kdysi delala s Symbolicsu, LISPovsky navyky ma dodnes, a to dela neco jinyho (konkretne GC pro JVM :-)
-
Ja spis cekam, kdy konecne zacnou vyssi programovaci jazyky nabizet programove konstrukce, ktere zvlada procesor pod nimi, ale k tomu asi nedojde :/
Tak to do konce roku nekdo tezko trumfne. Recyklovat programatory v cele firme a vyvojarske nastroje kazde 2 roky nebo jak casto se pridavaji nove instrukce na Intel/AMD
he, nekde se recykluji programatori kdyz prijde nova ficura? :) Ono se to samozrejme deje, ale docela pomalu a jak tak vidim ne mainstreamove. Napriklad http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html, Parallel.For/Parallel.ForEach, v minulosti s tim docela pohnuly Craye, v Jave 8 zase lambda vyrazy (s implicitni paralelizaci) atd. Ale pobavilo, jestli je na tom obecne IT tak spatne, ze nestaci vstrebavat nove technologie, tak snad jeste chvilku budu mit zajimavou praci :-)
Dobry pokus o flame. Zkusim protiflame:
Java vznikla jako prenositelna a protoze se neda spolehnout na procesor pod ni, tak by mel jazyk nabizet prazdnou mnozinu jazykovych konstrukci. V schovivavejsim pripade maximalne lidsky privetivejsi prepis bytekodu.
A ted zpatky bez flame. Proc chcete protlacit praci, kterou odvede kompilator o vrstvu vys primo do zdrojoveho kodu? Aby se mohly vsechny projkety zahodit, napsat znovu a prodat znovu? A kdo to zaplati?
-
Ja spis cekam, kdy konecne zacnou vyssi programovaci jazyky nabizet programove konstrukce, ktere zvlada procesor pod nimi, ale k tomu asi nedojde :/
Tak to do konce roku nekdo tezko trumfne. Recyklovat programatory v cele firme a vyvojarske nastroje kazde 2 roky nebo jak casto se pridavaji nove instrukce na Intel/AMD
he, nekde se recykluji programatori kdyz prijde nova ficura? :) Ono se to samozrejme deje, ale docela pomalu a jak tak vidim ne mainstreamove. Napriklad http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html, Parallel.For/Parallel.ForEach, v minulosti s tim docela pohnuly Craye, v Jave 8 zase lambda vyrazy (s implicitni paralelizaci) atd. Ale pobavilo, jestli je na tom obecne IT tak spatne, ze nestaci vstrebavat nove technologie, tak snad jeste chvilku budu mit zajimavou praci :-)
Dobry pokus o flame. Zkusim protiflame:
Java vznikla jako prenositelna a protoze se neda spolehnout na procesor pod ni, tak by mel jazyk nabizet prazdnou mnozinu jazykovych konstrukci. V schovivavejsim pripade maximalne lidsky privetivejsi prepis bytekodu.
A ted zpatky bez flame. Proc chcete protlacit praci, kterou odvede kompilator o vrstvu vys primo do zdrojoveho kodu? Aby se mohly vsechny projkety zahodit, napsat znovu a prodat znovu? A kdo to zaplati?
To jsem ale vubec netvrdil! Proc by se napriklad s pridamim lambda vyrazu (nebo coz porad doporucuji - vektorovych konstrukci) do C++ mely prepisovat nebo nedejboze zahazovat starsi projekty? Pisu o pridani dalsich konstrukci reflektujicich nove vlastnosti procesoru - driv ci pozdeji k tomu v nejake podobe dojde a zalezi jen na firmach jak se k tomu postavi (pro mnoho prumernych firem je samozrejme snazsi se vest, tech par firem na spicce to pravdepodobne prevezme nebo i zacne ridit - viz google a jeho vyvijeny procesor). Nebo snad chcete rict, ze se dnes programuje stale se stejnymi jazykovymi konstrukcemi jako pred 10,20,30 lety?
-
Nebo snad chcete rict, ze se dnes programuje stale se stejnymi jazykovymi konstrukcemi jako pred 10,20,30 lety?
Očividně ano, jinak by totiž na x86 nepůsobil tlak trhu, který vyžaduje zpětnou kompatibilitu se slunečními hodinami na dvoře faraona Tutanchamona ;D Doporučuji všem neznalým přečíst třeba něco o A20 (http://en.wikipedia.org/wiki/A20_line) nebo o pekle, kterým je snaha přepnout 64-bitový Intel z reálného do dlouhého módu. Krásný příklad toho, jaká kolosální stupidita je v základech 90 % veškeré dnešní "moderní" výpočetní techniky.
-
Nebo snad chcete rict, ze se dnes programuje stale se stejnymi jazykovymi konstrukcemi jako pred 10,20,30 lety?
Očividně ano, jinak by totiž na x86 nepůsobil tlak trhu, který vyžaduje zpětnou kompatibilitu se slunečními hodinami na dvoře faraona Tutanchamona ;D Doporučuji všem neznalým přečíst třeba něco o A20 (http://en.wikipedia.org/wiki/A20_line) nebo o pekle, kterým je snaha přepnout 64-bitový Intel z reálného do dlouhého módu. Krásný příklad toho, jaká kolosální stupidita je v základech 90 % veškeré dnešní "moderní" výpočetní techniky.
Pekne a bohuzel i pravdive receno s temi hodinami :) On i Intel se snazil nekolikrat prejit nekam dal, no ve svete Wintelu se to nikdy nepodarilo (skoro vsude jinde ano), ale ted s postupnym (a dosti rychlym) nastupem rekneme alternativ k umirajicimu PC se to konecne pohnulo rychleji dopredu (Aarch64 vypada skutecne dobre).
-
Ja spis cekam, kdy konecne zacnou vyssi programovaci jazyky nabizet programove konstrukce, ktere zvlada procesor pod nimi, ale k tomu asi nedojde :/
Tak to do konce roku nekdo tezko trumfne. Recyklovat programatory v cele firme a vyvojarske nastroje kazde 2 roky nebo jak casto se pridavaji nove instrukce na Intel/AMD
he, nekde se recykluji programatori kdyz prijde nova ficura? :) Ono se to samozrejme deje, ale docela pomalu a jak tak vidim ne mainstreamove. Napriklad http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html, Parallel.For/Parallel.ForEach, v minulosti s tim docela pohnuly Craye, v Jave 8 zase lambda vyrazy (s implicitni paralelizaci) atd. Ale pobavilo, jestli je na tom obecne IT tak spatne, ze nestaci vstrebavat nove technologie, tak snad jeste chvilku budu mit zajimavou praci :-)
Dobry pokus o flame. Zkusim protiflame:
Java vznikla jako prenositelna a protoze se neda spolehnout na procesor pod ni, tak by mel jazyk nabizet prazdnou mnozinu jazykovych konstrukci. V schovivavejsim pripade maximalne lidsky privetivejsi prepis bytekodu.
A ted zpatky bez flame. Proc chcete protlacit praci, kterou odvede kompilator o vrstvu vys primo do zdrojoveho kodu? Aby se mohly vsechny projkety zahodit, napsat znovu a prodat znovu? A kdo to zaplati?
To jsem ale vubec netvrdil! Proc by se napriklad s pridamim lambda vyrazu (nebo coz porad doporucuji - vektorovych konstrukci) do C++ mely prepisovat nebo nedejboze zahazovat starsi projekty? Pisu o pridani dalsich konstrukci reflektujicich nove vlastnosti procesoru - driv ci pozdeji k tomu v nejake podobe dojde a zalezi jen na firmach jak se k tomu postavi (pro mnoho prumernych firem je samozrejme snazsi se vest, tech par firem na spicce to pravdepodobne prevezme nebo i zacne ridit - viz google a jeho vyvijeny procesor). Nebo snad chcete rict, ze se dnes programuje stale se stejnymi jazykovymi konstrukcemi jako pred 10,20,30 lety?
Instrukce se i odebiraji.
-
V neposledni rade jsou zde bumbrlicci typu Swing, s tim mam zkusenost minimalni, tak to nebudu hodnotit.
uz samotna veta obsahuje hodnotenie. so swingom mame dost skusenosti, za bumbrlika by som ho nepovazoval. celkom dost firiem v tom ma napisanych aplikacii bez toho aby co len tusili "co ze to tam bezi".
-
java teoreticky problemova neni, a zajiste existuje spousta perfektne napsanych benchmarku (netroufam si napsat i aplikaci) kde bezi srovnatelne nebo jeste lepe nez prumerne napsane Ccko. Pointa ale je v tom, ze ti lide, co v Jave dokazi psat velmi vykonne aplikace je v realu pisi v necem jinem a tak v realnem svete zustavaji jen podivne splacane javovske podivnosti....ono to asi nebude jazykem samotnym, ale zpusobem jeho popularizace a soucasnymi trendy...
mimochodem, ktera ne-benchmark aplikace se da povazovat za takovou vykladni skrin Javy, nejaky takovy high performance big ass produkt napsany v jave?
-
java teoreticky problemova neni, a zajiste existuje spousta perfektne napsanych benchmarku (netroufam si napsat i aplikaci) kde bezi srovnatelne nebo jeste lepe nez prumerne napsane Ccko. Pointa ale je v tom, ze ti lide, co v Jave dokazi psat velmi vykonne aplikace je v realu pisi v necem jinem a tak v realnem svete zustavaji jen podivne splacane javovske podivnosti....ono to asi nebude jazykem samotnym, ale zpusobem jeho popularizace a soucasnymi trendy...
Java ma obecne nizsie poziadavky na programatora ako napr. C++, preto ju pouziva viac menej skusenych ludi (oproti C++). A to potom ovplyvnuje kvalitu vysledneho programu. Na druhu stranu Java umoznuje programovat ludom, ktorych by C++ od programovania odradilo.
mimochodem, ktera ne-benchmark aplikace se da povazovat za takovou vykladni skrin Javy, nejaky takovy high performance big ass produkt napsany v jave?
Napadaju ma dve slusne fungujuce aplikacie a to Azureus a FreeRapid Downloader.
-
Musim reagovat na to tlachani tady... tak napriklad cloudovy backend v Avastu je napsany v JAVA, na jednom serveru dava napr. 1 milion pripojenych klientu (comet), nebo 10k-15k requestu/sec. Prijde vam to na picu? Jasne, v Cecku by to mozna dalo 2x tolik, ale vyvoj by se nikdy nezaplatil.
-
mimochodem, ktera ne-benchmark aplikace se da povazovat za takovou vykladni skrin Javy,
twitter
vzzkutecnosti scala beziaca nad jvm
ale jvm je jo, co je gro vykonu
-
I kdybys tam měl 32 jader s HT bratru za 320 kKč, tak ti na jeden request vychází 4 ms a to ti jednoduše nevěřím že to v Javě dokážeš.
Patrně je to agregovaný výkon jednoho racku.
-
java teoreticky problemova neni, a zajiste existuje spousta perfektne napsanych benchmarku (netroufam si napsat i aplikaci) kde bezi srovnatelne nebo jeste lepe nez prumerne napsane Ccko. Pointa ale je v tom, ze ti lide, co v Jave dokazi psat velmi vykonne aplikace je v realu pisi v necem jinem a tak v realnem svete zustavaji jen podivne splacane javovske podivnosti....ono to asi nebude jazykem samotnym, ale zpusobem jeho popularizace a soucasnymi trendy...
mimochodem, ktera ne-benchmark aplikace se da povazovat za takovou vykladni skrin Javy, nejaky takovy high performance big ass produkt napsany v jave?
Mě napadá Hadoop, Cassandra, Elasticsearch a další
-
a minecraft!
nezapomenout na minecraft!
-
Mě napadá Hadoop, Cassandra, Elasticsearch a další
elasticsearch jako priklad? to snad nemyslite vazne. projekt, kteremu byla java "mala" a pouziva sun.misc.Unsafe v 16 souborech neni zrovna vzornou ukazkou pouzitelnosti javy.
-
ebay? (vraj aj c++)
-
Patrně je to agregovaný výkon jednoho racku.
Wtf? Normalni 4 jadrovy XEON s HT, server za cca 60 klacku. Ja tady nedavam zadne odhady, ale ciste fakta. http://www.youtube.com/watch?v=R6Sn4UWlZ0M wtf omg!
-
a minecraft!
nezapomenout na minecraft!
trolling? MC je ukazka toho, jak se to delat nema. Co vim, tak nejsou (nebo donedavna nebyly) normalne paralelizovany nacitani mapy a vykreslovani, ani herni tick (ticky jednotlivych tileEntit a bloku). A to jsem nikdy nezavital do kodu souvisejiciho s rendrovanim - to je pry hodne zpraseny. Je proste k placi, kdyz OptiFine mod (bez zhorseni kvality) bezne zlepsi FPS i na dvojnasobek, odstrani cast sekani souvisejici s nacitanim sveta atd. (tak to byvalo, nyni se ty performance tweaky presouvaji do Forge&FML a udajne i Mojang na tom "dela"1) IMO smutne, ze zakladni vykonostni problemy musi resit modifikace napsana lidmi, co za to nedostavaji zaplaceno...
1 - Cetl jsem, ze po vylepseni rendrovaciho enginu vetsine lidem kleslo FPS...
neni nahodou Twitter a LinkedIn ve Scale (bezi nad jvm)?
-
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:-)
-
ferren: presvedc nas, ze to nejde ;-)
-
twitter [scala on jvm] spada do kategorie
a) "par request/response serverov"
b) utilita
c) klient
d) hra?
ci co podla vas je v chlieve "velke a vykonne"?
plus, co sa tyka kategorie "jak se to delat nema", dovolim si formulovat postulat "v lubovolne velkom a vykonnom projekte su prasaciny".
elasticsearch a sun.misc.Unsafe je v backportoch java.util.concurrency z jdk8/jdk7
-
Google+ je tusim java. Staci iba pogooglit.
Napr. http://www.theserverside.com/news/thread.tss?thread_id=47135
Je to stare ale vela veci stale plati. Citujem:
"I have worked in France and spain for most of the big banks on europe including ING. They all use Java Jee with a lot of spring. Here in the US i see a lot of financial institutions use jee too with one exception Charles Schwab which i heard is moving from jee to msft."
Kde myslis, ze davaju tie platy 4000+ eur java developerom? Benzinky? (tie idu na .netoch :D)
Ako neviem, co by si chcel pocut. Ze java na desktope sux? Ano aj.
Ale zober si take adobe lightroom. Ma iba graficke jadro a gui je v lua a vies preco? Lebo c++ sux desatkrat viac. Je ovela lepsie napisat v tom iba kriticke casti (a to mozes rovno v C) a zvysok urobit v niecom normalnom.. Dost ma to inspirovalo k tomu vyskusat to a je to parada (s luajit a ffi). Este aj ten microsoft si dal explorer do systemu aby nemuseli robit guika v c++ :D. A len prosimta nevytiahni qt..
Skoda, ze ten smalltalk vyzera tak cude..
ps: nesom triezvy :D
-
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é“.
-
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é“.
Přijde mi to taky jako trošku přihlouplá debata, ale je fakt, že jsem třeba zatím neslyšel* o úspěchu nějakého v-javě-napsaného RDBMS, nosql, jabber serveru, voip... Bohužel ani Looking Glass se po několika letech nepodařilo rozběhat k aspoň jakés-takés spokojenosti...
* vůbec neříkám, že to neexistuje, javu fakt nesleduju...
-
Co treba Cassandra? Naprosto nezbytna nosql vec, pro urcitou tridu vyuziti zasadne lepsi nez treba HBase.
To totiz neni tim chlapci, ze by ty veci neexistovaly, ale tim, ze ze svych pozic bastlicu utilit v bashi a homepagi v PHP tak daleko nedohlednete.
-
RDBMS
H2, Derby
nosql
Neo4j, Voldemort, HBase
jabber serveru
OpenFire
-
Co treba Cassandra? Naprosto nezbytna nosql vec, pro urcitou tridu vyuziti zasadne lepsi nez treba HBase.
Ok, tak nosql bysme meli. To je nejjednodussi z tech veci, co jsem zminil. A dalsi?
To totiz neni tim chlapci, ze by ty veci neexistovaly, ale tim, ze ze svych pozic bastlicu utilit v bashi a homepagi v PHP tak daleko nedohlednete.
To mluvis o kom? Ja PHP neumim, takze prosim neprecenovat! Zustanme jenom u bastlicu utilit v bashi :))
-
Díky, Filipe. Ale žádná z těch zmíněných věcí není v té oblasti majoritní hráč, ne?
-
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.
NoSQL není jedna oblast, těch majoritních hráčů je tam spousta. A skoro co nová implementace, to nový jazyk nebo jejich kombinace… Ale HBase/Cassandra je podle mne ve své „podoblasti“ majoritní hráč.
No a když už se to zmínily relační databáze, Jabber a NoSQL, zmíním jedno prostředí, kde se tohle všechno dá používat – Google App Engine, hostované aplikace se tam píší v Javě (nebo jiných jazycích pro JVM) nebo Pythonu.
-
Co treba Cassandra? Naprosto nezbytna nosql vec, pro urcitou tridu vyuziti zasadne lepsi nez treba HBase.
Ok, tak nosql bysme meli. To je nejjednodussi z tech veci, co jsem zminil. A dalsi?
Nejjednodussi? Prijde vam, ze bazmek, co se dokaze clusterovat po celem svete mezi radou datacenter, linearne skalovat, zotavovat se z poruch atd atd je nejaka jednoducha hracka?:)
Jinak treba Netflix do toho uklada videa, co streamuje.
-
V případě Jabber serverů jsou myslím tři nejpoužívanější – ejabberd, jabberd a OpenFire (v tomto pořadí).
S tím, že AFAIK ejabberd má zdaleka největší podíl.
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.
Tak nějak jsem nad tím taky uvažoval. A přesně o tohle mi šlo - nikomu nestojí za to velké věci přepisovat do Javy, protože by tím nic nezískal.
NoSQL není jedna oblast, těch majoritních hráčů je tam spousta. A skoro co nová implementace, to nový jazyk nebo jejich kombinace… Ale HBase/Cassandra je podle mne ve své „podoblasti“ majoritní hráč.
Ok, díky za osvětlení, v téhle oblasti se nijak zvlášť nepohybuju. Jak jsem se teď zběžně díval na benchmarky, zakopl jsem o HyperDex, kterej jsem do té doby neznal. Pokud jsou benchmarky korektní, vypadá to docela impozantně. Až na to, že u těchhle věcí strašně záleží na use case (velikost dat vs. velikost paměti, typy transakcí, typy dat...) Nějak komplexně a korektně se to asi porovnat nedá...
No a když už se to zmínily relační databáze, Jabber a NoSQL, zmíním jedno prostředí, kde se tohle všechno dá používat – Google App Engine, hostované aplikace se tam píší v Javě (nebo jiných jazycích pro JVM) nebo Pythonu.
JVM určitě je jeden z nejvyladěnějších VM. Ale jednak JVM =/= java, 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á?) a pokud to tak je, tak uvidíme, jestli se třeba v budoucnu nezmění... (dart?!)
-
Nejjednodussi? Prijde vam, ze bazmek, co se dokaze clusterovat po celem svete mezi radou datacenter, linearne skalovat, zotavovat se z poruch atd atd je nejaka jednoducha hracka?:)
Abych rekl pravdu, tak tyhle vlastnosti me nijak zvlast neohromuji, mj. proto, ze aplikaci s takovymi vlastnostmi zvladne napsat zacatecnik v Erlangu za den :)
Ale spis mi slo o to, ze mi prijde slozitejsi napsat clusterovany, linearne skalovatelny a fault-tolerant jabber server nez nosql. Ale to je muj ciste laicky neinformovany odhad, mozna se mylim.
-
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:-)
A to já bych o něčem pěkném, používaném a stabilním věděl - je to vlastní JVM :-) Za ty roky se to vyvinulo ve výkonnou platformu, nad kterou se staví další jazyky, takže když někdo nechce z nějakého důvodu přímo Javu (jako jazyk), tak má na výběr ze spousty možností (Groovy, Scala, Jython, JRuby mé oblíbené Clojure a pro webisty i Rhino). A navíc je JVM i v určité míře "pluginovatelná", takže když někomu nevyhovují standardní knihovny, výměna/náhrada je věcí několika minut, nevyhovuje několik dodávaných GC? - taktéž lze přidat další, HotSpot je pro embedded příliš rozsáhlý?, fajn dáme JamVM, CACAO atd. atd. A na to, kolik toho JVM poskytuje za služby, to vlastně není až tak velký balíček...
-
Nejjednodussi? Prijde vam, ze bazmek, co se dokaze clusterovat po celem svete mezi radou datacenter, linearne skalovat, zotavovat se z poruch atd atd je nejaka jednoducha hracka?:)
Abych rekl pravdu, tak tyhle vlastnosti me nijak zvlast neohromuji, mj. proto, ze aplikaci s takovymi vlastnostmi zvladne napsat zacatecnik v Erlangu za den :)
Ale spis mi slo o to, ze mi prijde slozitejsi napsat clusterovany, linearne skalovatelny a fault-tolerant jabber server nez nosql. Ale to je muj ciste laicky neinformovany odhad, mozna se mylim.
Skoda, ze to vyvojarum Cassandry nikdo nerekl, nemuseli by se s tim ta leta patlat;).
Ad jabber, v Jave je napsany +-druhy nejpouzivanejsi server, prvni je v erlangu. A vazne radost s tim neco delat nebo nedejboze v tom neco menit:)
Btw zminil tu uz nekdo treba Android? Ten je docela rozsireny;) A ono je to rozlezle i v ruznych televizich, mate to v kazdem Blu-Ray prehravaci..
-
JVM určitě je jeden z nejvyladěnějších VM. Ale jednak JVM =/= java
Vý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?
-
Btw zminil tu uz nekdo treba Android? Ten je docela rozsireny;) A ono je to rozlezle i v ruznych televizich, mate to v kazdem Blu-Ray prehravaci..
dik za hezky darek, citim se jak kdyby mi bylo 5 let. ted jeste vyjmenovat ty zarizeni, ktere nepouziva jen minula generace, ale i ja :D
/trololol
-
Skoda, ze to vyvojarum Cassandry nikdo nerekl, nemuseli by se s tim ta leta patlat;).
Opravdu jsem neměl v úmyslu se bavit tímhle tónem. Ale dobře: není to dobrý argument, protože pro volbu javy si určitě umíme představit i jiné než čistě technologické argumenty, že jo. Např. že když to bude v javě, bude to víc lidí chtít používat, snadněji se najdou vývojáři, CIO k tomu budou vstřícnější, bude se to líp integrovat atd. atd.
Taky to snadno může být tradeoff - bude sice náročnější to napsat tak, aby to ty zmíněné vlastnosti mělo, ale potom to bude rychlejší než kdybysme to psali v Erlangu a měli to hotové za měsíc.
Pro jistotu ještě polopaticky: netvrdil jsem, že je Erlang lepší, jenom čistě to, že clusterovatelnost a fault-tolerance mě nijak nešokuje. To je vše.
Ad jabber, v Jave je napsany +-druhy nejpouzivanejsi server, prvni je v erlangu. A vazne radost s tim neco delat nebo nedejboze v tom neco menit:)
Je dobré vidět kontext: http://www.process-one.net/images/uploads/IMtrends_stats_by_domain.png
-
A vazne radost s tim neco delat nebo nedejboze v tom neco menit:)
No když někdo Erlang neumí, tak to asi je velkej opruz, to je jasný. Ale jinak v tom nevidím problém - napsal jsem do ejabberd několik pluginů a neměl jsem s tím sebemenší problém, naopak - fungovalo a funguje to skvěle a bylo to hotové cca za den.
-
Výtky k rychlosti nebo paměťové náročnosti se ovšem mohou týkat výhradně JVM, nikoli Javy jako jazyka.
Tahle teze se velmi lehce vyvrátí - stačí porovnat tyhle parametry u různých jazyků nad JVM.
-
Skoda, ze to vyvojarum Cassandry nikdo nerekl, nemuseli by se s tim ta leta patlat;).
Opravdu jsem neměl v úmyslu se bavit tímhle tónem. Ale dobře: není to dobrý argument, protože pro volbu javy si určitě umíme představit i jiné než čistě technologické argumenty, že jo. Např. že když to bude v javě, bude to víc lidí chtít používat, snadněji se najdou vývojáři, CIO k tomu budou vstřícnější, bude se to líp integrovat atd. atd.
uz si to nakousnul, tak presne to stejne je u toho elasticsearch. ma to dostatek buzzwords a lip se na tu vejicku nekdo ulovi. tak proste korporatni prostredi funguje.
elasticsearch mi prijde, ze je prave ukazkovy priklad jak polozit navnadu na kterou se chytne stado co jde s vlnami trendu, protoze pro to maji jine duvody (z jinych oboru) nez ktere se tu snazite rozebirat. a naopak bych vyzvedl elasticsearch za to (slovy mistnich) "jak prasit v jave na profesionalni urovni", co uz, ze tim pohrbi vsechny zakladni axiomy zastancu javy. dulezity je akorat, ze to dela co ma a prezilo to porod.
-
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í.
-
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í.
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...
-
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.
-
Jenže tenhle typ výkonu je úplně něco jiného, než o čem se tu celou dobu diskutuje
Já 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...
-
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
-
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
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?
-
you wish... https://news.ycombinator.com/item?id=5118070
To je dobrá připomínka - proč vlastně všchny "JVM-only" operační systémy zkrachovaly. Čistě pocitově mi to přijde podobné jako u toho Looking Glass - prostě se ukázalo, že java na tyhle věci vhodná není. Ale to je fakt jenom úplně laický neinformovaný odhad zvnějšku.
-
Jenže tenhle typ výkonu je úplně něco jiného, než o čem se tu celou dobu diskutuje
Já 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...
Ú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.
-
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.
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... " -- 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.?" Ne že bych s tím souhlsail nebo na to uměl odpovědět (žádnou javovou aplikace pravidelně nepoužívám ani na serveru nespravuju), ale pochopil jsem ten dotaz takhle. Navíc to slýchávám od adminů celkem často...
A pokud by se o tom diskutovalo, tak se přece nediskutuje o programovacím jazyce, ale o platformách a architekturách.
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.
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.
-
Záleží na tom, čemu říkáte operační systém.
Java OS, JNode, JX, ...
-
To je dobrá připomínka - proč vlastně všchny "JVM-only" operační systémy zkrachovaly.
Jelikož je Java navržena hloupě tak se nepodařilo vyrobit 100 % HW JVM a když není HW logicky není ani OS.
Dělat OS v softwarovém JVM je nesmysl z podstaty.
Java OS, JNode, JX, ...
OS z principu musí být hromada nativního kódu spouštěného vzápětí po Resetu, ovládající hardware a mimo jiné umožňující zavádět do paměti nativní aplikace a spouštět je. Jelikož pro Javu není a nebude HW, OS v Javě nikdy nebude moci vzniknout.
-
OS z principu musí být hromada nativního kódu spouštěného vzápětí po Resetu, ovládající hardware a mimo jiné umožňující zavádět do paměti nativní aplikace a spouštět je. Jelikož pro Javu není a nebude HW, OS v Javě nikdy nebude moci vzniknout.
Proč by musela? Poměr mezi množstvím kódu pod JVM a nad JVM může být celkem libovolný, ne? Umím si představit, že platforma s jenom tenoučkou nativní vrstvou pod JVM, napsanou namíru určitému virtuálizovanému hw, by mohla být celkem terno. Akorát se to prostě ještě přes mnohé pokusy neobjevilo. A docela by mě zajímalo, proč (pokud je pravda, že java je výkonostně plně srovnatelná třeba s C).
Mít možnost plné kontroly a inspekce spouštěného kódu na vysoké úrovni by přece byla pecka. Nejenom z bezpečnostních důvodů...
-
A JVM vyrobíte a spustíte v čem ? Odpovím si sám v nativním kódu. Taktéž tam bude muset být něco co toho bumbrlíčka JVM dokáže dostat a spustit, bude tam muset být podpora na přepínání vláken a a procesů a další věci a ovladače budou nutně muset být v nativním kódu.
Plná kontrola nad běžícím kódem je dávno hotová, je to režim virtuální paměti v x86,. Povšimněte si že od W2K a na Linuxu asi odjakživa se aplikace nemohou bořit navzájem, taktéž nemohou bořit jádro.
Platforma s tenkou vrstvou pro JVM se neujala proto, že vždycky se našel nějak blb co uměl aplikaci napsat nativně s lepšími výsledky než v Javě.
-
A JVM vyrobíte a spustíte v čem ? Odpovím si sám v nativním kódu. Taktéž tam bude muset být něco co toho bumbrlíčka JVM dokáže dostat a spustit, bude tam muset být podpora na přepínání vláken a a procesů a další věci a ovladače budou nutně muset být v nativním kódu.
Jasně, ale (naprosto laicky a neinformovaně) si umím představit, že ten kód pod JVM by byl opravdu minimalistický ve stylu mikrokernelu a většina logiky by byla už v jvm. Vždyť třeba takový driver v principu může jenom předávat data tam a zpátky a veškerá logika by klidně mohla být v javě (pokud by platilo, že výkon javy je v pohodě).
Plná kontrola nad běžícím kódem je dávno hotová, je to režim virtuální paměti v x86,. Povšimněte si že od W2K a na Linuxu asi odjakživa se aplikace nemohou bořit navzájem, taktéž nemohou bořit jádro.
Pod plnou kontrolou si představuju něco takového jakože třeba mám plugin, který může využívat jenom nějakou část funkcionality, protože na jinou prostě nemá jak šáhnout. To je trochu něco jiného než kód, který si může skákat kamkoli ho napadne.
Platforma s tenkou vrstvou pro JVM se neujala proto, že vždycky se našel nějak blb co uměl aplikaci napsat nativně s lepšími výsledky než v Javě.
Pokud by to bylo opravdu tak, tak by to byla odpověď na otázku, jestli je java stejně v pohodě* jako C nebo ne.
* všeobjímající termín zahrnující všechny myslitelné metriky jako spotřeba paměti, rychlost, vyvážený výkon, paralelizovatelnost atd. :)
-
To je dobrá připomínka - proč vlastně všchny "JVM-only" operační systémy zkrachovaly. Čistě pocitově mi to přijde podobné jako u toho Looking Glass - prostě se ukázalo, že java na tyhle věci vhodná není. Ale to je fakt jenom úplně laický neinformovaný odhad zvnějšku.
Protoze vlastne nejsou zapotrebi, evidentne se to po ekonomicke strance nevyplati nikomu vyvijet a podle me je to tak dobre. Kdyz uz mame tak slozite ulohy pro pocitace, ze potrebujeme operacni system (coz neni vzdy nutne - rekneme odhadem 50% mikroprocesoru a mikroradicu zadny skutecny OS nehoni, proc taky :), tak se ukazalo nejlepsi mit ten system vrstveny, dole nejaky HAL (at se za nim skryva cokoli, treba kus BIOSu), nad nim rozumne jadro/mikrojadro (ktere je vlatne tak jednoduche z hlediska navrhu, ze to zvladneme i v cecku), nad tim dalsi sluzby typu FS atd. a nad tim klidne i JVM. Proc cpat JVM na nizsi vrstvu nez je nutne a efektivni a proc na druhou stranu psat cele aplikace ve zbytecne nizkourovnovych jazycich?
-
Jasně, ale (naprosto laicky a neinformovaně) si umím představit, že ten kód pod JVM by byl opravdu minimalistický ve stylu mikrokernelu a většina logiky by byla už v jvm. Vždyť třeba takový driver v principu může jenom předávat data tam a zpátky a veškerá logika by klidně mohla být v javě (pokud by platilo, že výkon javy je v pohodě).
Jistě by šlo mít černou skříňku která nabootuje z firmware, nahraje z firmware JVM a to spustí, to bezesporu jde.
Driver musí mít nutně nativní část jelikož v Javě ani JVM vůbec nejsou některé věci třeba čtení a zápis portu, přístup do paměti na konkrétní fyzickou (nikoliv virtuální) adresu a mnoho dalšího, i když souhlasím s tím že nějaká logika může být teoreticky být v Javě.
Pod plnou kontrolou si představuju něco takového jakože třeba mám plugin, který může využívat jenom nějakou část funkcionality, protože na jinou prostě nemá jak šáhnout. To je trochu něco jiného než kód, který si může skákat kamkoli ho napadne.
Částečně to jde, dá se šachovat s dostupností DLL, ale není to obvyklé.
Pokud by to bylo opravdu tak, tak by to byla odpověď na otázku, jestli je java stejně v pohodě* jako C nebo ne.
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.
-
Protoze vlastne nejsou zapotrebi, evidentne se to po ekonomicke strance nevyplati nikomu vyvijet
To by mě právě zajímalo. Sun se o to pokoušel, takže si asi myslel, že by se to hodit mohlo. A zajímalo by mě, jestli to utnuli, protože se to nedařilo, nebo prostě jenom kvůli katování kostů...
Proc cpat JVM na nizsi vrstvu nez je nutne a efektivni
Umím si představit, že by to mohlo přinést spoustu úplně nových možností - hlavně pro bezpečnost: třeba snadnější verifikaci kritických částí kódu, nebo třeba lepší granularitu oprávnění a jejich volnou kombinovatelnost - ne jenom podle uživatele, jak je to víceméně dneska, ale podle funkcionality - a to ne jenom na úrovni procesů, ale i uvnitř nich - např. konkrétní plugin má právo udělat operace X,Y,Z, jiný X,Y a jiný Y,Z - a to všechno v rámci jednoho procesu a verifikovatelně (za předpokladu, že jvm pracuje správně).
Nebo právě různé ty klaudové skopičiny - třeba snadnější migrace běžících procesů by se určitě hodila, dneska se to řeší buď celkem krkolomně, nebo neřeší vůbec...
jelikož v Javě ani JVM vůbec nejsou některé věci třeba čtení a zápis portu
Samozřejmě jsem počítal s tím, že takový JVM-OS by měl to JVM trochu upravené oproti tomu současnému :)
Částečně to jde, dá se šachovat s dostupností DLL, ale není to obvyklé.
Pořádně to nejde, protože v rámci jednoho procesu může libovolný kód kamkoli zapsat, odkudkoli číst a cokoli spustit. Takže buď operaci X může udělat celý proces, nebo žádná jeho část.
-
Protoze vlastne nejsou zapotrebi, evidentne se to po ekonomicke strance nevyplati nikomu vyvijet
To by mě právě zajímalo. Sun se o to pokoušel, takže si asi myslel, že by se to hodit mohlo. A zajímalo by mě, jestli to utnuli, protože se to nedařilo, nebo prostě jenom kvůli katování kostů...
Proc cpat JVM na nizsi vrstvu nez je nutne a efektivni
Umím si představit, že by to mohlo přinést spoustu úplně nových možností - hlavně pro bezpečnost: třeba snadnější verifikaci kritických částí kódu, nebo třeba lepší granularitu oprávnění a jejich volnou kombinovatelnost - ne jenom podle uživatele, jak je to víceméně dneska, ale podle funkcionality - a to ne jenom na úrovni procesů, ale i uvnitř nich - např. konkrétní plugin má právo udělat operace X,Y,Z, jiný X,Y a jiný Y,Z - a to všechno v rámci jednoho procesu a verifikovatelně (za předpokladu, že jvm pracuje správně).
Nebo právě různé ty klaudové skopičiny - třeba snadnější migrace běžících procesů by se určitě hodila, dneska se to řeší buď celkem krkolomně, nebo neřeší vůbec...
Sun to zkousel, ale vime jak to posledni roky se Sunem bylo, nejak takto: http://static.arstechnica.net/assets/2009/04/sun-oracle-thumb-640xauto-4590.jpg :-)
S tou granularitou opravneni je to pravda a jde o zajimavou myslenku. Dneska to JVM resi pres java.policy a celkem rozumne, kdyby to bylo v ramci OS, bylo by to urcite pro nektere typy serveru (napriklad) zajimave. Ale porad je tady ten argument, jestli se to vyplati v dobe, kdy si kdokoli muze vzit Linux/BSD whatever, postavit nad tim desktop a zacit prodavat. Ty investice do Linuxu a hlavne predtim do Unixu by nekdo musel udelat znovu a asi by neziskal nejak vyznamnou hodnotu, jen o jednu vrstvu mezi aplikaci a HW mene; ale nevim, treba to napadne nekoho z IBM nebo podobnych molochu.
JVM (v dost osekane variante) bezi ale i na Kindle a podobnych zarizenich, takze to svoje opodstatneni asi ma (a tady bylo jasne proc - mnozstvi knihoven, ktere mohli autori kinkdlu pouzit).
-
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.
-
JVM-OS? Prosím vás, kecejte o takovejhle věcech až o nich budete něco vědět, fakt nesnáším když o čemkoli kecaj lidi kteří vědi hovno.
Čas který stráví program v kernel space musí být minimální. V případě javy a (buď JVM a nebo jazelle na ARM) by se tento čas opravdu velmi protáhl.
Nejenže by byl takový OS neefektivní, ale ještě žravý na energii (a jakou zbraň má ARM proti x86? SPOTŘEBU).
-
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.
-
Sun to zkousel, ale vime jak to posledni roky se Sunem bylo, nejak takto: http://static.arstechnica.net/assets/2009/04/sun-oracle-thumb-640xauto-4590.jpg :-)
Tak to je výborný :))
Ty investice do Linuxu a hlavne predtim do Unixu by nekdo musel udelat znovu a asi by neziskal nejak vyznamnou hodnotu, jen o jednu vrstvu mezi aplikaci a HW mene; ale nevim, treba to napadne nekoho z IBM nebo podobnych molochu.
Já mám stejně pořád takový podezření, jestli to nebylo právě podobně jako s tím Looking Glass - je to bomba koncept, přináší to super nové možnosti, dokázali jsme, že to v javě zrealizovat jde, ale ... ...ale bohužel je to nepoužitelně pomalý a padá to jenom se na to člověk podívá :)
(ale to je tím, že jsem k javě tak nějak předem skeptickej, žádný reálný důvody pro tenhle dojem nemám :)
-
Platforma s tenkou vrstvou pro JVM se neujala proto
Píšete o Androidu, že? Takže proč že se to neujal?
-
A proto je ve spoustě těch zařízení Android. Aha.
A web browser tam mají v Javě nebo nativní ? Pokud nativní, pak se žádná tenká vrstva nekoná. Nehledě na to, že v telefonech jsou tuny nativního kódu nutné pro samotný rádiové části a dalšího hardware.
konkrétní plugin má právo udělat operace X,Y,Z, jiný X,Y a jiný Y,Z
Nebo právě různé ty klaudové skopičiny - třeba snadnější migrace běžících procesů by se určitě hodila, dneska se to řeší buď celkem krkolomně, nebo neřeší vůbec...
A opravdu to tak funguje spolehlivě, je to odolné proti šťourání třeba přes reflexi ? To nevím, to se ptám.
V cloudech se přesunuje celý běžící VM mezi fyzickými stroji, mají na to udělátor třeba ve VMWare.
-
Pokud chcete porovnávat celkový uživatelský dojem – má někdo tyhle zkušenosti (pády, záseky, lagy) třeba s GMailem?
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.
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…
Já to ale slýchám i od adminů, kteří javové aplikace reálně spravují. Je možné, že to je fakt tím, že úroveň programátorů v Javě je obecně průměrně nižší, tomu bych i věřil.
Tohle je ale přece přesně o tom „hrubém výkonu“. Co chcete masivně paralelizovat na JDownloaderu, eclipse, Androidu? [...]
Nějaký prostor, co by bylo možné s JVM dělat lépe ale v Javě to nešlo, tam prakticky není.
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í"?
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.
Přesně tam myslím ta debata předtím směřovala: "ukažte mi aplikace v oblasti XY, které se prosadily".
Čas který stráví program v kernel space musí být minimální. V případě javy a (buď JVM a nebo jazelle na ARM) by se tento čas opravdu velmi protáhl.
Samozřejmě by v kernel space nejel celý JVM, to dá rozum. Proto zmínka o mikrokernelu.
Píšete o Androidu, že? Takže proč že se to neujal?
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)
-
A opravdu to tak funguje spolehlivě, je to odolné proti šťourání třeba přes reflexi ? To nevím, to se ptám.
Bavíme se čistě hypoteticky, takže: umím si představit, že by se pro určitý kód dala reflexe zakázat. A taky by třeba přístup k okolnímu světu šel jenom přes nějaký proxy-objekt, takže by se snadno dalo dokázat, co plugin opravdu může a co ne...
V cloudech se přesunuje celý běžící VM mezi fyzickými stroji, mají na to udělátor třeba ve VMWare.
No právě - a to je děsně těžkopádný.
-
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.
Přesně tam myslím ta debata předtím směřovala: "ukažte mi aplikace v oblasti XY, které se prosadily".
Jetty, Tomcat, Weblogic, Websphere, Gigaspaces
Hadoop (HDFS, HBase, Pig, Zookeeper atd.)
Eclipse, Vp-UML, SQL Developer, Protege
-
konkrétní plugin má právo udělat operace X,Y,Z, jiný X,Y a jiný Y,Z
Nebo právě různé ty klaudové skopičiny - třeba snadnější migrace běžících procesů by se určitě hodila, dneska se to řeší buď celkem krkolomně, nebo neřeší vůbec...
A opravdu to tak funguje spolehlivě, je to odolné proti šťourání třeba přes reflexi ? To nevím, to se ptám.
V cloudech se přesunuje celý běžící VM mezi fyzickými stroji, mají na to udělátor třeba ve VMWare.
Reflexi lze taktez pres policy zakazat, bud vsude, pro archiv, balicek, tridu... Samozrejme muze byt v security modelu chyba, to se nedavno nekolikrat stalo, ale opravuje se to docela rychle (i kdyz spoluprace Oracle s komunitou je v tomto ohledu dost mizerna).
-
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?
-
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é.
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.
-
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 .....
-
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 ...
-
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.
-
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.
-
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...
-
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.
-
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.
-
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).
-
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.
-
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...)
-
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.
-
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.
-
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.
-
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.
Vim, ale toto je neco jineho, jmenuje se to Shenandoah GC a delaji na tom dva kolegove z Red Hatu (ja to jenom testuju ;).
http://rkennke.wordpress.com/2013/06/10/shenandoah-a-pauseless-gc-for-openjdk/
http://rkennke.wordpress.com/2013/06/18/shenandoah-gc-an-overview/
Prijd pristi rok na Developer konferenci do Brna, mela by tam o nem byt prednaska :)
-
Aha jasny, ono to asi pro kratkodobe procesy je jednodussi, hlavne kdyz neni zapotrebi resit cyklicke reference
Pravě. Přesně o to mi šlo - že Erlang jako jazyk má prostě vlastnosti, které výrazně zjednodušují konstrukci GC a 1) umožňují postupy, které by jinak nešly 2) jednoduché postupy mají díky nim překvapivě dobré výsledky
Když je program správně napsaný - tj. long-lived procesy nebobtnají, procesů je spousta a většina z nich žije krátce, je z toho vlastně zadarmo inkrementální GC s minimálním dopadem na odezvu a žádným globálním stopem. Docela hezky jsou základní principy a vlastnosti popsané tady: http://prog21.dadgum.com/16.html
-
Aha jasny, ono to asi pro kratkodobe procesy je jednodussi, hlavne kdyz neni zapotrebi resit cyklicke reference
Pravě. Přesně o to mi šlo - že Erlang jako jazyk má prostě vlastnosti, které výrazně zjednodušují konstrukci GC a 1) umožňují postupy, které by jinak nešly 2) jednoduché postupy mají díky nim překvapivě dobré výsledky
Když je program správně napsaný - tj. long-lived procesy nebobtnají, procesů je spousta a většina z nich žije krátce, je z toho vlastně zadarmo inkrementální GC s minimálním dopadem na odezvu a žádným globálním stopem. Docela hezky jsou základní principy a vlastnosti popsané tady: http://prog21.dadgum.com/16.html
pekne vysvetlene dik moc za odkaz. Z JVM jazyku se nejvice odlisuje Clojure, a tam by se asi mohlo o necem podobnem uvazovat (izolace pameti pro funkce, "futures" atd.), ale jestli na to nekdo bude mit silu a chut.... tezko rict.
-
Z JVM jazyku se nejvice odlisuje Clojure, a tam by se asi mohlo o necem podobnem uvazovat (izolace pameti pro funkce, "futures" atd.), ale jestli na to nekdo bude mit silu a chut.... tezko rict.
Na nej jsem prave myslel. Akoratze porad tam zustava moznost kooperace s normalnimi javovymi metodami, takze tim to asi docela pada, ne?
-
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.
Vim, ale toto je neco jineho, jmenuje se to Shenandoah GC a delaji na tom dva kolegove z Red Hatu (ja to jenom testuju ;).
http://rkennke.wordpress.com/2013/06/10/shenandoah-a-pauseless-gc-for-openjdk/
http://rkennke.wordpress.com/2013/06/18/shenandoah-gc-an-overview/
Prijd pristi rok na Developer konferenci do Brna, mela by tam o nem byt prednaska :)
Diky za info. Muzu jeste dotaz k tomu, jak si myslel s tim, ze se "ted" objevil hardware, kde to ma smysl? Protoze Sun serverove procesory sveho casu byly zrejme presne tim co si asi mel na mysli. A pro Sun to byl jak vidime hrob.
Jeste je teda moznost, ze si myslel mobily a tam by pausless mel skutecne opodstatneni i se vsemi puvodnimi nedostatky. 20MB aplikace s 100MB daty co ma k dispozici 2GB a je potreba, aby se "neustale hejbala".
-
+ se nechava prace na GC i u objektu, jejichz zivotnost je evidentne jen mala - blok, metoda
Zrovne tohle dokaze runtime zoptimalizovat diky escape analyze, kratce zijici objekty jdou na stack, nektere se ani nemusi alokovat cele, tj tlak na GC v nekterych pripadech dost vyrazne klesa.
-
+ se nechava prace na GC i u objektu, jejichz zivotnost je evidentne jen mala - blok, metoda
Zrovne tohle dokaze runtime zoptimalizovat diky escape analyze, kratce zijici objekty jdou na stack, nektere se ani nemusi alokovat cele, tj tlak na GC v nekterych pripadech dost vyrazne klesa.
To jo, ale ja myslel (mel jsem to napsat jasneji) podporu v bytecode - tam neexistuje zadna instrukce typu delete (opak k new, newarray, anewarray a multianewarray), kterou by prekladac mohl (pokud by existovala) davat na konec metod/do finally/ja nevim kam jeste u objektu, jimz jasne a na zaklade compile-time analyzy konci zivotnost. Teoreticky by to mohlo snizit naroky na pamet, ale asi to nikdo nezkousel. On vubec bytecode moc JITu nepomaha, mohl by pridavat ruzne hinty ke spouste vecem, co se pri prekladu ztrati :-) ale proste takto to bylo navrzene a asi se dockame max. nejakych dalsich metadat jestli vubec.
-
Diky za info. Muzu jeste dotaz k tomu, jak si myslel s tim, ze se "ted" objevil hardware, kde to ma smysl? Protoze Sun serverove procesory sveho casu byly zrejme presne tim co si asi mel na mysli. A pro Sun to byl jak vidime hrob.
Jeste je teda moznost, ze si myslel mobily a tam by pausless mel skutecne opodstatneni i se vsemi puvodnimi nedostatky. 20MB aplikace s 100MB daty co ma k dispozici 2GB a je potreba, aby se "neustale hejbala".
No obavam se, ze je to presne pro opacne spektrum HW ;-) Je to cileno na servery s mnoha CPU a obrovskymi heapy (takze "enterprise" nesmysly a mracky), s kteryma maji soucasne GC problemy - dlouhe casy pri full GC + navic ten pitomej stop-the-world. Shenandoah by toto *mel* vylepsit, zatim vyvojova verze v benchmarcich (SPECjbb hlavne) dosahuje +- stejne vykonnosti jako ParallelGC, ale je to fakt vyvojova verze, ktera alespon nepada a neleakuje, coz je docela uspech ;-)
-
Diky za info. Muzu jeste dotaz k tomu, jak si myslel s tim, ze se "ted" objevil hardware, kde to ma smysl? Protoze Sun serverove procesory sveho casu byly zrejme presne tim co si asi mel na mysli. A pro Sun to byl jak vidime hrob.
Jeste je teda moznost, ze si myslel mobily a tam by pausless mel skutecne opodstatneni i se vsemi puvodnimi nedostatky. 20MB aplikace s 100MB daty co ma k dispozici 2GB a je potreba, aby se "neustale hejbala".
No obavam se, ze je to presne pro opacne spektrum HW ;-) Je to cileno na servery s mnoha CPU a obrovskymi heapy (takze "enterprise" nesmysly a mracky), s kteryma maji soucasne GC problemy - dlouhe casy pri full GC + navic ten pitomej stop-the-world. Shenandoah by toto *mel* vylepsit, zatim vyvojova verze v benchmarcich (SPECjbb hlavne) dosahuje +- stejne vykonnosti jako ParallelGC, ale je to fakt vyvojova verze, ktera alespon nepada a neleakuje, coz je docela uspech ;-)
rok 2007, 64 vlaken, UltraSPARC T2 (Niagara 2) 1GHz - 1.6GHz
rok 2007, 64 vlaken, UltraSPARC T2 Plus (Victoria Falls) 1.2GHz - 1.6GHz
rok 2010, 128 vlaken SPARC T3 (Rainbow Falls), 1.6GHz
rok 2009 http://www.sec.gov/Archives/edgar/data/709519/000119312509183962/d10k.htm
ITEM 6. SELECTED FINANCIAL DATA
2009 Dollars %
Income (loss) before taxes (2,183 ) (19.1 )
rok 2010 odprodej Sun spolecnosti Oracle
-
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í" ;)
Já jsem se taky neptal na metriky. Ono je totiž také možné (a řekl bych, že pravděpodobnější), že ty vlastnosti jsou typické pro ten typ aplikací, které spravují – bez ohledu na to, v čem jsou napsané.
-
Diky za info. Muzu jeste dotaz k tomu, jak si myslel s tim, ze se "ted" objevil hardware, kde to ma smysl? Protoze Sun serverove procesory sveho casu byly zrejme presne tim co si asi mel na mysli. A pro Sun to byl jak vidime hrob.
Jeste je teda moznost, ze si myslel mobily a tam by pausless mel skutecne opodstatneni i se vsemi puvodnimi nedostatky. 20MB aplikace s 100MB daty co ma k dispozici 2GB a je potreba, aby se "neustale hejbala".
No obavam se, ze je to presne pro opacne spektrum HW ;-) Je to cileno na servery s mnoha CPU a obrovskymi heapy (takze "enterprise" nesmysly a mracky), s kteryma maji soucasne GC problemy - dlouhe casy pri full GC + navic ten pitomej stop-the-world. Shenandoah by toto *mel* vylepsit, zatim vyvojova verze v benchmarcich (SPECjbb hlavne) dosahuje +- stejne vykonnosti jako ParallelGC, ale je to fakt vyvojova verze, ktera alespon nepada a neleakuje, coz je docela uspech ;-)
rok 2007, 64 vlaken, UltraSPARC T2 (Niagara 2) 1GHz - 1.6GHz
rok 2007, 64 vlaken, UltraSPARC T2 Plus (Victoria Falls) 1.2GHz - 1.6GHz
rok 2010, 128 vlaken SPARC T3 (Rainbow Falls), 1.6GHz
rok 2009 http://www.sec.gov/Archives/edgar/data/709519/000119312509183962/d10k.htm
ITEM 6. SELECTED FINANCIAL DATA
2009 Dollars %
Income (loss) before taxes (2,183 ) (19.1 )
rok 2010 odprodej Sun spolecnosti Oracle
Jenze Sun uz v te dobe nevedel, kam smerovat, na co se zamerit. Proste udelali spoustu prehmatu a nektery jejich vize se uskutecnily treba o deset let pozdeji (tenky klienti napriklad). Zpomaleni vyvoje Javy zacalo uz nekdy v 2008...
-
Asi to bude dusledek katovani kostu. Spousta aplikace v kombinaci s vetsinou existujicich GC pak dopada bez ohledu na jazyk/vm tak, ze je v beznem provozu tahana s nedostatecnou rezervou pro mimoradnou zatez, protoze pri mimoradne zatezi se jim krivka skalovatelnosti zalomi a "zrychli smrt". reseni to ale ma jen o nej nikdo jeste nezavadil, protoze je komplexni a z pohledu IT "mezioborove". zatim si to necham jako obchodni tajemstvi.
-
Jenze Sun uz v te dobe nevedel, kam smerovat, na co se zamerit. Proste udelali spoustu prehmatu a nektery jejich vize se uskutecnily treba o deset let pozdeji (tenky klienti napriklad). Zpomaleni vyvoje Javy zacalo uz nekdy v 2008...
rok 2005, 32 vlaken, UltraSPARC T1 (Niagara) 1 - 1.4 GHz
staci takhle? kdyz ostatni dva narazili na frekvencni fyzikalni strop a zacali pridavat jadra, tak se Sun neobtezoval k tomu frekvencnimu stropu dojit a rovnou udelal to co ostatni dva a naskocil na vice vlaken akorat jich pridal jeste vic, aby se dorovnal. a trh to asi vnimal jako menecennost.
-
Jenze Sun uz v te dobe nevedel, kam smerovat, na co se zamerit. Proste udelali spoustu prehmatu a nektery jejich vize se uskutecnily treba o deset let pozdeji (tenky klienti napriklad). Zpomaleni vyvoje Javy zacalo uz nekdy v 2008...
rok 2005, 32 vlaken, UltraSPARC T1 (Niagara) 1 - 1.4 GHz
staci takhle? kdyz ostatni dva narazili na frekvencni fyzikalni strop a zacali pridavat jadra, tak se Sun neobtezoval k tomu frekvencnimu stropu dojit a rovnou udelal to co ostatni dva a naskocil na vice vlaken akorat jich pridal jeste vic, aby se dorovnal. a trh to asi vnimal jako menecennost.
No jim se taky nepodaril vic prosadit Solaris, takze ani nemohli moc prodavat boxy se SPARCama (teda samozrejme je prodavali, minimalne v Brne vim o trech velkych firmach co Solaris+Sun HW nasazovali, ale proti te hromade jinych reseni to asi bylo dost slaby). Ale to je hlavne muj pocit, chtelo by to nejaky grafy s porovnanim nasazeni Solarisu, Linuxu, dalsich Unixu a Windows Server ed. mezi dejme tomu roku 2000-2012 (nemam po ruce :/)
-
Celkom by ma zaujimalo, kolko diskutujucich tu ma realne skusenosti s velkymi enterprise systemami. Myslim tym napr. aplikacie operatorov, velkych poistovni atp.
Ale nie ze kamarat kamarata spravuje taky system.. Okrem toho spravcovia aj tak do toho az tak nevidia. Potom sa stane, ze obcas ma aplikacia nejaku chybu, ktora vobec nesuvisi s tym na com bezi a uz to ma ta platforma zratane..
Ohladne sunu ja to vidim tak, ze pre mensie firmy bol zbytocne drahy (oproti napr. wintel platforme) a tie co to skutocne potrebovali uz davno bezali na ibm.
-
Protoze Sun serverove procesory sveho casu byly zrejme presne tim co si asi mel na mysli. A pro Sun to byl jak vidime hrob.
Hrob Sun procesorů byla architektura RISC, která je silně nevhodná v kontextu dnešních pamětí a s přechodem na 64-bit začala být situace neúnosná. Stejně tak skončili i jiní RISC veteráni jako Alpha, PowerPC a další a i Intel si zavařil s Itaniem.
Pro případné šťouraly: Bavíme o high-end serverech, ne o telefonech.
staci takhle? kdyz ostatni dva narazili na frekvencni fyzikalni strop a zacali pridavat jadra, tak se Sun neobtezoval k tomu frekvencnimu stropu dojit a rovnou udelal to co ostatni dva a naskocil na vice vlaken akorat jich pridal jeste vic, aby se dorovnal. a trh to asi vnimal jako menecennost.
Trh především vnímal jako méněcennost že ty Ultrasparc měl sice hodně jader, ale tyto jádra byly poměrně pomalé a hlavně byly hloupé, neměly spoustu vymožeností jako brach prediction, speculative executing a ani FPU. U konkurence měli jader méně, uměli maximálně dvě vlákna na jádro, ale ty jádra měli plnohodnotné, včetně FPU a SSE pro každé jádro. Když se k tomu přidala výhoda CISC, tak bylo rozhodnuto.
-
Stejně tak skončili i jiní RISC veteráni jako Alpha, PowerPC a další a i Intel si zavařil s Itaniem.
IBM power pořád ještě prodává, ne?
-
IBM power pořád ještě prodává, ne?
Stále ještě ano, jako stále se ještě prodává UltraSparc, ale je to s nimi silně nahnuté.
-
Protoze Sun serverove procesory sveho casu byly zrejme presne tim co si asi mel na mysli. A pro Sun to byl jak vidime hrob.
Hrob Sun procesorů byla architektura RISC, která je silně nevhodná v kontextu dnešních pamětí a s přechodem na 64-bit začala být situace neúnosná. Stejně tak skončili i jiní RISC veteráni jako Alpha, PowerPC a další a i Intel si zavařil s Itaniem.
Pro případné šťouraly: Bavíme o high-end serverech, ne o telefonech.
Ano klasická RISC architektrua s "širokými" a současně i jednoduchými instrukčními slovy těmito problémy trpí a zhruba mezi roky 2000-2009 se to pořád zhoršovalo (relativně rychlejší nárůst frekvence CPU oproti pamětem), ale ono většinu ne-x86 platform zabila spíš klasická "economy of scale", tj. Intel dokázal díky milionům prodaných CPU lépe rozložit náklady na vývoj a částečně i na výrobu. Takto skončila i řada 68k (vím, ještě se pořád uplatňuje, ale marginálně), což je CISC jak vyšitý :-)
-
ale ono většinu ne-x86 platform zabila spíš klasická "economy of scale"
Proč myslíš, že se to vyhlo ARMu, který naopak spíš roste? Jednodušší čistější architektura? "Vlastní trh", na kterém mu x86 nekonkuruje?
To některé architektury, které umřely, měly taky, ne?
Nebo prostě lepší management?
-
ale ono většinu ne-x86 platform zabila spíš klasická "economy of scale"
Proč myslíš, že se to vyhlo ARMu, který naopak spíš roste? Jednodušší čistější architektura? "Vlastní trh", na kterém mu x86 nekonkuruje?
To některé architektury, které umřely, měly taky, ne?
Nebo prostě lepší management?
ARM není klasický RISC, ale jeho instrukční sada dovoluje generovat "hutnější" kód, takže rozdíl v rychlosti CPU/paměti není tak dramatický jako u MIPSu a SPARCu (pozor: AArch64 je zcele odlišný od 32bitových ARMů). Navíc jak píšeš - ARM má vlastní trh a ještě k tomu navíc odlišný licenční model; firmy si mohou koupit právo na výrobu vlastních čipů s ARMovským jádrem, což je pro embedded věci, tablety a další podobná zařízení dost dobré.
-
Proč myslíš, že se to vyhlo ARMu, který naopak spíš roste? Jednodušší čistější architektura? "Vlastní trh", na kterém mu x86 nekonkuruje?
Protože spotřeba, spotřeba ARM RISC je o něco nižší a povšimněte si že se v oblasti počítačů prosadil jenom v zařízeních na baterie, nikoliv v desktopu nebo serverech.
Jelikož jsou ale uživatelé telefonů a tabletů stále nenažranější a chtějí vyšší výkon a 64-bit, bude se historie opakovat.
-
Proč myslíš, že se to vyhlo ARMu, který naopak spíš roste? Jednodušší čistější architektura? "Vlastní trh", na kterém mu x86 nekonkuruje?
Protože spotřeba, spotřeba ARM RISC je o něco nižší a povšimněte si že se v oblasti počítačů prosadil jenom v zařízeních na baterie, nikoliv v desktopu nebo serverech.
Jelikož jsou ale uživatelé telefonů a tabletů stále nenažranější a chtějí vyšší výkon a 64-bit, bude se historie opakovat.
a v SOHO infrastrukture 24/7 aplikacich nebo jim se blizicim.
-
IBM power pořád ještě prodává, ne?
Stále ještě ano, jako stále se ještě prodává UltraSparc, ale je to s nimi silně nahnuté.
Citation needed. Podle toho co jsem videl na poslednich Power serverech tak bych rekl, ze IBM je porad jeste hodne napred pred Intelem. Alespon to se vykonu a podpory virtualizace tyka. Horsi je to ale s cenovou politikou.
-
Citation needed. Podle toho co jsem videl na poslednich Power serverech tak bych rekl, ze IBM je porad jeste hodne napred pred Intelem. Alespon to se vykonu a podpory virtualizace tyka. Horsi je to ale s cenovou politikou.
Taky jsem měl pocit, že se o novějších powerech mluvilo v superlativech, ale asi to tak slavný nebude:
Total systems revenues decreased 19 percent, and revenues from Power Systems were down 38 percent compared with the 2012 period. Revenues from System x were down 18 percent. Revenues from System z mainframe server products increased 6 percent compared with the year-ago period.
http://techcrunch.com/2013/10/16/ibm-revenues-down-1-billion-for-third-quarter-as-hardware-sales-falter-with-popularity-of-the-cloud/
-
Jen tak pro zajimavost (re "vitezna" x86 platforma): http://www.bloomberg.com/news/2013-12-13/intel-seen-threatened-as-google-mulls-own-server-chips.html
-
Citation needed. Podle toho co jsem videl na poslednich Power serverech tak bych rekl, ze IBM je porad jeste hodne napred pred Intelem. Alespon to se vykonu a podpory virtualizace tyka. Horsi je to ale s cenovou politikou.
Taky jsem měl pocit, že se o novějších powerech mluvilo v superlativech, ale asi to tak slavný nebude:
Total systems revenues decreased 19 percent, and revenues from Power Systems were down 38 percent compared with the 2012 period. Revenues from System x were down 18 percent. Revenues from System z mainframe server products increased 6 percent compared with the year-ago period.
http://techcrunch.com/2013/10/16/ibm-revenues-down-1-billion-for-third-quarter-as-hardware-sales-falter-with-popularity-of-the-cloud/
vtipne je ako porovnavate predajnost s technickymi parametrami. alebo sa plynulo preslo od konstatovania "java je zla a pomala pretoze som nevidel ziadnu poriadnu aplikaciu v nej napisanu" ku konstatovaniu "nepredava sa to tak je to ksunt"?
-
vtipne je ako porovnavate predajnost s technickymi parametrami. alebo sa plynulo preslo od konstatovania "java je zla a pomala pretoze som nevidel ziadnu poriadnu aplikaciu v nej napisanu" ku konstatovaniu "nepredava sa to tak je to ksunt"?
Asi to cteme kazdy jinak,
Ja tam vidim, ze cenova politika (draha porizovaci cena) a planovani kapacity aplikace (spousta mrtve kapacity pro narazovou spicku) pomohla urychlit odchod Sunu, nadzvedla spouste spravcum mandle, protoze jim proste orizli rozpocet na 1/5 a po vystrizliveni dala vzniknout celemu novemu odvetvi - cloud. proto treba ni C aplikace a C++ bez GC netahnou cloudove prodeje.
-
a k tomu
> konstatovania "java je zla a pomala
asi tak, ze je to proste vlastnost vetsiny jazyku s GC. mezi obsazenou pameti po startu VM a padem VM s OOM je dlouha cesta a spousta mista, kde se zacne lamat pomer toho, jak rychle se dari uvolnovat pamet a kolik CPU na to GC spotrebuje. Cili standartni situace pri spicce kdy GC spotrebuje 80% CPU 20% a pritom VM je tesne pred OOM padem.
-
kdy GC spotrebuje 80% CPU 20% a pritom VM je tesne pred OOM padem.
kdy GC spotrebuje 80% CPU 20% necha aplikaci a pritom VM je tesne pred OOM padem.
-
Vy, co nadavate na pomalu Javu - skusili ste uz ine JVM?
Ja som mal problemy s vykonom / nedostatkom pamati este v dobe Javy 1.5, nasadil som JVM od IBM a pri desktopovom pouziti to subjektivne velmi pomohlo. Po kupe noveho PC som Javu neriesil a pouzivam OpenJDK a tak si netrufam tvrdit, ze je na tom IBM Java stale lepsie. Za pokus to stoji.
-
To handrkovani je zbytecne. Jde jenom o pouziti vhodneho nastroje pro dany problem. Tak jak je Java koncipovana a jake jsou k dispozici implementace virtualnich stroju a knihovny, je nesmysl v ni delat narocne hry, kde se pocita s kazdym framem a tikem procesoru. Nebo pro drobne systemove utilitky, s velkou frekvenci spousteni/ukoncovani. Nebo pro zarizeni na mikrocipech s malou pameti. Dovolim si tvrdit, ze je nevhodna i pro desktopove aplikace (rozezranost JVM na pamet, pomalejsi start, pocatecni latence).
Na strojich, ktere jsou zcela vyhrazene pro jednu nebo par aplikaci ktere trvale bezi to naopak dava dobre vysledky. Proto se asi uchytila jako nastroj pro enterprise sluzby a ne treba na domacich desktopech. Minecraft je takova vyjimka potvrzujici pravidlo ;-) I kdyz tam jde spis o myslenku, technicke zpracovani zejmena grafika je spis usmevna. Nehlede na to, kdyz si ho pustim vedle treba Netbeansu, tak to sezere ~ 1 GiB pameti, coz je na IDE v zakladu a celkem prostou hru docela narez. Nastaveni limitu alokovane pameti pro JVM jde jen castecne, kdyz to prepisknu zacne to brutalne lagovat.
Na desktopu se ji vyhybam jako cert krizi i pres teoreticky slusnou rychlost behu, ktera se v praxi moc neprojevuje. I LibreOffice poustim bez ni, jinak je to na odbehnuti si pro kafe.
-
Radeji bych dal slovo nekomu, kdo tomu rozumi: Karal Rank v CZ Podcastu: http://java.cz/article/cz-podcast-90-psani-low-latency-java-aplikaci
(disclaimer - se vsemi zucastnenymi se znam)
-
Wtf? Normalni 4 jadrovy XEON s HT, server za cca 60 klacku. Ja tady nedavam zadne odhady, ale ciste fakta. http://www.youtube.com/watch?v=R6Sn4UWlZ0M wtf omg!
Diky, zajimava prednaska.
-
Patrně je to agregovaný výkon jednoho racku.
Wtf? Normalni 4 jadrovy XEON s HT, server za cca 60 klacku. Ja tady nedavam zadne odhady, ale ciste fakta. http://www.youtube.com/watch?v=R6Sn4UWlZ0M wtf omg!
Diky, tohle video jsem zatim nevidel. Avasty je vetsinu celkem zajimave si poslechnout.
-
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
Díky za zajímavý odkaz.
Ještě mě napadlo (jako vždy kravina), že Java je pomalá proto, že jí nevymýšleli matematici.
-
Asi nevies o com je computer science (napr http://en.wikipedia.org/wiki/James_Gosling)