Qt vs. Java (diskuse)

[Ivan]

Hmm, tak to cely vychazi jednoznacne ve prospech QT/C++. Ty vyhody QT vychazi z ukazky 10ti radek kodu. Ja taky programuju v QT ale musim rict, ze treba MVC a plneni tabulky assynchornne bezicim vlaknem se dela v Jave mnohem snaz.

[Matěj Cepl]

Tedy nevím, co kouřil ale tvrdit "Research shows that in practice, garbage collection and other Java features, do not have a major influence on the programmer-efficiency." mi připadne jako docela odvážné tvrzení.

[Matěj Cepl]

Omlouvám se, že jsem na něco takovéhleho reagoval. Vřele doporučuji komukoli kdo by si to náhodou chtěl přečíst, ať jde někam jinam, tole je čistá ztráta času.

[Rezza]

Tak prvni vec je jasna - pise to borec z KDAB. Firma, ktera se vyvojem nad Qt zivi. Ja osobne bych si nevybral taky nic jineho, i kdyz i v te Jave zvladl psat - nejlepe opet s Qt/Jambi. Ale takovehle obecne porovnavaci clanky ze zasady nectu - vzdy zalezi na konkretni uloze!

[Bedňa]

Prepáč nedal som na teba a prečítal som si to, musím skonštatovať to isté, strata času, ale kto už si chce pozrieť niečo zaujímavé z programovania, tak odporúčam pozrieť na výborný český projekt u++

[__dark__]

Shodl jsem se už s více lidma, že API v U++ je jeden velký chaos. I když musím uznat, že ti 2 hlavní kodéři, co to celé napsali, jsou borci.

[Bedňa]

To by som bol rád, keby si mi to osvetlil.

[__dark__]

No pokud ti takové API vyhovuje, tak není co vysvětlovat Já osobně bych v takovém toolkitu nechtěl dělat ani kalkulačku;_)

[void]

Dříve, než si to přečtu, bych se skoro vsadil, že to bude další článek na téma "A proč nesnáším Javu já - člověk, který ji zná z vyprávění".

...

Podle abstraktu to vypadá na dost podivnou záležitost, je-li tam skutečně zataženo AWT samostatně (a nikoli jako část Swingu).

[void]

Aha, tak si to nepřečtu.

Firma autora (Klarälvdalens Datakonsult AB) se označuje za "The Qt Experts" a popisuje takto:

"KDAB, the world’s largest independent source of Qt knowledge, provides consulting and mentoring for developing Qt applications from scratch as well as expertise in porting from all popular and legacy frameworks. We offer Qt trainings and have trained 50% of commercial Qt developers globally. Our software products increase Qt productivity."

Neříkám, že to je nutně nevyvážené, ale je zde velmi vysoká pravděpodobnost, že ano. Takže nic. To už bych mohl číst i Michaela Meekse...

[kralyk z abclinuxu]

"A proč nesnáším Javu já - člověk, který ji zná z vyprávění".

Tihle lidé obvykle nesnášejí Javu ani ne tak z vyprávení, ale z pohledu uživatele desktop GUI SW napsaného v Javě.
Nechci teď s článkem nějak souhlasit, ani jsem ho nečetl (nezdá se to přínosné), ale z mnoha GUI aplikací napsaných v Javě člověk opravdu získá nedobrý dojem.

Fanoušci Javy mi na tohle vždycky řeknou, že to je chyba toho, kdo tu kterou aplikaci psal, a ne Javy. Což je samozřejmě možné, neříkám, že ne... jen bych rád někdy viděl nějakou tu správně napsanou GUI aplikaci v Javě.

[BlackShark]

Zkus se podivat na DbVisualizer. Pouzivame to v praci a nezda se to pomale. Nebo taky Jajuk. A konecne ani s Netbeans nijak netrpim (pouzivam to denne v praci).

[Bedňa]

Keď prídem domov Jajuk skúsim, ale keď to pôjde, ako všetko čo začína na "j", tak Ti to tu pekne otrieskam o komentár

[pozortucnak]

Auramp je jedna z nejlepších GUI aplikací co byla v Javě napsána... používá to totiž Qt jambi...

Jen škoda, že Qt jambi nefunguje s gcj...

[msk]

Jen škoda, že Qt jambi nefunguje s gcj...

Nestaci OpenJDK?

[pozortucnak]

Nestačí, gcj kompiluje i do nativního kódu...

[Filip Jirsák]

Myslel jsem, že už nesmysl jménem GCJ dávno zanikl. To opravdu ještě existuje a dokáže to fungovat se současnými Java aplikacemi? A zpomaluje to běh Java aplikací nebo to vede k jejich záhadným chybám hodně, a nebo jenom trochu?

[pozortucnak]

Nemám informace, ale mělo by to podporovat většinu z java 1.5 a mělo by tím jít zkompilovat swt, scala rhino, starší verze jythonu, pythonu, groovy... co se týče paměťoví náročnosti, tak nevím, ale rozhodne to tolik nežere paměť...

[Filip Jirsák]

Důvod k menší potřebě paměti by měl být jaký? Stejně tam musí být GC, a pochybuju, že by tam byla lepší implementace než v klasických JVM.

[Pavel Stárek]

