Existuje seriózní srovnání rychlosti Javy a C/C++? (diskuse)

[Luboš Doležel (Doli)]

Pokud porovnávat C++ a Javu, tak určitě ne s GCC, ale s plnou optimalizací v MS VC++...

Teoreticky nikdy nemůže být Java rychlejší než C/C++, dokud budou existovat kvalitní kompilátory. I kdyby byl JIT kompilátor Javy sebelepší, přijde mi konstrukce

new Random().nextInt() // popř. někam objekt uložit

podstatně náročnější než

rand()

Tohle asi není dobrá ukázka toho, co chci říct...ale jde mi o to, že kód v C/C++ bude vždy rochu víc low-level a bude tak přecejen snáze optimálně zkompilován.

[Luboš Doležel (Doli)]

Zapoměl jsem dodat, že teoreticky jsou mohou být všechny jazyky stejně rychlé, jen závisí na kvalitě kompilátoru. Potom závisí na obratnosti jazyka, kdy více high-level jazyky budou mít vždy problémy u low level věcí.

U high level věcí bude výkon vyrovnán, ale bude tu větší zátěž na vývojáře v nižším jazyce.

[jancici]

asi tak dva mesiace dozadu som riesil dilemu ze ktory jazyk vybrat, teda pracujem na matematicko/fyzikalnych projektoch, takze moje programy musia vediet rychlo pocitat,

tak som zacal porovnavat C/C++ a JAVU, napisal som si program ktory pocitat n-tu odmocninu v JAVE a spravil presne ten isty program v C. ak by ste chceli mozem to sem pastnut.

