Mýtus: pomalá Java

19.4.2005 21:19 | Přečteno: 2605× | Mýtobijství | poslední úprava: 15.5.2005 13:13

Odpůrci Javy velice často používají argument, že Java je "příšerně pomalá". Léta proti tomuto nařčení bojuji, ale nikdy jsem za tu dobu nezměřil, jak to ve skutečnosti je (publikované studie jsou jednou tak a jednou onak - podle toho, co chce ten který autor zrovna prokázat). Až nyní...

...došlo ke změně. Nedávnou jsem opět musel vyvracet nějakému obzvášť zatvrzelému antijavistovi, že to rozhodně není tak zlé, jak si myslí. Tak mě hned napadlo, že by nebylo od věci si změřit, jak na tom Java (ve srovnání s C) je.

Nepouštěl jsem se do žádných složitých benchmarků. Jen jsem vzal tři velmi jednoduché úlohy, které se dají velice snadno (a současně téměř identicky) realizovat jak v C, tak v Javě. V každém z jazyků to bylo jen pár řádků kódu.

Ještě důležitá informace - podmínky měření (konfigurace stroje): Celeron 1700, 512 MB RAM, deska MSI 648 Max, HDD Hitachi 120 GB 7200 ot./min. 8 MB cache; Fedora Core 3 (v plně aktualizovaném stavu), Java 5.0 (JDK 1.5.0). Měření času probíhalo pomocí programu time (tj. externě) na počítači bez další zátěže, uvádím vždy aritmetický průměr 3 naměřených časů. Java byla spouštěna v základní konfiguraci (tj. bez parametrů).

1. test - matematika. Javu jsem v minulých letech s oblibou používal pro matematické výpočty, proto jsem si od toho sliboval důkaz, že to nebyla špatné volba. Program provádí v cyklu opakovaně základní matematické operace (sčítání, násobení, dělení).
   Výsledky: C - real 26.0 s, user 25.6 s, sys 0.15 s; Java - real 23.7 s, user 22.8 s, sys 0.18 s
   Velmi zajímavé! Že bude Java rychlejší, to jsem opravdu nečekal. Ale je to (pro tento konkrétní výpočet) prostě tak. Ještě dodám, že program v C nebyl podroben optimalizacím - s optimalizacemi byly výsledky dokonce ještě o něco horší (pro -O3 dokonce o 5 %)!
2. test - zápis do souboru. Program alokuje buffer (pole) o velikost 100000 B a ten se 10000x zapíše do souboru (soubor tedy bude velký necelý 1 GB).
   Výsledky: C - real 32.5 s, user 0.58 s, sys 5.24 s; Java - real 33.1 s, user 2.10 s, sys 5.31 s
   Z výsledků je vidět, že výkon procesoru není pro celkovou rychlost podstatný. Proto, i když Java požírá mnohem více času procesoru, netrvá zápis významně déle než u C. Pro optimalizace platí totéž, co výše. U Javy bylo uvedených výsledků dosaženo s použitím "základního" streamu FileOutputStream, jakékoli pokusy o "optimalizaci" vedly vždy ke zpomalení.
3. test - spojování řetězců. Tohle je poměrně kontroverzní záležitost - co vlastně měřit. V C je řetězec pouhé pole znaků, takže záleží na způsobu alokace a na tom, co případně dalšího v programu ještě děláme. Zvolil jsem takový postup (není příliš efektivní), že se před každým spojením přialokuje (realloc) paměť a řetězec se připojí voláním funkce strcat(). V Javě jsem zavrhl třídu String (je to invariant, při spojování se musí vždy konstruovat nové objekty) a použil třídu StringBuffer (i při vědomí toho, že tato třída je přímo navržena pro dané použití a má tedy rychlostní optimalizaci).
   Výsledky: C - real 13.7 s, user 13.4 s, sys 0.15 s; Java - real 1.49 s, user 1.09 s, sys 0.16 s
   Řádově lepší výsledky Javy přičítám hlavně vhodně navržené třídě StringBuffer, která se v daném případě postarala o velice efektivní spojování řetězců. Bylo by zajímavé otestovat, jak by si stála v porovnání s třídou std::string (v různých jejích implementací) z C++. Rozhodně ale postup, který jsem pro C variantu použil, není pro takové použití vůbec vhodný.