To opravdu ještě existuje a dokáže to fungovat se současnými Java aplikacemi?

Bohužel ano. Třeba ve Fedoře je proti této věci zkompilována například OpenOffice (nebo ji má jako závislost). Nevím proč, když už existuje OpenJDK se používá tato věc.

[Bedňa]

Jajuk nijak nevybočuje z priemernej japlikácie, takže je na prvý pohľad poznať v čom to je napísané, svižné to asi nebude nikdy a to som sa pre istotu pozrel do softov čo používam ja, či náhodov niektorý nieje naklepaný v Jave, ale všetky sú C, C++ a Python.

[BlackShark]

Tak pak mozna bude problem u tebe. Protoze me ty Java aplikace chodi velice dobre a lecktere lepe nez aplikace v Qt . Napr. Jajuk ma lepsi odezvu GUI nez Amarok 2. Je to slyset casto, ze GUI javy je pomale, ale jedina aplikace, kde jsem to pozoroval byl jEdit.

[Bedňa]

Neverím tomu že ti nejaká Java app na desktope ide svižnejšie ako C, C++ Qt, mne idú svižnejšie aj Python app, dokonca teraz keď som prehrabával app či nepoužívam, alebo nepoužíval som niečo v Jave, tak som bol prekvapený že niektoré app sú v Pythone a ani som nepocítil nejaké spomalenie, napr. Gajim. Nič proti Jave v Tattoo mi Java behá ako hodinky a som spokojný, ale o desktope to povedať nemôžem.

[BlackShark]

Tak bys mozna mel zacit verit, protoze jinej dukaz ti tady dat nemuzu. Ale muzes prijet a ukazu ti jak behaji Qt aplikace (Amarok, Kate, KMail) a jak behaji Java aplikace . Nejsem zastancem Javy na desktopu za kazdou cenu (pouzivam jen DBVisualizer a Netbeans), ale pomale to neni (ve srovnani s ekvivalentem v Qt nebo .NET). Ale pokud vim, tak na Linuxu ma JRE defaultne vypnute vykreslovani pres OpenGL a musis ho povolit pri spusteni appky. Mozna je problem v tom. Zkusit muzes jeste tohle. Jde to i rovnou z prohlizece.

[kralyk z abclinuxu]

Ale muzes prijet a ukazu ti jak behaji Qt aplikace (Amarok, Kate, KMail) a jak behaji Java aplikace

To jsou ale KDE4 aplikace, tudíž nejen Qt, ale i Kdelibs. Imho Kdelibs nejsou zrovna výkvět rychlosti...

[Bedňa]

To pozvanie by som hádam aj prijal, máš doma chladené pivo?

[Václav "Darm" Novák]

On existuje někdo kdo doma nemá chlazené pivo? :)

(já vím, Jendo…)

[otula]

Třeba já Pivo jsem pil naposledy v roce 1990.

[void]

Hmm, já ani moc významných javovských aplikací (ve Swingu nebo jiném grafickém systému) neznám.

Jasně, jsou tu různé IDE jako NetBeans nebo Eclipse. Ty jsou skutečně pomalé (jak co do vykreslování, tak do spotřeby paměti) - ale já myslím, že pomalá jsou všechna IDE, takže to asi není o Javě... (pozn.: za IDE nepovažuju texťák zkombinovaný s příkazovkou a prohlížečem souborů)

Ostatně, na Javu se svádí i rychlost OpenOffice.org - to jen ke znalostem těch "kritiků".

[mirec]

:) mirec@kofola ~ $ java
bash: java: príkaz nenájdený

Rozhodne mi openoffice nepripadá o nič rýchlejší.

[void]

Buď jsi nepochopil, co jsem napsal, nebo jsem nepochopil, co jsi napsal.

[mirec]

Ostatně, na Javu se svádí i rychlost OpenOffice.org

Openoffice ide pomaly aj bez Javy.

[void]

Takže jsi to nepochopil ty. :)

Já jsem mínil tak, že hodně lidí si myslí, že OpenOffice.org je celé v Javě, a jeho "rychlost" svádí na Javu. Což je samozřejmě blbost.

Vlastně - můžeme dávat OpenOffice.org jako "jasný důkaz" toho, že C++ je pomalé. :)))

[kralyk z abclinuxu]

Vlastně - můžeme dávat OpenOffice.org jako "jasný důkaz" toho, že C++ je pomalé. :)))

No tak asm bude asi rychlejší

[mirec]

To, že C++ je pomalé je blbosť. OpenOffice mal byť pôvodne v Jave, ale bolo to príliš pomalé (nie, že by súčasný OpenOffice oplýval rýchlosťou).

[msk]

To, že C++ je pomalé je blbosť. OpenOffice mal byť pôvodne v Jave, ale bolo to príliš pomalé (nie, že by súčasný OpenOffice oplýval rýchlosťou).

