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

29. 11. 2004 | Leoš Literák | Programování | 11114×

Populární služba NAVRCHOLU.cz prošla loni zásadním vylepšením. V tomto rozhovoru její autor Michal Krause popisuje architekturu i důvody, proč opustil PHP.

Leoš Literák: Původní navrcholu.cz bylo napsáno v PHP. Jaké jsi měl důvody, že jste druhou verzi psali v Javě?

Michal Krause: Nejdříve malé upřesnění: původní verze byla napsaná z části v ANSI C (počítací server) a z časti v PHP (frontend).

Backend měl velkou výhodu v rychlosti, ale vývoj byl relativně pomalý a doslova peklem se ukázalo být ladění. Hledat chyby, které nastanou třeba jednou za sto tisíc zcela různorodých a v zásadě nesimulovatelných požadavků, a to navíc v multithreadové aplikaci psané v C, se mi jeví být takřka neřešitelným problémem.

Volba PHP pro frontend přinesla zejména jednoduchost a rychlost vývoje, ale zásadním problémem se ukázaly být zcela nekontrolovatelné a nepředvídatelné paměťové nároky. Neznám bohužel vnitřnosti PHP, ale z praxe se mi zdá, že režijní náklady jsou příliš vysoké. Ještě o něco starší verze NV měla i frontend napsaný v C (CGI skripty), takže jsem mohl docela dobře srovnávat shodné programy napsané v obou jazycích. Ukázalo se, že na to, co jsem v C zpracoval zhruba ve 2 MB paměti, potřebovalo tehdy PHP neuvěřitelných 64 MB.

Je to už delší dobu a lecos se mohlo v nových verzích zlepšit, ale i dnes při vývoji jiných projektů v PHP narážíme na vysoké paměťové nároky. Zní to trochu paradoxně, protože Java má pověst paměťového "nenažrance", ale režijní náklady na paměťové struktury se mi zdají být nižší a její nároky jsou z mého pohledu především předvídatelnější a do jisté míry kontrolovatelné.

V neposlední řadě bylo zbytečně komplikované psát backend a frontend v různých jazycích, protože to obnášelo částečné duplikování kódu.

Když jsme si tedy tohle shrnuli, začalo zkoumání konkrétních možností - například jsme potřebovali bezpodmínečně podporu jaderných vláken kvůli využítí více procesorů, podporu asynchronních nebo neblokujících IO operací atd. - a pochopitelně i testování výkonu. Java splnila všechno potřebné a tak vyhrála výběrové řízení :).

LL: Jaká byla úroveň tvých znalostí Javy, než jsi začal přepisovat navrcholu?

MK: V Javě jsem krátce programoval odhadem tak okolo roku 1997 nebo 1998. Pak jsem se delší dobu věnoval jiným jazykům a vrátil se k ní až kvůli tomuto projektu, tedy asi v polovině roku 2002. Musel jsem si samozřejmě lecos oživit a hlavně se seznámit s dostupnými knihovnami a podobně, ale v zásadě to šlo celkem hladce.

LL: Narazil jsi v průběhu vývoje na zásadní problémy, kvůli kterým jsi pochyboval o správnosti rozhodnutí zvolit Javu?

MK: Neřekl bych - na problémy jsem samozřejmě narážel, ale nikdy nešlo o nic tak zásadního, že bych litoval své volby. Jistě, umím si představit mnohá vylepšení, která by programátorovi usnadnila život, ale jsem přesvědčen o tom, že podobné by to bylo nezávisle na výběru jazyka. Na druhou stranu ovšem musím říct, že kdyby v době našeho rozhodování neexistovala verze 1.4 (mimochodem, teprve relativně krátce), asi by to dopadlo všechno trochu jinak.

LL: Jak se na tuto volbu díváš s odstupem několika měsíců od nasazení nové verze?

MK: Jak jsem řekl, nemám žádný důvod litovat, takže jsem v zásadě spokojen. To už mám spíš drobné pochybnosti o některých implementačních záležitostech, ale to je asi normální - člověk se stále rozvíjí a s ročním nebo dvouletým odstupem už na některé věci zkrátka nahlíží jinak :).

LL: Prozradíš nám něco o architektuře NAVRCHOLU? Jak to uvnitř funguje? A jaké Open Source komponenty či knihovny používáš?

