Vlákno názorů k článku Bude energie dražší než hardware? od Clock - Mikulas Patocka treba ma doma porad Pentium 200MHz...

Už je noc, takže odpovím na vše třeba zítra, ale v rychlosti.

Ano niektore kompilatori generuju nativny kod do suboru. Ine (JIT) az neskor v pamati ale je to nativny preklad do strojoveho kodu.

Řekněme, že Java na ten nativní překlad není tak úplně připravená.

Jazyk Java nema ziadny zamer v tejto oblasti. Je mu to uplne jedno ci sa kompiluje do pamate alebo do suboru.

řekněme, že Java byla vyvíjena jako interpretovaná. Dovolte mi to tedy nazvat záměrem.

Velmi jednoducho. Okolo volania ineho kodu urobim catch(Throwable th). Skuste si to.

To prostě nefunguje, není schopno se to zotavit ze všeho co dokáže C/C++/Asm, vyberte si co libo.

Priamo nie len ste na nas zacali hovorit akosi "s patra". Java zo svojimi kniznicami predbehne cokolvek co ste kde videli. Idealne prostredie pre programatora ktoremu ide o vysledok.

Víte z patra mluvím kvůli Vašim reklamám. "Java se svojmi kniznicami predbehne atd." je jen abstraktní nekonkrétní blábol. Stejně tak věta "Idealne prostredie pre programatora ktoremu ide o vysledok." je druhá reklamní věta, tedy druhý abstraktní nekonrétní blábol. Když třeba mým výsledkem má být rychlý nenáročný program, určitě Java nebude ideální prostředí. Prostě mě štvou lidi, kteří nenápadně manipulativně vkládají věty a nenápadně programují podvědomí pomocí oslavných hesel, která se prostě při bližším zkoumání ukáží ne zcela pravdivá, či v pořádku. A Vy to děláte na můj vkus až příliš často do textu, který má jasně a konkrétně argumentovat. Nezlobte se.

Akoze nie je pripravena ked ju ma?

Nalepit a dobastlit můžete věci i na něco co na to není připraveno.

A C ako jazyk pre salove pocitace. Nebavime sa o historii ale o stave Java vs C/C++ 2.11.2006.

C nebyl vyvíjen jako jazyk pro sálové počítače, ale jako jazyk pro přenesení operačního systému. A jak C, tak Java dostali do vínku určité vlastnosti, kterých se prostě nezbaví ani v roce 3000. Přiznejte si, že C je na překlad do strojáku vybaveno poněkud více.

Uvedte priklad. O dva prispevky nizsie som dal OutOfMemory handling. Inac je vas postreh tiez iba nepodlozeny blabol.

Který ovšem závisí na tom, zda se podaří uvolnit nějakou další paměť pro obsluhu výjimky. Jak má tenhle stav, zda bude k dispozici další paměť v libovolném místě možnost ovlivnit programátor Javy?

Ziadne take zadanie nikdy neexistuje (taketo zadania si vymyslaju programatori). To nema pridanu hodnotu. Mna zaujima co program robi nie ako to robi. Aj ked samozrejme mal by to robit najefektivnejsie ako sa da.

Tak tohle komentovat nebudu. Pokud popíráte, že existují úlohy kde přímo v zadání je nutnost rychlosti, tak jste demagog. Chcete snad říci, že třeba databázové systémy ala Oracle nejsou programované s ohledem na maximální rychlost práce s daty? Že zákazníkovi je jedno, jestli ta datová operace skončí za sekundu, nebo za 10 let? Že 3D grafika nemá přímo v zadání maximální rychlost operací? Že kódování videa dlabe na rychlost? Ano, máte pravdu, nikoho rychlost nezajímá, to si vymýšlejí jen paranoidní programátoři, kteří nesnášejí Javu. Fajn, a tu o Červené Karkulce znáte? A dotaz? Věříte ještě na Ježíška a na Bílou paní?