To sa lahko generalizuje. Aj v c++ sa da napisat pomala aplikacia, ale skor sa v nom da lahsie napisat leakujuca aplikacia. Java aplikacie budu asi vzdy pomalsie ( nemam vestiacu gulu a schvalne nepisem percenta, stale to bude ale n-nasobne rychlejsie ako napr. python ), ale z vlastnej skusenosti viem, ze mnoho java programov je pomalych bud kvoli komplexnosti, alebo skor kvoli sposobu "vyvoja" ( zlepenim tony gigaframeworkov naklikame aplikaciu nech je co najskor hotova a rychlost budeme riesit az ked bude pruser ... ). A to si teraz serem na vlastnu hlavu, a poriadne. Kto chce, ten si moje nazory na javu z pred takych 5 rokov moze vygooglit.

[mirec]

No to nebola moc generalizácia, myslím, že nízkoúrovňový jazyk pomalý byť nemôže (ak nie je fakt hnusne implementovaný kompilátor). Prirodzene pomalý program sa dá urobiť aj v Jave aj v C++. O rýchlosti Javy sa moc nezvyknem vyjadrovať, ale teraz urobím výnimku. Kedysi bol výkon javy bieda, teraz sa to výrazne zlepšilo a rozdiel v rýchlosti zhruba rovnakého kódu v C++ je väčšinou minimálny nehovoriac o strojoch podporujúcich hardvérovo Javu.

[void]

Myslím, že jsi to pořád nepochopil. To je fuk, sereme na to.

[kralyk z abclinuxu]

já myslím, že pomalá jsou všechna IDE

Až na Qt Creator Ten je poměrně hodně rychlý...

[Jan Drábek]

Nepřesvědčivě na tom zavání už jen umístění toho dokumentu.

[balevas]

No neviem. Po prve, je to povrchne, zopar prikladom vytrhnutych z kontextu, vela vagnych formulacii bez konkretnych cisiel a porovnani. Po druhe, cely clanok je zalozeny na citovani nejakeho 10 rokov stareho clanku, co znamena ze vtedy mohol autor tak porovnavat Javu 1.2 (prvykrat pouzity JIT kompilator, predpotopna implementacia Swingu atd.).

[majo]

BTW: Ta citacia (3) je povazovana dodnes za jedno z najlepsich porovnani produktivity prgramatora v roznych jazykoch.

[LukasT]

Ja osobne to považujem tiež za tendenčný článok, ale zaujímavý. V niektorých veciach súhlasím, v iných neviem odpoveď, pretože v Jave desktopovú aplikáciu nepíšem.

[deda.jabko]

pomalu v kazdem odstavci bych doplnil [citation needed]... pripada mi to jako kdyby ten clanek psal pan ponkrac.

[Miloslav Ponkrác]

Kdyby si pan Ponkrác měl vybrat mezi Qt a Javou, tak neváhá a zvolí Javu. Myslel jsem si, že zhruba tisícovka příspěvků na abclinuxu.cz, kde kritizuji Qt co to jenom jde nenechala nikoho na pochybách. Takže pro jistotu zdůrazňuji, že kdybych psal takový článek, tak Qt roztrhám na cucky. Tedy žádné podezření, že jsem autorem.

[__dark__]

Pokud chceš trhat Qt na cucky, tak nevím, na co menšího bys trhal další toolkity v C/C++

[Miloslav Ponkrác]

Základním problémem většiny lidí v této diskusi je, že kladou rovnítko mezi Qt a C++.

Považuji Qt za jeden z horších nástrojů. Mohl bych začít už tím, že to není C++ knihovna, ale potřebuje moc ke kompilaci. Tím, že v mnoha případech nehlásí chyby a to i v případech, kdy chyba může nastat. To, že mnoho let měla hrubé chyby v korektnosti multithreadového kódu, apod. Nemluvím o právnických omezeních Qt.

Po 25 letech zkušeností s IT jsem přišel na to, že knihovna, která se může na malém projektu jevit jako úžasná, protože je to rychle hotové, může na větším projektu udělat takovou paseku, že řešení problémů zabere desetkrát více času, než kdybychom takovou úžasnou knihovnu nepoužili.

Pokud bych dělal serióznější projekt a nechtěl bych riskovat problémy a měl seriózně navrženou věc, která bude efektivní i na větším projektu – pak mezi Qt a Javou musím jasně dát přednost Javě.

Řada lidí dělá chybu, že hodnotí knihovnu na malém, či středním projektu, který je řadového typu. Tedy takové rozsáhlejší hello world s pár okny veskrze nijak nevybočujícími z řady. Pak velmi reklamně působí rychlost, se kterou to napíšete. Otázka je, jak se takové knihovny vypořádají se zádrhely nastávající v méně standardních situacích a větších projektech. Na tom často taková knihovna v efektivitě shoří jako papír.

Proto mým favoritem jsou věci, u kterých si tu neučúráváte jako tady u Qt. Ale věci, které jsou především seriózně dělané a promyšlené. Ačkoli Javu moc nemusím, a miluju C++, měl-li bych na výběr mezi Qt a Javou, jdu do Javy.

Jinak grafických knihoven a toolkitů pro C++ je hrozně moc.

[__dark__]

...

Já nejsem většina lidí, ale Qt je prostě jeden z nejlepších dostupných toolkitů pod open-source licencí. Jasně, má chyby v návrhu (třeba pokud selže něco ve Stringu nebo někde hluboko v nitru, tak to v aplikaci není možné detekovat), ale kolik aplikací se v dnešní době nepoloží při nedostatku paměti? (to nemyslím jako argument, je to špatně, a to uznávám).

