Co možná (ne)víte o Javě

3. 10. 2003 | Daniel Michalik | Recenze | 16131×

Java dlouhou dobu polarizovala linuxovou komunitu. Možná slibovala víc, než byla schopna splnit. Vytýkalo se jí, že je pomalá, že se nehodí pro vývoj desktopových aplikací nebo zabírá spoustu paměti. Jak je na tom Java dnes?

Pokud Javu zatím nepoužíváte, přinese vám článek náměty k zamyšlení. Srovnáme výkon Javy s C++ (zaručuji překvapení), popíšeme optimalizující HotSpot kompilátory v Sun J2SDK 1.4.2 a řekneme si o správě paměti a grafickém uživatelském rozhraní.

Budeme popisovat knihovny a nástroje, které se osvědčily ve vývoji aplikací provozovaných v režimu 24x7, tedy 24 hodin denně a 7 dnů v týdnu, u kterých je restart velmi nežádoucí a pád naprosto nepřijatelný (stejně jako u našeho oblíbeného operačního systému . Proto pominu open source projekty, které zatím s distribucí Sunu nesnesou srovnání a nabízí obvykle pouze podmnožinu celé platformy.

Výkon

Níže uvádím výsledky numerického benchmarku SciMark 2.0, který simuluje typicky výpočetně náročnou aplikaci. Pro účely spravedlivého srovnání jsem upravil zdrojový kód třídy Random.java, která se používá v testu Monte Carlo, tak, aby stejně jako verze C neobsahavala žádné synchronizované metody. Test byl prováděn na systému Red Hat Linux 8.0 s procesory Intel Xeon 2.66GHz. Zdrojové kódy SciMarku jsou k dispozici na http://math.nist.gov/scimark. Pro kompilaci C verze byl použit originální makefile, který vyvolával C kompilátor s přepínačem -O6.

	GNU C++ 3.2	HotSpot Server VM 1.4.2	HotSpot Client VM 1.4.2
Composite Score	456.67	510.56	207.24
FFT (Mflops)	283.16	300.52	98.17
SOR (Mflops)	391.66	663.55	356.32
Monte Carlo (Mflops)	144.32	179.26	54.16
Sparse matmult (Mflops)	697.19	440.43	139.56
LU (Mflops)	767.04	969.01	387.99

HotSpot Server ve všech testech kromě Sparse matmult dost výrazně překonává C verzi. Výsledek je o to zajímavější, že Java narozdíl od C provádí za běhu kontrolu indexu pole a všechny metody v Javě jsou virtuální!

Technologie HotSpot VM

V dalším výkladu pod pojmem kompilátor budeme rozumět modul virtuálního stroje Javy, který překládá Java bytekód do kódu procesoru, případně provádí optimalizace (nezaměňovat s kompilátorem zdrojového kódu - tím se zabývat nebudeme).

První generace virtuálních strojů Javy v dobách verze 1.0 používala pouze interpretaci bez žádných optimalizací.

Druhá generace strojů použitých pro řadu 1.1 a 1.2 používala tzv. JIT (just in time) kompilátory, které překládaly bytekód třídy při načtení do kódu procesoru počítače. Překládaly se všechny metody třídy a při startu aplikace nebyl čas na provádění kvalitnějších optimalizací. Jednou přeložený kód byl ponechán po celou dobu běhu programu.

Třetí generace strojů (počínaje verzí 1.3) obsahuje plně adaptivní kompilátory, které sledují běh programu, hledají jeho slabá místa ("hot spots") a ty pak silně optimalizují. Vycházejí z aplikace zásady, že 80 % času program stráví ve 20 % kódu. Zbylých 80 % programu může být dokonce zbytečné převádět do kódu procesoru a postačí interpretace. Jedná se o absolutní high-end technologie dynamických interpretů, jak uvidíme dále.

Standardní distribuce Sunu obsahuje dvě verze těchto strojů. Tzv. "HotSpot Client" a "HotSpot Server", které se liší tím, kolik času si mohou dovolit na provádění optimalizací.

HotSpot Client je předvolený virtuální stroj, pokud spouštíte Java aplikaci. Explicitně se tyto stroje rozlišují pomocí přepínačů při spouštění příkazu:

java ... java -client ... java -server ...

HotSpot Server VM

Tento virtuální stroj je doporučeno použít pro dlouho běžící aplikace, u kterých nevadí, že startují déle nebo zabírají více paměti. Právě to umožňuje provádět podstatně agresívnější optimalizaci. Charakteristika HotSpot Server VM:

• Podpora instrukční sady SSE a SSE2 - výrazně zrychluje výpočty v systémech s procesory Intel Pentium 4.
• Eliminace kontroly indexu polí - specifikace Javy vyžaduje, aby při každému přístupu k prvku pole byla provedena kontrola indexu. Tato optimalizace je schopna kontrolu indexu potlačit, pokud je kompilátor schopen provést důkaz, že index pole je v povoleném rozsahu.
• Rozbalení smyčky - standardní optimalizace kompilátorů, která umožňuje rychlejší provádění smyček a zvyšuje také efektivitu dalších optimalizací.
• Optimalizace Java Reflection API - kompilátor "zná" důležité knihovní třídy a metody a generuje pro ně mnohem efektivnější kód, což se projeví zejména u aplikačních serverů, objektově-relačních mapérů, XML binderů, dynamických proxy apod.
• Agresívní inlining - technika, v níž místo vyvolání určité metody se na požadované místo rovnou rozbalí tělo metody, která tímto funguje jako makro. Agresívní proto, že inlining může být uplatňován do větší urovně hloubky volání. Důležitým ziskem této optimalizace je dramatické snížení počtu volání metod a hlavně vygenerování větší porce kódu, která se stává dobrým materiálem pro další optimalizace.
• Dynamická deoptimalizace - ačkoliv je inlining nesmírně důležitou optimalizací, nesmíme zapomenout, že je komplikován dynamickou povahou načítání tříd Javy za běhu programu a tím, že metody tříd jsou virtuální. Při načtení podtřídy, která překrývá určitou metodu, může být proto nutné provést deoptimalizaci (případně reoptimalizaci) již předem optimalizovaného bloku a to třeba za běhu tohoto bloku.

HotSpot Client

Tento virtuální stroj provádí minimální množství optimalizací za účelem co nejrychlejšího startu aplikace a poskytutí co nejrychlejší odezvy pro uživatele.

Nikde ovšem není řečeno, že pro klientské aplikace nelze použít HotSpot Server. Prostě se musíte smířit s tím, že aplikace bude nabíhat déle a bude mít zpočátku pomalejší odezvy. Ale s tím, jak jsou procesory stále rychlejší, je tento faktor stále více zanedbatelný.

Správa paměti

Jeden z největších přínosů Javy pro programátory je v tom, že je to první široce dostupný programovací jazyk, který poskytuje automatickou správu paměti (garbage collection). V tradičních jazycích se dynamická alokace a vrácení paměti provádí pomocí explicitního volání příslušných funkcí (malloc/free). V praxi to bývá zdrojem úbytků paměti, chyb a pádů programů, problémů s výkonem (!) a potíž při psaní opakovatelně využitelného kódu (různé moduly musí respektovat společná pravidla).

Garbage collector Javy automaticky provádí uvolňování nepotřebné paměti v pozadí a to tak, že vrátí paměť objektu, když může "dokázat", že objekt již není déle pro běžící program dosažitelný. Takový důkaz není v praxi vůbec triviální a není zde prostor pro naivní algoritmy.

Například microsoftí technologie COM nebo Python jsou založeny na tzv. reference counting neboli počítání odkazů na objekty. Když se na objekt nikdo neodkazuje, čítač má hodnotu 0 a objekt se skartuje. V praxi se ovšem používají složité struktury, u kterých vznikají cyklické odkazy. Lze si např. představit, že objekt A se odkazuje na B a B se odkazuje zpětně na A. Čítače odkazů budou u obou objektů rovny 1 a tudíž nedojde k jejich uvolnění. Pokud navíc tyto objekty drží nějaký systémový zdroj (např. neuzavřené databázové připojení nebo soubor), máme vážný problém.

Dalším závažným problémem, který má dopad na výkon systému, je fragmentace paměti, která se projeví obzvlášť u dlouho běžících programů (serverové procesy). Fragmentace vzniká postupně tím, jak program alokuje novou paměť a vrací tu, kterou nepotřebuje. Taková paměť pak připomíná silně děravé síto, kvůli němuž musí operační systém přidělit programu více paměťových stránek, než odpovídá jeho "teoretické" spotřebě. Systém pak více "swapuje". V praxi se to stane velice snadno, když nastane špička provozu nějakého serverového procesu (např. mail nebo web server). Jak a zda vůbec se s tím tvůrci serverů vůbec vypořádavají mi není známo. V každém případě při použití jazyků, které používají ukazatele (C, C++, .NET!), se to jeví jako velmi problematické.

Tradičně byly garbage collectory považovány za pomalé a vzhledem k výše popsaným problémům je to pochopitelné. Navíc musí občas pozastavit provádění vlastní aplikace (ta pak v extrémním případě "zamrzne" i na několik vteřin) a provést úklid paměti. Velmi dobrá zpráva je, že výzkum v této oblasti pokročil natolik, že výkon systémů s moderními garbage collectory je lepší než u modelu s explicitním uvolňováním paměti.

HotSpot Garbage Collector

Java HotSpot VM obsahuje prokročilý systém správy paměti, který uvolňuje všechny nedostupné objekty a odstraňuje problém fragmentace paměti a občasného zamrzání aplikace. Stává se tak výbornou platformou pro provoz trvale běžících aplikací s požadovanou vysokou propustností, rychlou odezvou a takových, ve kterých jsou úbytky paměti nebo nedostatek paměti v důsledku fragmentace velmi nežádoucí.

Throughput Collector

Jedná se o typ collectoru maximalizujícího propustnost aplikace ve víceprocesorových systémech. Tento garbage collector pracuje paralelně na více procesorech, čímž se zkrátí čas pro uvolňování paměti a tím se zvýší průchodnost celého systému. Vhodný např. pro použití u aplikačních serverů, kdy požadujeme co nejkratší odezvy.

Throughput Collector se aktivuje pomocí přepínače -XX:+UseParallelGC.

Concurrent Low Pause Collector

Tento collector minimalizuje přestávky, na které musí zastavit aplikaci. Na druhou stranu tento garbage collector běží ve vlákně, které konkuruje aplikaci, a tak na jednoprocesorovém systému může dojít k nepatrnému snížení celkové průchodnosti. Výborné se hodí pro aplikace, které vyžadují plynulost (např. animace - viz Java2Demo). Mohu potvrdit, že narozdíl od starších virtuálních strojů Javy jsem skutečně žádné trhané animace už neregistroval (včetně aplikací v Java3D).

Concurrent Low Pause Collector se aktivuje pomocí přepínače -XX:+UseConcMarkSweepGC.

Desktopové aplikace

Java byla dlouho kritizována jako nevhodná platforma pro vývoj klientských grafických aplikací. I zde bohužel platí, že 100krát opakovaná lež se stává pravdou a tak zatímco jedni kritizovali, druzí pracovali a ukázalo se, že Java mezitím dozrála do stavu, kdy se hodí pro grafické uživatelské rozhraní víc než dost.

Swing nebo SWT?

Pro tvorbu profesionálního uživatelského rozraní máme dnes v zásadě 2 možnosti. Buď knihovnu Swing (známou též jako JFC neboli Java Foundation Classes), která je součástí každé distribuce Javy (od verze 1.2), a nebo knihovnu SWT (neboli Standard Widget Toolkit), jejíž vývoj sponzorovala IBM v rámci projektu vývojového prostředí Eclipse.

Pro úplnost ještě dodám, že existují projekty s Java bindings pro GNOME a KDE, nicméně jejich použití výrazně omezuje počet cílových platforem, na kterých lze vyvíjenou aplikaci provozovat.

Swing

Swing je napsán celý v Javě pomocí rozhraní Java2D, z čehož automaticky plynou tyto důsledky:

1. O veškerou správu paměti se stará javovský garbage collector, což výrazně omezuje riziko vyčerpání systémových zdrojů.
2. Uživatelské rozhraní je na všech platformách stejné (pochopitelně kromě fontů). Z hlediska programátora je to výhoda, protože aplikace se odladí jednou a obvykle bez problémů běží i na jiné platformě nezávisle na verzích různých knihoven operačního systému. Použije-li se navíc tzv. systémový look&feel, aplikace dost dobře emuluje vzhled i chování aktuálního uživatelského rozhraní. Java ve verzi 1.4.2 obsahuje poměrně použitelnou emulaci GTK, ve verzi 1.5 je slíbeno další zdokonalení.
3. Prvky uživatelského rozhraní lze dále v Javě rozšiřovat, upravovat způsob kreslení, přidávat vlastní vykreslovací logiku. Snad proto se o Swingu říká, že je extrémně přizpůsobitelný.

Vzhled předvoleného look&feelu (Metal) je trnem v oku spoustě uživatelů. Toto už dnes není problém, protože existují atraktivní a profesionální look&feels, kterým se z hlediska grafického designu nedá nic vytknout. Pro příklad se podívejte na odkaz http://www.jgoodies.com, kde také najdete užitečné aplikace ke stažení zdarma. Ukázky spousty profesionálních aplikací ve Swingu najdete také přímo u Sunu na adrese http://java.sun.com/products/jfc/tsc.

Rozhraní Java2D je velmi pokročilým rozhraním pro práci s grafikou. Poskytuje antialiasing, texturování, alpha blending, množinové geometrické operace, logické rastrové operace a spoustu jiných zajímavých věcí. Výkon linuxové implementace do verze 1.3 silně pokulhával, ve verzi 1.4.2 jej lze označit za dobrý a ve verzi 1.5 se můžeme těšit na akceleraci pomocí hardware podporujícího OpenGL (z diskuzních skupin, do kterých přispívají sunovští inženýři, se zdá, že lze očekávat špičkový výkon).

Ukázka možností Java2D:

SWT

SWT je tím, čím mělo být AWT, tedy javovskou obálkou nad nativními prvky uživatelského rozhraní poskytovanou hostitelským operačním systémem. S jedním drobným rozdílem: SWT to dělá opravdu dobře.

Prvotní příčinou pro vznik SWT byl zřejmě kdysi neuspokojivý výkon Swingu, což už dnes neplatí.

Dalším argumentem pro vývoj SWT byla otázka, proč znova vymýšlet již vymyšlené a odladěné a dělat všechno úplně znova (přesně to dělá Swing). Místo toho je lepší použít kvalitní, odladěný kód knihoven uživatelských prvků, jako je např. GTK nebo Motif. Navíc se aplikace chová a vypadá tak, jak je uživatel ve svém systému zvyklý.

Jistým problémem je použití nativního kódu a nativních zdrojů operačního systému, což vyžaduje explicitní uvolňování objektů barva, štětec, font apod., čímž ztrácíme výhody, které nám poskytuje javovský garbage collector a vnášíme potenciální zdroj chyb. Pokud tedy potřebujete nejen použít hotové prvky, ale také kreslit, je zřejmě lepší volbou Swing a Java2D.

Pokud vyvíjíte aplikaci pro SWT, musíte počítat s laděním na více platformách a musíte se smířit s tím, že na každé platformě bude aplikace nejen jinak vypadat(look) ale bude se i jinak chovat(feel). Budete se muset zajímat o to, které verze těch či oněch závislých systémových knihoven uživatel používá, zkrátka nebude to bez problémů.

Srovnání Swingu a SWT knihoven není vůbec snadné a je těžké argumenty nenaštvat zastánce té či oné knihovny. Situace silně připomíná konkurenci ve světě Smalltalku, kde se výrobci také rozdělili do dvou táborů: obálka nad nativním uživatelským rozhraním a emulované rozhraní vykreslované plně v režii Smalltalku. Jedno je jisté: oba toolkity tu zůstanou a je to tak dobře, protože jejich konkurence bude podporovat pokrok. Pokud dobře zvládáte jeden z nich, nemá smysl investovat do zvládnutí druhého. Spoustě vývojářů je bližší Swing, protože je v čisté Javě a je víc objektově orientován.

Instalace Javy v Linuxu

Pokud si chcete Javu vyzkoušet a nemáte ji nainstalovanou, proveďte níže popsané kroky.

Stáhněte si přímo z http://java.sun.com instalační soubor javy pro Linux (pro verzi 1.4.2 je to j2sdk-1_4_2-linux-i586.rpm.bin). Tento zkopírujeme do nějakého adresáře, kde jej z příkazového řádku spustíme. Objeví se licenční ujednání, které pomocí mezerníku odklikáme, a nakonec napíšeme yes. Tímto vznikne instalační soubor j2sdk-1_4_2-linux-i586.rpm, který pomocí příkazu rpm -ivh j2sdk-1_4_2-linux-i586.rpm nainstalujeme.

Poznámka: vyše popsané kroky platí pro RedHat Linux. Distribuce nepoužívající rpm mohou vyžadovat jiný postup.

Při instalaci vznikl adresář /usr/java/j2sdk1.4.2, v jehož podadresáři bin je řada nástrojů pro vývoj a spouštění Java aplikací. Tento adresář je vhodné přidat do cesty, například editací souboru /etc/profile:

JAVA_HOME=/usr/java/j2sdk1.4.2 PATH=$PATH:$JAVA_HOME/bin ... export JAVA_HOME ...

Chcete-li si spustit demo ukázané na obrázku, proveďte tyto kroky:

cd /usr/java/j2sdk1.4.2/demo/jfc/Java2D java -jar Java2Demo.jar

       

Komentáře

[MOJE]

Uvedene demo jsem si spustil a s hruzou jsem sledoval jak se za 100%niho vytizeni procesoru pred myma ocima zacina trhat to co je ve screenshotech. Ja si teda vykon v grafickem rezimu predstavuji jinak nez vycerpat procesor jen zobrazenim nekolika zakladnich primitiv. Java je 1.4.2 a 1.2GHz by taky melo stacit. Doufam, ze aspon surovy vykon (bez grafickych knihoven) je takovy jak je prezentovany na zacatku clanku (zkusim asi radsi overit sam). Java je velice dobra technologie, ale podle mych zkusenosti neni vykon to proc bych ji chtel pouzivat.

[Daniel Michalik]

Java2Demo je vícevlaknova animace s antialiasingem texturovanim apod. Myslim, ze aplikace v jakekoliv jazyce bude brat 100% procesoru. Spustte si treba SwingSet2 demo a to nebere zaden vykon. Jinak verim, ze ve verzi 1.5 s OpenGL to bude fungovat lip.

[MOJE]

Zalezi na tom co chce aplikace zobrazovat. Pokud vypnu antialiasing a take ostatni veci zatizeni se nemeni. Jen pohyb je o neco mene trhany. Ja vim, ze pokud mam graficke demo tak ze to musi zanechat nejakou stopu na procesoru, ale aby tech nekolik jednoduchych objektu udelalo 100% a jeste se trhalo je pro mne prece jen obtizne pochopitelne. SwingSet2 je hezke demo, ale nedejboze aby se tam neco zacalo hybat, protoze to zase procesor leti nad 50% (ale uz to aspon neni 100). Ono pokud by aplikace, ktera nic nedela generovala zatizeni u statickych veci tak by to bylo hodne divne.

[Ludek]

Co se jakychkoli animaci a demicek tyka, vetsinou se pisi tak, ze totalne vycucnou CPU. A to plati at jsou udelana v Jave nebo v C. Typicke graficke demo (s doublebufferingem) vypada takhle (a napr. pro hry je to totez):

while(! konec){
  aktualizuj_model_sceny();
  renderuj_screen_do_bufferu();
  prohod_buffery();
}

A to opravdu sezere veskery vykon procesoru at to piste v cemkoli. A co se trhani tyka .. proste to nestiha (alpha blending a antialiasing si zadaji sve) - coz ovsem nestihaji ani nativni C dema (viz gl 2D xscreensaver renderovany pres MESA), pokud nemaji k dispozici HW akceleraci.

[Leoš Literák]

hezky clanek. uz jsem upravil spousteci prikaz a pridal -server, jsem zvedav, jak se to projevi na vykonu

[Lukáš Zapletal]

hehehe připojuji se, je to nejlepší článek, co jsem zatím o javě četl, trošku flameoidní ale výborný :) mimochodem není v té tabulce chyba? jestli jsem to správně pochopil, tak čím menší číslo tak tím horší výkon nebo naopak?