Co z toho vyplývá? Že Java není vůbec pomalá, může sice být někdy pomalejší, ale jindy je naopak rychlejší. Navíc, rozsáhlé standardní knihovny umožňují snadno efektivně programovat věci, pro které musíme mít v C externí knihovny nebo psát hromady kódu (viz spojování řetězců). Samozřejmě, věci jako GUI Swing pomalé jsou, ale to už vyplývá z jejich filosofie, kterou je prakticky plná přenositelnost - a je to prostě daň, která se za to platí.

Koho by zajímalo, jak přesně vypadaly testovací prográmky, může si je stáhnout a vyzkoušet.

       

Komentáře

[doubleZ]

konecne neco rikajici srovnani, diky, zajimave! Jsem ale typicky Ceckar, javu neznam, toto hodnoceni je zajimave a potvrzuje co kazemu rikam ja, ze kazdy jazyk je nekdy pomalejsi nekdy rychlejsi, ale spis bys mel porovnat javu a c++ ty jsou si podobnejsi, ale diky!

[Michal Kubeček]

Co k tomu říct? Snad jen parafrázovat známý aforismus. Existují tři stupně lži: lež, sprostá lež a benchmark. O analytických benchmarcích to platí dvojnásob. Asi nemá smysl pouštět se do podrobného rozboru, ty testy jsou prostě k ničemu. Naprosto.

Uvedl bych jen jeden ilustrativní příklad. Nedávno mi jeden kolega tvrdil, že systém pod vmware by při dostatku paměti měl běžet asi na 97 procent rychlosti nativního systému na témže počítači. Moc se mi to nezdálo, ale ono záleží na úhlu pohledu. Rychlost procesoru, měřená pomocí openssl, byla skutečně jen neznatelně nižší než u nativního systému. Totéž platilo i pro rychlost disku nebo rychlost přenosu dat po síti. Jenže… na počítači, na kterém kompletní instalace systému (přes AutoYaST, takže lidský faktor nehrál roli) trvala 20-25 minut (podle přesné konfigurace), trvala stejná instalace do vmware 40-50 minut.

Poučení? Analytický benchmark nemá šanci postihnout reálnou rychlost aplikací. Tak primitivní, jako jste tu předvedl vy, nevypovídá už vůbec o ničem.

[jm]

S rychlosti Javy mam sve zkusenosti. Napriklad takova slast, jako je cca 15s vytuhnuti prohlizece pri prihlasovani do eBanky, je jednim z projevu uzasne rychlosti Javy.

[User682]

pred chvili jsem si dopsal kus male aplikacky ve swingu. a v souvislosti s tim me napadla jedna vec ohledne te rychlosti.

java-blackdown - bezi to neskutecne pomalu i na P4. jak na co, ale swing to poradne neumi anebo bezi hodne pomalu.

java od sunu - 1.5.0 - jede to vcelku dost rychle na to, ze jsem selectoval asi 300 radku do tabulky.

tak, jestli zde v tomto nahodou neni chyba. ja mam nainstalovane obe na masine.

bye gf

[TomCat]

Ten priklad s VMware, ktery uvadis, je uplne stejny FUD. Bud meris rychlost virtualniho stroje (ta je skutecne a *objektivne* jen o nekolik procent nizsi nez u realneho stroje - by design) a nebo rychlost cteni/zapisu do diskove partition emulovane v souboru vcetne journalu a pripadneho verzovani (snapshot). Nainstaluj si virt. machine na *realnou* partition na *realnem* disku a dostanes se zhruba ke stejnemu vykonu.

VMware bezne pouzivam uz dlouho - workstation na vyvoj/testing (W2K+Delphi+VisualStudio, testing: W2K, WXP, WXPSP2, W98SE, Slack) a server na testing (W2Ksrv, WNT4, Solaris10, CentOS). Pokud to provozujes na realnych discich, ztrata vykonu u jedne VM je minimalni, pri vice spustenych najednou se o vykon hosta samozrejme dynamicky deli.