Jinak grafických knihoven a toolkitů pro C++ je hrozně moc.

A mohl bys napsat, který z těch toolkitů preferuješ? Který je v návrhu mnohem lepší než to zatracené Qt?

[majo]

Ak by ti neslo o GUI tak napriklad PoCo - http://pocoproject.org/info/

[kralyk z abclinuxu]

To vypadá, že to je něco jako boost, ne?

[__dark__]

Vždycky mě zajímala jedna věc z pohledu návrhu VM. Například garbage collection se mi osobně zdá jako dobrá věc pro programátora (starat se o paměť je někdy opruz), ale naprosto nevýhodná věc pro běh aplikace. Každý normální programátor zná alespoň odhad cyklů čtení/zápisu z/do paměti, která je v cache (L1, L2) nebo v cache není.

Co jsem tím chtěl říct, že pro dočasné instance tříd je tento postup nevýhodný, protože po opuštění takové instance pošlu do háje nacachovanou paměť L1 nebo L2. Pokud tedy správně chápu to, že až do běhu GC se k této paměti už nedostanu. V nějakých java věcech už jsem viděl i object pool, takže na tom asi něco bude

PS: Nerýpu do javy, jen mi to přijde jako zajímavé téma, a zajímalo by mě, jestli mám pravdu nebo ne, a popřípadě jak si tuto věc obhájili návrháři jazyka (konkrétně třeba javy).

[Filip Jirsák]

Procesor si ale řídí keš sám, bez ohledu na nějaký GC nebo toho, co chápe JVM jako objekty. Tj. dočasný objekt sice zůstane v hlavní paměti, ale z keše ho procesor brzo vykopne (resp. on ani nemusí mít v keši celý objekt, ale jenom část jeho dat). Navíc novější GC (používané v Javě třeba nějakých 5 let) se také umí k dočasným objektům chovat lépe, takže pool objektů je často přežitek minulosti.

[__dark__]

Asi mě evidentně nepochopils, jasně, že se procesor o tu paměť stará sám, ale je celkem k ničemu, když natáhneš do cache něco, co pak zahodíš, a přitom se jedná o dočasné data, a uděláš to třeba 10.000x za sebou. Ale já chápu to, že toto někoho vůbec nezajímá, jde jen o to, co programuješ.

Navíc novější GC (používané v Javě třeba nějakých 5 let) se také umí k dočasným objektům chovat lépe, takže pool objektů je často přežitek minulosti.

No nevím, stačí si pustit nějakou aplikaci v javě, a sledovat JVM. Zjistíš, že třeba pro překreslení okna a jiné další blbosti jede využití paměti hodně nahoru a nějaké jemná fáze GC (nevím, jak se jmenuje) se pouští docela často.

Navíc jak chceš zaručit, že JVM pozná dočasný objekt? Stačí zalovat nějakou funkci, a předat tento objekt jako parametr. O inner loops se tu nebavím, tam to snad pozná:)

[__dark__]

zalovat->zavolat

[Filip Jirsák]

je celkem k ničemu, když natáhneš do cache něco, co pak zahodíš, a přitom se jedná o dočasné data, a uděláš to třeba 10.000x za sebou.

To ale nijak nesouvisí s Javou ani GC, to je prostě obecná vlastnost jakéhokoli kódu.

Zjistíš, že třeba pro překreslení okna a jiné další blbosti jede využití paměti hodně nahoru a nějaké jemná fáze GC (nevím, jak se jmenuje) se pouští docela často.

To potvrzuje to, co jsem psal.

Navíc jak chceš zaručit, že JVM pozná dočasný objekt? Stačí zalovat nějakou funkci, a předat tento objekt jako parametr. O inner loops se tu nebavím, tam to snad pozná:)

Jednoduše. Každý objekt je dočasný, a teprve když žije nějakou dobu, stává se z něj objekt trvalý a je přesunut mezi trvalé objekty (současné javovské GC těch generací objektů mají ve skutečnosti víc než dvě).

[__dark__]

To ale nijak nesouvisí s Javou ani GC, to je prostě obecná vlastnost jakéhokoli kódu.

Škoda, že to nevidíš v kontextu toho co jsem začal.

To potvrzuje to, co jsem psal.

Jenže vytížení paměti jede strašně rychle nahoru, mi žere třeba netbeans po skrolování i o 200MB víc, tady věřím, že by to šlo udělat mnohem líp.

Navíc to opět nevidíš v kontextu, asi ani nechceš vidět

Jednoduše. Každý objekt je dočasný, a teprve když žije nějakou dobu, stává se z něj objekt trvalý a je přesunut mezi trvalé objekty (současné javovské GC těch generací objektů mají ve skutečnosti víc než dvě).

Bavili jsme se o objektu na zásobníku, tyto jsou dočasné (a tady je cache miss téměř nulový), všechny ostatní jsou objekty vytvořené na heapu.

Opět to nevidíš v kontextu

[Filip Jirsák]

Opravdu asi nevidím ten kontext. Mám nějakou hromadu bajtů v paměti, procesor si z ní vyzobe ty bajty, které bude potřebovat pro výpočet a umístí si je do cache. To je podle mne kontext – a není tam žádný zásobník a už vůbec ne objekty.