[Daniel Michalik]

Čísla v tabulce označují Mflops, tedy milióny operací v plovoucí desetinné čárce za vteřinu. Dík za pochvalu. Pokud Vám článek v něčem pomůže, bylo mi potěšením.

[jiri]

Hezký a zasvěcený článek. Díky. Jen kdyby tak byla Sunovská java normální součástí všech distribucí Linuxu. To by mi připadalo jako naprosto logická věc, ale Sun si klade jakási licenční omezení. Přitom dohoda se Sunem je možná, protože pánům z qcm (mandrake.cz) se podařilo umístit javu na bonusCD distribuované s běžným GPL setem. A ještě se chci zeptat: máte nějaké tipy na dobrý software napsaný v Javě? Používám editor jedit (www.jedit.org) a zkusil jsem také funkčně poněkud chudší filemanager muCommander (www.mucommander.com).

[Daniel Michalik]

Podívejte se na odkazy na konci článku - doporučuji si projít "Swing sightings" a mrknout se na JDiskReport (www.jgoodies.com). Jinak pro vývoj jednozačně doporučuji Eclipse (www.eclipse.org).

[Lukáš Zapletal]

absolutně nejlepší IDE (zejména pro serverové aplikace) je prostředí IDEA, dělá se to tady v Praze, jenže je poněkud dražší....