vysledok: na niektorych PC bola JAVA 2x rychlejsia ako C, ale na inych zase C bolo omnoho rychlejsie ako JAVA, (PC sa odlisovali OS (wintendo,gentoo) a HW (gentoo je na amd64, wintendo na athlonXP)

tak som do porovnavacieho testu pridal MONO: MONO bolo trosku pomalsie ako C na gentee, ale na wintende to uz bolo zrovnatelne ci som pouzila mono alebo VM od wintenda

zaver: vychadza mi to na C/C++ ale musim najst vhodne prostredie, vysledny program potrebuje mat graficky vystup, a mal by byt prenositelny na linuxy a winteda.

[Miloslav Ponkrác]

Já osobně bych na matematické výpočtu jednoznačně použil C++. Už jenom z toho důvodu, že Java nepodporuje nic jiného, než 32 a 64 bitová reálná čísla. Na PC se běžně počítá v 80 bitových číslech a také je možné využít multimediální vektorové instrukce, na což Java také nemá vhodné datové typy. Při vhodném využití vektorových instrukcí můžete takto velmi výrazně urychlit výpočty a z C/C++ na to dosáhnete.

[elviin]

Blitz

[Lukáš Rýdlo]

Zatim jsem zadne seriozni srovnani nevidel. Mozna je to tim, ze je to asi tak jako chtit seriozni srovnani vimu a emacsu. Vzdy to skonci u flame (protoze kazdy rozumny clovek vi, ze nejlepsi je vim ).

BTW. v C++ se ucim druhy semestr a zatim jsem nasel hromadu nevyhod, ale z vyhod asi jen to, ze se v tom da programovat velmi nizkourovnove (coz se da take oznacit za nevyhodu ). A v Jave jsem zatim nedelal, ale podle historek kolegu Javistu je mi jasne, proc si nas prednasejici z C++ dela srandu ze vsech moznych programovacich jazyku, jen ne z Javy

[smrtak_]

treba proto ze v tom nedela :d

[Luk]

Kdysi jsem tu jedno velice neseriózní porovnání prováděl. V čem ale vítězila Java za každých okolností (i když jen o pár procent), byly matematické operace. Nevím proč, ale prostě to bylo tak...

[Michal Vyskočil]

Nějaké testy jsem zkoušel dělat, než mi došlo, že na to nemám . Ale Java byla rychlejší než C u rekurzí. Dále se domnívám, že u alokací většího množství paměťových bloků by Java nad C/C++ také vyhrála.

Ale základní problém nebývá rychlost. Pro většinu gui aplikací bohatě stačí Python (Perl, Ruby). Problémem je (u desktopových aplikací) spíše paměťová náročnost.

[Michal Kubeček]

Java byla rychlejší než C u rekurzí.

Že by chybějící '-fomit-frame-pointer'?

Dále se domnívám, že u alokací většího množství paměťových bloků by Java nad C/C++ také vyhrála.

Chcete říct, že by v tomto specifickém případě vyhrál defaultní alokátor paměti Javy nad implementací malloc() v glibc resp. standardním new? To je dost dobře možné, ono totiž nelze napsat alokátor, který by byl nejefektivnější ve všech situacích, protože ty požadavky jsou do značné míry protichůdné. Právě proto máte možnost použít vlastní implementaci malloc() resp. new. Ale to vlastně jen na konkrétním příkladu demonstrujeme to, o čem psal autor příspěvku…

[Miloslav Ponkrác]

Čistě můj osobní názor je, že pokud by se napsal alokátor pro C/C++ tak, aby fungoval podobně jako v Javě - tedy, že by ukrutně plýtval pamětí a používal nadbytek paměti k tomu, aby zrychlil operace s heapem, pak by to asi nebyl problém. Ono spoustu algoritmů lze zrychlit v případě, že se smíříme s paměťovou nenažraností.

[Michal Vyskočil]

Nee, zkoušel jsem jednotlivé optimalizace. Ale stejně výsledky takto krátkých programů (třeba hanojské věže) nejsou vůbec směrodatné. Ostatně psal jsem, že vím, že na seriózní porovnání těchto jazyků nemám .

[Michal Kubeček]

V čem ale vítězila Java za každých okolností (i když jen o pár procent), byly matematické operace.

Tohle tvrzení už jsem párkrát viděl. Ale nikdy jsem nikoho neviděl napsat, co tím výrazem matematické operace vlastně konkrétně myslí. Můžete uvést nějaký příklad pro představu?

[Luk]

Bude to někde v mém blogu (tipoval bych to tak na únor/březen, nechce se mi to hledat). Byly to základní početní úkony (sčítání, odčítání, násobení, dělení), nic složitého.

[Michal Kubeček]

Tak teď už tomu vůbec nerozumím. Základní aritmetické operace totiž vykonává tak jako tak procesor, at už se bavíme o celočíselných nebo floating point operacích. Takže moc nechápu, jak by mohly být v jednom jazyce rychlejší než ve druhém. Takže byl-li ve vašem testu někde rozdíl, tipoval bych spíše tu omáčku okolo, rozhodně ne samotné aritmetické operace.

[Luk]

Také tomu nerozumím. Co třeba optimalizace využití registrů?

[Leoš Literák]

Prvni dogma jsem v zivote neslysel. Java je objektove orientovany jazyk. Je mnohem vice objektove orientovany a lepe navrzeny nez C++, coz je pokus naroubovat OO principy na C. Ale nejlepe objektove orientovany? Na Smalltalk nema.

Pokud jde o druhe dogma, tak bych jej spise obratil. Existuje dogma, ze Java je priserne pomala. To uz hezkych par let neni pravda. Program v Jave je oproti kompilovanym programum nenazrany na pamet. GUI aplikace jsou pomalejsi nez nativni, protoze swing je takhle navrzen (ale verze 1.5 prinesla zlepseni). Ale jinak Java neni vyrazne pomalejsi nez jine programovaci jazyky. Zvlaste na serveru dotahuje na C/C++.

[Luk]

GUI aplikace jsou pomalejsi nez nativni, protoze swing je takhle navrzen (ale verze 1.5 prinesla zlepseni).

Troufám si tvrdit, že je dnes (1.5) Swing rychlejší než SWT. Nemám pro to žádné důkazy, ale srovnatelné programy používající to či ono (např. Eclipse vs. Netbeans) jsou na stejném stroji různě rychlé (Swing rychlejší). Paměťová náročnost obojího je ovšem ukrutná (u větších aplikací)...

[Lukáš Zapletal]

Jojo, je to tak. Eclipse je nechutně pomalé, zejména pokud na to nabalíte další pluginy (EJB atd). Tady vítězí asi Netbeans.

[xkucf03]

Dávám přednost Swingu před SWT, taky mi přijde rychlejší. A vlastně i hezčí

[Miloslav Ponkrác]

Jednak by to chtělo definovat, jaké je vlastně kritérium "objektovosti" jazyků, a na to žádná definice neexistuje. Existuje dokonce několik různých směrů pojetí objektově orientovaného jazyka, které mezi sebou neustále soupeří a dokazují si, že to jejich pojetí je to správné. Jsou z toho značné teoretické debaty a zvláště v poslední době tak vzniká spousta nových programovacích jazyků, jejichž cílem je mimo jiné být ten nejlepší OOP jazyk. Proto diskuse o tom, který jazyk je správně objektový beru jen za mlácení prázdné slámy.

Můj osobní názor je, že OOP má sloužit člověku, zatímco často se stává, že OOP je cílem, nikoli prostředkem, jak by tomu mělo být. Důkazem toho je, že třeba i v Javě nejsou všechno objekty. Můj názor je, že rozdíl mezi Javou a OOP co se týká OOP je hlavně ten, že Java je určená pouze pro OOP programování a v podstatě nic jiného nesvede. C++ je multipradigmový, C++ nebylo vytvořeno za účelem, aby v něm šly pouze objekty a nic víc. A C++ má všechny potřebné prostředky pro OOP programování, nic mu z tohoto hlediska nechybí. Věděl bych o spoustě věcí, které bych C++ skutečně vytknul, ale určitě ne to, že by OO principy a zvláště ne, pokud bych je srovnával s Javou.

Co se týká rychlosti Javy, ani na okamžik jsem se nezmínil, že je pomalá. Koneckonců stejně většina programů dnes nedělá z větší části nic jiného, než volá API funkce operačního systému, a tam pak na rychlosti moc nesejde. Na druhé straně je pravdou, že pokud mám já osobně na desktopu používat aplikaci napsanou v Javě, raději si jí odpustím úplně. Je totiž podstaně náročnější na systémové zdroje a při práci s ní je to znát. Na serveru bych se ale Javy vůbec nebál.

Ale mým cílem není tvrdit, že Java je pomalá, nebo rychlá. Chtěl bych vědět, jak moc je skutečně pomalá, či rychlá. A v článku jsem pouze shrnul poznatky za posledních několik let, které mě provázely při seznamování se testů na rychlost Javy.

[Luk]

Chtěl bych vědět, jak moc je skutečně pomalá, či rychlá.

Teď jsem si vzpomněl, že jsem kdysi někde potkal nějaké rozsáhlejší testy. Neporovnávaly (podle mnoha kritérií) jen Javu s C a C++, ale také C/C++ kompilované různými kompilátory, a ještě nějaké další jazyky. Už si ale nevzpomenu, kde to bylo.

[Luboš Doležel (Doli)]

Já jsem to taky někde viděl a pamatuju si, že s GCC to bylo většinou horší než Java a s MSVC++ C++ vyhrávalo.

[Sinuhet]

Java je objektove orientovany jazyk. Je mnohem vice objektove orientovany a lepe navrzeny nez C++, coz je pokus naroubovat OO principy na C.

Podle ceho soudite, ze je lepe navrzeny?

[Michal Kubeček]

On je lépe navržený - z určitého úhlu pohledu. Stejně jako je z určitého úhlu pohledu skvěle navržený Pascal. Ale ten úhel pohledu je (v obou zmíněných případech) spíše dán teoretickými představami o jazyce, než praktickou použitelností a efektivitou. To je právě hlavní síla C a C++: jsou to jazyky, které nebyly navrženy podle určité teoretické vize, ale podle potřeb těch, kdo je budou používat. Proto jsou sice C a C++ z teoretického hlediska navrženy nesystematicky a mnohdy nelogicky, ale pro praxi se hodí daleko více.

Jednoduchý příklad: Wirth se rozhodl, že pro porovnávání použije '=' a pro přiřazení ':=', protože to odráží logiku obvyklého matematického zápisu. Kernighan a Ritchie si udělali malou statistiku a zjistili, že přiřazení se v programech používá podstatně častěji než porovnávání na rovnost, takže zvolili '=' pro přiřazení a '==' pro porovnávání. A podobný rozdíl v logice uvažování se potom projevuje i v podstatnějších otázkách návrhu jazyka.

[podlesh]

To je právě hlavní síla C a C++: jsou to jazyky, které nebyly navrženy podle určité teoretické vize, ale podle potřeb těch, kdo je budou používat. Proto jsou sice C a C++ z teoretického hlediska navrženy nesystematicky a mnohdy nelogicky, ale pro praxi se hodí daleko více.

Toto právě platí i o Javě. Vlastně možná především o Javě...

Pouze to zaměření je výrazně jiné, než u C++

[Ladislav Thon]

... program v C/C++ provádí více činností, než program v Javě...

V případě ideálně napsaného programu v Javě a ideálně napsaného ekvivalentu v C/C++ bych očekával, že Céčko bude o nějaké to procento rychlejší, konkrétně proto, že program v Céčku neprovádí takové <ironie>nesmysly</ironie>, jako kontrola mezí polí a podobně :)