Ale jinak souhlasim, benchmarky jsou nejsprostejsi lzi. A umele benchmarky typu uvadeneho v blogu tim tuplem. Java urcite neni pomalejsi pokud jde o elementarni operace nebo mozna jen o malinko. Ale rozhodne JE pomalejsi VETSINA komplexnich Java aplikaci oproti jejich "nativnim" protejskum. Je to IMHO dano obrovskym overloadem Javy diky objektum, pametovym mechanismum apod. Tak to byl kousek FUDu ode mne Taky je otazka, co je presne pomalejsi. Pravda je, ze treba prvni spusteni Eclipse nebo jEditu trva docela dlouho, ale pak uz jEdit jenom svisti... Takze rychlost ci pomalost je vzdycky relativni a jsem si jisty, ze jakekoliv tvrzeni se da snadno vyvratit. Tyhle kecy jsou dobre tak mozna PR managerum pro jejich ucelove dohadovani o nesmrtelnosti chrousta... Kdo by to sakra bral vazne?

[Michal Kubeček]

To není FUD, rozhodně jsem tím neměl v úmyslu nějak pomlouvat vmware, je to bezesporu skvělý software. Je to příklad toho, že subjektivní rychlost reálné aplikace nelze měřit pomocí analytických benchmarků. Kdybyste si přečetl můj příspěvek pořádně, všiml byste si, že tam píšu, že ani rychlost čtení z disku nebo zápisu na něj nebyla nějak výrazně nižší než u nativního systému, rozhodně ne poloviční. Tedy aspoň u delšího souvislého bloku. Ještě budu muset vyzkoušet náhodné čtení a zápis krátkých bloků, které jsou roztroušeny po disku (reálném nebo virtuálním). Samotného by mne totiž zajímalo, kde přesně ten ohromný propad výkonu vzniká.

[unchallenger]

To spojování je nesmysl, takhle to přece nikdo neimplementuje.

Měl bys to testovat oproti alespoň trochu slušně navržené knihovní funkci: g_strconcat, GStringu; nebo třeba oproti implementaci spojování řetězců z článku Ulricha Dreppera o optimalizaci...

Pak bys snad srovnával srovnatelné -- postavit proti sobě lineární a kvadratický algoritmus je výsměch.

[unchallenger]

No, a jak jsem se díval na math, tak to je o ničem. Co to má testovat?

[Michal Kubeček]

Na obranu autora je třeba dodat, že existují i daleko horší pokusy o benchmark…

[Michal Čihař]

Ano, všechno jde udělat ještě mnohem hůře než bylo udělánö

[Michal Čihař]

Eh, jak se mi tam dostalo to ö?

[Vašek Lorenc]

Navštivte krásná jözöra? :))

[©]

Tö jüä srändßä

[Christof]

Eremü

[Christof]

Tedy, vlastně Erőmű

[Pravák Bob]

Áno, áno, uděláme si dovolenou ve Švécku, hlavně aby nás tam nehrüzl lööös.

[Jan Kundrát (jkt)]

Hm. Tak test b spis benchmarkoval filesystem, rozhodne ne vykon daneho jazyka. Ono zapis 1GB fakt nejakou dobu trva . Pokud by mela byt tato cast aspon trosku objektivni, bylo by fajn uvest i vysledky time dd if=/dev/zero of=./soubor bs=1M count=1024, (pochopitelne na stejnem filesystemu, jako byly ty benchmarky) - idealne opet vickrat zopakovat a mezi testy hezky pustit sync (ten samozrejme nezapocitavat do casu).

Posledni test je podle autora zbytecny, resp. silne nerovnopravny

Nicmene ta matika je zajimava. Mohl bych poprosit o zdrojak? Nebyla tam nejaka bota typu operace na ruzne velkych promennych (short vs. long a tak)?

[unchallenger]

Zdroják tam máš. Umí někdo dostat z JIT assembler?

[Jan Kundrát (jkt)]

oops, sorry .

[Luk]

Jak jsem uvedl, moje primitivní prográmky nepovažuji za žádný benchmark ani pokus o něj. Prostě mě jen zajímalo, jak rychle ta konkrétní věc v C a Javě poběží - a o výsledky jsem se tu podělil. Je jasné, že v praxi to může být (a je) jiné. Ale největší antijavovské křiklouny by to mohlo aspoň trochu uzemnit

Jěště k tomu spojování - kdo trochu programuje/programoval pro nenáviděný OS, konkrétně pomocí MFC, tak ví, že až do nějaké verze (nepamatuji se přesně které) používal CString pro spojování stupidní kvadratický algoritmus a opravili to až později (1999?). A u STL záleží na konkrétní implementaci, některé spojují řetězce v lineárním čase jiné v kvadratickém.

