Rozhovor: Proč je NAVRCHOLU.cz v Javě? (diskuse)

[mira]

diky za zajimavy clanek, zajimal by me ten bod "kvůli opakujícím se problémům s ReiserFS" ... slo by to rozvest? Reiserfs celkem masivne pouzivam, vlastne vsude kde se da, jsem celkem spokojeny

diky!

[Petr Kos]

Taky by mě velmi zajímalo, o jaké problémy šlo.

[Jetty]

Taky be mě to zajímalo. Nikde jsem ho nepoužíval, používal jsem XFS, až včera jsem ho poprvé nasadil na svůj notebook, když v Gentoo Handbook píšou, že XFS doporučují jen na zálohované SCSI disky. Tak ať to kdyžtak ještě včas znofu zformátuju, než je tam mnoho dat

[Jan Molic]

S reiserem mam velmi dobre zkusenosti, zejmena pri praci s mnozstvim hodne malych souboru je oproti XFS citelne rychlejsi, takze se pripojuji k dotazu.

[Michal Krause]

Ten problém spočíval v tom, že se nám opakovaně na několika serverech používajících ReiserFS některé soubory stávaly samovolně zcela nepřístupnými. Nejde je číst, nejde je smazat, nejde je přepsat, nejde s nimi udělat naprosto nic. Podotýkám, že práva a atributy (lsattr) byly v pořádku.

Těžko říct, zda by to nespravil reiserfsck, ale protože jeden náš FS (naštěstí testovací) dokázal v podstatě definitivně zničit, netroufli jsem si ho spustit (ale v tomto případě je třeba říci, že jde o zkušenost zhruba rok a půl starou - dnes už to může být úplně jinak). Na XFS jsem měl celkem dobré reference od pár známých, takže jsme to zkusili a zatím jsme s ním naprosto spokojeni.

[Ctirad Feřtr]

A nepoužíval jste některé z těch starých jader o kterých je známo, že tam v reiseru měly nějaké chyby ?

Osobně totiž už cca dva roky dávám reisera všude a nikdy jsem nic podobného nezaznamenal. Dokonce jsem zažil i extrém, kdy se vlivem chyby HW jeden těžko přístupný stroj kousal snad každou půlhodinu a po zresetování watchodogem vždycky poslušně najel a takhle to trvalo snad týden, aniž by došlo k jakémukoliv nakopnutí filesystému.

[bk]

Ja pouzival ReiserFS nekolik let na desktopu a behem te doby se mi dvakrat stalo, ze vytuhlo jadro a po nabootovani byl filesystem masivne poskozen, takze bylo nutne system reinstalovat. V soucasne dobe pouzivam Reiser4 a stezovat si rozhodne nemuzu...

[Tomáš Bžatek]

Souhlas, pouzivam na systemovou partition taky Reiser4 a zatim naprosto bez problemu, rychlost vynikajici

[Neci]

chcem len upozornit na malicku chybu a to "Xeon 2,8 MHz" asi tam ma byt G :)

[Leoš Literák]

dik

[paja]

tiez ma zaujma riesenie toho problemu zo sietovim diskom. mame u nas 8 disklessov na jadre 2.6 a serever tiez jadro 2.6 a jeden z 20 startov zlyha pretoze nepripoji / . ale hlavne kazdy znich vytuhne aspon raz za den. take iste gentoo na takom istom stroji ale z hdd nema ziaden problem. viacej nfs procesov, softmount, hardmount zmena dalsich parametrov neprinasa ziadnu zmenu. dik.

[Cyclone]

Pokud jak zde pises ... se ti nelibilo PHP z duvodu nadmerne spotreby pameti. Proc jsi presel k Jave ? Co jsem vydel testy jazyku "pro web". Tak prvni byl myslim mod_perl pak mod_php a pak nekde v zadu Java s nekolika nasobnou spotrebou pameti? .. nic mene se nedivim php je opravdu pro male projekty. Ne ze by se to v tom nedalo napsat. Php se da psat hodne neciste...

pokud se pletu, omlouvam se. btw. NoFlame

[Karel Zak]