Vy mě chytáte za slovíčka. Já bych jen zareagoval, že JVM se stará o paměť transaprentně, tedy programátor nemá jistotu, že může odchytnout výjimku při nedostatku paměti, a že gc bude mít dost paměti na obsloužení této situce. zaručit se to nedá a klidně to v Javě může spadnout, aniž by programátor to mohl nějak ovlivnit. na rozdíl od C/C++ kde lze napsat obsluhu této situace, která funguje na 100%.

Jinak co se týká rychlosti, napsal jste, že rychlost nikoho nezajímá, a že je to jenom výmysl programátorů. 3D grafika se dělá v Javě, ale Java volá vnitřně stejně C/C++ kód, jinak by to nezvládala rychlostně. Já netvrdím, že se všude musí honit rychlost, ale na rozdíl od Vás bych si nikdy neodvážil tvrdit nic o tom, že rychlost není důležitá. A pomocí hw všechno nenaženete.

Co take pre implementaciu ktore algoritmu Vam v Jave chyba?

V Javě nechybí na implmentaci algoritmu nic, neboť jak je z teorie známo, na implementaci všeho stačí podmíněný skok. Ale je to pak poněkud nudné psaní. Aby bylo jasno, já jsem nepsal, že v Javě nejde něco napsat, takže nic mi nechybí, jen jsem psal, že se to musí ohýbat.

Tymto co chcete povedat? Povodne bol interpreter. Dnes kazda normalna JVM obsahuje JIT alebo sa kod nativne kompiluje (GCJ).

Tím chci říct, že Java a C++ jsou nesrovnatelné. C++ přeci jen kompiluje do strojáku přímo. JIT není kompilace, JIT je normální způsob, jak interpretovat jazyky. Nebo snad chcete říct, že zkompilovaný java soubor je nativní stroják? GCJ je sice kompilátor, ale není to původní záměr jazyka a sám GCJ se musí uchylovat k interpretaci, neboť se musí počítat s dynamic load class.

Asi tak isto ako v Jave. Mimochodom nakukli ste napriklad do balika java.util.concurrent.atomic. V C++ dokazete aby pocitac urobil salto alebo prepisat kernel memory. Lebo nic ine co by Java nevedela ma nenapada.

Tak napište v Javě ovladač pro linux kernel :-) Opravdu si myslíte, že dokážete naprogramovat, aby java program ošetřil nedostatek paměti v JVM a přežil to? To jste první na světě.

Tak a toto je vrchol. Dostudujte si podtriedy triedy RuntimeException. Este Vam davam do pozornosti setUncaughtExceptionHandler v triede Thread (ale to je iba pre advanced programatorov ;-) ).

Hm, ok, znovu říkám, jestli si fakt myslíte, že ošetříte v Javě všechno, zkuste si to.

Tiez nemam rad ked niekto kto robil v C++ si mysli ze Java je len take orezane C++.

Kde to tvrdím?

Nie vsetko v Jave je take jednoduche ako to vyzera. Ten stroj ma svoje systemove vychytavky. Co napr. sandboxing, security (vo vyzname permissions nad vasim kodom napr. RuntimePermission).

Já to Javě neupírám. Všimněte si, že celá tato debata vznikla na základě Vaší lži o tom, že Java je rychlejší, než C/C++.

Ako si ste pozabudli na to najdolezitejsie a to ze Java dotiahla to co C/C++ slubovalo od zaciatku - prenositelnost. Iste sa da urobit prenositelny kod aj v C++ ale musite sa o to postarat. V Jave sa velmi tazko pise neprenositelny kod.

Programoval jsem dost pro mobily a o přenositelnosti Javy mohu říct jediné - neexistuje. Co jiný typ mobilu, to se musel Java program přepsat, nebo upravit. Zatímco třeba v Symbianu, což je C++ byla přenositelnost na mobilech 100%. Ale to jen tak na okraj.

Přenositelnost je něco co není až taková specifika Javy. Třeba u Pythonu se mi přenositelnost zdála vyšší.