[Michal Čihař]

Tak jsem si vyzkoušel tu matematiku a s gcc 4.0 je to cca o 33 % rychlejší než s gcc 3.3 . Javu kvůli testování instalovat nehodlám...

[Michal Čihař]

A u stringu je to nějakých 10 %...

[VícNežNic]

A u mě, u matematiky, rovná nula Jak s gcc3 tak s gcc4 jsem dostal to samé. Java o pár sekund rychlejší

[Jan Kundrát (jkt)]

Hmm, tak jsem si to taky pustil, a uz uz jsem chtel reportovat vysledky, kdyz mi doslo, ze se na pozadi furt kompilujou nejaky updaty. Pozitivni vec je to, ze jsem to pri normalni praci vubec nepoznal

[mimi.vx]

Java je ve skutecnosti celkem rychla.....

kdyz ji spustite s parametrem server tak u matematickych a jinych hromadnych vypoctu dokaze divy

ale .... co ji lehce zpomaluje je to ze potrebuje vrstvu navic oproti c/c++ a gui.....

[User682]

zajimava diskuse. neco pridam. jsou asi 3 nejvetsi problemy s rychlosti u tohoto jazyka. samozrejme, ze na vse se nehodi.

1) ze neco spatne naprogramujete. viz spojovani retezcu jsem bez tridy Stringbuffer dokazal zpomalit v aplikaci asi minimalne 20xkrat pred par mesici.

2a) problem, ze lidi radeji kodi v necem, co nema hotove a efektivne napsane knihovny a je to jednoduche. cilize nepouzivate hotove veci a ty java hodne ma.

2b) programovat neobjektove ci s malou podporou objektu, nepouzivat kompilator je rychlejsi. nekdy. kdyz to spocitate, tak zjistite, ze delate nektere veci podstatne dele.

3) HW. vetsina lidi vam rekne, ze java je narocna na HW. jenomze si spocitejte, co stoji vice: prace programatora v jinem jazyce navic anebo koupit pri dnesnich cenach lepsi pocitac.

drive jsem na javu hodne nadaval i jako programator. dneska na ni nedam dopustit. vetsina bludu o rychlosti javy ma pricinu uplne nekde jinde.

nic proti benchmarkum, ale ty nejlepsi jsou na klavesnici a monitoru.

gf

[Michal Kubeček]

Ad 3. To je velmi oblíbený argument, ale zdaleka ne vždy je správný. Zapomíná se na to, že cena hardware neroste zdaleka lineárně. Zdaleka ne všechny úlohy se dají dobře rozkládat na víc počítačů (a mnohé se nedají rozumně rozložit ani na víc procesorů). U jednoprocesorových systémů narazíte na výkonnostní strop poměrně brzy a u víceprocesorových není o moc výše.

S extrémním příkladem nesmyslnosti podobného uvažování jsem se setkal v článku, kde ukazovali, jak se programuje a jakousi elementární úlohu tam vyřešili kvadraticky místo lineárně. Na konci článku se pak psalo, že by to samozřejmě šlo vyřešit efektivnějí, ale že při výkonu dnešních počítačů je to jedno (pro zajímavost: bylo to někdy v roce 1988…).

[Luk]

Častou chybou v Javě je, že se spoléhá na garbage collector a vytvářejí se objekty (a dokonce i velká pole) jak na běžícím pásu. GC je pak nestíhá odstraňovat, alokuje se další a další paměť, OS swapuje a rychlost rapidně klesá. Někdy to končí až vyhozením OutOfMemoryError. Programátor pak nadává na Javu a přitom by se měl zamyslet nad svým stylem programování.

[unchallenger]

Ad 2a). A pro C ty hotové knihovny nejsou (viz i můj první příspěvek)? Že je lidi nepoužívají, není problém jazyka.

[Luk]

Není to problém jazyka, je to problém toho, že je lidé musí hledat, zatímco v Javě je to všechno hned u nosu. (Nejen) programátoři jsou totiž obecně líní jak prasata

[zabza]

No to je pravda, ovšem výsledkem té lenosti jsou právě ony knihovny...