Skoda, ze Michal nakonec vymeknul a zadnu DB nepouzil Zajimalo by mne par cisel (na ktere se celkem nepochopitelne LL nezeptal...) pokud nejsou tajna: pocet requestu za den, ve spicce a pripadne rozlozeni z hlediska agregace (teba 1% ze vsech sledovanych serveru dela 90% requestu apod.) a celkovy pocet sledovanych serveru. Bez alespon techto cisel si clovek tezko udela predstavu.

A dalsi vec je skalovatelnost, lze to rozlozit na vice stroju (nejen DB a ostatni, ale treba i samotny agregator na vice masinach apod.)?

Jinak pokud duvodem k pouzivani NFS/SMB je sdileni DB tak mi to pripada jako hodne sverazne reseni.

[Linear]

Java je ve vyuzivani pameti naprosto neefektivni (stejne jako .net a jine gc-based systemy). Nejlepe to poznate pokud potrebujete obcas vytvorit 50 tisic malych objektu, nasledne je uvolnit a tak kolem dokola. V podobne situaci, moje Java aplikace zabrala 200-300 MB Heapu, zatimco jeji C++ verze (STL-based) vyuzije 30 MB. Samozrejme, pokud bych v C++ udelal new() na kazdy objekt zvlast, budu mit stejnou spotrebu jako javovsky vector, ale proc bych to delal kdyz mam STL vector? Secteno podtrzeno, Java se da srovnavat s C++ pouze v pripade aplikaci ktere nevytvareji/nemanipuluji s velkym poctem objektu v pameti (CAD, Hry, GIS...). V techto aplikacich ma pouziti Javy tragicke nasledky (swapovani). Proto zadny spickovy CAD ani Hra v Jave napsana neni, pritom by to bylo daleko jednodussi/produktivnejsi.

[kolisko]

Samozrejme, pokud bych v C++ udelal new() na kazdy objekt zvlast, budu mit stejnou spotrebu jako javovsky vector, ale proc bych to delal kdyz mam STL vector?

Muzu se zeptat, cemu pripisujete vetsi spotrebu pameti? Je to vetsi rezii datovych objektu nebo tim, ze u Javy lezi v pameti pomerne dost mrtvolek?

[bigsam72]

No GC-based memory managament je proste "cena" za efektivnost a rychlost vyvoje.

Zatimco programator ktery pise kod v C/C++ si nejdrive rozmysli pri skladani message jestli nahodou nemuze zaalokovat pamet "dopredu" a pak v ni poskladat message, java programator nad tim proste nepremysli a zacne pouzivat String + String + String. Ten prvni se vice nadre, riskuje ze udela memory leak, ale vysledny kod je efektivni. Ten druhy se nenadre, funguje to ale ..... tot vecne dilema.

[jk]

ja si nemyslim, ze je mozne tuto dulezitou skutecnost jen tak odlozit na stranu se slovy "tot vecne dilema."

V C MAM tu moznost, si vlastnimi prostredky dodelat tu obalku pro moji bezpecnost a pohodlnost ale v ostanich jazycich, ktere si mysli ze vedi lepe nez programator na co ktery pointer ukazuje tuto moznost NEMAM. A to je ten zasadni filozoficky rozdil.

[Leoš Literák]

jsem rad, ze tuto svobodu v jave nemam. Pointery a jejich aritmetika, to je nocni mura Schvalne srovnejte pocet utoku pres stack overflow na javove a C aplikace.

Az to Sun zoptimalizuje tak, ze start desktopovych aplikaci nebude vice nez o 20% pomalejsi nez nativni aplikace, tak to bude prulom javy i na desktop. Uz ted pouzivam denne nekolik GUI aplikaci v jave a takove IDE, to je pekny bumbrlicek Zvlaste kdyz mate projekt s tisici tridami.

[BigSam72]

No nevim nevim, java ma uz za sebou pekny kus cesty a napriklad takove Eclipse to je nastroj pro masochisty , radsi zustanu u oskliveho vimu

[deda.jabko]

kdyz si zvyknes nechces jinak, taky na Ceckove a PHP aplikace jedine ViM, ale kdyz si zvyknes na Eclipse (ano jsem masochista) nechces jinak u projektu kolem 50 az 100 tisic radku neni nic lepsiho... zalezi na zvyku... a taky na dobrem pocitaci