Doufám, že počáteční režii Javy (start VM, JIT kompilace) nepovažujete za argument.

Jinak si myslím, že vcelku nemá smysl tu rychlost běhu programu řešit, protože na obvyklé problémy jsou oba jazyky/platformy rychlé dostatečně. Co takhle benchmark rychlosti vývoje v tom kterém jazyce? :)

[Kyosuke]

http://www.flownet.com/gat/papers/lisp-java.pdf

/me devil...

[Ladislav Thon]

Ó, tak tenhle paper jsem neznal, jinak jsem vášnivým teoretickým zastáncem Lispu. I když jsem v něm nikdy nenaprogramoval nic jiného, než interpret sebe samého :)

[Luk]

V LISPu (přesněji řečeno AutoLISPu) jsem dělal jednu jedinou věc - nějakou aplikaci pro AutoCAD, snad to bylo něco na návrh vodovodního potrubí. A naplno říkám: "Již nikdy více!!!"

[Kyosuke]

AutoLISP má s dnešním LISPem asi tolik společného jako K&R C s ISO C 99...

[Luk]

Ale základní syntaxe je stejná. Nebo ne?

[Hynek (Pichi) Vychodil]

Já bych to řekl asi takhle. Na začátku byl Fortran a Lisp. Od Fortranu jdeme dlouhou oklikou přes C, C++, Paskal, Perl, Java, Python, Ruby k Lispu. Ještě máme před sebou dlouhou cestu, než se k tomu Lispu dostaneme. Ti chytřejší skočí rovnou do cíle

[Barney]

) ach lisp ...
hlavny dovod preco preferujem emacs (tym druhym je schopnost emulovat vi)

[Lukáš Zapletal]

O žádné emulaci nemůže být ani řeč.

[Ladislav Thon]

AutoLISP má s dnešním LISPem asi tolik společného jako K&R C s ISO C 99...

Já žiju v představě, že LISP je čtyřicet let stále stejný, a to zejména z toho důvodu, že není možné ho jakkoli vylepšit :)

[Kyosuke]

Vy určitě víte, jak to myslím, jen to nezatloukejte!

[Miloslav Ponkrác]

Jinak si myslím, že vcelku nemá smysl tu rychlost běhu programu řešit, protože na obvyklé problémy jsou oba jazyky/platformy rychlé dostatečně. Co takhle benchmark rychlosti vývoje v tom kterém jazyce? :)

Osobně se domnívám, že rychlost vývoje v 90% případů závisí daleko spíše na knihovnách a nástrojích, než na zvoleném programovacím jazyku. No, a těch 10% případů se povede náhodou využít vhodnou vlastnost toho kterého jazyka a tam může být rozdíl. Takže podle mě seriózní benchmark nemá moc smysl.

Po mnoha letech praxe a zkušenostech se domnívám (a věřím, že mnozí mu budou oponovat), že rychlost vývoje v Javě i v C++ je zhruba srovnatelná. Problém je, že na rychlý vývoj v C++ musíte mít výborné znalosti a zkušenosti s C++. S Javou se dá zvládnou rychlejší vývoj i s podstatně nižším stupněm znalostí. Při dobré znalosti obou jazyků a dobrých knihovnách není podle mě v rychlosti vývoje až tak znatelný rozdíl.

[Miloslav Ponkrác]

V případě ideálně napsaného programu v Javě a ideálně napsaného ekvivalentu v C/C++ bych očekával, že Céčko bude o nějaké to procento rychlejší, konkrétně proto, že program v Céčku neprovádí takové nesmysly, jako kontrola mezí polí a podobně :)

Třeba v takovém .NET je možné kontrolu mezí polí vypnout, pokud si věříte

Já bych rychlosti C/C++ věřil více taky proto, že se spousta proměnných a objektů odehraje na zásobníku a nemusí se kvůli tomu hrabat na dynamickou paměť jako v Javě.

