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

[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