[Nikola Ciprich]

tak tak, taky si myslim ze eclipse je velmi kvalitni nastroj. (i kdyz priznavam ze ke koupi noveho pocitace jsem se rozhodl hlavne kvuli eclipse). a rozhodne bych ho nezavrhoval ani pro C/C++ aplikace (s CDT pluginem) a pripadne dalsi jazyky. editory jako vi/emacs (a to jsem velky priznivec emacsu) maji sve vyhody, ale ted kdyz uz jsem si zvykl na vychytavky eclipse uz bych v nicem jiem nic velkeho nepsal. vsem, kteri jeste nezkouseli a nejsou zrovna hc zasnanci assembleru vrele doporucuji k vyzkouseni. i kdyz jsou se svym editorem spokojeni - mozna budou prijemne prekvapeni.

[Radek Červinka]

viz index pouzivani programovacich jazyku dle dotazu do google (i kdyz si myslim, ze to neni uplne presne meritko, jelikoz vetsina lidi uz ma nejake knihvny nebo komponenty, takze se furt znova neptaji)

http://www.tiobe.com/tpci.htm

jo a proto programuji v Delphi, kde mam OBE moznosti (pokud je umim vyuzivat), (tj, lehkost a bezpecnost programovani v JAVE, skvely memory manager - RTL si vezme blok pameti od OS a pak ho sam rozdeluje a 95% moznosti a silu C + integrovany assembler :) ), upozornuji ze kdo mi chce odporovat musi rict, ze udrzuje program kteryma vice nez 10000 radek kodu :) (muj aktualni projekt ma 80000+ radek).

[Peter Figuli]

Neviem, ale po mojich skusenostiach v jave mam pocit, ze prave tato tema je zbytocne davana do popredia bez prihliadnutia k dalsim podstatnejsim moznostiam tohoto jazyka. Tak trochu mi to pripomina dobu 15 rokov dozadu, ked som na 386ke mal pocit, ze C++ a OOP je sice pekna hracka, ale za stratu vykonu to nestoji. To som ale nemusel robit nieco vacsie ako aplikaciu na domace CD
Vykon sa castokrat prejavuje viac v algoritmoch, ako v realnej implementacii. Ak sa pozriem na Vas priklad String + String + String, hned ma napada StringBuffer. Ano je tam viacej alokacii aj pri StringBuffer, no co je podstatne, ze sa udaje nekopiruju pri zvacseni pola, ale robi sa zoznam takychto stringov. Nakoniec sa vyalokuje vysledne pole a kopirovanie je len jedno... V kolkych pripadoch vaseho algoritmu musite nakoniec postupovat rovnako? Ak ste masochista, nikto vam nebrani si urobit pole char a pouzivat ho...
Ak by som mohol upriamit vasu pozornost na par pre mna podstatnych veci:

• zabranenim destruktorov sa vyrazne odburali memory-leaky a memory pady - ak aj poslete referenciu na alokovanu pamat "prec", nemusite sa bat, ze ju neskor niekto zabudol uvolnit, alebo naopak uvolnil, ked nemal
• zrusenie globalnych premennych, #ifdef, povinnosti OOP a takmer nemoznosti napisat aplikaciu v jednom subore sa vyrazne zvysila citatelnost kodu, jej refaktoring a znovupouzitie
• neuverilna stabilita - ked som zacinal niekedy s NetBeans 2.x, tak sice obcas nefungovali (padali aj NULL pointer exception), no aplikacia to skoro vzdy rozhodila
• OS/vendor indepence, pricom existuje len jedna Tym narazam na x verzii prekladaca Cka, exoticke OS dependent kniznice ala VCL a podobne. Samozrejeme pripustam, ze v jave je tiez mozne takto orientovane aplikacie/kniznice vyrabat, no pri beznych veciach ako GUI, sockety, File access, DB access a podobne sa to nedeje. Ak si ale spomeniem na autoconf madness - myslim, ze je to naozaj niekde inde
• Zmena pohladu na riesenie problemov - ked uz nemozem "optimalizovat" na low level scitavanie stringov a stratu vykonu na kontrole pretecenia bufferov, viac sa sustredim na podstatu problemu - a tu je ten nas cas a rychlost