[Ludek]

XmlMind XML editor - "WYSIWYG" editor XML - zakladni verze zdarma bez zdrojaku. Pouzivam ho na editaci DocBook dokumentu. Ve verzi zdarma chybi integrace s FO procesory, XSLT procesory a tak. http://www.xmlmind.com

[Daniel Michalik]

Můžu se zeptat, jaké prostředí používáte pro docbook (myslím, čím generujete html a pdf)? Zkoušel jsem distribuci z e-novative.de, ale z té nejsem tak úplně nadšen. A dávat dohromady parsery a katalogy DTD samostatně se mi příliš nechce.

[Pavel Franc]

Já na to mám Xalan a fop (http://xml.apache.org/). Ne že by nedalo práci to dobře nakonfigurovat, ale výsledek stojí za to. Jestli se Vám s tím nechce dělat, kupte si profesionální verzi XMLmind, ta umí převod do PDF sama (HTML zvládá i ta standardní verze). A XMLmind je i ve standardní neplacené verzi skvělý editor, dokonce celý v češtině:)

[Martin Kocourek]

No tak ja vas potesim. Treba ve Slackware 9.1 je standardni soucasti j2sdk-1_4_2_01-i586-1.tgz. Snad nemusim "prekladat" o co se jedna, ze...

[Martin Slouf]

S Javou (a ještě k tomu s c++ a s pythonem) si hraju takřka denně -- celkem mě ten článek pobavil. Java je vcelku dobře navržený jazyk s rosáhlou řadou _standardizovaných_ knihoven, umožňujících výtečné věci. To je její výhoda. Nikoli však už rychlost. Nemám tušení, jak je to na víceprocesorových strojích, ale na mém 1 CPU Athlonu XP 1700 se Java namůže srovnávat s aplikacemi napsanými v c++ a koneckonců i v pythonu -- speciálně to platí pro grafické aplikace -- srovnej gtk aplikaci se swingovou -- to uváděné demo je dobrý příklad . Malý testík -- mám dva miniprográmky, které se připojí na můj MySQL server spustí jeden (stejný) SELECT, uvolní zdroje a skončí -- jeden v C, druhý v Javě. Ten v C běží při opakovaném spouštěním (time mysql_pokus) asi real 0.004 s, Ten v Jave asi real 0.52 s). Věřím, že většinu času zabere start JVM a samotný kód se vykoná už vcelku rychle. Ale ošetřování vyjímek, tvorba objektů, volání virtuálních funkcí je prostě _pomalejší_ než volání běžných funckí, kontrola návratových hodnot apod. Program je sice v Javě hezčí, lépe se spravuje a dodává se mu nová funkčnost, ale platí se za to. Nicméně -- nic proti Javě -- osobně ji mám rád a s potěšením kvituji, že takový jazyk je (JSP, aplety, java.net.*).

[Daniel Michalik]

HotSpot jsou adaptivní kompilátory, tzn. program musí chvíli běžet, než se "zahřeje" (tzv. "warm up"). Opakujte ten test prosím 10 krát v rámci jednoho spuštění javy a musíte dostat naprosto jiné výsledky. Pokud ne, je JDBC driver na MySQL napsán mizerně. Další otázka, je to připojení na MySQL přes socktety? Nepoužíváte náhodou MySQL v tom testu in-process? Existují SQL databáze napsané v čisté Javě, které když beží in-process běhají _velmi_ rychle (http://hsqldb.sourceforge.net).

[Lukáš Zapletal]

přesně tak, srovnáváte hrušky s jabkama, jak se java zahřeje, všechno ostatní se může jít klouzat :) mimochodem Hypersonic je na nic, je to šidítko, zkuste raději OzoneDB

[Martin Slouf]

vse jede pres sokety jenom na okraj -- ted jsem doplnil to same v pythonu (nekde to tu je) a je to 10krat rychlejsi nez Java (jinak opet dodavam -- Java je ok, jen to, jak autor clanku dokazuje, ze je rychla (resp. rychlejsi jak C++) me proste trochu zarazilo, protoze aplikace v Jave, tak i v C++ pouzivam denne a proste _to_neni_stejne_rychle_)

[Jakub Hegenbart]

Jenomže to jste ve skutečnosti napsal program v Cčku, jehož pořadí prováděných funkcí je definováno jednoduchým bajtkódem - Java běhá v mnohem větší míře ve VM, Python je rychlejší než Java, využívá-li daný program časově náročné standardní funkce (které jsou všechny v Cčku), ale jakmile začnete psát kreativní algoritmy, Python dostane infarkt a odpadne :/ (To samozřejmě není pokus o flame, mám Python stejně rád jako Javu, tj. podstatně více než cokoliv jiného, ale taková jsou prostě fakta...vzpomínám si, že někdo z autorů Pythonu navrhl vylepšení, které by zvýšilo rychlost VM asi 10x, ale ozvala se protistrana, že by i pak byl 10x pomalejší než Cčko a vzhledem k nativním Cčkovským funkcím by se to nevyplatilo - jestli jsem to nějak překroutil, omlouvám se, paměť mi už, dvaadvacetiletému, tolik neslouží :)