A taky proto, že dvoustupňová kompilace Java -> byte kód a pak JIT kompilace byte kód -> strojový kód musí být alespoň o pár procent méně efektivní, než přímá kompilace C++ -> strojový kód.

Kromě toho je Java víc zaměřená na přenositelnost, což stojí další rychlost.

Mě by taky zajímalo, jak by se Java rychlostně vypořádala třeba s tím, kdyby C++ začalo používat vektorové instrukce v procesoru. Jestli vůbec Java je schopná třeba optimalizovat stejným způsobem.

[podlesh]

Předem svého příspěvku upozorňuji, že reaguji jen na konkrétní věc a netvrdím že Java je rychlejší. Konkrétně právě Java nemá některé feature, což obecně brání dosažení nejvyššího výkonu (alokace na zásobníku, předávání hodnotou, struktury jako hodnotový datový typ, atd). Navíc, vše dále uvedené se nevztahuje konkrétně v Javě.

A taky proto, že dvoustupňová kompilace Java -> byte kód a pak JIT kompilace byte kód -> strojový kód musí být alespoň o pár procent méně efektivní, než přímá kompilace C++ -> strojový kód.

Proč? Ale vážně.

Je to spíše naopak - JIT může použít optimalizace na základě aktuálních informací. Tedy například konkrétní typ procesoru, ale především na základě reálných informací o běhu. Typicky může nejčastěji volané metody vložit (inline), smyčky částečně (nebo úplně) rozvinout a podobně.

Samozřejmě pokud mluvíme v teoretické rovině. V praxi mají ty nejlepší kompilátory C a Fortranu stále výrazný náskok a nejspíše ho udrží.

Mě by taky zajímalo, jak by se Java rychlostně vypořádala třeba s tím, kdyby C++ začalo používat vektorové instrukce v procesoru. Jestli vůbec Java je schopná třeba optimalizovat stejným způsobem.

Viz výše - proč by ne? Dokonce to AFAIK některé JIT používají, ale nevím v jakém je to stavu - a hledat to nebudu, raději půjdu spát.

[Ladislav Thon]

A taky proto, že dvoustupňová kompilace Java -> byte kód a pak JIT kompilace byte kód -> strojový kód musí být alespoň o pár procent méně efektivní, než přímá kompilace C++ -> strojový kód.

Proč? Ale vážně.

Jeden důvod bych viděl: úspěšnost generování optimálního cílového kódu závisí mj. na tom, jaké máš o programu informace. V nějakém mezikódu (bajtkód či cokoliv jiného) jich určitě máš míň, než třeba v abstraktním syntaktickém stromu (proto třeba překladač Flexu negeneruje v průběhu činnosti žádný mezikód, pokud si to dobře pamatuju :) ). To je jediné, co mne napadá.

Je to spíše naopak - JIT může použít optimalizace na základě aktuálních informací. Tedy například konkrétní typ procesoru, ale především na základě reálných informací o běhu. Typicky může nejčastěji volané metody vložit (inline), smyčky částečně (nebo úplně) rozvinout a podobně.

V tom máš samozřejmě pravdu.

Mě by taky zajímalo, jak by se Java rychlostně vypořádala třeba s tím, kdyby C++ začalo používat vektorové instrukce v procesoru. Jestli vůbec Java je schopná třeba optimalizovat stejným způsobem.

Viz výše - proč by ne? Dokonce to AFAIK některé JIT používají, ale nevím v jakém je to stavu - a hledat to nebudu, raději půjdu spát.

Vážně? To jsou věci. Osobně bych určitě nechtěl psát generátor cílového kódu pro procesor, který oplývá instrukcí hledání kořene polynomu, nebo jaká to byla :)

[Miloslav Ponkrác]

Vážně? To jsou věci. Osobně bych určitě nechtěl psát generátor cílového kódu pro procesor, který oplývá instrukcí hledání kořene polynomu, nebo jaká to byla :)

Proč? Bežné procesory v PC obsahují různé instrukce typu proveď stejný výpočet třeba se čtyřmi, nebo osmi čísly najednou. Výborné na počítání s vektory a maticemi, výsledkem je obrovské zvýšení výkonu. Ale to je asi pro Javu nevyužitelné, protože Java nemá potřebné datové typy.

[Ladislav Thon]

Proč? Bežné procesory v PC obsahují různé instrukce typu proveď stejný výpočet třeba se čtyřmi, nebo osmi čísly najednou. Výborné na počítání s vektory a maticemi, výsledkem je obrovské zvýšení výkonu. Ale to je asi pro Javu nevyužitelné, protože Java nemá potřebné datové typy.

Napsal jsem to blbě, už mi to moc nemyslelo :) Měl jsem na mysli vlastně to, že bych nechtěl psát optimalizátor, který bude v kódu běžného (mezi)jazyka bez speciálních konstrukcí hledat místa, kde by bylo možné takové instrukce použít. Nepochybuju o tom, že takové překladače existují (zmíněno níže v diskusi), ale na můj vkus je to hodně drsná matematika.

Pokud jde o Javu, přijde mi taky trochu líto, i když bych to nejspíš nevyužil, že JSR 83 leží ladem (aspoň se mi zdá), tam by se nějaká kouzla dělat dala.

[podlesh]

Jeden důvod bych viděl: úspěšnost generování optimálního cílového kódu závisí mj. na tom, jaké máš o programu informace. V nějakém mezikódu (bajtkód či cokoliv jiného) jich určitě máš míň, než třeba v abstraktním syntaktickém stromu (proto třeba překladač Flexu negeneruje v průběhu činnosti žádný mezikód, pokud si to dobře pamatuju :) ). To je jediné, co mne napadá.