PS: Uff uz je to moc dlhe na prispevok, takze uz len maly detail, ktory podla mna hovori asi za vsetko: Tomcat vs Apache
PS2: Vznik C# od MS podla mna potvrdilo, ze java nie len predbehla svoju dobu, ale urcila aj smer, ktorym sa urcite budeme dalej uberat...
PS3: Nizsie spominane memory leaky. Priznam sa, ze este som nevidel memory-leak sposobeny chybou GC, no poznam implementacie "javistov", ktori maju pocit, ze sa uz naozaj nemusia o nic starat Urobia si klbko strong referencii, ktore GC len ztazka rozmota a mame to... Ale aj tu je treba jazyk poznat, pripadne mat "spravny" navrh, ale to je uz o ludoch, ktori ho pouzivaju (WeakReferencie)

[Michal Kubeček]

Vždy mne pobaví, když si někdo myslí, že omezením jazyka donutí programátory psát čistě a přehledně. Kdo nemá sebekázeň, bude své prasečí konstrukce používat stejně, ať je to v Javě nebo v C kriminál. Jediné, čeho dosáhnete, je, že ty nečisté triky budou navíc ještě neuvěřitelně krkolomné a nepřehledné. A občas samozřejmě budou neuvěřitelně krkolomné a nepřehledné i zcela legitimní konstrukce, které měly jen tu smůlu, že se autorovi jazyka nehodily do jeho dogmatu.

[gregy]

no nerekl ze to je cena GC - v lispu (mimochodem pro nej byl vymyslen GC) jsem takove pametove naroky nezaznamenal - a to se v nem v 70letech psali OS. mohlo by to ale byt stylem programovani - funkcionalni me pripada vhodnejsi - objekty me nevisi na promennych.

[Lukáš Zapletal]

Java je ve vyuzivani pameti naprosto neefektivni...

Zalezi jak na co. JRE samozrejme uz umi recyklovat objekty a podobne finty. Nekdy se GC muze i hodit a urychluje beh aplikace - zejmena jeji ukonceni. Proste to co jste napsal neplati vzdy.

Urcite neni zcela spravne vytvoret hloupe 50 tisic objektu. Jak jste podotknul, neni to vhodne ani pro C++, natoz pro Javu. A uz vubec nechapu, co se snazite resit pomoci kontejneru Vector, ktery je pochopitelne i v Jave. Jestli myslite nejakou linou inicializaci, tak tim se nic neresi.

Nerelevantni je tvrzeni, ze se (Java) proste neda srovnavat s aplikacemi, kde se vytvori statisice objektu. Java je objektove orientovany jazyk, proste se v ni vytvari tisice, desetitisice i statisice objektu. To je proste tak. A ze i velike programy jsou dnes napsany v Jave (nejen CAD, hry nebo databaze) je myslim kazdemu jasne.

Doporucil bych Vam nejakou knihu o optimalizaci Javy, nez zacnete "srovnavat". Zacit muzete manualovou strankou JRE, protoze staci napriklad jen par parametru (nastavit spravne HEAP) a ejhle -- neswapuje to. A kdyz mate zkusene programatory, kteri vedi, jak programovat (v Jave), muzete se pustit bez starosti i do nejakeho CADu.

[Linear]

Mozna by sis mel precist muj prispevek jeste jednou. "Hloupe" vytvaret 50 tisic objektu musi spousta aplikaci: napr. takovy CAD model ma klidne i mnohem vice nez 50 tisic objektu ktere musi zpracovat v pameti. V 99.9% pripadu, autory aplikaci pouzivaji C++ objekty. Pokud by totiz pouzily Javu, pamet by jim nestacila anebo by se museli uchylit k trikum (napr. dat vsechny objekty do bajtoveho pole a parsovat je odtud, jako to dela map24.com). Kdyz uz jsem u map24.com, to je dobry priklad pro GIS. Mesto ma klidne vice nez 50 tisic objektu a zase: v C++ pohoda, v Jave obrovsky problem. Ad: STL Vector versus Java Vector: U STL vectoru vyuziti pameti rovna se velikost objektu * pocet objektu (+-). U Java vectoru kazdy objekt se alokuje zvlast takze je to stejne (jak jsem uz psal) jako kdyby STL udelal pro kazdy objekt new(). V praxi to znamena mnohonasobne vyssi vyuziti pameti.