[gregy]

nejsou ty zdrojaky nahodou v c ?

[Daniel Michalik]

Máte pravdu. Zdroják "Random.c" mě zmátl. Z hlavičkových souborů je to jasné.

[Martin Slouf]

ajaj jo, jsou v C nicmene ted jsem je prepsal do pythonu (2.3) python (time mysql.py): real 0.05 s zkousel jsem i c++ (mysql++-1.7.9, gcc-2.95), ale nerozchodil jsem novou verzi mysql++ (SIGSEGV od libmysqlclient). zkousel jsem to kdysi davno (cca pred rokem) a bylo to v podstate stejne jako c. c++ teda nemam, cimz moje argumentace ponekud trpi ... ted nemam cas, asi se na to jeste kouknu. m.

[Martin Slouf]

trochu zmateni ode me -- predchozi prispevek neni reakci, ale doplneni meho puvodniho. sorry za zmatenost. m.

[MOJE]

Docela by mne zajimalo, kde vzal autor ta cisla z testu, protoze u mne vypadaji malinko jinak. (GCC 3.3.1, SUN Java 1.4.2, IBM Java 1.4.1)

Test	GCC	SUN	SUN -server	SUN -client	IBM
Composite score	301.74	118.5	170.3	137.3	230.9
FFT	257.26	57.6	131.9	58.0	190.5
SOR	272.17	247.8	240.1	273.9	267.6
MonteCarlo	91.0	24.2	45.8	24.3	55.6
Sparse matmult	393.61	63.2	109.1	130.5	220.2
LU	494.69	199.6	324.3	199.7	420.5

Pouzil jsem to co bylo ke stazeni na autorem odkazovane strance. Pokud bude mozne otestovat autorem upraveny kod, rad to udelam take. V soucasnosti nejsem ochoten verit, vysledkum jeho testu.

[Daniel Michalik]

Opět za všechno dobré i špatné může adaptivní kompilátor. Pokud runtime zjistí, že pracuje sa systému s procesorem Pentium 4 s instrukcemi SSE2, tak je využije. Pokud používáte Athlon, tak bohužel ne Verze 1.5 má mít rozsáhlou podporu procesorů AMD Opteron.

[MOJE]

Dobre. Pentium4 mam k dispozici take a kdyz uz jsme u tech optimalizaci pridal jsem do testu take icc-7.0 (CPU bylo P4 2.4GHz, ostatni parametry stejne)

Test	ICC	GCC	SUN	SUN -server	SUN -client	IBM
Composite score	524.6	493.3	189.7	436.2	195.5	390.3
FFT	306.0	281.3	49.6	249.0	73.1	261.6
SOR	582.2	365.0	324.6	601.4	324.5	360.6
MonteCarlo	58.1	136.3	37.4	58.2	41.1	63.6
Sparse matmult	593.1	782.5	126.0	404.7	127.8	373.5
LU	1083.6	901.2	410.6	868.0	411.2	892.1

Rozdil se znatelne snizil, ale GCC je az na jedinou vyjimku porad lepsi (u ICC dva pripady, ale zase jinde je znatelne lepsi nez GCC). Je hezke, ze s fungujici optimalizaci je java opravdu velice rychla. Bude to velmi dobry argument pro ni. Ale znovu se tazi: Kde vzal autor vysledky, ve kterych je java v prumeru rychlejsi nez kompilovany kod ?

[Daniel Michalik]

Ve zdrojácích javy jsem z třídy Random vyhodil klíčové slovo synchronized. Originální zdrojáky jsou zabaleny dosti mizerně a kompilují se trochu nesnadno, v každém případě po této úpravě se 10x zlepšilo Monte Carlo a o cca 10% FFT. Dále je otázkou, nakolik Javě prospěl procesor Xeon (respective 2 procesory). Xeon má podstatně větší cache.

[MOJE]

Jak budu mit chvili tak vyzkousim. (nedelam jevu, takze tam mi budou upravy trvat malinko dyl). Mohlo by vas zajimat, ze pokud s random_getdouble, ktera je volana mooooc casto da jako inline tak vysledky pro ICC vypadaji takto:
Composite Score: 581.74
FFT Mflops: 307.08 (N=1024)
SOR Mflops: 576.93 (100 x 100)
MonteCarlo: Mflops: 217.36
Sparse matmult Mflops: 732.25 (N=1000, nz=5000)
LU Mflops: 1075.07 (M=100, N=100)
GCC je tady:
Composite Score: 492.80
FFT Mflops: 277.75 (N=1024)
SOR Mflops: 367.74 (100 x 100)
MonteCarlo: Mflops: 164.68
Sparse matmult Mflops: 728.18 (N=1000, nz=5000)
LU Mflops: 925.65 (M=100, N=100)
blizsim pohledem do toho C kodu jsem zjistil, ze opravdu neni psany s ohledem na vykon, takze realne vysledky dobre napsane aplikace budou asi malinko lepsi pro kompilovane jazyky. Coz nic nemeni na tom, ze Java pri spravnem pouziti muze mit velmi zajimavy vykon.

[Daniel Michalik]

Líbí se mi Váš závěr. Nejde o žádnou soutěž, ale to zda Java má dostatečný výkon. Ukazuje se, že ano - a to jsme si nezačali hrát s nestandardními přepínači HotSpot kompilátorů

[MOJE]

S touto interpretaci souhlasim. Java ma dostatecny vykon pro aplikace, ktere prilis nevyuzivaji GUI a kde neni aplikace dostatecne optimalizovana (v takovem pripade si k jave prihodim optimalizovanou knihovnu . Muj zaver je, ze az bude mit java dostatecne kvalitni (rozumej rychle) knihovny pro praci s GUI tak bude pouzitelna i pro normalni programy a ne jen na server, nebo jednoucelove konzolove aplikace.

[dart0]

Ale i to GUI se v Javě dá psát hodně slušně. A běží to i docela rychle a v novějších verzích to vypadá i pěkně. Problém jsou jen nároky na paměť a to je asi také nejvetší problém Javy.

[MOJE]

Omluvam se, ale zapomel jsem napsat parametry testovaciho stroje. CPU athlon1200 RAM 512MiB (vetsina volna pro gcc jsem pouzil tyto parametry: -O3 -ffast-math -fomit-frame-pointer -march=athlon -mcpu=athlon Na stroji v tu chvili nebezelo nic jineho, co by mohlo zatezovat CPU a swap byl vypnuty. Kazdy test jsem udelal 2x a vysledna hodnota je prumer.

[Karel Zak]

Pripada mi, ze nekteri lide snazici se dopracovat v testech podobnosti u vykonu programu psaneho v C/C++ a Jave si dost v ocich ostatnich ublizuji. Pokud oboje bylo napsano podobne kvalitne tak tezko bude programek v Jave stejne rychly nebo dokonce rychlejsi a to proste pro, ze Java (a treba i ten zminovany Python) musi delat to same a jeste _musi_ delat par dalsich veci -- ktere jsou dani za pohodli prace v Jave -- ktere program v C/C++/apod nedela. Co se tyka fragmentace pameti a vykonu klasicke alokace tak autori klasickych programu se to pochopitelne snazi resit. Takze napriklad Apache nebo PostgreSQL se snazi alokovat po blocich, ktere jsou prirazeny nejakemu deji (napriklad requestu klienta) a po jeho vykonani je ta pamet zase jako blok uvolnena nebo znovu pouzita. Pokud jsou pak pozadavky na program podobne tak stale dokola pouziva tu samou pamet a fragmentace se zase tak moc nekona. Predstava, ze nekdo u rozsahlejsiho (kvalitniho) programu vola primo malloc/free je naivni. Java je super, jen by to chtelo nezapomenout na klasicke UNIXove "The right tool for the right job".

[Daniel Michalik]

Dynamická optimalizace dokáže zázraky - třeba eliminace kontroly indexace pole. Tyto benchmarky mluví samy za sebe. Původně jsem je ani neměl v plánu zveřejňovat, ale když Vám vyjdou tak provokativní výsledky, tak si je nenechám pro sebe! Díky za informaci o fragmentaci paměti. V každém případě to není legrace. The right tool for the right job. Ano, Java se skvěle hodí pro vývoj informačních systémů. Ikdyž portfolio open-source produktů v javě je podstatně širší (mail servery, HTTP servery, atd... viz třeba http://jakarta.apache.org). Samozřejmě Java není lékem pro všechno. Cílem článku bylo naznačit, že Java je dnes někde jine, než byla před řekněme dvěma léty a vyprovokovat k zamyšlení ty, kdo ji tehdy zavrhli.

[Karel Zak]

Jde o to, ze neni asi problem najit podminky za kterych je Java srovnatelne rychla a udelat z toho nejaky benchmark. Dobre by ale bylo pak pribalit i nejaky test ktery napriklad zamestnava i ten memory managment v Jave. Napriklad par desite tisic objektu, ktere jsou a nasledne nejsou pouzivany ruzne meneny z nich vytvarene dalsi nove objekty apod.

[MOJE]

Jo a jeste jsem zapomel podekovat za hezky clanek, ktery mi prinesl nekolik novych informaci. To ze neverim konkretnim zverejnenym vysledkum je jina vec.

[CIJOML]

Pane redaktore moc jste mne svymi vysledky pobavil :) Srovnavate neporovnatelne. Sun ma samozrejme koupenou presnou specifikaci, takze jeho schopnost tvorit kod pro dane CPU bude jiste vyssi nez u kodu generovanym kompilatorem GCC, uz proto, ze muze vyuzit i oficialne nepublikovane instrukce. Jestli chcete prezentovat vysledky, pouzijte Intelsky za penize koupeny kompilator. Potom se pobavime a vyjde najevo srackovitost javy :)

[Daniel Michalik]

ICC to zrychlíte, jistě. O kolik? 5-ti násobně, 10-ti násobně, nebo spíše o 10-20%? Cílem srovnání bylo vyprovokovat diskusi o tom, zda je java dosud pomalá (třeba pro numerické výpočty). Pokud Vám uvedené výsledky říkají že je, tak použijte ICC, nebo jiné prostředí. Dík za názor. Hodně štěstí.

[CIJOML]

Co kdybych to napsal v C a pouzil mnou napsane rutiny v ASM ? :) Co vy na to? :)

