Co přinese další generace virtuálních машин? (diskuse)

[Ilfirin]

No, zjistilo se, že to nebude tak žhavé (respektive železo žhavé bylo, ale program se nehýbal), tak se začalo optimalizovat.

Tak tohle mě rozesmálo, díky.

[ajikdpoe]

to sú ale žvásty

[Martin Baleja]

Sorry, ale nemuzu si pomoct: To vypada na komentar "pubose", ktery s programovanim zacinal v Jave pred necelym rokem na dvojkovem pocitaci (2 jadra, >2 GHz, > 2GB RAM) a nedostal se dal nez k "Hello World". Nebo se pletu?

[alblaho]

Ale třeba má pravdu, jsou to tak trochu žvásty, to se přiznám

[Honza Jaroš]

Ovšem i já si vzpomínám na první setkání s Javou tuším že v pětadevadesátém (mám pocit, že jsme ještě jeli pod Windows 3.11) a pamatuju si, jak jsem u tehdy celkem průměrného stroje čekal na spuštění prohlížeče HotJava několik minut...

[Michal Kubeček]

To mi připomíná, jak jsem si kdysi celý natěšený nainstaloval první veřejně dostupný StarOffice a pak jen nevěřícně zíral, jak může něco spotřebovat veškerou paměť a k tomu navíc provádět zátěžový test procesoru a disku, aniž by byla vidět nějaká produktivní činnost... :-)

[s0]

jo, a pak na tebe po pár minutách vyskočil ten StarDesktop, odkud se konečně spouštěly jednotlivé programy, Které ovšem také pár minut chroupaly celým HW než se poo-maaa-luuuu vykreslily.

Někdy si připadám jako zasloužilec. Takže teď tu historku o tom, jak jsme na schodech rozsypali balík děrných štítků...

[Honza Jaroš]

Pamatujete, jak nám tehdy došlo palivo v chlazení u ENIACu...?

[Michal Kubeček]

Tak to nemohu sloužit. To mne o pár let minulo. Když jsem nastupoval na matfyz, byl už tam dokonce čerstvě přiveden Internet. :-)

[Aleš Kapica]

No tak to mě teda silně překvapuje, protože na notebooku co jsem měl k dispozici na přelomu r.1999-2000 s pentiem 133 MHz s 96 MB paměti (panasonic přímo z japanu) fungovaly staroffice 5 docela svižně.

[Michal Kubeček]

Tou dobou jsem z 233 MHz K6 s 32 MB přecházel na 650 MHz Athlon s 128 MB. Na obou měl StarOffice do svižnosti zatraceně daleko.

[trekker.dk]

Svižnost je subjektivní veličina velmi silně ovlivněná tím, jak moc člověk pije kafe (nebo vlastně cokoliv) při práci.

Přece jenom programy jsou svižnější v případě, že spustím - zvednu hrneček - napiju se - položím hrneček - můžu pracovat. Když nemám co pít, tak spustím - trvá dlouho - trvá dlouho - trvá dlouho - konečně můžu pracovat.

Za "spustím" lze přitom dosadit prakticky jakoukoliv akci při běhu programu.

[thingie]

Což pak vede i k spustím - jdu na záchod - přijdu ze záchoda - můžu pracovat. A to už se toho stihne ještě víc.

[Zdenek.Z]

Nebo pustím, jedu na dovču, vrátím se a mů6u pracovat.

[Aleš Kapica]

Mohu nabídnout hned několik lidí, co se v počítačích a jejich hardware tou dobou dost hrabali na to, aby potvrdili že ten stroj byl neskutečný. Při těch parametrech co měl hravě výkonově překonával desktopy s nominálně větším výkonem.

Ten stroj byl mírná ojetina od jednoho japonce. Sem se ty panasonicy nikdy ani nedovážely, takže všichni mají tuhle značku spojenou tak maximálně s videorekordéry. Ovšem šlo o naprosto špičkový stroj. Bohužel se po roce a půl intezivního používání upekl. Přeci jenom už měl něco najeto.

[Luboš Doležel (Doli)]

Hmm, já jsem měl také za to, že JIT kompilace nebyla od úplného počátku.