[kolisko]

Ad: STL Vector versus Java Vector: U STL vectoru vyuziti pameti rovna se velikost objektu * pocet objektu (+-). U Java vectoru kazdy objekt se alokuje zvlast takze je to stejne (jak jsem uz psal) jako kdyby STL udelal pro kazdy objekt new(). V praxi to znamena mnohonasobne vyssi vyuziti pameti.

Prominte, ale stale tomu nerozumim. Mohl byste to vysvetlit podrobneji nebo me odkazat na relevantni zdroje? Uplne presne si uz nevybavujju, jak funguje STL Vector, ale z Vaseho prispevku predpokladam, ze pri vzniku instance Vectoru alokuje jiz nejaky prostor a v nem vytvori nekolik (napr 50) instanci pozadoveneho objektu. Ale to znamena, ze jsou objekty ve Vectoru ulozeny hodnotou a to s sebou nese jiste problemy pri pridavani.

Druhou moznosti, jak si drzet objekty ve vektoru, je pamatovat si na ne odkazy. To s sebou nese jistou pametovou rezii: tak 2B na odkaz + nejaka mala rezie, ktera bude po rozpocitani na jednotlive prvky vektoru asi tak desetina bitu (nebo min, zalezi na poctu prvku a implementaci).

Stale tu ale nevidim souvislost pametove narocnosti s vytvarenim objektu pojednom vs. en bloc. Muzete mi to prosim objasnit?

Jinak s Vami souhlasim, ze mit aplikaci s 50 * 10^3 objektu je celkem normalni. V takovych aplikacich je vsak relativne malo typu objektu. V tom pripade je mozne tyto objekty recyklovat misto mazat a znovu vytvaret. Jiste je to prace navic (pokud to jiz nepodporuje VM), a v tom pripade je na zvazeni, zda je pracnejsi obejit se bez vymozenosti Javy nebo muset delat v Jave vlastni recyklaci.

Co se tyce poctu programu typu GIS, CAD, ale i office napsanych v jave: myslim, si, ze Java je z pohledu techto programu velmi mlada -- v tom smyslu, ze zacala byt pro tyto ucely pouzitelna teprve pote, co tyto programy meli za sebou jiz nekolik uspesnych komercnich verzich (a jsou tedy napsany napr. v C). Firma, ktera vyrabi takovyto software pak musi nutne zvazit, jestli ji prepsani programu do Javy prinese vic vyhod nez nevyhod. Znamena to totiz, ze se nejakou dobu nebudou pridavat nove funkce, ze je potreba preskolit programatory, kteri pomerne dlouho dobu nebudou mit v Jave takovou vykonnost jako v C, prijmout nove programatory misto tech, co firmu kvuli jave opustili, a zaskolit je ve firemnim know-how. Prepracovat/koupit podpurne a vyvojove nastroje. A co je ze vseho nejhorsi, ze prepisovanim se nutne zavlecou nove chyby, ktere bude nutne odstranit.

Osobne se tedy domnivam, ze prevedeni komercne uspesneho a rozsireneho programu z jednoho programovaciho jazyka do druheho se pohybuje na hranici pricetnosti. Proto IMHO mame tak malo programu v Jave.

[kciii]

Predpokladam ze v povodnom prispevku autor uvazuje standardny new teda malloc. A pre naozaj male objekty a naivny malloc moze vznikat velky overhead. std::vector uklada objekty hodnotou (co ma svoje nevyhody) ale zbavuje problemov s neefektivnym malloc.

[Linear]

Je to tak. Pro STL vector ktery ma dejme tomu 50 objektu po 16 bajtech se alokuje 800 bajtu (je to dynamicke, po vlozeni 51. se to treba rozsiri na 1600 bajtu pro dalsich 50 elementu, ale to je ted jedno). V Jave Vector nema informaci jaky typ objektu v nem bude ulozen, takze musi ukladat jen ukazatele, zatimco skutecny objekt se alokuje zvlast. Alokace mnoha malych objektu znamena fragmentaci pameti a tim padem pouziti mnohonasobne vetsi kapacity Heapu nez je nutne, a take GC v tom pripade musi pracovat na plne obratky aby zjistil co lze/nelze uvolnit. Nova verze (5.0) JVM ma, pokud vim, Vectory s definovanym typem, cimz by se uvedeny problem dal vyresit. Uvidime.