[Daniel Michalik]

Ano, budete rychlejší a vyhrajete. Ale až budete pracovat na reálnych projektech s reálným rozpočtem, na jejichž konci je faktura a nikoho nezajímá v čem je to dělané, a Vám a Vašemu týmu Java pořádně zvedne produktivitu, budete možná uvažovat jinak.

[CIJOML]

Jiste klasicke napiseme to v Delfinach a ti nymandi stejne nic nepoznaj...jen at si radeji koupi novejsi P4 3.6 GHz a 2 GB RAM, YES, prodali jsme, vyhrali jsme. Jenze kdyz pouzijete funkce s O(n^2) nebo O(n^3) nebo hur, tak vam stejne nic nepomuze, vite?? Oni totiz ti vasi super vykonni programatori jsou moc lini implementovat funkce s O(nlogn)...vite?

[Daniel Michalik]

Teď jste mě pro změnu pobavil Vy...

[CIJOML]

Prave, flamewar nema moc smysl - shodli jsme se, ze kod v cecku musi byt rychlejsi a doplneny rozumnyma rutinama v ASM o to vic a to mi staci :) Kazdy interpretovany jazyk poste musi byt pomalejsi...o kolik to je otazka vyzkumu - stejne jako musi byt pomalejsi kod generovany prekladacem namisto vymysleny clovekem

[Jozef Vondrák]

Bez újmy na obecnosti není pravda, že: "Kazdy interpretovany jazyk poste musi byt pomalejsi...". Pepa

[Ladislav Sückr]

výsledný kod v C a ASM poběží (?) ve výsledku určitě rychleji. Ale za jak dlouho? Hlavní výhoda vyšších programovacích jazyků je přeci v tom že se nemusím zabývat technickými detaily stroje a můžu se věnovat čistě požadavkům zákazníka (aplikace). A většinou jde právě o rychlost a kvalitu návrhu a zprovoznění aplikace než o její rychlost. A když už to jede tak se líp upravuje např. JAVA než ASM. A co se týká ASM tak to zrovna moc přenositelný není a může to zlobit stroj od stroje jinak. si myslim

[Aleq]

Vykonnost aplikaci napsanych v Delphi bych takhle neshazoval, dovolil bych si tvrdit, ze se lisi od binarek z C/C++ radove o jednotky procent.

[MOJE]

A co kdybych v jave na platforme na ktere mi zalezi udelal optimalizovane rutiny na to podstatne a pouzil je ? Vysledek bude uplne ten samy. Jen to pojede vsude a tam kde to nebude optimalizovane holt pomalu. Jo a kdyby si se podival tak o neco vys jsem psal jake vysledky ma ICC.

[David Olszyński]

Muzete si taky vyrobit vlastni procesor urceny pro jednu vasi konkretni ulohu a budete jeste rychlejsi! Vubec nevadi, ze od reality je to asi stejne vzdalene jako vas napad s C+ASM.

[Aleq]

Autorovo resume melo vyznit - podle techto cisel si dovolim tvrdit, ze Java je jednou z nejlepsich moznosti (ne-li primo nejlepsi) tvorby aplikaci s nejlepsim pomerem vykon / snadnost+rychlost vytvoreni aplikace. Alespon ja bych si to tvrdit dovolil. A RAW Ceckari budou spokojeni, ze si muzou susnit systemovy veci v C a ASM, zatimco vetsi projekty typu informacni, ekonomicke a pod. systemy si budou tvorit high-levelaci v jazycich typu Java, C# apod.

[Leoš Literák]

Vcera jsem nasel na serverside zajimavou funkci: mark message as noisy. Rikal jsem si, ze bych ji tady mohl taky naimplementovat a to pro pripady, kdy nekdo pise sproste, nekoho osocuje nebo porusuje zakon (propagace fasismu, rasismu, detske pornografie apod). Dneska lituji, ze ji jeste nemam implementovanou. Hned bych ji mohl pouzit.

[honza]

autor se netaji tim, ze se ve svem clanku zabyva zejmena jednim aspektem problematiky programovacich jazyku = rychlosti, jakym je nejaka aplikace nebo program zpracovana. Ze se pritom odvolava na testy, o jejichz pouzitelnosti pro praxi by se dalo jiste s uspechem pochybovat je jeho dobre pravo - my take neukazujeme navsteve bordel v loznici ale cerstve uklizeny obyvak. Co mi chybi, je to , co ke kazdemu clanku v bezne inzenyrske praxi patri - totiz zaver se zhodnocenim, co probirana problematika prinese celkove - v tomto konkretnim pripade, co zvyseni rychlosti zpracovani v jave prinese pro programatorskou praxi. Predpokladejme, ze ma autor pravdu a java je rychlostne nyni srovnatelna s ostatnimi jazyky (pan Zak viz vyse si neni tak jisty). Tim je odbourano ono KO-kriterium, ktere v minulosti nasazeni javy blokovalo. Nyni muzeme rozebrat zhruba 2 pripady, kdy se nekdo rozhoduje, ze nasadi javu. Tym c_1 sestavajici z peti programatoru se musel pred 5-ti lety rozhodnout v cem programovat. Nemohl zvolit javu, protoze pro nejaky framework to bylo nepouzitelne. Po 5-ti letech se tento tym pta, zda je mozno na javu prejit. Skoleni a dalsi vydaje pro tym je mozno odhadnout minimalne na 1/2 milionu kc. Otazka: zaplati se vubec nekdy vyhody javy? Odpoved: ne Tym c_2 je novy a v dnesni situaci by se mohl rozhodnout pro javu. Takovych tymu je zruba 10% z celkoveho poctu vsech aktivnich. naklady zde nehraji roli, protoze jsou pro ruzne technologie zhrub srovnatelne. Ale co s C# a .NET. Takovy tym stoji pred otazkou jakym smerem se vydat. Otazka: rozhodnou se pro javu Odpoved: minimalne 50 % ne Zaver: Vylepseni v jave je relevantni pro ca 5 % celkove programatorske kapacity. A to jeste nejsou odstraneny pochyby pana Zaka.

[Daniel Michalik]

Článek se ani okrajově nedotkl produktivity, což je námět na samostatnou studii. Bylo by nutné seriózně zkoumat následující otázky. 1. Kolik kč mě stojí 5-ti členný tým měsícně, za kolik prodávám jeho práci? Je položka na přeškolení v porovnání s tím tak drastická? 2. Jak ovlivní produktivitu přechod na Javu? Přidá nebo ubere starostí v jednotlivých fázích projektu? Kolik mě stojí změna v systému nebo vyhledání chyby poté, co je systém předán do provozu? Jaké jsou náklady na údržbu systému? 3. Kolik platím za vývojové prostředí a knihovny za 5 let pro 5 programátorů? Pro javu to může dnes být 0Kč! 4. Kolikrát za 5 let musím migrovat na další majoritní vylepšení stávající platformy? Jak zpětně kompatibilní je tato majoritní změna (DDE, OLE, ActiveX, .NET)? 5. Co je nejlepší platforma pro segment trhu, který se snažím svými produkty pokrýt? Jistě Vás napadnou spousty dalších užitečných otázek. Co se týče nových projektů, tak podle posledních údajů v Evropě většina startuje v J2EE nikoliv v .NET, takže si nejsem jistý, proč by "nejméně" 50% mělo zvolit C#. Dále existující Java týmy jsou pod tlakem IT managerů aby migrovali na C#. Vyvrácení starých mýtů jistě prospěje i jim, takže si nemyslím, že vylepšení javy je relevantni pouze pro 5% komunity.