Každej programátor napřed hledá, odkud by kód mohl zkopírovat (případně hledá ty knihovny) a až pak něco začne psát...

[Pavel Stárek]

Není to problém jazyka, je to problém toho, že je lidé musí hledat, zatímco v Javě je to všechno hned u nosu. (Nejen) programátoři jsou totiž obecně líní jak prasata

No něco u toho nosu taky není hnedka, ani v Javě, to se člověk sakra musí prohrabat dokumentací

[Bubak]

Jo jo, je to moc hezke, kdyz to tak clovek cte. Ale tezko se mu veri, kdyz musi obcas s Javou neco delat na PIII/500 (384M RAM).

Krome toho, ze kazda trosku slozitejsi vec vyzere, kdyz ne celou, tak podstatnou cast pameti. A nedejboze, aby si clovek pustil nekolik Javovych aplikaci

RT.

[kolemjdouci]

Asi tak. Ja mam doma P166, bezne ho pouzivam (i na programovani a ladeni programu v C). Pokusy delat na nem zapoctak z Javy jsme vzdal docela rychle

[User682]

je rok 2005. bezne jiz se pouzivaji P4. masinu koupite za 8kKc a podobne castky.

spocitejte, co se vam vyplati vice. cekat na to, az aplikace vytvori nejaky vysledek ( to je take cas) anebo jit na ~ 1-2 mesice na nejakou brigadu a koupit si lepsi stroj ?

kdyz denne cekate 20 minut na pocitac, tak za mesic je to 10 hodin. toto jiz nikdo nevidi.

toto je vyvoj. a branit se mu nema moc smysl.

ps: na PII-Cel500, 384MB RAM jsem zacinal v jave vyvijet. ted uz mam P4. setri mi to celkove hodne cas.

pavel kysilka

[Luk]

S Javou (tehdy 1.1.7b ) jsem začínal na 486sx/25, 8 MB RAM. Možná tomu nikdo nebude věřit, ale dalo se to. Pravda, kompilace byla trochu pomalejší (během ní jsem si mohl uvařit "Javu" a někdy ji i vypít), ale program pak už běžel (po cca dvacetivteřinovém startu) poměrně svižně, a to včetně AWT GUI (Swing tehdy ještě neexistoval).

Jsou skutečně aplikace (zvlášť, když se jedná o řešení pro konkrétní jedinou nebo několik málo instalací), kde je mnohem levnější koupit i třeba 3x výkonnější HW než platit čas vývoje navíc.

[Michal Kubeček]

Hezké. Ale já mám Athlon64 3500+ a 1 GB RAM a většina javových aplikací je pořád viditelně "líná". Co mi poradíte?

[jm]

Cluster?

[Luk]

Co je to ta "většina aplikací", které konkrétně? Něco jako Eclipse, SunONE, JBuilder (a další podobné aplikace s rozsáhlým GUI)? Ty budou relativně pomalé vždycky, ale pokud je pomalé něco jiného (třeba serverové nebo konzolové aplikace), za to už Java nemůže.

[jm]

Jasne, vsichni programuji v Jave spatne...

[Bubak]

Ja bych radsi, aby programatori umeli programovat...

[Bubak]

Sorry, to jsem trosku zjednodusil Samozrejme bych si mohl poridit lepsi pocitadlo, ale abych pravdu rekl, vzdycky mi vyhovovalo mit starsi, prave proto, aby me to brzdilo - hele tohle je pomale, dej si pozor... Na trigigovem athlonu se pekne vyviji, ale chudak uzivatel... A porad jeste beha spousta starsich pocitadel a me se proste prici software, ktery nuti lidi zbytecne cpat prachy nekam, kam by nemuseli, kdyby nekdo jiny nebyl liny...

[User682]

tuto teorii i praxi jsem razil take. mit pomalou masinu a vyvijet tim padem rychle aplikace.

ano, jde to. obcas udelate neskutecne rychle aplikace.

ale pokud nemuzete najit chybu, nebo casto kompilujete, tak vas to brzdi. a hodne. pak to zacina byt kontraproduktivni.

neni to o vykonu masin. ale o programatorech. radeji rychlejsi masinu a ve volnem case se vzdelavat a zdokonalovat. to se mi zda jako rozumny kompromis. cilize do toho musite videt a znat, co kdy pouzit. to je jeden z nejlepsich sporicu prace.