[Kyosuke]

To sice nebyla, ale přesto něco podobného fungovalo už na PDP-10 blahé paměti.

[ajikdpoe]

No asi ta sklamem, s programovanim som zacal okolo roku '91, na Atari 800XL, serioznejsie az ked som dostal prvu 286tku (cca '93).

[Martin Tůma]

Troufnu si tvrdit, že řada monstrózních enterprise javovských aplikací by po přepsání do, řekněme C++, stejně nebyla rychlejší.

Zkus si o tom popovídat s vývojáři Microsoftu, kteří po 3 letech vývoje Windows Vista zahodili veškerou dosavadní práci psanou v C# a z důvodu extrémní pomalosti všechno přepsali do C++...

[alblaho]

No, tohle znám, je to fakt sranda.

Od té doby jsem toho názoru, že systémové knihovny musí být _opravdu_ rychlé (a tedy v C/++). Programovat GUI aplikace v Pythonu? Klidně, ale nad Qt nebo Gtk. Žádný Swing... Oni ti mikrosofťáci v .netu taky používají "poctivé" Win32 gui.

[Kvakor]

Kdysi se delaly stroje, co byly hardwarove optimalizovane na to, aby na nich bezel bezel Lisp - viz Lisp machines. No a s Javou ted prichazi neco podobneho, alespon pro mobily - ARM dela procesory, co dovedou primo chroustat Java bytekod. Takze si klidne dokazu predstavit, ze driv ci pozdeji nekdo s necim podobnym prijde i pro dnesni skriptovaci jazyky, treba s necim jako "skiptovaci koprocesor", postaveny na treba zaklade nejakeho FPGA. Protoze se obavam, ze ne vsechny skriptovaci jazyky budou umoznovat JIT kompilaci jako Java, ktera na to byla diky jednoduchsti JVM celkem dobre pripravena.

BTW: Problemem C/C++ neni GC. Knihovny na GC existuji a chodi docela slusne (viz treba Boehm-Demers-Weiser Garbage Collector). Problemem je to, ze jazyk umozni delat programatorovi akce, ktere jsou potencionalne nebezpecne (sahat primo do pameti, popr. na porty, prepisovat zasobnik, pretekat meze poli a delat rozlicne brikule s ukazately). Jenze kdyz zakazete delat veci, ktere mohou byt spatne, zakazete tim i spoustu veci, ktere mohou byt dobre. Proto i pres predpovedi propagatoru Ady, Javy, C# a podobnych jazyku ma C a C++ stale svoje misto na slunci, stejne jako ostatni "stare" jazyky z "pocitacoveho davnoveku", jako Lisp, Prolog a Fortran.

[Kyosuke]

U malých programů to opravdu platí (GC má prostoje).

Jestli se těmi prostoji rozumí pauzy GC, pak upozorňuju, že existujou i softrealtimové garbage collectory (jeden z nich má třeba RScheme). Pokud jde o amortizaci správy paměti, pak přinejmenším malloc+free v porovnání s GC absolutně neobstojí, aspoň tedy podle měření mnohých lidí. Leda psát si vlastní alokátory, a to se asi pro většinu věcí buď nevyplatí, nebo to rovnou nejde.

Virtuální stroj pro dynamické jazyky, který by byl dostatečně rychlý a ještě by třeba takových jazyků zvládal víc, mohl věci pěkně pošoupnout.

Takových existuje... Třeba všechny implementace Common Lispu, protože přenést snad všechny vlastnosti třeba Ruby 2 do implementace, co jako backend používá třeba Allegro, LispWorks nebo SBCL by nebyl až takový problém. Požadavek na virtuální stroj bohužel nesplňují, všechno se v nich kompiluje pěkně nativně. Otázka je, kdo se bude psát s parserem pro Ruby. Ale třeba PyPy už CL backend má. Otázka je, jak dobrý - nezkoušel jsem. Nicméně do objektových runtimů Allegra a LispWorks už napumpovali milióny dolarů a umí to všechno, co Python a Ruby potřebují (na rozdíl od JVM).

[alblaho]