A to ze Sun ma komplexy s C++? Velmiiiiii zabavne. Asi si odlozim aj linku aby som to mohol ukaz niekomu zo Sun-u. Asi pukne smiechom. Este aj teraz sa mi trasie notebook na kolenach.

Smích prodlužuje život :-)

Java i C++ jsou každý něco jiného.

Smart pointers (ak ich narychlo podla Googla spravne chapem) nie su sucastou jazyka samotneho, ale len urcitou implementaciou kniznice

Smart pointers mají podporu v jazyce C++. Vznikají prostě z toho, že C++ jazyk automaticky uklízí lokální objekty (volá jejich destruktory) a smart pointers toho jenom využívá.

menej skuseny programator (a budme objektivni, ze kazdy z nas raz zacinal), velmi lahko aj neumyselne bude produkovat zbytocne nebezpecny kod

Vlastností jazyka C++ je dát do ruky větší, a tím pádem nebezpečnější prostředky. To je jeho filozofie.

Koniec koncov, aj implementacia smart pointeru znamena CPU time navyse, takze ostava len otazka o kolko je to v sumare vyhodnejsie.

Pozor! Implementace smart pointeru ve většině případů neznamená CPU time navíc, protože to kompilátor zoptimalizuje. Výhoda je v tom, že se uvolní vše: paměť, i další zdroje systému. Je to víc, než gc.

Myslim si, ze JIT VM ponuka aj ine vyhody (aj ked je mozne, ze v C++ je to tiez implementovatelne alebo sa to aj bezne pouziva) a to je hlavne schopnost zajazdy pridavat kod - hot deploy, alebo schopnost pisat kod 'prezerajuci si' dosle instancie cez Reflection.

Tohle je výhoda každého interpretovaného, nebo dynamického jazyka. Jen poznámku: v Javě na mobilech jsem možnost reflexe neměl.

Znamena to, ze reference counting tam realne nefunguje? Ak teda potrebujem urobit lokalnu cache objektov musim ich nevyhnutne clonovat? To moze mat drasticky dopad na spotrebu pamate alebo znacnu komplikaciu algoritmu.

Ne to neznamená.

Vo Vasom priklade (uvedena linka) ste uvadzali pouzitie struct miesto objektu. Ok,je to mozne, no zavadzat hodnotove typy namiesto referencnych lahko vedie ku komplikaciam ako ukazal C#...

Víte možná to patří k folklóru těch co mají rádi Javy, ale javisti všude vidí problémy. Já zase naopak vidím problémy v absenci hodnot v Javě. V Javě jsou jen odkazy a to je problém. Žádný jazyk to nedonesl tak důsledků. Právě proto nepotřebuje třeba C++ gc, protože má hodnoty i reference. Java neumí pracovat s hodnotami vůbec (mluvím o objektech) a proto si javisti nedokáží představit co to vlastně znamená. V C# je to bohužel hybrid, který se trochu nepovedl, neboť v tomto blbě napodobil Javu, i když ne zcela.

Zakladne typy jednoducho su len hodnoty a ked nahodou je potrebne mat univerzalnejsiu funkciu koder nema moc na vyber...

A ve skutečně objektových jazycích nejsou primitivní typy. A s hodnotami tam problémy nemají, protože jak říkám, každý jazyk s výjimkou Javy má hodnoty i reference. Proto v jiných jazycích tyto problémy nejsou.

Bud to dynamicky casti cez object, alebo vytvara overloady, alebo si posiela NULL ako 0, -1 alebo nieco podobne vymyslene.... alebo si este moze zapuzdrit 'long' do vlastneho objektu. Myslim si, ze prave MS je krasny priklad toho ako sa to nerobi v duchu vykonu, kedze nullable types zaviedol do C# 2.0! Je fajn, ze na trivialne priklady sa to celkom hodi, no neskor prave takeho predcasne optimalizacne rozhodutia vedu ku tragedii v dalsom kode...

Je to trochu přeplácané.