[Abraxis]

Ekonomicky pohled II. - Java i C# jsou vice mene srovnatelne, kazdy ma nejaka bezvyznamna +-, ktere se vzdy daji obejit. ALE problem je v tom, ze pro Javu existuje UZ DNES hromada volnych nastroju a tak je zavislost na SUNu v podstate eliminovana. Zatimco u MS je clovek PLNE odkazan na jejich rozhodnuti a MS jiz v minulosti dokazal, ze se toto naprosto nevyplaci.

[Roman Dagi pichlik]

Zavislost Javy na Sunu neni. Je to spise naopak, Sun je zavisly na Jave. Jak Java tak C# maji dnes standradizacni procesy, kterymi se muze jazyk dale rozsirovat. Navic za Javou nestoji jen Sun, ale napr. Oracle,IBM atd. kdezto v pripade C# je to pouze Microsoft. Co se tyce vyvojovych prostredi, tak pro .NET jich moc neznam, lepe receno tech opravdu dobrych. Pro Javu muzu jmenovat jedno za vsechny Eclipse, naprosto profesionalni vyvojove prostredi, ktere je zcela zdarma.

[rosta]

S osobni zkusenosti vim, ze neni problem prejit z C++ na Javu. Syntax je stejna. Diky IDE Eclipse se da zvladnout behem par dnu. I treba 10 cleny tym. Problem je ale s rychlosti. Hot Spot technologie nezvlada vetsi objemy kodu. Takze pokud program obsahuje spoustu kodu, ktery se neopakuje, spoustu classu a method, tak optimalizace je zanedbatelna a Java je vice nez 5x pomalejsi. Zkuste si vygenerovat nahodny kod, bez cyklu, proste nejaka prirazeni, vytvareni objektu. Nahodne classy. Pri poctu nekolika tisic radku kodu je rozdil markantni. Pokud programator napise 500 radku ounittestovaneho kodu denne, tak prace peticlenneho tymu, je kazdy tyden pomalejsi a pomalejsi. Apropos, i Eclipse neni napsany jave.

[rosta]

Nechci jen Javu kritizovat. Sam mam pocit, ze jsem v ni produktivnejsi. Pro male aplikace je Java super, ale pro tvorbu kompilatoru je to na nic.

[Jakub Hegenbart]

No, standardní SUNovský javac JE psaný v Javě, ale rozumná IDEčka vám přece nijak nebrání v použití skvělého IBMkovského (open source) dílka jménem Jikes. assert("vývojové prostředí" != "kompilátor"); ^_^

[Daniel Michalik]

Eclipse v Javě napsaný JE. Můžete si stáhnout zdrojády a dle libosti se v nich hrabat. Pro GUI je použito SWT (viz článek).

[Franta]

To jsou teda počty

Kdyby se tým rozhodoval takhle, tak bude dodnes programovat v pascalu, protože učit se nový jazyk by se během nejbližšího projektu nezaplatilo.

[Leoš Literák]

Prijde mi zajimave, jak Java pusobi na spoustu lidi jako cerveny praporek na byka. Okamzite reaguji a snazi se za kazdou cenu dokazat, ze java je spatna (v lepsim pripade, u nekterych lidi mam pocit, ze povazuji javu za antikrista a vyhlasili proti ni krizacke tazeni). Prijde mi normalnejsi ignorovat veci, ktere se mi nelibi, nez se je snazit shazovat. Me treba prijde ulitle, ze v Pythonu se delaji cykly odsazovanim kodu - ale nepisu do kazde diskuse, ze Python je spatny (to netvrdim). Treba Cijoml se mi snazil dokazat, ze Java je nemoderni, mrtva cesta a ze je to dokazane na nejakych konferencich Sam pouzivam Javu na desktopu i serveru uz hezkych par let, stejne jako se profesionalne venuji programovani v tomto jazyce (takze jsem "zaujaty"). Rozhodne si nemyslim, ze se Java vykonostne vyrovna reseni v kompilovanem jazyce. Je skvele, ze se ten rozdil kazdy rok snizuje, ale existuje. Podle mne je nejvetsim problemem narocnost na pamet. I ta nejmensi aplikace zabira nekolik megabajtu, co teprve XML editor XXE ci moc hezke IDE IntelliJ IDEA? To jde do desitek mega. I kdyby samotny beh byl srovnatelne rychly, tak naroky na spravu pameti budou Javu vzdy srazet dolu. JDK 1.5 ma pry prinest sdileni VM, takze kazda nove spustena aplikace nebude vyzadovat novy VM. To bude fajn, ale stejne - Sun by se mel spise nez na pridavani novych vlastnosti soustredit na snizeni narocnosti na pamet. A dalsi optimalizace na rychlost. (Nove jazykove vlastnosti jako generics vypadaji skvele a uz se na ne tesim). Nicmene abych se vratil zpet, tak hlavni bodem je efektivita programatora a ta je IMHO v Jave nejlepsi. Proto se velka cast serverovych aplikaci realizuje prave v ni. Vsichni, kdo mame mobil nebo bankovni ucet, jsme de facto uzivateli Javy. Oskar, Eurotel, T-Mobile - Java. Pocet bank (s castmi nebo celymi IS implementovanymi v Jave) take rychle roste. Na strane serveru Java dominuje, to je fakt (tim nemyslim SMTP, HTTP apod, ale enterprise reseni). To ovsem neznamena, ze Java je nejlepsi jazyk a ostatni jsou spatne. Napriklad jsem rad, ze KDE ci Mozilla neni napsano v Jave Kazdy pouzivejme, co nam vyhovuje a neurazejme se navzajem, jak to predvadi Cijoml.

[Karel Zak]

Souhlas, jen by bylo mozna korektni rict co ta Java v techo IS dela. Neni to tak, ze vetsinou ceka na nejaky Oracle a procento casu z celkove narocnosti aplikace ktere je venovane Jave neni tak moc vyrazne a hodne moc toho je udelano mimo Javu? BTW, zarovnavani v Pythonu je mozna divne, ale pokud srovnate citelnost s treba s Perlem tak je to naprosto genialni napad.

[Marek Slapak]

mno, nevidel sem tyto IS, ale pokud jsou psany jakozto J2EE reseni prostrednictvim EJB, tak mam ten dojem, ze urcite jen necekaji na vystup nejakeho DBMS pod nimi.... .. ale je to jen muj laicky nazor :)

[Marek Slapak]

Souhlas ... na javu je asi opravdu takova moda neustale nadavat. Taky v ni nejakej ten cas vyvijim, nasazuji ji predevsim na serverova reseni a vesmes sem spokojenej, takze muj nazor je asi tez zaujaty :) Kazdopadne: vsechno ma svoje "mouchy", ale co je u javy neoddiskutovatelny je prave produktivita, cistota a efektivita kodu. Zejmena ta cistota kodu resp. cistota koncepce platformy - je faktor, kterej hodne lidi proste opomiji, ale v pripade podnikovych reseni je tohle IMHO zatracene fest dulezity faktor ktery se v konecnem dusledku dost odrazi na celkove nakladovosti reseni.. U java platformy se mi hrozne libi to, ze ma hlavu a patu, ze se neustale totalne nemeni koncepce (jako u Microsoftu - nejdriv DDE, pak Network-DDE, pak COM, pak DCOM, pak COM+ a nakonec .NET, co bude nasledovat po .NET?) a ze je k dispozici nepreberna plejada kvalitnich frameworku a API pouzitelnych v podnikove praxi a vse vesmes OSS (viz. super vytvory nadace jakarta.apache.org) Zejmena to, ze mam jistotu, ze narozdil od microsoftich reseni me neceka kazdou chvili pri upgrade reseni prepisovat vic nez pulku sveho reseni znovu, to je pro me nesmirne dulezity faktor - ktery se opet odrazi v nakladovosti Pravda je, ze pametovy naroky sou vetsi nez u klasickych kompilovanych platforem, ale mam ten silny dojem, ze cena 1GB RAM navic do serveru muze byt v konecnem dusledku naprosto zanedbatelna polozka ve srovnani s nakladovosti na vyvoj a skalovani reseni napsaneho na nejake monolyticke platforme, ktera ma k objektove abstrakci a cistote java platformy hooodne daleko. Je to jen muj nazor nic vic, nic min. Sou pripady, kde je java naprosto nevhodna, netvrdim ze je vselek na vse, ale na bussiness-logic programovani je IMHO absolutne Best-of, uz jenom kvuli stabilite, cistote a zpusobu obhospodarovani pameti...

[Leoš Literák]