radeji mit rychlejsi masinu.

tohle muzete udelat vzdycky:

# echo -n {cislo} > /proc/acpi/processor/CPU0/throttling

bye gf

[Michal Kubeček]

To není úplně ono. Pomalejší (a starší) počítač je pomalejší i z mnoha jiných důvodů, než jenom kvůli procesoru. Naopak, můj osobní dojem je, že hrubý výkon procesoru má na (subjektivní) rychlost dnešních PC daleko menší vliv, než tomu bylo před 10-15 lety.

[Luk]

Je to tak. Při naprosté většině činností procesor není vytížen naplno, čeká na všechno možné (paměť, různá zařízení apod.). Největším problémem dneška se stává pomalost mechanických částí, hlavně disků.

[Pavel Stárek]

Jo jo, je to moc hezke, kdyz to tak clovek cte. Ale tezko se mu veri, kdyz musi obcas s Javou neco delat na PIII/500 (384M RAM).

No kolega dělá na PIII@800MHz/256MB v JBuilderu a pravda odezvy jsou o něco pomalejší, ale jde to. Pravda na mém pracovním AthlonuXP 2100 je to jiné kafe Doma mám Durona 1200 256MB a jde to taky. Holt si člověk musí zvyknout Krom toho, učím se a i úspěšně používám Python a nějak jsem v něm našel alternativu k Javě (až na to GUI ).

[Bubak]

Jo jo, JBuildera jsem zkousel, pak jsem presel na netbeans a nakonec jsem zjistil, ze ty blbosti, ktere delam (zatim) docela dobre napisu v textaku (at zije Kate) Musim zkusit, jestli nahodou neumi zvyraznovani Javove syntaxe Rhide.

RT.

[Hobit]

wxpython.org

[Jan Karasek]

nekolikrat v diskuzi zaznelo, ze u komplikovanych aplikaci je prece jen problem s rychlosti. Ten pocit mam take a rad bych to obratil do jeste obecnejsi roviny - my v Evrope budeme v brzke budoucnosti odkazani na to, delat pouze komlikovane veci. Pro ty jednoduche je zde dostatek lidi v Asii. Ja pracuji na nekolika takovych aplikacich a tam mam jiz problemy s C/C++ a to si kazdou radku 5 x rozmyslim, jaky to ma rychlostni dopad.

Jeste k tem pocitacum - P4 je standard. A ze to stoji 8kkc je take jen velmi zuzeny pohled. Nase aplikace bezi dostatecne rychle i na P166 a u posledni zakazky to bylo KO-kriterium. Ne proto, ze by nove pocitace staly tolik - ta zasadni castka byla ta nova instalace vsech pocitacu, objednavani dalsiho software apod.

To dalsi co me silne odrazuje je skutecnost, co vse je treba pro beh Javy a pro vyvojove okoli nainstalovat. Kdyz chci spolupracovat s ruznymi kolegy, tak musi mit kazdy nainstalovany vselijake ty Jboss veci a buhvi co jeste a to v tech spravnych verzich, zatimco pro bezny vyvoj v C jsem jeste nikdy nemel problemy.

Ono se to lehce napise nekolik c/Java test-programu, ale ta problematika je uplne nekde jinde.

[Luk]

Co je potřeba pro běh Javy instalovat? Pouze JRE (=stáhnout 1 soubor a spustit instalaci). Pro běžný vývoj v Javě stačí JDK, tzn. opět 1 soubor (ve kterém může být i vývojové prostředí NetBeans). Jiná věc je, když se používají nějaké frameworky (jako je třeba právě JBoss), ale to je u C/C++ úplně stejné (kdo vyvíjí něco např. na Qt, ví své).

[Libor Tvrdík]

Zdravím,

pokud to běží na 1.5 je dobré použít místo StringBufferu třídu StringBuilder. Je rychlejší, protože neobsahuje synchonizace (důsledky si domyslíte sami ;) ).

Je to takový rozdíl jako Vector versus ArrayList nebo Hashtable a HashMap.

[Luk]

Verze 1.5 vůbec obsahuje řadu příjemných zlepšení (např. v Collections Framework, v multithreadingu, ale i ve Swingu atd.). Dokonce mám pocit, že je i o něco rychlejší (a hlavně rychleji startuje), ale to je čistě subjektivní.