Jinak s bodem 2 a 3 jak ho uvádíte souhlasím. Akorát bych uvedl, že je smutné, když se zase na toto místo tlačí Java, neboť existuje mnoho schopnějších dynamických jazyků. Já sám píšu v dynamickém jazyce, ale Java to bývá jen, pokud jí dostanu přikázáno. Java není moc dobře vyřešený dynamický jazyk. V Javě se musím starat až o příliš moc věcí, které dělat v jiných dynamických jazycích nemusím, aniž by mi to něco přineslo.

Ale ten reference counting som nepochopil - je tam nie je tam? Priznam sa,som lenivy to googlit...

Přímo v jazyce není. Reference counting se dá naprogramovat a v základních knihovnách boostu už je. V příštím standardu C++ už bude reference counting rovnou. Jde v zásadě o rozšíření současné třídy auto_ptr, která už v C++ je.

Ale ten reference counting som nepochopil - je tam nie je tam? Priznam sa,som lenivy to googlit...

Přímo v jazyce není. Reference counting se dá naprogramovat a v základních knihovnách boostu už je. V příštím standardu C++ už bude reference counting rovnou. Jde v zásadě o rozšíření současné třídy auto_ptr, která už v C++ je.

Já bych doplnil, nechci tady kritizovat Javu, i když osobně jí považuji za dost nepovedený jazyk. Jazyk, který prostě se ujal, protože do něj cpala peníze velká firma. Ale to mi nebrání abych neviděl také kladné stránky tohoto jazyka. Spíše jsem trochu ve střehu, protože Java se prezentuje dost často příliš nepravdivě.

Debata s Vámi je konstruktivní a je to radost. Pokud máte pocit, že vystupuji trochu ostřeji, nebo nedbale, tak je to jen ospalostí, takže se omlouvám. Nedejte se mnou prosím odradit.

Myslim, ze sa zhodneme aj na fakte, ze ak by sme naozaj mali v reale kompilovat pre kazdu kombinaciu CPU krabicovu aplikaciu... asi by sa to zle aj vyrabalo...

Máte pravdu.

Viete preco napr. moze byt kod v Jave rychlejsi

Vy jste velký teoretik. Pořád může být rychlejší. Problém je, že není a nikomu se to ještě nepovedlo. Praxe říká něco jiného. Fakt se odmítám dále bavit na teoretické bázi, buď dokažte nějakým testem tu Vaší lež, kterou opakujete jako kolovrátek, a nebo se prostě jděte bodnout.

napisat a spravne ohandlovat multi threadovu aplikaciu v Jave je ovela jednoduchsie nez v C++

to je pravda, nicméně tohle není důvod pro rychlost, spíš naopak

Java je silny nastroj ktory dokaze dobry programator vyuzit vo svoj prospech.

C++ je silný nástroj, který dobrý programátor dokáže využít ve svůj prospěch

Ruby je silný nástroj, který dobrý programátor dokáže využít ve svůj prospěch

Python je silný nástroj, který dobrý programátor dokáže využít ve svůj prospěch

C# je silný nástroj, který dobrý programátor dokáže využít ve svůj prospěch

Smalltalk je silný nástroj, který dobrý programátor dokáže využít ve svůj prospěch

V C++ Vam stale zostava C pomocou ktoreho si mozete niekde prepisat pamat. V Jave to nejde.

Jasně, možnosti C/C++ jsou prostě větší. A proto se s tím spojují i větší rizika. Mimochodem by bylo docela smutné, kdyby C++ neuměl přepsat paměť.

Takze aj pouzitie 3rd party kniznic je napr. bezpecnejsie. A to je aj dovod preco su v Jave rozne frameworky take oblubene (a programatori taky lenivy).

A to je také důvod, proč je Java taky pomalejší a hlavně žravější. :-)