taky souhlas Hrozne se mi libi cistota navrhu (vetsiny rozhrani java.*). napriklad takovy InputStream ci Collection - parada. I to, ze vsechno je potomkem tridy Object - matne si vzpominam, ze C++ spolecneho predka nema. Taky se mi libi, ze java developeri (ktere znam) se snazi o sebevzdelavani, hledaji best practices, nasazuji patterny .. Ach jo, kde jsou ty casy 12snap, to byl skvely tym!

[ales kubasek]

jako konecne nekdo uhodil hrebicek na hlavicku, konkretne: cistota navrhu/code.. :)) mam rad javu :) jinak: cus marku :))))))

[Zedik]

Hm ... a premysleli Javisti, proc kazdy reaguje na Javu jako byk na cerveny praporek? Protoze od Javistu se clovek nedocka niceho jineho nez "Java je nejlepci a ostatni jsou sracky" (moje zkusenost). Myslim, ze si za tuto nevrazivost muzou sami.

[Leoš Literák]

Ach jo, cijoml to zacal a zacina se Zive efekt sirit jako lavina Upozornuji na prisny zakaz pouzivani sprostych slov (kam aspon ja "sracky" zarazuju). Takove prispevky budou bez ohledu na relevantnost zbytku textu smazany! Jinak k tvemu prispevku: pausalne shazujes vsechny javisty do jednoho pytle. Kdyby sis precetl poradne tuto diskusi, najdes tu spoustu reakci programatoru v Jave, kteri tak necini. Takze jsem matematicky dokazal, ze tvuj konstrukt neni pravdivy (dukaz sporem)

[Lukáš Zapletal]

Koukám, Leoši, že jsi to ještě nezapomněl :) Matematiku...

[miho]

Udrzuje se seznam "korenovych objektu" tzn. statickych objektu a podobne. Behem GC se zkouma strom techto objektu (hrany jsou ukazatele na objekty). Objekt nedosazitelny timto postupem lze uvolnit.
.NET provadi defragmentaci pameti tak, ze platne objekty "sesype" na zacagtek a upravi ukazatele. Diky reflexi to zas takovy problem to nebude.

[jean]