[deda.jabko]

Každý normální programátor zná alespoň odhad cyklů čtení/zápisu z/do paměti, která je v cache (L1, L2) nebo v cache není.

zalezi na definici slova normalni... a v jakem programovacim jazyce pise... ergo od takovych veci by normalni programator mel byt odstineny

Co jsem tím chtěl říct, že pro dočasné instance tříd je tento postup nevýhodný, protože po opuštění takové instance pošlu do háje nacachovanou paměť L1 nebo L2.

ne nezbytne... JVM umi takove objekty identifikovat a napr. umistit je na zasobnik nebo je rozlozit na jednotlive promenne, atd.

[__dark__]

zalezi na definici slova normalni

No dobře, tak každý, kdo k tomu má vlohy

JVM umi takove objekty identifikovat a napr. umistit je na zasobnik nebo je rozlozit na jednotlive promenne, atd.

Jak jsem psal nahoře. Myslím, že vyhodnocovací kritéria jsou docela přísné, takže toto určitě platí jen v několika málo případech, ale aspoň se snaží, no:)

[deda.jabko]

No dobře, tak každý, kdo k tomu má vlohy

obavam se, ze tech situaci kdy se vyplati resit cache je v realnem svete minimum. navic, spustis program na jinem typu procesoru a vsechny tve predpoklady jdou do haje...

Myslím, že vyhodnocovací kritéria jsou docela přísné, takže toto určitě platí jen v několika málo případech, ale aspoň se snaží, no:)

cetl jsem o tom docela dost paperu, ale nevim, kolik procent z toho je v soucasnych JVM realne implementovano... i kdyz by to byla polovina, tak na tom java neni zase tak spatne, jak si mozna myslis

[__dark__]

obavam se, ze tech situaci kdy se vyplati resit cache je v realnem svete minimum. navic, spustis program na jinem typu procesoru a vsechny tve predpoklady jdou do haje...

Šak to by si měla pořešit právě JVM, ale základní znalosti o tom, jak věci fungují uvnitř, podle mě nejsou na škodu.

cetl jsem o tom docela dost paperu, ale nevim, kolik procent z toho je v soucasnych JVM realne implementovano... i kdyz by to byla polovina, tak na tom java neni zase tak spatne, jak si mozna myslis

Taky jsem o tom něco četl, ale nemyslím si, že by to v současnosti byla výhra. Stačí spustit libovolný program napsaný v javě

[deda.jabko]

Šak to by si měla pořešit právě JVM, ale základní znalosti o tom, jak věci fungují uvnitř, podle mě nejsou na škodu.

nejsou naskodu... ale realne muzu mit pouze mlhavou predstavu, ci zadnou... napr. jako normalni programator se rozhodnu zavolat "select * from foo" mam resit kolikrat doslo ke cache miss?

[kralyk z abclinuxu]

Problém tohohle threadu je, že tu operujete s fuzzy pojmem "normální programátor".
Nic jako normální programátor není. V některých obastech je potřeba vědět, jak funguje procesor a jaký je HW pod pokličkou, v jiných je tahle znalost naprosto zbytečnná.

Nemá cenu dělat nějaký generalizující rozhodnutí, jestli to je nebo není potřeba. Prostě někdy jo a někdy ne.

[__dark__]

napr. jako normalni programator se rozhodnu zavolat "select * from foo" mam resit kolikrat doslo ke cache miss

O tom to přece vůbec nebylo :)

[Kvakor]

obavam se, ze tech situaci kdy se vyplati resit cache je v realnem svete minimum. navic, spustis program na jinem typu procesoru a vsechny tve predpoklady jdou do haje...

Doporučuju přečíst What Every Programmer Should Know About Memory od Urlicha Dreppera, kde je dostatek příkladů, dokazujících, že dnes stále záleží na tom, jak je paměť zarovnaná nebo jestli se data vejdou či nevejdou do cache. Je pravda, že u Javy a podobných jazyků je mnohem méně možností jak ovlivnit vzhled dat v paměti, ale stále platí obecná pravidla, která platí nezávisle na jazyce (napr. zarovnávat datas, nejlépe podle velikosti cache line, držet společně užívaná data pospolu a pod.).

[deda.jabko]

Doporučuju přečíst What Every Programmer Should Know About Memory od Urlicha Dreppera, kde je dostatek příkladů,

ten clanek neni moc o ,,normalnim programovani'', navic mi prijde docela x86-specific.

dokazujících, že dnes stále záleží na tom, jak je paměť zarovnaná nebo jestli se data vejdou či nevejdou do cache.

nicmene, pokud nekdo neprogramuje neco vylozene low-level tak by takove veci mel brat pouze na vedomi. jinak se to blizi predcasnym optimalizacim. napriklad, i kdyz delam hodne low-level veci... tak jsme praci s cachema musel zacit ignorovat, protoze napr. procesor core duo, co mam v ntb ma jiny pristup k pameti nez treba xeony a ty zase jiny nez opterony... a to nemluvim o tom, kdyz dany program spustim na sparcu...

stále platí obecná pravidla, která platí nezávisle na jazyce (napr. zarovnávat datas, nejlépe podle velikosti cache line, držet společně užívaná data pospolu a pod.).