Pokud ovšem nepovažujeme AST za mezikód

[Ladislav Thon]

Pokud ovšem nepovažujeme AST za mezikód

Jasně že AST je svým způsobem mezikód, to je otázka jenom terminologická. Ale je to mezikód s největší vyjadřovací schopností :)

[Miloslav Ponkrác]

Je to spíše naopak - JIT může použít optimalizace na základě aktuálních informací. Tedy například konkrétní typ procesoru, ale především na základě reálných informací o běhu. Typicky může nejčastěji volané metody vložit (inline), smyčky částečně (nebo úplně) rozvinout a podobně.

Je to sice teoreticky pravda, ale když jsem se nad tím zamyslel, tak už s tím tolik nesouhlasím. Nedokážu si dost dobře představit získávání statistických informací třeba o tom, kolikrát proběhla, která smyčka, aby to bylo možné využít pro optimalizaci, respektive dokážu, ale za cenu ukrutného zpomalení běhu. Takže to ve skutečnosti bude asi jinak.

Mimochodem, stejným způsobem snad má fungovat i nejlepší existující kompilátor pro C/C++, a to od Intelu. Přeložíte program a necháte chvíli běžet program, on ho otestuje, zjistí spoustu profilovacích, statistických a jiných informací. A pak ho kompilátor přeloží znovu, ale s použitím zjištěných informací a vytvoří tak výrazně rychlejší program. A dokážu si představit, že taková binárka jde otestovat podstatně lépe, než to, co zvládne JIT.

Nevím, pořád slyším, jaké zázraky zvládne JIT, ale pořád mi něco říká, že C/C++ kompilátor musí fungovat lépe, protože má na analýzu daleko více času, než kolik času může analýze věnovat JIT. Vždyť některé velké C/C++ projekty se mohou překládat i hodiny! Pochybuji, že by si takový JIT kompilátor mohl dovolit řekněme hodinu analyzovat kód, aby dělal optimalizaci. Navíc mi přijde, že prostě kompilátor C/C++ má v zásadě více informací k optimalizaci, než má JIT.

[Kyosuke]

A Stalina už jste si vyzkoušel?

[sofr]

Mimochodem, stejným způsobem snad má fungovat i nejlepší existující kompilátor pro C/C++, a to od Intelu. Přeložíte program a necháte chvíli běžet program, on ho otestuje, zjistí spoustu profilovacích, statistických a jiných informací. A pak ho kompilátor přeloží znovu, ale s použitím zjištěných informací a vytvoří tak výrazně rychlejší program. A dokážu si představit, že taková binárka jde otestovat podstatně lépe, než to, co zvládne JIT.

To umi i gcc, ne? -fprofile-generate a -fprofile-use

[Miloslav Ponkrác]

Problém gcc je, že je to houby platné. Já osobně nevěřím ani moc na to, že gcc dokáže nějak slušně optimalizovat. Na druhé straně u Intelovského kompilátoru je každá optimalizace skutečně "hmatatelně" vidět.

[podlesh]

Nevím, pořád slyším, jaké zázraky zvládne JIT, ale pořád mi něco říká, že C/C++ kompilátor musí fungovat lépe, protože má na analýzu daleko více času, než kolik času může analýze věnovat JIT.

Už jsem to sice psal, ale znova: zázrak je, že to vůbec funguje tak dobře, že se o tom zde můžeme bavit. Zázrak je ten obrovský pokrok, jaký se za posledních pár let udělal.

Vždyť některé velké C/C++ projekty se mohou překládat i hodiny! Pochybuji, že by si takový JIT kompilátor mohl dovolit řekněme hodinu analyzovat kód, aby dělal optimalizaci. Navíc mi přijde, že prostě kompilátor C/C++ má v zásadě více informací k optimalizaci, než má JIT.

To se většinou řeší tak, že se ze začátku metody přeloží bez optimalizací ("expanze pseudoinstrukcí") a až teprve postupně se používané metody kompilují optimalizovaně. Kompilovat se obecně může mnohokrát, podle potřeby (už kvůli možnosti dynamicky přidávat třídy).

[podlesh]

První "dogma" asi nemá opravdu cenu rozvádět. Maximálně to vypovídá něco o daném jedinci a jeho přehledu. Smalltalkisté jsou zde stále.

Co se týká druhého, tak je to skutečně obráceně. Dogma zní, že je Java pomalá, protože je interpretovaná. Tyto benchmarky se objevily teprve nedávno a neukazují že by byla skutečně Java rychlejší (stejně je takové porovnání nesmyslné), ale že je srovnatelná!

Opět platí, že pokud by někdo tvrdil že je Java opravdu obecně rychlejší, je to blbost. Ale lze poukazovat na některé zajímavé výhody JITu, například že není potřeba pro pořádnou optimalizaci specifikovat procesor při překladu Jistě, není to korektní diskuse, ale zde se jedná o reklamu/propagaci, ta nemusí být korektní.

[Hood3]

Čo tento benchmark, asi to nieje zrovna naserioznejší test ale tiež o niečom vypovedá, porovnáva rýchlosť pôvodného Quake2 enginu s jeho java portom

[elviin]

Rychlost je jen jednim ukazatelem kvality. Rychlost aplikace se muze ladit postupne, pokud to umoznuje navrh a zakaznik. C++ ma trpi schizmatem prebujelosti konceptu, do jiste miry je to dany jeho minulosti a pozdnim standardem (BTW se mrknete do zdrojaku Fluxboxu). Pak na zacatecnika pusobi jako soubor vseho mozneho, kde lze delat vse mozne, vsemi zpusoby - no neni to nadhera - moznost vyberu. Pak uz jen chybi, aby si uzivatel osvojil API, ktere vyhovuje jeho podminkam.