MK: Měření je realizováno vlastní implementací HTTP serveru, který je samozřejmě výrazně jednoúčelový. Jeho úkolem je "jen" prostý sběr dat, na která pak čeká agregátor. Ten generuje výsledky, které nakonec v různých pohledech mohou uživatelé vidět na webu. Protože při testech se databázové servery, které jsem zkoušel, na obdobné objemy dat netvářily zrovna optimálně, nakonec jsme si napsali i vlastní úložiště - samozřejmě opět jednoúčelové.

Webové rozhraní je realizováno pomocí servletů běžících pod Tomcatem.

Pokud jde o knihovny, zmínil bych například Log4j, Lucene, Freemarker, Proxool, Hibernate nebo Dom4J. Našlo by se ještě pár dalších, ale tyhle bych rád zdůraznil, protože je považuji za mimořádně povedené a hodně mi ulehčily práci.

LL: Jaké stroje používáte pro příjem dat, jejich zpracování a webové rozhraní? Jak jsou dimenzovány a jaký mají load?

MK: Backend, který v součastnosti realizuje sběr i agregace dat, je rackový Sun s dvěma procesory Xeon 2,8 GHz a 2 GB RAM. Jeho obvyklý load se pohybuje okolo 0,60. Frontend je pak 2x Pentium III 1 GHz s 768 MB RAM. Jeho load je za normálních okolností také někde okolo 0,5 až 0,6.

LL: Běží pod Linuxem? Jaké máte jádro a souborový systém?

MK: Oba běží pod Linuxem. Jádro na backendu je 2.6 a na frontendu 2.4 - to proto, že nejsme schopni zaboha uchodit stabilně síťové sdílení disků při kombinaci 2.6<->2.6. Přitom je jedno, zda se používá NFS či SMBFS - v obou případech dochází při zátěži k rozpadávání spojení a někdy až k vytuhnutí stroje. Pokud je na klientovi jádro 2.4, běží tatáž konfigurace naprosto v pohodě, problém je opakovatelný i na jiném hardwaru. Takže bych tak trochu tenhle rozhovor zneužil pro dotaz k ctěnému čtenářstvu, jestli náhodou někdo nezná řešení :).

Pokud jde o souborové systémy, přecházíme kvůli opakujícím se problémům z ReiserFS na XFS, zatím k plné spokojenosti. V současnosti je to zhruba půl na půl.

LL: Jaké je heslo na roota?

MK: Ha ha :)

LL: Myslíš, že serverové aplikace psané v Javě jsou výkonnostně srovnatelné s aplikacemi psanými v céčku?

MK: Já jsem nedělal žádné sofistikované testy, takže nechci rozhodně vynášet nějaké konečné soudy. Ale konkrétně v našem případě jsem měl k dispozici reálnou, takřka shodnou aplikaci napsanou v obou jazycích a rychlost byla v podstatě totožná. Myslím si, že HotSpot kompilátory v posledních verzích Javy opravdu odvádějí skvělou práci a na výkonu je to znát.

Na druhou stranu jsou ale oblasti, kde rozdíl mezi javovou a céčkovou aplikací vnímám celkem silně, a to třeba u desktopových GUI aplikací - pravda ale je, že pracuji převážně na počítačích, které z dnešního hlediska mají svůj zenit už dávno za sebou (abych byl konkrétní, vcelku spokojeně a bez větších obtíží jsem do tohoto týdne používal počítač s procesorem PIII 450 MHz :).

LL: Jaké vývojové prostředí používáš?

MK: VIM :)

LL: A co ROOT? Plánuješ jej také převést na Javu? ;-) Kdy nasadíte nový redakční systém a na jaké novinky se můžeme těšit?

MK: ROOT v Javě určitě napsaný nebude, protože bude využívat stávající redakční a publikační systém. Termín po mně nechtěj, dle Murphyho zákonu znamená jeho zveřejnění v podstatě absolutní jistotu, že se nestihne :).

Z obdobného důvodu bych si rád nechal pro sebe i většinu novinek, protože ještě stále probíhá vývoj, ale určitě bude nový design, mohu slíbit propracovanější vyhledávání, lepší diskuze či detailnější a doufejme přehlednější členění článků do rubrik. Na to ostatní si budeš muset Ty i čtenáři ještě chvíli počkat :).

       

Komentáře

[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é.