to by mel delat prekladac/runtime

[majo]

Ano, cital som tie vyskumy, bolo to o optimalizacii vytvarania objektov na zasobniku ak dynamicka analyza JVM identifikuje ze ide o docasny/lokalny objekt. Kazdopadne je to na dalsiu analyzu - rozumej dalsie CPU cykly navyse.

Cital som vsak iny zaujimavy problem - filozofia GC versus velky HEAP na dnesnych 64 bit CPU. Predstavte si napriklad aplikaciu ktora ma alokovane stovky milionov objektov v dajme tomu 64GB HEAPu, bezi nad tym niekolko threadov - objekty stale pribudaju a miznu ...

Tento scenar je dnes mozny a buducnosti bude este beznejsi - vysledok je ten ze GC vdaka neustalemu prechadzaniu HEAP je uplne mimo a nadmerne zatazuje CPU iba svojou reziou - L1/L2 cache musi byt poriadne horuca.

Problem ktory som sa snazil popisat dnes riesi jedna firma (alternativny JVM) ktora uvadza ze ma odpoved ale tvrdi to uz dost dlho a nikdo nic konkretne nevidel.

Ak sa mylim alebo niekto vie viac, opravte ma.

Tradicne kompilovane jazyky s malloc/free schemou tymto neduhom samozrejme netrpia.

[deda.jabko]

ak dynamicka analyza JVM identifikuje ze ide o docasny/lokalny objekt. Kazdopadne je to na dalsiu analyzu - rozumej dalsie CPU cykly navyse.

napsal jsem to nepresne... afaik escape analyza se dela pri kompilaci do JBC, takze to nedela JVM, ale javac.

Tento scenar je dnes mozny a buducnosti bude este beznejsi - vysledok je ten ze GC vdaka neustalemu prechadzaniu HEAP je uplne mimo a nadmerne zatazuje CPU iba svojou reziou

s tou rezii to neni zase tak zhave. malloc/free ma taky vcelku brutalni rezii (udrzovani seznamu volnych bloku) atd.

Tradicne kompilovane jazyky s malloc/free schemou tymto neduhom samozrejme netrpia.

zase trpi spoustou jinych neduhu. napr. standardni general purpose alokatory se blbe vyrovnavaji s vicevlaknovou zatezi...

[xavier]

>vysledok je ten ze GC vdaka neustalemu prechadzaniu HEAP je uplne mimo a nadmerne zatazuje CPU iba svojou reziou

Zrovna tenhle problém řeší generační GC, který v javě je. Když si skusíš pustit nějakou větší aplikaci v javě a trochu sleduješ co dělá s pamětí, tak zjistíš, že GC je neskutečně líný. V podstatě pravidelně uvolňuje jenom objekty, které mají úplně minimální životnost. Ostatní jsou uvolňované jenom když to je potřeba. Např. moje analýza běhu Netbeans: max. velikost heapu je 128MB, po staru zabírají 27MB(verze pro vývoj v Java SE a ME s vypnutými zbytečnými pluginy). Po pár hodinách používání naroste využitá pamět až k 128MB. Ale když vynutím spuštění GC, využitá paměť klesne někam k 50MB. Většinu zabrané paměti tedy zabírají odstranitelné objekty, ale vzhledem k tomu, že je pořád dostatek paměti tak se uvolňují pouze objekty z první generace(vs. malloc/free zbytečně uvolňuje všechno). Osobně si myslím, že ve většině reálných aplikací pracuje GC lépe než programátor, ale vždycky záleží na konkrétním projektu takže se nemá cenu bavit o tom co je obecně lepší.

[majo]

Sme sa nepochopili - ten problem sa prejavuje od niekolko GB nahor a zatial nema riesenie.

[cronin]

G1GC? Azul?

[majo]

Citovanu studiu som zatial necital ale skusim hned reagovat pretoze tu samu temu sme mali v praci par dni naspet.

Najpr background - sme firma s dlhorocnou praxou v C++ aj Java, s aplikaciami od embedded po desktop, od linuxu po windows, od military az po ATC, rozsah projektov od malych az po 10-20 cloveko-rokov.

Mame znacne investicie ako v C++ tak v Java kode ako aj viacej vyvojarov. To co chcem napisat je o tomto:

Mladsi vyvojari ktory zacali bud priamo v Jave alebo sa mierne "smahli" okolo C++ a potom prisla Java, nemaju co riesit - ti maju jasno. Je tu vsak este jedna skupina, starsi vyvojari ktory presli toho viacej - Javu maju zvladnutu na jednotku, ked vsak pride projekt kde maju pouzit Qt a/alebo C++ tak si vydychnu - konecne zase SLOBODNE programovanie.

JAVA - pohodlny, pomerne objektovy jazyk pre tych co nepotrebuju moc premyslat ale skor programovat - programovat zo zdarnym vysledkom a bez zbytocnych prekvapeni.

C++ - jazda na harley-davidson, ziadne obmedzenia, ziadne ochrany od tvorcu jazyka, je len na vas ako vela nato slapnete a ak ste dobry tak ziskate velky naskok Dnes v case nastrojov ako je valgrind a std::auto_ptr je dokonca velmi pravdepodobne ze tu jazdu prezijete