Je dobre, ze je tu s nami tolik zajimavych jazyku a pristupu, pak se nedostaneme tak jednoduse do slepe ulicky.

Asi nejlepsi by bylo se blize zajimat o jazyk z hlediska pracovnich prilezitosti a ne rychlosti. "Jasne super, takze kde jsme to naposled skoncili s tim Visual Basicem":). Prave z tohoto hlediska mi vysel zajimavejsi jazyk C++, protoze se v nem proste dela vic zajimavych projektu (studoval jsem biokybernetiku). C++ je pestry, pak i jeho uplatneni je pestry. Ale vcera jsem se dival na projekt Nutch a ten je myslim v Jave, mrknete se.

Jak pestry? Asi takhle. Prevod cisel serazeno od nejrychlejsiho zpusobu po nejpomalejsi, od nejmene bezpecneho k bezpecnemu, od specifickeho k obecnemu reseni - jen si vybrat podle potreby:

C:

atoi, atof, atol

stl:

template<typename T>
inline T convertToFrom( const std::string& fromString ) 
{
    T toT;
    std::istringstream tmpStream(fromString);
    char c;
    if( !(tmpStream >> toT) || tmpStream.get(c))
        throw std::out_of_range( "convertToFrom is
            std::out_of_range." );
    return toT;
} 

stl,boost:

 
T i = boost::lexical_cast<T>("123");

[Hynek (Pichi) Vychodil]

Tak se nám tu rozhořela zajímavá hádka o to jestli se dá při dvoukrokovém překladu dosáhnout lepší optimalizace nebo ne. Zajímavé je, že si diskutující neuvědomili dvě důležité skutečnosti.

1. Dvoukrokový překlad se často používá i u C/C++ (gcc určitě).
2. Java bytekód je stroják JavaVM a to je zásobníkový počítač.

Z toho nám vyplývají dvě zajímavé věci. Překladem Java->JavaByteCode vzniká jednodužší jazyk než v prvním kroku překladu C/C++. JavaVM má jen jeden registr-akumulátor, kdežto překladem C/C++ obecně vzniká pseudokód pro VM s nekonečno/konečno registry. Zásobníkový počítač má ale tu příjemnou vlastnost, že se paradoxně mnohem snáze optimalizuje, kdežto pro více registrové počítače jsou optimalizační postupy mnohem složitější. Kdyby to tímhle skončilo, tak by ale Java na reálném procesoru s více registry jednoznačně prohrála, ale teď do toho ještě přichází JIT. Ten vrchol zásobníku rozhodí do více registrů a díky jednodužšímu kódu je tato optimalizace kupodivu jednodužší, než když to samé má udělat C/C++ překladač, který naopak těch hodně registrů musí nacpat do n reálných registrů konkrétního procesoru. Jednodužší co do algoritmu, ale C/C++ překladač to může udělat stejně dobře i když složitějším algoritmem. Otázka zní jestli se v tom složitějším algoritmu vývojáři překladače nezamotají. K tomu se nám připojí speciální instrukce a schopnost nalézt v kódu části na které je můžu použít a tady je zase určitá výhoda jednoduchosti zásobníkového počítače.

Z toho nám zdánlivě Java vychází jako vítěz. Její optimalizace jsou jednodužší a tak se v nich dělá méně chyb, dají se lépe matematicky popsat, rychleji se vyvýjí atd. Jenže už to tu jednou zaznělo, Java nutí programátora dělat spoustu zbytečností a ne všechny ty zbytečnosti optimalizace může odstranit. Ve výsledku je to asi tak, že když programátor v C/C++ ví co dělá a autoři překladače neudělali chybu, by Java neměla být rychlejší. Takže na otázku co je rychlejší C/C++ nebo Java bych odpověděl: optimalizoavný Forth. Jeho kód zabere míň místa na disku, zabere míň paměti při běhu a ještě ke všemu se stejně dobře optimalizuje jako Java

[Leoš Literák]

Promiň, ale tohle mi trhá oči: jednodužší->jednodušší, vyvýjí->vyvíjí.

[Hynek (Pichi) Vychodil]

Jo to ti věřím

[Lukáš Zapletal]

lolec

[Miloslav Ponkrác]

Dvoukrokový překlad se často používá i u C/C++ (gcc určitě).

To je otázka. GCC používá vícekrokový překlad a pokud jsem pochopil, je to značnou příčinou jeho problémů. Osobně považuji koncepci GCC za jednou z příčin, proč špatně optimalizuje. Byl bych rád, kdybychom se bavili o dobrých překladačích C/C++, a ne o GCC. Navrhuji bavit se o Intelovských, nebo přinejhorším alespoň o Microsoftích kompilátorech C/C++, které optimalizují podstatně lépe a úspěšněji, než GCC.

Překladem Java->JavaByteCode vzniká jednodužší jazyk než v prvním kroku překladu C/C++.

Ano, ale také se překladem Java->JavaByteCode ztrácejí některé informace, které by bylo možné využít k lepší optimalizaci.

Otázka zní jestli se v tom složitějším algoritmu vývojáři překladače nezamotají. K tomu se nám připojí speciální instrukce a schopnost nalézt v kódu části na které je můžu použít a tady je zase určitá výhoda jednoduchosti zásobníkového počítače.

Ano, do složitějších algoritmů se mnozí vývojáři překladačů zamotají, viz třeba případ GCC, kterému čím dál víc dochází dech. Ale přesto existují překladače, které to zvládly na výbornou, třeba Intel. Intel kupodivu mimo vysoce kvalitní optimalizace také špičkově zvládá i hledání mnohých speciálních instrukcí v kódu. Není pak divu, že kdo potřebuje skutečně rychlý program, překládá Intelem.

[Hynek (Pichi) Vychodil]

Dvoukrokový překlad se často používá i u C/C++ (gcc určitě).

To je otázka. GCC používá vícekrokový překlad a pokud jsem pochopil, je to značnou příčinou jeho problémů. Osobně považuji koncepci GCC za jednou z příčin, proč špatně optimalizuje. Byl bych rád, kdybychom se bavili o dobrých překladačích C/C++, a ne o GCC. Navrhuji bavit se o Intelovských, nebo přinejhorším alespoň o Microsoftích kompilátorech C/C++, které optimalizují podstatně lépe a úspěšněji, než GCC.

To, že si na ten mezikód nemůžeš šáhnout, ještě neznamená, že se nepřekládá také vícekrokově. Abych pravdu řek, nevím jak by jste chtěl dělat jakékoli optimalizace bez mezikroku sémantického grafu. Jinými slovy, jakýkoli C/C++ překladač, který provádí optimalizaci, musí ten mezikrok udělat. To že je jen u gcc vidět navenek nic neznamená.

Překladem Java->JavaByteCode vzniká jednodužší jazyk než v prvním kroku překladu C/C++.

Ano, ale také se překladem Java->JavaByteCode ztrácejí některé informace, které by bylo možné využít k lepší optimalizaci.

A jaká informace se ztrácí. Kde se ztrácí? Něco bližšího by k tomu nebylo? Jak už jsem jednou napsal, s výjimkou neoptimalizujících překladačů všechny C/C++ překladače ten mezikrok udělat musí. Kód zásobníkového počítače má právě tu výhodu, že se velmi snadno transformuje do sémantického grafu a pak se nad ním dělají optimalizace. Je pochopitelné, že ten graf musí dělat přesně to samé, co chtěl básník/programátor tím kódem říct. Nic se nesmí ztratit! Problém Javy je, právě to, že básníka nutí říct víc než musí a překladem do ByteCode se z toho nic neztratí. Teprve optimalizace některé zbytečnosti může vynechat, což je pochopitelně práce navíc. Dtto je to s C/C++, ale tam je toho navíc míň.

[Miloslav Ponkrác]

To, že si na ten mezikód nemůžeš šáhnout, ještě neznamená, že se nepřekládá také vícekrokově.

Ok, možná jsme se trochu zamotali do slovíček. Přísně vzato neexistuje žádný kompilátor, který by nepoužíval mezikód. Takže jde spíše o kvalitu a "vyjadřovací schopnosti" toho kterého mezikódu.

A jaká informace se ztrácí. Kde se ztrácí? Něco bližšího by k tomu nebylo? Jak už jsem jednou napsal, s výjimkou neoptimalizujících překladačů všechny C/C++ překladače ten mezikrok udělat musí. Kód zásobníkového počítače má právě tu výhodu, že se velmi snadno transformuje do sémantického grafu a pak se nad ním dělají optimalizace. Je pochopitelné, že ten graf musí dělat přesně to samé, co chtěl básník/programátor tím kódem říct. Nic se nesmí ztratit! Problém Javy je, právě to, že básníka nutí říct víc než musí a překladem do ByteCode se z toho nic neztratí. Teprve optimalizace některé zbytečnosti může vynechat, což je pochopitelně práce navíc. Dtto je to s C/C++, ale tam je toho navíc míň.

Teď, když jsme si vyjasnili, že mezikód se provádí vždycky, bych měl asi napsat to, co jsem myslel, že vyplyne mezi řádky.

Problém byte kódu Javy, stejně tak jako jakéhokoli mezikódu, který je dělán "příliš přenositelně" je, že musíte nutně některé optimalizační informace ztratit.

Rozdíl mezi byte kódem Javy a mezikódem C/C++ překladačů je ten, že u C/C++ je mezikód šitý na míru cílové platformě a má větší vyjadřovací schopnost, než byte kód Javy. Byte kód Javy je přenositelný, a musí být nutně obecnější a nemůže obsahovat tolik informací jako mezikód C/C++.

[Hynek (Pichi) Vychodil]

Mezikód Javy je kód zásobníkového počítače. Ten je tak jednoduchý, že jednodužší je už snad jen Turingův stroj. Zároveň ale do toho kódu nic nepřidává. Vy si asi představujete, že se tam používají nějaké instrukce, které určitou operaci udělají jako vedlejší efekt, jako se to dělává u skutečných CPU. JavaVM je narozdíl od skutečných CPU navržený tak, aby se právě tyhle věci v něm dělat nemuseli a nedělají. V tom je právě ten vtip. Nikde se žádná informace neztrácí a ani nesmí a taky nepřidává jak by se dělo u mezikódu pro skutečný procesor! Optimalizace nad tím mezikódem jsou ve srovnání s C/C++ překladači jednodužší o několik řádů. Naopak, pravou a hlavní nevýhodou Javy je právě C like syntaxe, která nutí programátora psát úplně jinak než by psal přímo pro JavaVM zásobníkový počítač. Problém je právě to co tam programátor napíše navíc a překladem do mezikódu se to neztratí a při optimalizaci nezoptimalizuje. Na druhou stranu C like syntaxe a C like styl programování je zároveň jedna z hlavních výhod Javy, protože to umožnilo její rozšíření. Takže ještě jednou, překladem do mezikódu se nic neztrácí, ale naopak Java nutí programátora tam psát zbytečnosti, které překlad do mezikódu nesmí ztratit a optimalizaci se je odstranit nemusí podařit. Naopak zručný programátor v C může ty zbytečnosti nenapsat a optimalizátor C překladače má o tohle jednodušší práci. Už nevím jak bych to napsal srozumitelněji.

[Hynek (Pichi) Vychodil]

A zase jednodužší Já se toho už asi nezbavím.

[Luk]

Překladem z javového zdrojáku do bytekódu se ztratí jen komentáře Lze se o tom snadno přesvědčit zpětnou dekompilací.

[Hynek (Pichi) Vychodil]

Už jsem na to přišel, už vím kde se ztratí to co máte na mysli. Programátor má myšlenku jak něco udělat. Pak je Javou nucen to napsat v Javě a tady se právě ztratí to co máte patrně na mysli. Ztratí se původní záměr a ztratí se v balastu Javové syntaxe. Při překladu a optimalizaci se pak už neztratí nic z toho co napsal, ale ztratí se to co chtěl napsat. Něco z toho co napsal se podaří zoptimalizovat, ale ne vždy z toho vznikne jen a pouze to co chtěl udělat. Důležité je to, že se to ztratí už při tom zápisu do Javy a ne až při překladu. Už si rozumíme?

[Miloslav Ponkrác]

Já zkusím zareagovat na oba příspěvky.

Vy si asi představujete, že se tam používají nějaké instrukce, které určitou operaci udělají jako vedlejší efekt, jako se to dělává u skutečných CPU.

Ne, to si nepředstavuji. Mezikód Javy, ani mezikód C/C++ určitě na svém počátku zpracování ani jeden z nich neobsahují žádné instrukce. Na svém konci ovšem oba z nich instrukce obsahují (plus samozřejmě nějaká metadata), Java svůj byte kód, C/C++ strojový kód cílového procesoru.

Rozdíl je ten, že Java bytekód neumožnuje zohlednit naprosto žádnou skutečnost týkající se cílové platformy, zatímco mezikód C/C++ ano. Dám pitomý příklad: do Javovského byte kódu nedáte informaci třeba o žádané volací konvenci nějaké funkce (chcete-li metody,když jsme v Javě), stejně tak jako do Javovského byte kódu nestrčíte třeba práci se 128 bitovým reálným číslem, přestože jej třeba cílová platforma podporuje. To jsou všechno věci, které mohou mít na optimalizaci vliv, ale "vyjadřovací schopnost" Javovského byte kódu jej neumožňuje využít (a koneckonců ani samotná Java ne).

Pak je Javou nucen to napsat v Javě a tady se právě ztratí to co máte patrně na mysli. Ztratí se původní záměr a ztratí se v balastu Javové syntaxe.

Ano, rozumíme si. Java je jazyk, u kterého mám pocit, že své myšlenky musím dost přiohýbat. Když to srovnám s takovým C#, nebo i C++ mám pocit, že v těchto jazycích se dá vyjadřovat mnohem efektivněji.

[Honza Jaroš]

Rozdíl je ten, že Java bytekód neumožnuje zohlednit naprosto žádnou skutečnost týkající se cílové platformy

Ačkoli překladačům rozumím asi stejně jako ryba horolezectví, neodpustím si otázku: nemá právě tohle dělat JIT?

[Sinuhet]

GCC používá vícekrokový překlad a pokud jsem pochopil, je to značnou příčinou jeho problémů. Osobně považuji koncepci GCC za jednou z příčin, proč špatně optimalizuje.
Ta koncepce byla zvolena s ohledem na to, ze gcc je predevsim multiplatformni prekladac. Nicmene ve verzi 4.0 je novy "mezikod", ktery obsahuje vice informaci ze zdrojaku a mel by umoznit vetsi optimalizace (treba vektorizaci).

[amnesiac]

Docela se divím, že nikdo nebere v potaz režii. kterou spotřebovává JVM.

Určitě také záleží na optimalizačních schopnostech toho kterého kompilátoru, ale za obdobných podmínek poběží nativní aplikace vždy rychleji.

Schválně jsem si zkusil vygooglit pár testů, kde javovská aplikace údajně běžela rychleji. Sám jsem si přepsal do ekvivalentního kódu v C++ (bez nějakých prasečinek) a výsledek ? O 20 až 250% kratší čas. Potvrdilo se i při zvýšení poštu iterací. GCC 3.3.6, Java 1.5.0 .

[Luk]

O 20 až 250% kratší čas.

Gratuluji ke stvoření stroje času. Cestovat do minulosti bych také chtěl - nebo abych měl již dnes dokončenou kompilaci, kterou spustím zítra večer

[amnesiac]

Kdybych si to po sobě aspoň jednou přečet

Správně mělo být samozřejmě O 20 až 25% kratší čas

Sorry

[Lukáš Zapletal]

Nevím, jestli jsi v době psaní tohoto příspěvku chápal co je to JIT. Ta režie je u všech rychlostních testů zcela zanedbatelná, po JIT kompilaci hotspotů pak aplikace může běžet rychleji a věhem prvních 10 % testovacího času smazat ten "náskok".

Takže moje odpověď -- ty "studie" o tom, že java může být rychlejší než kompilovaný kód s tou režií již počítají.

[Miloslav Ponkrác]

Musím pořád zdůraznit, že dobře napsaný a přeložený program v C++ prostě Java nemůže ani dohnat natož předehnat, Java může pouze čím dál více ztrácet. Ty "studie" vždycky počítají s tím, že C++ program je buď neefektivně napsán, nebo neefektivně přeložen.

Všechny tzv. "studie" rychlosti Javy předvedly jenom to, že autoři testu (většinou zapálení zastánci Javy) mají o programování v C++ podobné představy jako koza o autobusu.

[Radek]

http://dada.perl.it/shootout/

Tady máte srovnání i se zdrojáky, myslím, že je to dostačující a přesné.

[pavlix]

Vzhledem k tomu, že Java obvykle bez "céčka" neběží, tak asi C+Java nemůže být rychlejší než čisté C.

Z virtual machine má z principu vlastní režii, která u céčka neni.