[Leoš Literák]

Ja tedy to STL neznam, ale podle popisu to odpovida poli. Kdyz mate pole urciteho typu, pak se samozrejme alokuje jeho presna velikost. Jenze pokud mate obecny List, tak do nej muzete vkladat cokoliv. A taky (obvykle) predem nevite, kolik prvku v nem bude. Takze opravdu jedinou moznosti je ukladat "pointery".

Ad Java 5: zklamu vas, ale takhle to fungovat nebude. Kvuli zpetne kompatibilite je toto rozsireni jazyka pouzivano ciste kompilerem jako dalsi kontrola. Proste reknete, ze tento List bude pouzivat Stringy a on bude pri kompilaci vsude kontrolovat, zda do nej nahodou nestrkate treba Integer. Je to *jen* dalsi zpusob, jak programovat bezpecneji. Ale pri runtime to nijak nepoznate.

Jeste bych se trochu opravil u toho pole. I kdyz znate pocet prvku pole, tak v jave musite rucne vytvaret jednotlive prvky skrze konstruktor. Proste je to vlastnost jazyka. Navic v OOP malokdy znate predem presny pocet bytu, ktere dany prvek zabere. To je tak mozne u jadra v C a jeho struktur. Jenze v OOP mate ruznou hierarchii objektu, casto pouzivate stringy majici dynamickou delku, nektere vnorene objekty mohou byt nedefinovane ..

Presna alokace pameti na miru velkemu poctu *obecnych* objektu je IMO nemozna.

[Linear]

Jen pro upresneni, v STL pocet bajtu take neni treba pocitat. napr. pokud potrebuju pole objektu "neco" udelam: std::vector< neco> pole_objektu_neco; pak muzu pridavat objekty: neco moje_nove_neco;
pole_objektu_neco.push_back(moje_nove_neco); a STL se postara o spravnou alokaci. Element ctu s: neco& pate_neco = pole_objektu_neco[5]; Vsimnete si take ze pri spravnem programovani v C++ nemusite VUBEC NIKDY pracovat s ukazately. Jedinou vyjimkou je komunikace s knihovnou napsanou v jazyce C (treba libpng) nebo volani funkci kernelu/glibc. Jeste dodam ze si nemyslim ze Java je spatna (sam ji casto pouzivam) ale existuje omezena skupina uzivatelskych aplikaci ktera (zatim) pro Javu neni vubec vhodna.

[kciii]