Neverte ludom ktory tvrdia ze generika v jave su to iste ako sablony v C++ alebo makra v C.

Qt API je urcite konzistentnejsie ako Java SE API.

Multiplatformne programy urobite jednoduchsie v jave ale napr. Skype je dokaz ze ani Qt moc nezaostava.

Vysledok z praxe je ten ze podla mna ludia vo firme ktory pouzivaju v projekte Qt, nepisu ani chybovejsie projekty ani im to netrva dlhsie nez tym co pouzivaju Swing.

Tak, a teraz si idem precitat to dielko o ktorom uz teraz nepochybujem ze bude podobne ako vsetky porovnavania subjektivne ...

[pozortucnak]

Skype na Mac OS X údajně nepoužívá Qt...

[mirec]

Tento príspevok si rozhodne zaslúži skôr prečítanie než ten blábol, ktorý je uvedený v správičke.

Ja sa osobne zaraďujem skôr k C++ "programátorom", ale i s Javou som už čo-to robil.

Qt Jambi poskytuje celkom peknú integráciu so systémom (vyzerá skoro ako natívna aplikácia) a beží prekvapujúco celkom svižne. Čo sa týka ostatných toolkitov GTK som neskúšal a tie Javovské ... no poviem to rovno, že ma moc nenadchli.

Ako som už hovoril robím prevažne v C++ s Qt 4. Rýchlosť vytvorenia aplikácie a kvalita je zrovnateľná s Javou, ale prirodzene je to o niečom inom. Veci ako GC mi v C++ moc nechýbajú, o väčšinu sa postará QObject a zvyšok, kde si alokujem nejaké tie vlastné objekty dokážem upratať s minimálnou námahou.

Objektívne porovnanie písania aplikácií v C++ s Qt 4 a v Jave je asi nemožné, každy nech používa čo mu vyhovuje. Odborníci na či už jednu, alebo druhú platformu dokážu pracovať porovnateľne rýchlo a kvalitne.

[imploder]

Swing je pomalý. Eclipse má reakce pomalu jak nějaká online aplikace. Prostě dojem z uživatelského pohledu je, že Swing je na houby a Qt rulez.

[mol]

Eclipse není psaný ve Swingu, ale v SWT. (IMHO by to ve Swingu bylo ještě horší.)

[Filip Jirsák]

Moje uživatelská zkušenost je taková, že SWT je subjektivně línější než Swing.

[bender]

trolovina...

[msk]

Ako byvali vyvojar qt/c++ a momentalny vyvojar qtjambi/java si dovolim par postrehov.

Co sa tyka vyvoja, vyvija sa mi jednoznacne lepsie v jave. Ci je to samotnym jazykom, komplexnostou IDE, niecim inym, tazko posudit. Asi z kazdeho trochu. Po prechode z c++ na javu som zo zaciatku niekolko krat riesil garbage collector a zravost aplikacie, hrozne mi chybalo delete(). Bolo to ale sposobene c-ckovym pohladom na sposob programovania a zabudnutym zavolanim close() na jednom objekte ( po oprave spadla zravost z 3GB na 50MB ). Co mi z c++ vobec nechyba je jeho katastrofalna a nekonzistentna libstd(c++). Kym som programoval v c++, neprisla mi az taka zla, ale ako som vyskusal ine jazyky, povazujem jej stav za ubohy az katastrofalny.

Co musim uznat je, ze v jave mam podstatne mensie moznosti ovladat pamat jvm _procesu_ voci moznostiam v c++. To je nevyhoda v pripade desktop aplikacii, tie asi budu zravejsie na pamat a nebudu tak dobre zvladat zdielanie zdrojov ( napr. .so-ciek ) ako v pripade c++ ( moj predpoklad prameni z toho, ze java pouziva qt a qtjambi liby z jar-u, takze pre kazdu jvm ich asi bude drzat v pamati zvlast ).

Pamatova narocnost jvm _procesu_ je ale z pohladu javistu menej relevantna v pripdade EE aplikacii ( preto javisti tolko tu pamat neriesia, pretoze ich jvm aplikacneho servera je de-facto ako pre c++kara samotny operacny system ). Zvacsa si neuvedomuju, ze tu pamat co si sysluje AS by mohol chciet napr. iny proces . To uz ale nema nic spolocne s jambi.

Co sa tyka qt/c++ vs qtjambi/java, vyvija sa mi lepsie v qtjambi/java a to aj napriek tomu, ze qtjambi je projekt v plienkach s niekolkymi z mojho pohladu nedotiahnutymi vecami. Vyhody javy / kvalitneho javoveho ide / jednoduchsieho build systemu / mnozstva dostupnych kniznic proste prevazili.

Z pohladu OS ale budu qtjambi/java aplikacie IMHO zravejsie na pamat, pretoze co aplikacia to jedna jvm a jedno qtjambi+qt ( neviem ako sa linux postavi k zdielaniu .so-cok zabalenych v jar-e, ale myslim, ze ich medzi jvm zdielat nebude ).

Z pohladu rychlosti behu je to u beznych aplikacii asi fuk, aplikacia aj tak riesi len kraviny typu click event a podobne. U zlozitejsich veci bude java tratit viac ( a je to vidno aj na niektorych examploch z qtjambi demo, najma tych graficky narocnejsich co vela pocitaju ).