No, u toho GC jsem to myslel tak, že správně umístěné free() uvolní paměť okamžitě, ale GC obvykle až po nějaké době. Stop-the-world efekt jsem nemyslel. Samozřejmě třeba reference-counting uvolní paměť hned a jsou též všelijaké paralelní GC, co svět nezastavují...

Do toho Lispu moc nevidím a moc tomu nerozumím. Popřemýšlím nad tím ráno

[Kyosuke]

free() IMHO neuvolní paměť okamžitě, nějakou dobu mu to přeci jen trvá. Průšvih začne ve chvíli, kdy správa paměti začně tvořit postatnou část run timu. Ale ouplně nejlepší je pořádný kompilátor, co umí garbage eliminovat bez GC...jako třeba Stalin. Možná to dělá i GHC, to netuším.

[thingie]

free() to má chudák vůbec těžké.

[Ladicek]

Počítání referencí, AFAIK, je výpočetně náročnější než běžné typy "poctivých" garbage collectorů. Jinak co vím, tak dnešní alokátor v Javě je rychlý dost (v Java Concurrency in Practice se uvádí 10 instrukcí procesoru pro průměrný případ). Je to magie

[alblaho]

Jo, počítání referencí má velký overhead. Navíc je potřeba čas od času pustit detekci cyklů. Používá se to snad jen v Pythonu.

[rADOn]

Troufnu si tvrdit, že řada monstrózních enterprise javovských aplikací by po přepsání do, řekněme C++, stejně nebyla rychlejší.

Skalni javisti jsou schopni nalezt spousty duvodu proc Java _muze_ byt vykonove srovnatelna s C++. Zatim mi zadny z nich nebyl schopen vysvetlit proc jsou tedy javi aplikace tak pomale a nenazrane.

... GC nemusí být optimální, ale lehce může být lepší než taková nějaká pesimistická strategie. Cokoliv, co programátorovi ulehčí život, se hodí.

Jinak receno, hlavni vyhoda javy je ze kdyz nekdo neumi prgat nebo prga prasacky tak to za nej odre JVM. Coz by, pravda, vysvetlovalo obsesi Javy vnutit programatorovi ten "jediny spravny" styl programovani.

JVM je nyní brutálně optimalizovaný a složitý kus softu. Ale zároveň je to široce akceptovaná technologie pro psaní obrovských aplikací. Proč?

Protoze se stala modni vlnou. Protoze spousta takyprogramatoru bastlicich visual basic najednou mohla byt "enterprise" aniz by si musela namahat hlavicky.

Dočkáme se doby, kdy budou enterprise aplikace skoro výhradně v Ruby/Pythonu/Groovy/Perlu/whatever a Java se bude používat je na speciality?

Ja doufam ze se dockame doby kdy se enterprise aplikace budou psat v tom jazyce ktery je pro ne nejvhodnejsi a ne v tom co je zrovna v mode.

---

Noflame disclaimer: Jestli to vypada ze nemam javu rad tak je to mylka. Nemam rad javisty kteri z ni delaji reseni na vsechno.

[thingie]

> Jinak receno, hlavni vyhoda javy je ze kdyz nekdo neumi prgat nebo prga prasacky tak to za nej odre JVM.

Pod poznámkou o GC čirý bullshit.

[podlesh]

Noflame disclaimer: Jestli to vypada ze nemam javu rad tak je to mylka. Nemam rad javisty kteri z ni delaji reseni na vsechno.

Tohle miluji: pod čistý a nefalšovaný flame napsat "No flame".

tzv. syndrom "Nejsem rasista, ale cikány bych rovnou střílel"

[wake]

Jak lze Perl neznat a zároveň jej nemít rád?

[Michal Kubeček]

Prostě se s ním člověk seznámí a pak na něj ve vlastním zájmu zapomene, aby se v noci nebudil hrůzou ze sna. A aby se zkušenost neopakovala, zachová si tu negativní asociaci… :-)

[alblaho]

No tak já ho znám, jen v něm neumím. Ale veškerý kód, co jsem viděl, se mi fakt nelíbil @#%%%.

[Elvis]

Je to vec nazoru. Ja ho znam, obcas v nem neco napisu a na nektery veci je proste super.