Obavam sa kompilacia na zaklade profilacie ma istu vaznu slabinu - kazdy vacsi system ma svoj zivotny cyklus... Takze rano importujem data, cez den s nimi pracujem, vecer zase exportujem. Moze to byt dokonca aj horsie. Mzdy sa sa robia den alebo dva, vypis z banky zadava jeden klient raz za mesiac, no druhy to robi kazdy den... V takychto pripadoch staticka kompilacia skoncila.

Já bych řekl, že přínos dynamické kompilace bude menší, než se tvrdí. Ono ať chcete, nebo ne, stejně 99% kódu, který Java vykonává je staticky překompilovaný v C/C++.

Este by som rad spomenul napriklad upravu bytecode za behu. Viem,ze je to extrem, ale celkom pouzivany k prospechu celkoveho vykonu... Z uvedeneho by som povedal, ze C++ bude pravdepodobne pri jednoduchych prikladoch asi vzdy rychlejsie, no pri long running systemoch to bude mat dost tazke...

Já bych se odvolal na praxi. Zatím se C/C++ systémy ukázaly vždy rychlejší. Až bude Java rychlejší, věřte mi, že se začnou kritické věci psát v Javě - a to se neděje. Zatím máte kernely operačních systémů psané v C/C++/Asm a rychlostně kritické části si zatím nikdo nedovolil přepsat do Javy, ale píšou se v C/C++/Asm. Řekl bych, že to o něčem svědčí. Stejně tak jako kódování a dekódování videa se v Javě taky nezačalo psát. A 3D grafika, která se používá v Javě stejně volá vnitřně C/C++ rutiny, které provedou ty rychlostně náročné věci. Náročné vědecké výpočty, které simulují matematické modely také nepoužívají Javu. Věřím, že stačí jeden důkaz, že Java je rychlejší, než C/C++ a ti lidi to do Javy začnou přepisovat, neboť každé procento výkonu navíc se v těchto aplikacích hodí. Ale oni to stále nepíší v Javě a asi vědí proč.

Jenže tohle je právě sice mainstream názor, ale mylný. Jednak neexistuje jen svatá trojice. Jednak C++ není pomalejší, než C, tudíž C++ je na tom rychlostně stejně jako C. Existuje spousta jiných jazyků, které se používají a jsou třeba velice rychlé. Já to řeknu jinak, zabýval jsem se kdysi realtime jazyky. Jinak třeba NASA všechno píše v Adě - statický kompilovaný jazyk zaměřený na maximální bezpečnost a na to, aby bylo maximálně těžké v tomto jazyce napsat chybu. Přesto je to jazyk docela rychlý. Amiga měla část operačního systému napsánu v jazyce B, předchůdci Céčka. Viděl jsem operační systém napsaný v Module 2 - rychlostně je na tom podobně jako Céčko. Spousta core Java věcí je sice napsáno v Javě, ale pak to dopadá tak, že Microsoft napsal svojí JVM, která regulérně byla velmi výrazně rychlejší, než cokoli od Sunu a neměla tuším ani JIT. Java samotná jen velmi mizerně podporuje rozšířování pomocí C, sice to jde, ale nikde se to nepropaguje a nikdo to moc nedělá. Prostě v Javě nejde o rychlost tak co by se někdo namáhal.

Vykonostny rozdiel pride v pripade pouzitia OOP nie? Ak si dobre pamatam, tak prve verzie C++ boli riesene len cez preprocesor.

Proč myslíte, že použití OOP by mělo snižovat výkon? Musíte si uvědomit, že z hlediska C++ nejjednodušší třída nemá prakticky naprosto žádnou výkonnostní režii. První verze C++ byla opravdu v preprocesoru, ale taky uměla asi tak 1% toho co dnešní C++.

OOP není o snižování výkonu, OOP je jen metodika programování. To je třeba taky důvod, proč opravdové OOP jazyky nají všechno jako objekty, i celá čísla, a přitom rychlostně je to stejné jako práce s primitivními typy.