A sme opat pri tom ze kym v Jave sa v zasade vzdy pouzivaju referencie (okrem zakladnych typov) (napr. v kontajneroch). Tak v C++ mozem pouzivat v kontajneroch bud referenciu alebo hodnotu podla toho ako sa mi to hodi. Teda v C++ sa MOZEM rozhodnut (musim prijat rozhodnutie kym v JAVE nemam inu moznost ako pouzit referencie. (neuvazujem ako pouzitelne nieco take: String.getBytes()...)

[Petr Ferschmann]

Dobrý den,

v Jave díky generačnímu alokátoru nedochází k fragmentaci k paměti. Také alokátor v jave má oproti jeho C-čkové alternativě konstatní složitost (správně alokace paměti má složistot O(1) - dokud nedojde paměť - pak je to trošku složitější). C-čkový alokátor má složistost podstatně horší.

[Lukáš Zapletal]

Je každému asi jasné, že 50 tisíc objektů je zcela běžná věc. Vyjádřím se tedy přesněji: je hloupé dokola vytvářet a mazat desítky tisíc objektů pořád dokola. To jsem měl na mysli. Existují pooly objektů a podobně, Java dokonce umí objekty recyklovat.

Je jasné, že při obrovských množstvích dat bude Java aplikace rychle ztrácet dech (resp. paměť) a je nutno buď aplikaci vyladit (viz. map24) nebo (částečně) přepsat (do C++).

To, že se každý objekt alokuje zvlášť je logická daň za bezpečnost.

[Gamer]

Javu sice take nemam rad, ale:

http://www.chromethegame.com/en/show.php?800&n=50

a ten samy engine i v

http://www.xpandrally.com/en/show.php?003

Takze si trosku rozsirte obzory.

[hugo]

Co se tyce tvorby malych objektu - doporucuji Vam precist si knizku "Java - vylaďování výkonu - Účinné a efektivní strategie vylaďování" a dozvite se, jak s tim efektivne bojovat....

[Lukáš Zapletal]

Ještě lepší je Effective Java (vyšla i v překladu).

[egg]

Podle mě, když člověk píše něco většího v C++, dojde zákonitě k tomu, že si ten GC napíše sám. A pak tím musí obalit i STL vector a dostane se k mrtvolám v paměti (dokud nezavolá sweep) atd. Čili si myslím, že ty problémy, které Javě vyčítáte, jsou nevyhnutelné u jakéhokoliv "velkého" projektu.

[Beda]

vrele doporucuji, ale ma to podminku aplikace se musi priblizne vejit do 300MB za behu zivych provazanych obektu. cele jvmko se musi vejit do RAM a nesmi dojit na swapovani a samozrejme tomu prospiva vice procesoru nebo aspon HyperThreading.

Parametry HotSpot JVM (od Sunu) ktery se osvedcily.

-server -verbose:gc -XX:+PrintGCTimeStamps -XX:+UseConcMarkSweepGC -XX:+PrintGCApplicationStoppedTime -Xms400M -Xmx400M -Djava.awt.headless=true

[Pavel Janousek]

A vite, ze se mylite, tech her psanych v Jave je cim dal vice a obcas to ani nepoznate... ono hry != 3D shootery...

[bigsam72]

No s tou javou je to tezky, umi to spoustu muziky, za malo penez ( rozumej malo kodu/ hodne funkcionality ). Ale je to vykoupene Garbage Collectorem. Mame napsany jeden "pomerne velky system" v C++ ktery jako urcite interface procesy pousti Javu. Obcas je to boj, pouzivame zejmena 1.4.x. Bohuzel musim konstatovat ze ma Java i po nekolika letech vyvoje detske nemoci. Nejvice me trapi memory leaky apod. Na druhou stranu musim konstatovat ze je to cim dal tim lepsi, HotSpot apod je jiste perfektni vec.

Napriklad me stvalo u JDK1.4.x ze numoznovalo poradnou praci se signaly, coz zejmena v momente kdy integrujete javu do nejakeho vetsiho projektu neni sranda. Skolni priklady, jsou skolni priklady a relny zivot je jim na hony vzdalen. Pokud vim tohle je nejak lepe reseno v 1.5 .

Jsem sice C/C++ a javu nehanim ale proste vidim urcite jeji slabiny na druhou stranu ma spoustu plusu.

Cau.

[ivan]

Podle me je pouzitelnej az kernel 2.6.9 Do verze 2.6.7 se stavalo, ze byla poskozena dat, struktura ve ktery byly procesy a jejich vlakna.

Az v 2.6.8 byl opravenej tenhle bug. http://oss.sgi.com/projects/netdev/archive/2004-10/msg01171.html Na 2.6 kernelu se stavalo, ze kdyz jste meli skutecne rychle propojeni mezi pozitaci, tak linuxu preteklo scaling window a pak se nedalo tahat data rychleji nez 200-300B/sec po gigabitu :)

A to ma byt 2.6 stable.

[Michal Kubeček]

Mám pocit, že jste se netrefil úplně přesně do správné diskuse...

[Peter]

Myslim, ze sa trafil - v rozhovore sa spominaju problemy kernelu 2.6 pri komunikacii s kernelom 2.6. Skutocne, az kernel 2.6.9 odstranuje niektore nechutne chyby, ktore by mohli sposobovat nahodne problemy popisane vyssie.

[martin]

ahoj, dobry clanok. To heslo na roota je ha ha:) aj s tou medzerou? Nejak mi to nejde. Niektoré ženy sú všetky rovnaké.