Ospravedlnujem sa trochu off-topic ale velka cast fora sa aj tak zaobera niecim inym. Pan Ponkrac je tazky super ohladom C++ vs Java napriek tomu si dovolim tvrdit ze beh velkych programov bude v Jave rychlejsi. Dolezite su nasledovne veci:
1. Kniznice/Frameworky
2. Multithreading
3. Object locking (Semafor vs. instruction lock)
4. Asynchronne operacie s OS (Sietovy interface, File, ...)
5. Platform/Processor specific optimization
6. Memory management
A prave to ze napisat skutocne optimalny program v komplikovanych nestalych podmienkach je narocne a asi aj nemozne pretoze vzdy je balance medzi univerzalny pronositelny kod vs. platformovy rychly.
Nakolko som ale dlhe roky pracoval aj s C/C++ tak je iste ze rovnaky Java program sa da prepisat do optimalnejsieho C/C++. Otazka ale znie kolko ludi to zvladne. S dobrym frameworkom aj priemerny Java programator napise kod priblizne rovnako rychly ako spickovy specialista na C/C++.
Souhlas. Nutno dodat, ze ten program v Jave zpravidla clovek napise rychleji a spolehliveji. Zatimco v C++ clovek lovi memory-leaky, aplikace v Jave uz muze davno bezet.
Mam dlouhou zkusenost s C++ a je to jazyk, na kterem jsem zacinal. Ale Java umoznuje, abych se soustredil na to, co je pro me podstatnejsi nez delat to co za me muze udelat stroj. Mozna je to tim, ze jsem spatny C++ programator, ale s timhle statutem jsem ochoten se smirit :)
ad 1. - Jaký to má podle vás vliv na rychlost? Podle mne tato věc rychlost nijak zvýšit nemůže.
ad 2. - Proč by měl mít multithreading nějaký vliv na rychlost? Navíc opět - to je věc vlastní i C++. Nevhodně udělaný multithreading bude naopak zpomalovat.
ad 3. - Souvisí s předchozím a opět nevidím nic, co by mělo mluvit ve prospěch Javy.
ad 4. - To je záležitost OS a ne programovacího jazyka - leda že by ta javovská mašinérie obalila kolem toho, co nabízi OS, ještě nějaký svůj zpomalující balast.
ad 5. - Naprostý nesmysl. Bytekód je všude stejný a jediná možná optimalizace je tedy na úrovni interpretace bytekódu. Kompilované C++ může optimalizovat "přímo" algoritmus na míru procesoru, to tedy Java z principu nemůže - takže v tomto bodě vlastně ukazujete, že v těchto otázkách musí být Java zákonitě vždy pomalejší.
ad 6. - Zákonitě pomalejší, než v C++, a to kvůli GC.
"dobrym frameworkom aj priemerny Java programator napise kod priblizne rovnako rychly ako spickovy specialista na C/C++" - Na to se dá říci jen jedno - ROFL! Takového průměrného javistu vs. takového specialistu na C++, kde by to takhle platilo, bych chtěl vidět. Špičkový javista je rád, když jeho výtvor není o mnoho pomalejší, než výtvor průměrného C++kaře.
1) Pomaly framework bude brzdit Vas program alebo si ho zase napisete sam. To ale je dovod preco je C++ tam kde je. Mala reusabilita (v porovnani s Javou).
2 a 3) Lebo multithreading a lockovanie je dost komplikovane. V Jave su rovno triedy na execution queues reentrant locks, read/write locks. Napisat ich vyzaduje hlbkovu znalost ale pouzivat ich uz moze kazdy bez znalosti ako to funguje (a funguje to optimalne).
4) Ciastocne ano ale ak napr. bezim na specifickej platforme ktora umoznuje niektore veci robit rychlejsie tak Java my ich moze prelozit pre kazdu platformu inac. Ak to dame dohromady s multithreadingom tak mozme dojst do zaujimavych performace rozdielov.
5) Java uz davno neinterpretuje ale preklada do nativneho kodu. Na danej platforme to potom moze prelozit optimalnejsie ako univerzalny C program.
6) Nemusi byt. Paralel garbage collector to moze robit skoro az neviditelne.
2), 3) Takovým věcem je nejlepší se rovnou vyhnout. ;-) Erlangisté tak učinili a udělali IMHO opravdu dobře.
5) Jak jsem se ohradil proti Biktopovi, tak se musím ohradit i proti Vám. :-) Neexistuje žádný racionální důvod si myslet, že by JIT kompilace dosáhla vyššího výkonu než staticky zkompilovaný kód jindy než v opravdu extrémních případech (server, co nikdy nevypnu, běží pořád naplno, a mění se jeho zátěžová charakteristika). Už vidím, jak Java dělá za chodu to, co třeba MLton nebo Stalin - cokoliv získám navíc oproti třeba C++, vyžaduje takové analýzy, že si je za běhu samotné aplikace nemůžu dovolit. V oblasti platformně specifického kódu nemá Java před C++ moc velkou výhodu - i kompilátor C++ má svoje přepínače, a přinejmenším na x86 není jejich vliv nijak závratný. Ostatně máme i Acovea, pokud si s tím někdo chce pohrát. Opravdu přínosné optimalizace jsou de fakto 1) platformně nezávislé, 2) výpočetně velmi náročné. Vliv na generovaný kód na úrovni instrukcí mít mohou, ale je skoro až třešínka na dortu.
5) Zajímalo by mě, co znamená "přímo algoritmus" - jestli je řeč o zdrojovém kódu, jak Java bytecode je jen o stupínek níž nez zdrojový kód. :-) Netuším, proč by zrovna tohle mělo JVM omezovat. (JVM omezuje při JITování hlavně dostupný čas na kompilaci. S tím se potýkal už Self.)