Pekne napsany clanek, ale nelibi se mi, ze prilis knihoven pro Javu se zas pise v Jave, takze je to za chvili pomalej nenazranej moloch. Pro normalni desktopove/serverove aplikace se mi uz zda vhodnejsi kombinace C a Ruby. Kde to jde, pouzit uz existujici a rychly C knihovny a pouze k nim napsat binding: C: * multiplatformni (snad vsude k dispozici) * hodne pruhledny * dobre optimalizovany Ruby: * interpretovany * multiplatformni (graficke aplikace napr. pomoci vazby na GTK) * hodne silny (>= Perl) * hodne cisty (>= Python) * hodne pruhledny * ciste objektove orientovany * GC * jednoducha rozsiritelnost pomoci C (diky GC - proste dal pisete v Ruby, ale pritom to pisete v C * _velmi silna_ a rychla std. knihovna (napr. String ma cca 100 metod, vsechny v C), takze 99% programu vykonavaji rychle C metody. * binding na vsechny mozny C knihovny * velka komunita uzivatelu * docela jednoduse by sel preklad Ruby kodu -> C kod pouzivajici libruby.so -> gcc -> spustitelna binarka (kdyby o to nekdo stal ;) Rychly start, rychly beh i u hodne slozitych projektu (mam v nem napsany server o nekolika tisici radcich kodu a beha jako vino), opravdu jednoduse rozsiritelny pomoci C kodu (mozne tedy psat cast kodu v Ruby, cast v C/C++), podpora threadu i v DOSu (kdyby o to nekdo stal , atd. Zda se mi to jako systemovejsi pristup - pouzivat co nejvic knihoven, ktere uz existuji, nez si vsechno psat znovu - pro Javu. Napr. existuje temet 100% binding na vsechny gnome knihovny. A hodne z tech knihoven vam pobezi i na Widlich, takze porad pisete multiplatforme .

[honza]

dozvedel jsem se neco noveho a mam sto chuti se hned na tu kombinaci c/Ruby podivat. Ale zivot me naucil, se pri te vsi chvale zeptat, kde je ten zakopanej pes. Napis nekde take ten vycet NEVYHOD, ktere ta kombinace ma. Zacni klidne tim, kolik knizek o Ruby, Perlu, Jave je v regalech v knihkupectvi. Ne ze bych mel neco proti c a spol. Ale kazda vec, produkt a vubec cokoliv na tomto svete ma sve pro a proti.

[Abraxis]

Presne tak. Ruby uz sleduji dlouho a libi se mi, jak narusta komunita uzivatelu. Problem je totiz v tom, ze kdyz mam nejaky projekt v C/C++/PHP/Perlu, tak muzu klidne nejake knihovny/fce dat napsat/odladit/zdokumentovat externistum/studentum. Kdybych to jel v Ruby, tak je musim dlouho premlouvat, at se to nauci...

[Wejn]

No, to mate mozna pravdu, ze je treba se Ruby naucit ... nicmene si troufnu tvrdit, ze slusny programator zvladne Ruby behem 3-4 dnu na takove urovni, ze jeho produktivita v nem bude alespon tak dobra jako v jeho predchozim jazyce (mluvim o Perl/Python/C/C++, neb Javu a C# moc neznam ... a tak si netroufnu do nich rypat ). Navic dokumentace (online) a knizek je myslim dost a dost ... Dokonce s verzi 1.8 je uz i nativni Ruby celkem rychly A stejne pokud by nebyl, je prevod Ruby->extenze_v_C jednoduchy (jak uz tu bylo zmineno).

[honza]

to, ze se nekdo za den nauci, jak se tahaji figurky na sachovnici, jeste neznamena , ze je sachista.

[Wejn]

Ano, toto tvrzeni v pripade sachu plati. Bohuzel jako analogie silne pokulhava ... Programovani je imho o schopnosti algoritmizovat problem ve zvolenem paradigmatu. Pokud nekdo ovlada objektove/funkcionalni/strukturovane/logicke programovani v jazyce X a chce se naucit jazyk Y, zpravidla mu staci pochopit syntaxi jazyka Y, protoze "zbytek" jiz zna z X. Samozrejme je to daleko od "expert v Y", ale o tom v mem predchozim prispevku nepadlo slovo. Mimochodem, Ruby je vhodny nejen na objektove orientovane veci ... Lze v nem psat i strukturovane (a omezene i "funkcionalne"). Nehlede na to, ze se hodi (velmi) i na one-liners.

[jean]

No, osobne jsme byl schopny prejit z Perlu na Ruby za 3 hodiny, co jsem si precetl nekolik kapitol z knizky o Ruby (http://www.rubycentral.com/book/). Pak jsem byl schopny napsat v Ruby to co v Perlu -- samozrejme, ze ne tak rychle.

[Petr Fischer]

Neni nahodou Java2D novejsi zalezitost nez samotny Swing? Je Swing opravdu kompletne prepsan do Java2D?

[Václav Dvořák]

Jenom drobná oprava: můj oblíbený Python už nějakou dobu má garbage collection taky. Ale nic proti Javě.

[David Olszyński]

Vzdyt je to v textu napsano dokonce i s popisem, jak funguje (reference counting).

[Jiri Dvorak]

Privital bych v clanku vice tehnickych detailu namisto PR reci. Zejmena v sekci o pameti by mohlo byt misto neustaleho "je to skvele, rychle, uzasne" napsano jak to vlastne funguje. Pak by si clovek mohl udelat lepsi obrazek jak Java pokrocila .

[jakub]

Celkom fajn clanok ale neviem kde autor prisiel k tomu ze v jave nemozu nastat problemy s uvolnovanim pamate, pripadne s memory leaks? Odporucam prestudovat si material z JavaOne2002 (uz presne nepamatam meno). Prednasajuci bol z IBM a spolupracuje na novej specifikacii prace s pamatou. Autor tiez robi z hotspotu zazrak. Technologia je to dobra ale vsetko ma svoje medze a hlavne autor ma nepresvedci ze optimalizacia ktora moze bezat radovo x krat dlhsie ako v Jave (tym myslim pribeh kompilacie v C a C++) je horsia ako optimalizacia za behu. Presne ako garbage collector. Napr. zaujimava vlastnost je z mnozstvom pamate sa cas jeho prace nezvysuje linearne ale exponencialne. Inac Java pouzivam - ci je alebo neni o 20% rychlejsie je pri sucasnom vyvoji v procesoroch nepodstatne, jej hlavne plus su fantasticke kniznice.

[Milan Vančura]

Když člověk od filtruje balast určený (možná nevědomky) k naštvání čtenáře jen s malinko rozdílným názorem než má autor, tak se dozví zajímavé možnosti javy a kam až dospěla za posledních pár let. Fajn. Článek má aspoň zajímavé jádro, narozdíl od rozhovoru se šéfem IT v České spořitelně, jehož autor teď tady v diskusi ukazuje svůj slovník nevybíravých výrazů. Tu "naštvávací část" se tu pokusím shrnout, protože to mimo jiné ukazuje, proč JAVA působí jako onen pověstný rudý prapor: 1. použité výrazy - nebo spíše větné kostrukce - jsou emotivní 2. závěry předkládané v článku jsou naprosto nedostatečně podpořeny fakty 3. článek vyznívá, jako by autor pracoval pouze v javě a informace o jiných jazycích měl pouze z třetí strany. Z této pozice se pak pouští do porovnávání. Hned na začátku testu je uveden přepínač -O6 pro gcc nemající dobrý smysl. V dokumentaci od gcc se totiž dozvíme, že takové číslo optimalizačního postupu vůbec neexistuje a překlad projde jen proto, že gcc obsahuje "normovací" podmínku. Test probíhal na jediné konfiguraci z hlediska SW i HW a přitom jsou z něj vyvozovány obecné závěry. Žádný slušný statistik by z jednoho pozorování nezveřejnil závěr, který jde proti obecné logice věci nebo mírněji řečeno proti zavedenému názoru (JAVA VM musí provádět nad kódem více operací než nativní kód získaný kompilací). Obecně platí, že čím inovativnější a provokativnější názor je, tím musí být lépe podložený, aby vůbec mohl nastartovat rozumnou debatu a ne flamewar. Tuto zásadu autor nedodržel. A je to vidět i v diskusi pod článkem, kde sám autor v odpovědích logicky skáče od jednoho aspektu tvorby programu k druhému, třetímu a tak pořád dokola. Od rychlosti výsledného kódu přes "čistotu" kódu, schopnost v praxi ho rychle napsat a udržovat apod. Nejsem JAVA programátor a tudíž nemohu psát podobné hodnocení (a vím to o sobě ) ale v praxi se potkávám s výsledky takového programování - s hotovými produkty. A jako systémák vidím, kolik to potřebuje systémových zdrojů a jak rychle to funguje. Stejně tak vím své o čistotě kódu v java aplikacích, se kterými se setkávám. (Jejich tvůrci jsou např. Oracle.) Často je vůbec problém najít odkud se berou vstupní parametry. Také se potkávám s mnoha lidmi, kteří o sobě tvrdí, že jsou programátoři (v javě) a já přitom vidím jejich kód. Jak snadné je "splácat" pár tříd a nemít ani ponětí o časové či paměťové náročnosti. To vám nemusí souviset článkem, ale dává to další střípek k odpovědi na otázku o rudém praporu. Daň za módnost. Doufejme, že se to časem upraví. Proto článek beru spíše informativně a z tohoto pohledu autorovi děkuji za dobrý nápad ukázat nové možnosti javy. Rozhodně stojí za to zamyslet se, jak java aplikace urychlit, když jsou opravdu skoro všude kolem nás.

[honza]

vazeny kolego, nejsem vaseho nazoru, ze java-diskuze v te forme jako zde je dana tim, ze autori jsou nekriticti a neznaji pravidla pro psani clanku. Vidim ten duvod jeste na mnohem vyssi urovni: ve stretu dvou zcela rozdilnych filosofii: javiste jsou priznivci te vecne lidske touhy po nalezeni univerzalniho stroje odpurci jsou skutecni inzenyri, kteri vedi, ze mnohotvarnost a nasazovani tech nejvhodnejsich prostredku je ta spravna cesta. Druhym dulezitym faktorem je vira ve vsemocnost programovych prostredku. Proto to nadseni pro GC, ktery z nas sejme tu cast odpovednosti a usili. Neni to jenom v jave. napr. v databazich se vola vecne po nejakem prostredku (ER-tool) , ktery tu databanku navrhne sam tak pekne a ciste. nejen javistum, ale vsem univerzalistum by prospelo, kdyby nahledli zevnitr do nejakeho strojirenskeho podniku. Tam nestoji univerzalni obrabeci stroj, nybrz soustruhy, brusky a vrtacky. Vyhody univerzalniho stroje by byly prece nesporne - stale stejna obsluha, male naklady na skoleni, mnozstvi dodatecnych modulu atd. A protze skutecni inzenyri to vsechno vedi, tak proto se obcas usmeji nad takovymi clanky a nekteri to nevydrzi a neco i odpovi.

[Lukáš Zapletal]

S tim -O6 to tady kazdy vi, s tim se tady nemusite chlubit. Vi to i autor, o tom nepochybujte. Autor clanek publikoval, protoze ho vysledek prekvapil. Jako systemak vydite akorat ten vas zastaralej Oracle, kterej se porad snazi protlacit jakesi pochybne java programy se silenym ovladanim a bezici nad nejakou buhvijakou starou VM verze 1.1. Oracle to zkratka s javou podelal, meli si nechat ty svy formsy. Neni to chyba javy, to je snad jasne. To, ze jste potkal nejake "programatory", kteri spatne pisi kod to nic nedokazuje. Kvalitni kod se da psat jak v Jave tak i v Perlu jak z hlediska prostoru tak i casu. To, ze to byli programatori-amateri, zpusobuje fakt, ze java je nanejvys vhodna pro vyuku OO programovani. Rekl bych vyhodnejsi nez cokoliv jineho. Doporucuji brat tento clanek s nadsazkou... No ne?

[Daniel Michalik]

Děkuji všem čtenářům za cenné názory v komentářích. V pasáži o výkonu jsem nezdůraznil, že se jedná o čistě mé subjektivní zkušenosti a některé výsledky jsem příliš zobecnil. Jelikož problém srovnání výkonu je tímto neuzavřen, navrhuji provést objektikvnější srovnání, na kterém by se podílelo víc čtenářů (uvítal bych zejména guru v oblasti kompilace dobře optimalizovaného kódu C kódu a to i na Linuxu i na Windowsech) a které by se provedlo na více platformách. Mohlo by to být něco jednoduššího než je SciMark2, třeba výpočet Mandelbrotovy množiny.

[agent]

Hrozně se těším na další spolehlivý důkaz. A to tentokrát, že assembler je pomalejší, než Java. Zhruba asi takto mi vyzní celý článek.

[Cohen]

Jenze je to tak - za urcitych okolnosti. Pokud budu psat ASM kod, mam dve moznosti: a) napisu ho primo a pouze pro jeden specialni hw a pouziju maximum optimalizaci, ktere dany procesor poskytuje b) napisu ho tak, aby chodil na vetsine hw, takze optimalizace nevyuziju Java hotspot dela optimalizace za behu, tudiz MUZE po detekci procesoru ziskat mnohem vyssi vykon nez univerzalni ASM kod. Totez plati pro kompilovane C programy, s tim rozdilem, ze staci prekompilovani. Nehajim zadnou verzi JVM, pouze upozornuji, ze to mozne je. Vsechno je zalezitost vyuziti prostredku.

[agent]

Samozrejme, ze mozne je vsechno. Ale proste dobre a optimalizovane na rychlost napsany program v C, C++, nebo Asm a prelozeny s dobrym kompilatorem pro stejny procesor, na kterem se bude testovat Java i to druhe, musi IMHO Java rychlostne prohrat. Pokud autor optimalizoval Javu odebranim synchronized, je to zasah udelany specialne pro tento test a vyssi rychlost Javy. Na testovacim C programu nebyl udelan zadny zasah pro optimalizaci na rychlost, a ostatne pochybuji, že puvodni program byl psan srovnatelne. Samotny program na testovani neznam, ale vyhodil autor z programu abstrakce vyssich urovni, ktere zerou vykon, apod.? Uz jsem par programu C na testovani videl, a s prominutim, vzdycky jsem ho napsal o dost lepe. Veskere Javovske vyhry v rychlosti predpokladaji, ze program v C bude spatne zkompilovan, tj. pro jiny procesor, nez na kterem bezi test. Jinak receno, vzdy predpokladaji bud spatne napsany program v C/C++/Asm, a nebo predpokladaji nevyhodne zkompilovany program v C/C++/Asm. Nemohu se proste zbavit pocitu, ze to neni O.K., zejmena ne, pokud se testuje.

[mirec]

btw: diskusia dlha jak na Zive IMHO kde je Jezevec? ))))))))))

[Drak]

Mam ale jeden problem: po spusteni balicku j2sdk-1_4_2_01-linux-i586-rpm.bin se zobrazi licence atd. a nakonci me to vyzve YES/No...po zadani yes se balicek zacne rozbalovat, pak se otestuje a napise ze je korupted a je konec....stahoval jsem to nekolikrat tech vic jak 30MB a stale to same. Nevi prosim nekdo co s tim _? Mockrat dekuji

[Leoš Literák]

bud spatna linka nebo jste to stahoval pres ftp v textovem rezimu ..

[Jan Navratil]

fujfuj :) ze se nestydite :) (viz subject & screenshot z Eclipse :) ienik