Musíte si uvědomit, že kompilátor prostě je od toho, aby optimalizoval a také to, že pro C++ nejsou objekty spojeny s takovou režií jako v Javě, protože prostě jsou to z hlediska strojového kódu vnitřně jenom struktury, metody jsou jen funkce s parametrem navíc. Proto také se nikdo neobává používat OOP v C++ i na rychlostně kritické věci, neboť OOP v C++ nemá výkonnostní režii prakticky žádnou a v případě využívání pokročilých OOP věcí je v C++ výkonnostní režie naprosto mizivá.

Vykonostny rozdiel pride v pripade pouzitia OOP nie? Ak si dobre pamatam, tak prve verzie C++ boli riesene len cez preprocesor.

Proč myslíte, že použití OOP by mělo snižovat výkon? Musíte si uvědomit, že z hlediska C++ nejjednodušší třída nemá prakticky naprosto žádnou výkonnostní režii. První verze C++ byla opravdu v preprocesoru, ale taky uměla asi tak 1% toho co dnešní C++.

OOP není o snižování výkonu, OOP je jen metodika programování. To je třeba taky důvod, proč opravdové OOP jazyky nají všechno jako objekty, i celá čísla, a přitom rychlostně je to stejné jako práce s primitivními typy.

Musíte si uvědomit, že kompilátor prostě je od toho, aby optimalizoval a také to, že pro C++ nejsou objekty spojeny s takovou režií jako v Javě, protože prostě jsou to z hlediska strojového kódu vnitřně jenom struktury, metody jsou jen funkce s parametrem navíc. Proto také se nikdo neobává používat OOP v C++ i na rychlostně kritické věci, neboť OOP v C++ nemá výkonnostní režii prakticky žádnou a v případě využívání pokročilých OOP věcí je v C++ výkonnostní režie naprosto mizivá.

Nebol rozdiel vo vykone dany aj tym, ze MS si mohol dovolit natlacit veci do jadra, co hold Sun nemal?

Řekl bych, že MS umí na rychlost optimalizovat lépe, než Sun. Především na rozdíl od Sunu oni neměli všechny standardní knihovny Javy v Javě, a pak taky asi napsali lépe optimalizovanou JVM. MS vůbec dokazuje, že nad Sunem rychlostně vede, když si spočítám kolik let trvalo Sunu dostat se rychlostně s JVM na dnešní úroveň, a MS bez problémů udělal z placu naráz rychlejší JVM (kterou mu potom Sun napůl soudně zakázal). A stejně tak dnešní .NET je rychlostně plus mínus srovnatelný s Javou (někde jsem slyšel, že dokonce mírně rychlejší) a to ho MS naprogramoval do dnešního stavu za pár let s porovnání s několikanásobkem času, který potřeboval Sun. Tím neoslavuji MS, jen se snažím dát dohromady fakta.

Já bych se odvolal na praxi. Zatím se C/C++ systémy ukázaly vždy rychlejší. Až bude Java rychlejší, věřte mi, že se začnou kritické věci psát v Javě - a to se neděje.

Já bych to viděl takhle: Java je slušně rychlá, ale obávám se, že opravdu velký přínos z dynamické kompilace přinese spíš Strongtalk a jeho odvozeniny, nebo nějaký jiný VM Smalltalku – nevím o tom, že by v současnosti v Javě byly využívány až tak agresivní techniky. Pokud Self mohl před skoro patnácti lety běžet polovinou rychlosti céčka, co teprv o něco méně dynamický kód dneska?

Pravda je, že šablony a intrinzika dělají v C++ svoje – kombinací těchto dvou funkcí se dá například vymáčknout z vektorových jednotek maximum, na což Java potřebuje knihovnu. Pokud vím, Java u generik dělá jen type erasure a interní konverze, docela by mě zajímalo, jestli je to aspoň trošku optimalizované (nebo optimalizovatelné) na úrovni VM, když na úrovni kompilátoru to řešené není. Kvalitní VM by to taky dost možná dokázal dynamicky, ale nějak se mi nechce věřit, že by VM Javy byl kvalitní natolik, aby zrovna tohle uměl. C++ to řešit pochopitelně nemusí.