Z pohladu garbage collectoru sa mi lepsie vyvija v qtjambi/java, pretoze v qt/c++ som si nikdy nebol isty, ci bude dany objekt zmazany, alebo nie ( myslim teraz hierarchicke delete() nad qt objektami ). QT do c++ totiz s tymto pritiahlo cosi, co tam vobec nepatri ( akusi nahradu GC ). Predpokladam, ze desktop aplikacia napisana v jave bude zrat stale viac pamati ako aplikacia napisana v pyqt a toboz qt.

Tot vsetko, uz sa v tom stracam ...

[msk]

Dalej k linkovanemu clanku:

C++ has the advantage of having compilers that are clearly superior in execution speed. In order to be able to ship their compilers (and other tools) on various platforms, vendors tend to implement their Java tools in Java itself, with all the aforementioned memory and efficiency problems.

Toto je uplna kravina. Nas projekt sa za posledny rok dost rozrastol, je tam ohromne mnostvo kodu a "skompilujem" ho odhadom 5-6x rychlejsie, ako ekvivalentne mnozstvo c++ kodu z predoslych projektov ( na 1 cpu, nepocitam moznost distcc farmy ).

Inak autorovi vobec nevyvraciam, ze program v qt/c++ bude napisany rychlejsie ako v sw[ing,t]/java, pokial sa bavime len o samotnom GUI. Akonahle ta aplikacia ma este aj nieco robit, zacne sa to rychlo obracat.

[cronin]

U zlozitejsich veci bude java tratit viac ...

... alebo viac ziska. To, na co ortodoxni C-ckari casto zabudaju, je, ze Hot Spot moze robit dynamicky optimalizacie, ktore staticky C prekladac principialne nemoze nikdy urobit, pretoze v case prekladu nema k dispozicii informacie, ktore ma k dispozicii Hot Spot za behu. V urcitych nie az tak zriedkavych pripadoch moze byt rozdiel dramaticky v prospech Javy. JVM robi pocas behu programu veci, ktore nativny program nikdy robit nemusi, takze uz principialne je kodova cesta v pripade Javy ovela dlhsia, a teda pomalsia v podmnienkach "paribus ceteris". Casto sa vsak ten overhead Javy prejavi signifikantnou usporou niekde inde. Velakrat sa "Java virtual machine" redukuje na "Garbage collection"; aj v mnohych prispevkoch tejto diskusie. GC je sice podstatnou castou JVM, ale zdaleka nie jedinou.

[__dark__]

Samozřejmě máš pravdu v tom, že JVM má možnosti udělat nějaké optimalizace až za běhu, ale ještě nikdy jsem neviděl nějaké pozitivní výsledky v praxi, kromě nějakých na-míru šitých mikrobenchmarků.

Ta analýza, optimalizace a generování kódu taky něco stojí, a JVM to musí dělat až za běhu, a pokud možno rychle. Rozhodně nemůže ztratit třeba 5 sekund tím, že bude optimalizovat pár funkcí.

Na druhou stranu C++ programátor může říct překladači, ať udělá funkci inline, funkce umístěné v knihovnách jsou obvykle komplikovanější, a ten overhead pro zavolání je podle mě minimální. Navíc i pro C++ existují knihovny pro dynamické generování kódu, když už to je potřeba.

[majo]

+1

http://bruscy.republika.pl/pages/przemek/java_not_really_faster_than_cpp.html

[Hynek (Pichi) Vychodil]

Někde jsem to četl velmi hezky vyjádřeno asi takto, i špatně napsaná Java může být občas rychlejší než špatně napsané C++, dobře napsané C++ nikdy nemůže být pomalejší než sebelépe napsaná Java.

[Filip Jirsák]

Ta analýza, optimalizace a generování kódu taky něco stojí, a JVM to musí dělat až za běhu, a pokud možno rychle. Rozhodně nemůže ztratit třeba 5 sekund tím, že bude optimalizovat pár funkcí.

Vzhledem k tomu, že ten kód pak na serveru poběží několik měsíců, může tomu věnovat klidně i víc.

Na druhou stranu C++ programátor může říct překladači, ať udělá funkci inline

Tak před rokem se to řešilo v Jaderných novinách – zjistilo se, že gcc to bere jen jako doporučení, protože to spousta programátorů nadužívá a generuje se pak neefektivní kód. V LKML se nad tím chvíli rozčilovali, že gcc dělá něco jiného, než se mu říká, pak se ale zjistilo, že se to i v jádře používá špatně a gcc se svou heuristikou to nakonec určuje lépe, než programátoři v kódu.

Navíc i pro C++ existují knihovny pro dynamické generování kódu, když už to je potřeba.

Pro Javu zase existuje knihovna pro spouštění nativního kódu, když už je to potřeba

[XY]

ze niekoho este taketo diskusie bavia... linux vs. windows, ubuntu vs. X, iphone vs. Y, java vs. Z... vsetko ma svoje klady a vsetko ma aj zapory, rozumny clovek si vyberie case by case podla toho, co sa mu kam lepsie hodi...

[default]

Kdo chce, hledá způsoby; kdo nechce, hledá důvody. Tady se hledají důvody.