Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Bla 01. 01. 2014, 18:19:13
-
Ahoj,
existuje pro Linux jazyk podobný C#?
- Překladač z toho musí udělat nejlépe strojový kód, potřebuji to na realtime aplikaci.
- Java je sice pěkná a vyhovovala by, ale je na to příliš, příliš, pomalá.
V zásadě se nechci start o alokaci paměti, mimo jiné a musí to být opravdu exra rychlé.
-
Pokud je pro tebe Java pomalá, nepouštěj se do toho a zkusil bych jiný projekt, třeba puzzle.
-
Za jenvýznamější výhodu C# je možno považovat .NET (a tedy i mono) platoformu. Samozřejmě že C# je již vyzrálejší a má lepší věci než Java, například LINQ. Java i C# jsou skvělé pro tvorbu enterprise aplikací, tedy velkých molochů typu ERP systémy.
Pro realtime aplikaci zvaž použití C++, nevidím zas až takovou výhodou GC oproti smart pointeru - není až tak těžké starat se o alokaci paměti.
Pokud chceš jazyk opravdu vyšší úrovně, tak je tu Cython (http://cython.org/) který kompiluje do C, ale ten má k Java / C# HODNĚ daleko.
Hodně odvážné by bylo vyzkoušet Haxe (http://haxe.org/), to je transkompiler s jazykem mající podobnou syntax jako C#/Java a umožňuje pak vytvořit nativní zdroják v C++, Java, C# a pár dalších obsukrních jazycích jako třeba JavaScript. Nevýhodou je, že se to bude blbě debugovat, jedině přes nějaký ten logger či trace...
-
Vala (https://wiki.gnome.org/Projects/Vala)
-
Nechci flejmovat, ale můžu se zeptat co to má být za aplikaci, na kterou je java "příliš, příliš pomalá"?
-
Java a C# su co sa tyka vykonu na velmi podobnej urovni, takze ak ti vykonovo vyhovuje C# tak Java ti vyhovovat bude urcite. Ak chces nieco naozaj, naozaj extra rychle odporucam assembler (iste podobnosti s C# tam su, napr. obidve bezia na pocitaci).
PS: najviac by som sa smial, keby si sa nakoniec rozhodol pre Python, ktory je asi tak 100x pomalsi nez Java
-
Jestli potřebuješ realtime aplikaci, tak cokoliv s garbage collectorem nechceš. Jestli to má být opravdu realtime aplikace, tak nechceš ani nic s dynamickou alokací paměti. Obecné alokátory jsou totiž ve své podstatě časově nedeterministické, nedá se dost dobře určit, jak dlouho bude alokace trvat, protože to závisí na mnoha věcech (fragmentace paměti, počet alokovaných bloků, zámky od odstatních threadů, jestli jsou zrovna datové strukrury alokátoru v cache nebo ne...), takže nemůžeš ani zaručit latence. Možná by bylo dobré napsat, co to má být za aplikaci. Pokud aplikace typu vyčítám periodicky z teplotního čidla nějaké hodnoty a když je náhodou nedostanu, tak mi to nevadí, protože přijdou později, tak to klidně můžeš napsat v jave. Pokud děláš řídicí aplikaci pro letecký motor, tak na javu zapomeň a zapomeň i na dynamickou alokaci paměti, protože musíš všechno alokovat staticky nebo jen při inicializaci a za běhu už ne.
-
Gamer:
A co memory pool? Tam jde zaručit opravdu velmi rychlou alokaci paměti...
-
existuje pro Linux jazyk podobný C#?
- Java je sice pěkná a vyhovovala by, ale je na to příliš, příliš, pomalá.
Ja myslim, ze skor to vydebuges preco je to v Jave pomale a opravis to a bude to rock solid, ako skusat nejaky iny obskurny jazyk v ktorm pocas vyvoja narazis na iny problem.
-
Můžeš zkusit jazyk jménem Scala, který se kompiluje do bytecodu JVM.
Problém je spíš v použití JVM/.Netu pro realtime aplikace. Na tomto poli jsou kladené zcela jiné požadavky než u běžných aplikací (navíc se liší mezi jednotlivými RT aplikacemi) a začíná to již u operačního systému.
-
To s pomalou Javou je asi blbost co? Tedy pokud nedoplníte, že je stejně pomalá jako C#/.Net. Dobré řešení by mohl být nějaký crosscompiler do C, např. už zmiňovaná Vala. Scala je moc pěkný jazyk, ale také běží na JVM.
https://wiki.gnome.org/Projects/Vala/About
The syntax of Vala is similar to C#, modified to better fit the GObject type system. Vala supports modern language features as the following:
-
eMko: ona i java se da pouzit pro realtime aplikace, ale musis pouzivat jine nastroje, nez pro "bezne" programovani, viz treba Javolution a Java RTS
-
Problém jazyků je ten, že se k ní vyjadřují blbci, kteří v tom napsali Hello World. Rychlost běhu C#/Java je naprosto srovnatelná. Oboje se kompiluje do nativního kódu, u Javy můžete dokonce nastavit kompilaci při prvním průběhu programu. Říká se tomu Virtual Machine Hints, to jen na opravu místních kecalů. Častý mýtus mnoha lidí je, že prostý překlad do jiného jazyka, který se následně kompiluje do strojového kódu, cokoliv urychlí. Takové pověře může uvěřit jen ten, který zatím vůbec netuší, co se děje s jeho kódem. C# i Java mohou být stejně rychlé, někdy dokonce i rychlejší než jazyky, kterým se říká "nativní", jako je C. Proč ? Inu:
1) VM má k dispozici informace o vašem hardware a kompiluje přímo pro něj, nikoliv univerzálně. Některé operace (hlavně aritmetika a práce se soubory) se tak dají značně urychlit.
2) Důvod, proč kód v jazycích, které dovolují práci na nižší úrovni abstrakce, bývá po překladu rychlejší, je jednoduchý: Malá obecnost řešení a málo bordelu. Otázka bývá špatně položena. Vůbec nejde o to, jestli něco generuje nativní instrukce a něco nikoliv (oboje lze přinutit ke kompletnímu překladu). Jde o to, jak generovaný kód vypadá. Funkce, které voláte v Javě či C#, jsou přeci jen univerzálnější. Nemusíte sledovat pointery na soubory. Java dokonce od verze 7 automaticky uzavírá alokované zdroje v kontrolovaných blocích. A protože jsou napsané univerzálně, jejich strojový kód vypadá jinak než ten, který vygeneruje Vámi napsaný prográmek v C/C++, který ale nevyhovuje tak obecnému použití. Pokud použijete v C++ obecnou knihovnu, vůbec nemusí být rychlejší než přeložený program v Javě, někdy naopak.
V Javě můžete kritické části implementovat v jiném jazyce, říká se tomu JNI. A na zbytek použít Java knihovny. Říká se, tj. nemám to ověření, že volání nativní metody trvá okolo 35 nanosekund. Pokud je její průběh rozumně dlouhý (což u kritických částí programu bude), máte k dispozici zbraň slušného kalibru. Krásná ukázka, že Java umí běžet naprosto stejně rychle jako program v C++, je JOGL. Když na procesoru počítáte matice a pouze výsledný předáváte shaderům, pak zjistíte že Java umí optimalizovat práci s maticí reprezentovanou jednorozměrným polem naprosto skvěle - tj. práce s ní je stejný fofr jako když to samé izoluji a napíši v C. S tím že C kód má o dost horší metriku.
Výhody a nevýhody obojího si musí každý zvážit sám.
Závěr je následující: Jestliže někdo hledá náhradu za C#, pak v něm pravděpodobně nic moc neumí či nic seriózního nedělá. C# se totiž nahradit nedá, pomineme-li ostatní jazyky z balíku .NET. Má jinou úlohu než Java, jeho API je jiné (jestli někdo přijde s tím, že oboje má kolekce a podobné kecy...). Dokonce i vláknování, což většina programátorů nedělá a neumí, je v C# připravené pro Windows. Proto je jeho portování (jako projekt Mono) tak šíleně kontraproduktivní. Dotnet je spjatý s platformou Windows, na které dejme tomu funguje dobře a rozumí si s ní. Čím toto chcete nahradit ? Zkuste v Javě najít rozlišení vláke na foreground/brackground. Zkuste v ní najít podporu D3D. To vše je Windows only.
Všechny tyto thready jsou jen důkazem toho, jak je teorie a vzdělání důležité.
-
eMko: ona i java se da pouzit pro realtime aplikace, ale musis pouzivat jine nastroje, nez pro "bezne" programovani, viz treba Javolution a Java RTS
Neříkám, že se to nedá, právě naopak, vím, že se používá. Ale vzhledem k povaze původního příspěvku to nemá smysl rozpitvávat.
-
Existuje i realtime JVM http://www.oracle.com/technetwork/middleware/jrockit/overview/index-086343.html
A realtime a rychlé jsou dvě různé věci, realtime především znamená garantovanou dobu odezvy, nikoliv však nějaké rekordy v množství vyřízených požadavcích délce doby vyřízení.
-
Můžeš zkusit jazyk jménem Scala, který se kompiluje do bytecodu JVM.
Problém je spíš v použití JVM/.Netu pro realtime aplikace. Na tomto poli jsou kladené zcela jiné požadavky než u běžných aplikací (navíc se liší mezi jednotlivými RT aplikacemi) a začíná to již u operačního systému.
Je realtime a realtime. Ja robim realtime aplikacie na java SE a staci to. Trosku treba zmenit styl uvazovania, mysliet multiparadigmovo (Rozmysliet si, co sa hodi viac v objektoch a co uz treba robit proceduralne ), hlavne umyselne neplytvat z drojmi a ked sa najde bottleneck, tak optimalizovat. Java je svizny jazyk, ked si clovek aplikaciu nezabloatuje. Vyhodou je, ze poskytuje celkom velavravne chybove hlasky nie ako v C, ked sa proste nieco pokazi a teraz debuguj ...
-
A realtime a rychlé jsou dvě různé věci, realtime především znamená garantovanou dobu odezvy, nikoliv však nějaké rekordy v množství vyřízených požadavcích délce doby vyřízení.
Tohle by se mělo tesat do kamene. Požadavky na latenci (doba zpracování nějakého požadavku) a propustnost (počet zpracovaných požadavků za čas) jdou hodně často proti sobě. Je to vidět i na hardwaru. CPU jsou optimalizované na latenci a GPU na propustnost.
Pravé realtime (garantovaná doba odezvy) se vůbec nedá na x86 s běžným OS dosáhnout.
-
Vala (https://wiki.gnome.org/Projects/Vala)
Hlavne NE vala!!! Vala je sice na prvni pohled vyborny projekt - vsechny vyhody "osvedceneho" glib/gobject frameworku pro C, uzasne snadne pouzivani knihovny ve vale z jinych jazyku, kompilace do C, umoznujici kompilovat pro temer jakoukoliv platformu, atd, atd.
Vsechno krasne, pokud se to cte, pokud se to tyka psani nejnovejsich glib/gobject knihoven. Ale jakmlile v tom potrebujete pracovat a prijde prvni problem, zjistite, ze:
* podobnost s c# je pouze povrchni, jedna se o vyrazne jiny jazyk, a mnoho veci funguje VYRAZNE jinak, nez se zda ze by to fungovat mohlo
* temer neexistuje dokumentace, ta co existuje je pro starou verzi, obsahuje chybne priklady a nebo proste neni
* pouziti existujicich ne-gobject C knihoven je porod, ktery ve vetsine pripadu konci smrti - nektere veci, proste NEJDOU, takze bud existujici knihovnu prepisete do valy, nebo napisete "normal-C"->"gobject-C" rozhrani.
* podpora v make, autotools, atd je zoufala
* debugovani je katastrofa, diky automatickemu prekladu do C mate temer jistotu ze nepochopite v cem vlastne chyba byla
ve zkratce: NE, NE, NE a jeste jednou NE!
Mluvim z vlastni zkusenosti, "vyhodili" jsme diky vale cca 4 mesice prace 3 lidi. Takze vam radim, vale se zdaleka vyhnete!!!
-
Díky Belzebube, začínala se mi líbit a uvažoval jsem že bych se jí začal věnovat. :)
-
...
ve zkratce: NE, NE, NE a jeste jednou NE!
Mluvim z vlastni zkusenosti, "vyhodili" jsme diky vale cca 4 mesice prace 3 lidi. Takze vam radim, vale se zdaleka vyhnete!!!
Jinymi slovy tedy rikas "Dejte Vale vale!"
-
Problém jazyků je ten, že se k ní vyjadřují blbci, kteří v tom napsali Hello World. Rychlost běhu C#/Java je naprosto srovnatelná. Oboje se kompiluje do nativního kódu, u Javy můžete dokonce nastavit kompilaci při prvním průběhu programu. Říká se tomu Virtual Machine Hints, to jen na opravu místních kecalů. Častý mýtus mnoha lidí je, že prostý překlad do jiného jazyka, který se následně kompiluje do strojového kódu, cokoliv urychlí. Takové pověře může uvěřit jen ten, který zatím vůbec netuší, co se děje s jeho kódem. C# i Java mohou být stejně rychlé, někdy dokonce i rychlejší než jazyky, kterým se říká "nativní", jako je C. Proč ? Inu:
1) VM má k dispozici informace o vašem hardware a kompiluje přímo pro něj, nikoliv univerzálně. Některé operace (hlavně aritmetika a práce se soubory) se tak dají značně urychlit.
2) Důvod, proč kód v jazycích, které dovolují práci na nižší úrovni abstrakce, bývá po překladu rychlejší, je jednoduchý: Malá obecnost řešení a málo bordelu. Otázka bývá špatně položena. Vůbec nejde o to, jestli něco generuje nativní instrukce a něco nikoliv (oboje lze přinutit ke kompletnímu překladu). Jde o to, jak generovaný kód vypadá. Funkce, které voláte v Javě či C#, jsou přeci jen univerzálnější. Nemusíte sledovat pointery na soubory. Java dokonce od verze 7 automaticky uzavírá alokované zdroje v kontrolovaných blocích. A protože jsou napsané univerzálně, jejich strojový kód vypadá jinak než ten, který vygeneruje Vámi napsaný prográmek v C/C++, který ale nevyhovuje tak obecnému použití. Pokud použijete v C++ obecnou knihovnu, vůbec nemusí být rychlejší než přeložený program v Javě, někdy naopak.
V Javě můžete kritické části implementovat v jiném jazyce, říká se tomu JNI. A na zbytek použít Java knihovny. Říká se, tj. nemám to ověření, že volání nativní metody trvá okolo 35 nanosekund. Pokud je její průběh rozumně dlouhý (což u kritických částí programu bude), máte k dispozici zbraň slušného kalibru. Krásná ukázka, že Java umí běžet naprosto stejně rychle jako program v C++, je JOGL. Když na procesoru počítáte matice a pouze výsledný předáváte shaderům, pak zjistíte že Java umí optimalizovat práci s maticí reprezentovanou jednorozměrným polem naprosto skvěle - tj. práce s ní je stejný fofr jako když to samé izoluji a napíši v C. S tím že C kód má o dost horší metriku.
Výhody a nevýhody obojího si musí každý zvážit sám.
Závěr je následující: Jestliže někdo hledá náhradu za C#, pak v něm pravděpodobně nic moc neumí či nic seriózního nedělá. C# se totiž nahradit nedá, pomineme-li ostatní jazyky z balíku .NET. Má jinou úlohu než Java, jeho API je jiné (jestli někdo přijde s tím, že oboje má kolekce a podobné kecy...). Dokonce i vláknování, což většina programátorů nedělá a neumí, je v C# připravené pro Windows. Proto je jeho portování (jako projekt Mono) tak šíleně kontraproduktivní. Dotnet je spjatý s platformou Windows, na které dejme tomu funguje dobře a rozumí si s ní. Čím toto chcete nahradit ? Zkuste v Javě najít rozlišení vláke na foreground/brackground. Zkuste v ní najít podporu D3D. To vše je Windows only.
Všechny tyto thready jsou jen důkazem toho, jak je teorie a vzdělání důležité.
+100
-
Autor ma pravdu v tom ze Java aplikacie nie su uplne plynule. Neviem ci za to mozu konkretne implementacie jvm (pouzivam javu od oracle, skusal som aj open jdk) alebo graficke toolkity (swing, swt) ale este som sa nestretol s java aplikaciou ktra by bola 100 percentne plynula (preto. Nepouzivam IDEcka ako IDEA, Eclipse ani NetBeans proste sa mi s v tom nepracuje dobre). Taktiez su java aplikacie dost nenazrane (maju divny memory management) a dlho startuju, nehovoriac o otrasnej typografii v ui swing (menucka nemaju nastavene paddingy takze su vsetky itemy nalepene na seba co znizuje celkovy user xp a bezneho uzivatela java na desktope maximalne odradi. Naopak u .NET appiek som sa s podobnymi problemami nestretol (ak nepocitam pomalsi start) - bezny uzivatel ich nerozozna od nativnych.
-
nehovoriac o otrasnej typografii v ui swing (menucka nemaju nastavene paddingy takze su vsetky itemy nalepene na seba co znizuje celkovy user xp a bezneho uzivatela java na desktope maximalne odradi. Naopak u .NET appiek som sa s podobnymi problemami nestretol (ak nepocitam pomalsi start) - bezny uzivatel ich nerozozna od nativnych.
hmm
(http://i.imgur.com/wTeSivc.png)
jak presne ze se lisi to menu (nebo jakykoliv jiny ovladaci prvek) v Jave od nativniho (testovano na desktopu s win7)? horni je WPF a dolni Swing. Dokonce bych rekl, ze Java ma vic nativni vzhled nez WPF (rozmazly radio control a menu vyber). BTW docilit nativniho vzhledu ve Swingu byla otazka dvou radku (+ jednoho radku importu).
-
Java ma vic nativni vzhled nez WPF
Swing je lépe porovnávat s Windows.Forms než s WPF.
Každopádně pokud má karol problém s paddingy ve Swingu, je chyba někde jinde než ve Swingu samotném. Každý vzhled je má nastaveny jinak.
-
Ahoj,
existuje pro Linux jazyk podobný C#?
- Překladač z toho musí udělat nejlépe strojový kód, potřebuji to na realtime aplikaci.
- Java je sice pěkná a vyhovovala by, ale je na to příliš, příliš, pomalá.
V zásadě se nechci start o alokaci paměti, mimo jiné a musí to být opravdu exra rychlé.
Pokud chces programovat v necem, v cem uz bylo takovych aplikaci napsanych habadej a troufam si rict, ze jeste bude tak rozhodne zvol nizsi patro - C# a Java se nachazeji na identickem podlazi a pro realtime aplikace navrzeny nebyly. Jak tady jiz nekdo psal - Assembler mam osobne rad :) (nebo C - zalezi na obsahlosti aplikace). Kdysi jsem v nem napsal jeste v DOSu docela robustni aplikaci, ale precejen to bylo zaroven naposled. Precejen se pohybujes na urovni dvou az tri znakovych, dookola se opakujicich instrukci a v dost velkem projektu by z toho mohla jit casem hlava kolem ;) Takze jsem se v tom sam zamotal a zvolil bych uz z tohoto duvodu C - jak jsem jiz zminil - nepreberne mnozstvi kodu, velka komunita, mnozstvi knih a dokumentace, moznost pouzit Assembler bloky a ta prehlednost je taky podstatne lepsi :)
-
A realtime a rychlé jsou dvě různé věci, realtime především znamená garantovanou dobu odezvy, nikoliv však nějaké rekordy v množství vyřízených požadavcích délce doby vyřízení.
Tohle by se mělo tesat do kamene. Požadavky na latenci (doba zpracování nějakého požadavku) a propustnost (počet zpracovaných požadavků za čas) jdou hodně často proti sobě. Je to vidět i na hardwaru. CPU jsou optimalizované na latenci a GPU na propustnost.
Pravé realtime (garantovaná doba odezvy) se vůbec nedá na x86 s běžným OS dosáhnout.
Dovolim si nesouhlasit - pokud napisu aplikaci v OS DOS like, tak se na x86 da realtime aplikace napsat. Pokud se mylim, prosim o zduvodneni - drzme se OS, ktery jsem uvedl a pro priklad uvedme aplikaci, ktera bude snimat data z detektoru, zanalyzuje data a dle vyhodnoceni provede urcitou cinnost - napr. zaslani TCP paketu (priklad berte s rezervou ;))
-
Já vím, že pro linuxáka je to urážka něco takového vytahovat, ale co takhle jazyk
C++
-
Dovolim si nesouhlasit - pokud napisu aplikaci v OS DOS like, tak se na x86 da realtime aplikace napsat. Pokud se mylim, prosim o zduvodneni - drzme se OS, ktery jsem uvedl a pro priklad uvedme aplikaci, ktera bude snimat data z detektoru, zanalyzuje data a dle vyhodnoceni provede urcitou cinnost - napr. zaslani TCP paketu (priklad berte s rezervou ;))
Tohle není realtime aplikace. Realtime je třeba ABS v autě, kde se řeší úlohy typu snímám otáčky kola a když zjistím, že se to netočí dost rychle, musím do 10 ms (zaručeně!) sepnout čerpadlo ABS, jinak se stane něco nehezkého. V tom DOSu je třeba ovladač myši, který si občas vezme řízení v přerušení. Když nedokážu zaručit, že to bude do 10 ms (včetně všech ostatních věcí, které se mohou stát), tak DOS použít nemůžu.
-
C# i Java mohou být stejně rychlé, někdy dokonce i rychlejší než jazyky, kterým se říká "nativní", jako je C.
Proboha uz zase tenhle bunk o Jave rychlejsi nez C? Tohle muze napsat jedine clovek co vubec netusi jak funguje pocitac...
-
Proboha uz zase tenhle bunk o Jave rychlejsi nez C? Tohle muze napsat jedine clovek co vubec netusi jak funguje pocitac...
To právě není tak jisté. JIT kompilátor může mít třeba k dispozici informace, které C kompilátor nemá, a díky tomu může být pak rychlejší.
-
Galgonek dokážeš tento svůj fábul podložit nějakým jiným argumentem než ocucaným prstem?
-
Proboha uz zase tenhle bunk o Jave rychlejsi nez C? Tohle muze napsat jedine clovek co vubec netusi jak funguje pocitac...
To právě není tak jisté. JIT kompilátor může mít třeba k dispozici informace, které C kompilátor nemá, a díky tomu může být pak rychlejší.
=== nahrazení skillu optimalizací kompilátorem. Jdeme lepit v Jave :) (nic proti Jave, to je proti lepicum trid)
-
Galgonek dokážeš tento svůj fábul podložit nějakým jiným argumentem než ocucaným prstem?
Na tohle nejsem expert, ale moderním precesorům například docela vadí skoky. V kódu je často obsaženo hodně ifů, které jen ošetřují anomální případy, která takřka nikdy nenastanou. Pokud JIT kompilátor zjistí, že v 95% případů je nějaká podmínka vždy true, tak prostě ten kousek kódu přeloží tak, že se v těch 95% případů vůbec skákat nebude. Překladač C ale takovéto informace nemá (minimálně ne v takové kvalitě) k dispozici. Takže to je jedna z možností, kde má JIT teoretickou šanci být lepší.
-
=== nahrazení skillu optimalizací kompilátorem.
Tak vývoj sem spěje. Například dnes už skoro nikdo z nás nenapíše v asembleru kód, který by byl rychlejší než ten, co si napíšeme v C a necháme přeložit. Dnešní procesory už jsou prostě příliš složité.
-
nahrazení skillu optimalizací kompilátorem
To jako že by si programátor ke každému uživateli sedl, pozoroval způsob jeho práce, a pak by mu program překompiloval na míru? Teoreticky je to možné… Ale proč to dělat, když do kompilátor zvládne lépe a nesrovnatelně levněji?
-
Já vím, že pro linuxáka je to urážka něco takového vytahovat, ale co takhle jazyk
C++
Ono na tom kupodivu neni C++ v open source projektech tak spatne, jak to nekdy muze (hlavne v diskuzich :-) vypadat. Tady je pekne videt, jak se C, C++ i Java pekne srovnaly na nejakych 10% commitu u sledovanych projektu:
http://www.ohloh.net/languages/compare?measure=commits&percent=true&l0=cpp&l1=c&l3=java&l4=java&commit=Update
(Btw. kdyz uz jsi tady v diskusi - jak vlastne byly portovany Brany Skeldalu na Android? Prepis z C++ do Javy nebo jsou tam porad nativni casti kodu?)
-
Galgonek dokážeš tento svůj fábul podložit nějakým jiným argumentem než ocucaným prstem?
Na tohle nejsem expert, ale moderním precesorům například docela vadí skoky. V kódu je často obsaženo hodně ifů, které jen ošetřují anomální případy, která takřka nikdy nenastanou. Pokud JIT kompilátor zjistí, že v 95% případů je nějaká podmínka vždy true, tak prostě ten kousek kódu přeloží tak, že se v těch 95% případů vůbec skákat nebude. Překladač C ale takovéto informace nemá (minimálně ne v takové kvalitě) k dispozici. Takže to je jedna z možností, kde má JIT teoretickou šanci být lepší.
Je vidět, že o tom víš prd a vaříš jen z vody. Není skok jako skok, jsou short a far jumpy, mezi nimi je zásadní rozdíl a moderní procesory si už řadu let dokáží poradit s predikcí skoků velmi dobře, nastuduj si to například zde http://www.agner.org/optimize/microarchitecture.pdf Velmi nás unavuje číst tvé nekompetentní příspěvky psané stylem: "Něco napíšu, protože myslím, že dnes z palce vycucám něco fakt zázračného!".
-
[...]
Přečti si ještě jednou, co jsem tu jako první napsal, zamysli se nad sebou a začni se chovat slušně.
-
Na tohle nejsem expert, ale moderním precesorům například docela vadí skoky. V kódu je často obsaženo hodně ifů, které jen ošetřují anomální případy, která takřka nikdy nenastanou. Pokud JIT kompilátor zjistí, že v 95% případů je nějaká podmínka vždy true, tak prostě ten kousek kódu přeloží tak, že se v těch 95% případů vůbec skákat nebude. Překladač C ale takovéto informace nemá (minimálně ne v takové kvalitě) k dispozici. Takže to je jedna z možností, kde má JIT teoretickou šanci být lepší.
Je vidět, že o tom víš prd a vaříš jen z vody. Není skok jako skok, jsou short a far jumpy, mezi nimi je zásadní rozdíl a moderní procesory si už řadu let dokáží poradit s predikcí skoků velmi dobře, nastuduj si to například zde http://www.agner.org/optimize/microarchitecture.pdf Velmi nás unavuje číst tvé nekompetentní příspěvky psané stylem: "Něco napíšu, protože myslím, že dnes z palce vycucám něco fakt zázračného!".
No nevim. Sice moderni procesory maji hodne slozite resene predikce a pomerne upsesne, to ale neznamena ze to nejde lepe (prediktory rozhodne nejsou 100% a za kazde selhani se plati cim dal draz). A prece jen JIT ma lepsi moznosti hlubsi analyzy kodu (asi za cenu urcite pocatecni rezie?), nez co si muze dovolit analyzovat procesor na urovni hw (co vim, tak se nic takoveho nedeje, protoze je to slozite a drahe [detekce hotspotu a nasledna optimalizace]).
-
noef
JIT v podání Java má už z principu své práce značnou režii, přemýšlení o kódu totiž stojí nějaký strojový čas!!! stejně tak jako iterace objekty s průzkumem a validací referencí. Jak třeba v java zakážeš provádění interuptů? Udělej si jednoduchý pokus, spusť si program, který bude používat n*5 vláken, kde n je definováno jako počet logických procesorů a každé vlákno měří čas od minulého spuštění kódu.
Hlavní vlákna by měla podávat konstantní výsledky, ale nebudou, čas bude kolísat, protože se tam motají další vlákna.
Přes java concurent locks se dostaneš na lepší hodnoty, ale ani náhodou na hodnoty dobré, rozhodně se nedá spolehnout, že reakce na událost přijde řekněme v předem přesně definované době. Zkus si to!
Galgonek
Správná odpověď na mojí výtku by byla: ,,Omlouvám se, mám kecavku a rád troluju, ale pokusím se mluvit jen k věcem, kterým rozumím." nikoliv "Chovej se slušně!"
Chováš se jako dítě a když tě napomenu, říkáš mi, abych se choval slušně, chovám se slušně, nemůžu za to, že žvaníš blbosti.
-
Správná odpověď na mojí výtku by byla: ,,Omlouvám se, mám kecavku a rád troluju, ale pokusím se mluvit jen k věcem, kterým rozumím." nikoliv "Chovej se slušně!"
Chováš se jako dítě a když tě napomenu, říkáš mi, abych se choval slušně, chovám se slušně, nemůžu za to, že žvaníš blbosti.
Nepsal jsem, jak věci jsou a že to vím jistě. Pouze jsem naznačil, že by mohly být i jinak. Fajn, procesor má branch prediction, ale ta má své meze, například rozpozná jen určité patterny, je to tak? Co když JIT (který může rozpoznávat složitější patterny) uspořádá skoky tak, aby vytvářely pattern, který procesor pozná? Nevím, zda to dělá a ani to netvrdím. Každopádně zatím jsi tu neukázal nic, co by nějak dokázalo či naznačilo, že informace získané při konkrétním běhu programu nelze použít k jeho optimalizaci, neboť informace získané staticky z kódu a dynamicku procesorem stačí.
Takže ještě jednou a jasně, nikdy jsem netvrdil, že Java je jistě rychlejší než C. Jen jsem říkal, že nelze tak jednoznačně tvrdit, že to nemůže být (za určitých podmínek) pravda.
-
Ona to zdaleka neni jenom predikce skoku. Devirtualizace metod, odstraneni nepotrebnych zamku, vyhozeni nedosazitelneho kodu...
-
Přes java concurent locks se dostaneš na lepší hodnoty, ale ani náhodou na hodnoty dobré, rozhodně se nedá spolehnout, že reakce na událost přijde řekněme v předem přesně definované době. Zkus si to!
Vsak taky, kdyz chces v Jave (a nejspis i cemkoli jinem) psat low latency aplikaci, abys mel zajistene reakce do urcite doby, tak nenasekas 5*n threadu a nepustis si je nadivoko.
Poslechni si, jak se to dela:
http://www.dagblog.cz/2013/12/cz-podcast-90-psani-low-latency.html
-
http://stackoverflow.com/questions/2684364/why-arent-programs-written-in-assembly-more-often
Hellо, I am a compiler.
I just scanned thousands of lines of code while you were reading this sentence. I browsed through millions of possibilities of optimizing a single line of yours using hundreds of different optimization techniques based on a vast amount of academic research that you would spend years getting at. I won't feel any embarrassment, not even a slight ick, when I convert a three-line loop to thousands of instructions just to make it faster. I have no shame to go to great lengths of optimization or to do the dirtiest tricks. And if you don't want me to, maybe for a day or two, I'll behave and do it the way you like. I can transform the methods I'm using whenever you want, without even changing a single line of your code. I can even show you how your code would look in assembly, on different processor architectures and different operating systems and in different assembly conventions if you'd like. Yes, all in seconds. Because, you know, I can; and you know, you can't.
P.S. Oh, by the way you weren't using half of the code you wrote. I did you a favor and threw it away.
-
Ve žvanění blbostí jste tu momentálně přeborníkem vy. Když JIT nějaký kód přeloží do nativního, tak už nad ním dál nepřemýšlí a ten kód běží stejně rychle, jako by vylezl z jiného kompilátoru. Zrovna predikce větvení je věc, ve které se kompilátory snaží procesorům pomoci - aby se procesor trefil správně, protože když se netrefí, je to drahé. JIT logicky může mít víc informací a může tedy přeložit kód tak, aby byl procesor úspěšnější. Vybrat si jeden okrajový případ z miliard používanějších a dokazovat na něm něco, co nijak nesouvisí s tématem diskuse, to taky nebyla šťastná volba.
Ono vůbec měřit rychlost aplikace tím, jak rychle procesor přežvejká nějaký kus kódu, je dnes úplně mimo. V drtivé většině použití to závisí na něčem úplně jiném. V tom zbytku, tam, kde záleží na výpočetním výkonu, zase ve velkém množství případů vůbec nejde o to, co počítá CPU, ale jak efektivní je specializovaný kód pouštěný třeba na GPU. A vtom malinkém zbytečku jsou pak specializované jednoúčelové aplikace, kde opravdu záleží na rychlosti provádění kousku nativního kódu.
-
Že zrovna vy nechápete, že JAVA není programovací jazyk vhodný pro psaní realtimových aplikací, bych rozhodně nečekal.
Doufám, že až pojedu autem, nebude tam brzdný systém od vás napsaný v Java.
ICC dělá samozřejmě také řadu optimalizací, měl jsem tu smůlu, že jsme se o něco takového v Java už pokoušeli, ale s chutí do toho, udělej software pro řízení lokomotivy a zabij si pár set lidí, když ti to udělá radost a nikdo z lidí, které mám rád, při tom nezemře, tak si to užij.
Galgonek
Za určitých okolností bys mohl být i prezident USA, to ale neznamená, že někdy nastanou.
Za určitých okolností bys dokázal sbalit i tisíc dívek za den, to ale neznamená, že sbalíš víc než jednu nalitou pipinu za měsíc.
Za určitých okolností může být program v Java rychlejší, než program v C, to ale neznamená ani to, že to tak bude vždy.
2 Nekola
Java není jazyk pro realtimové aplikace, ať si už myslíš, co chceš.
-
poslechni si ten podcast a PAK pokračuj
-
Za určitých okolností
Použil jsem schválně slovo podmínka. Takovou podmínkou například je, že aplikace běží dostatečně dlouho.
-
Že zrovna vy nechápete, že JAVA není programovací jazyk vhodný pro psaní realtimových aplikací, bych rozhodně nečekal.
Doufám, že až pojedu autem, nebude tam brzdný systém od vás napsaný v Java.
ICC dělá samozřejmě také řadu optimalizací, měl jsem tu smůlu, že jsme se o něco takového v Java už pokoušeli, ale s chutí do toho, udělej software pro řízení lokomotivy a zabij si pár set lidí, když ti to udělá radost a nikdo z lidí, které mám rád, při tom nezemře, tak si to užij.
...
<grammar-nazi>
Proč píšete a skloňujete Javu, jako by to byla zkratka?
</grammar-nazi>
-
Že zrovna vy nechápete, že JAVA není programovací jazyk vhodný pro psaní realtimových aplikací, bych rozhodně nečekal.
Za prvé, otázka je, kdo tady čemu říká realtimeové aplikace. Pro opravdové realtimeové aplikace je nepoužitelný i Linux. Pro opravdové realtimeové aplikace není důležitá rychlost (ta se naopak musí obětovat), ale garantovaná doba odezvy. Takže se tady asi nebavíme o opravdových realtimeových aplikacích.
Za druhé, Java jako jazyk se pro realtimeové aplikace použít dá. Akorát to samozřejmě nemůžete spouštět pod desktopovou nebo serverovou JVM, ale musíte použít realtimeovou JVM.
To, že jste se o něco pokoušel, a nepodařilo se vám to, nedokazuje, že to nejde.
Já doufám, že až pojedu autem, nebude tam brzdný systém od vás běžící pod Linuxem.
-
Je vidět, že o tom víš prd a vaříš jen z vody. Není skok jako skok, jsou short a far jumpy, mezi nimi je zásadní rozdíl a moderní procesory si už řadu let dokáží poradit s predikcí skoků velmi dobře, nastuduj si to například zde http://www.agner.org/optimize/microarchitecture.pdf Velmi nás unavuje číst tvé nekompetentní příspěvky psané stylem: "Něco napíšu, protože myslím, že dnes z palce vycucám něco fakt zázračného!".
Ukludni sa prosim ta, ta tvoja povysenost sa neda v diskusii zniest, tebe musel niekto asi stupit na otlaky ze si taky hnusny.
-
Ahoj,
existuje pro Linux jazyk podobný C#?
- Překladač z toho musí udělat nejlépe strojový kód, potřebuji to na realtime aplikaci.
- Java je sice pěkná a vyhovovala by, ale je na to příliš, příliš, pomalá.
V zásadě se nechci start o alokaci paměti, mimo jiné a musí to být opravdu exra rychlé.
Tak presne tyto pozadavky splnuje jazyk D. (http://dlang.org/)
Ale jak uz zde uvedli ostatni i v Jave se daji psat realtime aplikace a dokonce i aplikace co jsou "extra rychle"
-
Že se s tim Bla ještě máte náladu bavit....
nicméně, Bla, proč teda např. Sun i IBM vyhazují za realtime javu peníze, když je to taková blbina?
http://en.wikipedia.org/wiki/Real_time_Java
A taky si nastuduj např.
https://www.google.cz/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&ved=0CFoQFjAE&url=https%3A%2F%2Fwww.cs.tcd.ie%2FDavid.Gregg%2Fpapers%2Ftoplas05.pdf&ei=H_naUrn1BZK1hAfbzoHICg&usg=AFQjCNEAJEBOIHwvi-zhjE23edLWHJ9U_A&sig2=dH2ZDVJYkyo9lgp8TM8E_g&bvm=bv.59568121,d.ZG4&cad=rja
-
Ono na tom kupodivu neni C++ v open source projektech tak spatne, jak to nekdy muze (hlavne v diskuzich :-) vypadat.
V souvislosti s tim me pobavilo tohle: http://www.youtube.com/watch?v=ON0A1dsQOV0 (http://www.youtube.com/watch?v=ON0A1dsQOV0) Takze Linus Torvalds je nucen pouzivat C++! :-)
-
Logik: jeste bych dodal knihovnu Javolution, kdyby si Bla stezoval na synchronizovane metody
-
Ona to zdaleka neni jenom predikce skoku. Devirtualizace metod, odstraneni nepotrebnych zamku, vyhozeni nedosazitelneho kodu...
A co z toho plyne? Špatně napsaný kód v javě může být rychlejší než špatně napsaný kód v c. Nic víc. Nejlepší informaci o tom, co se bude dít, má autor kódu. Pokud ji neumí nebo nechce použít, měl by místo matlání kódu jít dělat něco užitečného.
-
Nejlepší informaci o tom, co se bude dít, má autor kódu. Pokud ji neumí nebo nechce použít, měl by místo matlání kódu jít dělat něco užitečného.
Mě by zajímalo, jakou informaci o tom, co se bude dít, má autor u tohoto kódu:
for (;;)
{
if (getchar() < 'A')
{
printf("neni pismeno\n");
}
else
{
printf("je pismeno\n");
}
}
Nebude o těch datech třeba vědět víc java kompilátor, který může udělat runtime branch optimalizaci podle dat, které to skutečně zpracovává?
-
A co z toho plyne? Špatně napsaný kód v javě může být rychlejší než špatně napsaný kód v c. Nic víc. Nejlepší informaci o tom, co se bude dít, má autor kódu. Pokud ji neumí nebo nechce použít, měl by místo matlání kódu jít dělat něco užitečného.
Trochu fantazie :-)
class Foo
{
static final boolean cnd = initCnd();
void bar() {
if(cnd) {
// větev A
} else {
// větev B
}
}
Jedna z těch větví (A nebo B) bude nedosažitelná, ale která to bude, to se dozvíš až po spuštění programu. Stejně tak je možné volat metodu bar() nevirtuálně, pokud se od Foo v programu nedědí. Pokud je ale například Foo součást knihovny, tak tuhle informaci autor kódu prostě nemá. Nevím, zda zrovna tyhle optimalizace JIT dělá, ale rozhodně nejdou udělat jen ze znalosti kódu.
-
Nejlepší informaci o tom, co se bude dít, má autor kódu. Pokud ji neumí nebo nechce použít, měl by místo matlání kódu jít dělat něco užitečného.
Nesmysl. Software se často používá úplně jinak, než autor zamýšlel. I když se používá tak, jak bylo zamýšleno, používá se různým způsobem.
Proč by třeba Linuxové jádro mělo tolik konfiguračních voleb, když podle vás mají jeho autoři nejlepší informace, co se bude dít? Když už jsme u jádra, tam bylo také dost případů, kdy autoři ručně vynucovali nebo zakazovali nějakou optimalizaci, která byla špatně a kompilátor by to udělal správně. Kdyby všichni ti matlalové kódu šli dělat něco jiného, zbyl byste na celém světě na programování jen vy a možná pár dalších supermanů, kteří programují tak, že mají otevřeno několik desítek terminálů, a tam píšou rovnou nativní instrukce optimalizované pro konkrétní procesor. Jak byste zvládli všechen ten software napsat?
-
Ono na tom kupodivu neni C++ v open source projektech tak spatne, jak to nekdy muze (hlavne v diskuzich :-) vypadat.
V souvislosti s tim me pobavilo tohle: http://www.youtube.com/watch?v=ON0A1dsQOV0 (http://www.youtube.com/watch?v=ON0A1dsQOV0) Takze Linus Torvalds je nucen pouzivat C++! :-)
Tam jsou i dalsi dobre hlody, napriklad i okolo 12:40 - "written and designed by monkeys on crack...... a lot of crack" :-)
-
A co z toho plyne? Špatně napsaný kód v javě může být rychlejší než špatně napsaný kód v c. Nic víc. Nejlepší informaci o tom, co se bude dít, má autor kódu. Pokud ji neumí nebo nechce použít, měl by místo matlání kódu jít dělat něco užitečného.
Tvrdis, ze "dobry" autor kodu ma sanci predem vedet, zda bude mit nehjake rozhrani vic implementaci? Nebo ze nema pouzivat rozhrani? Nebo neco jineho?
-
Velmi pochybuji o zázračných schopnostech urychlení kódu JIT strojem, dle mého názoru to je blbost.
Názory made by Galgonek není nutné číst, na to jsem přišel už před delší dobou a nyní mě potěšilo, že nejsem sám, kdo to tak vidí.
Ale odchýlil jsem se od toho, co jsem chtěl napsat, jediný, kdo tady tomu opravdu rozumí, je Tišňovský.
Až Tišňovský napíše, že JIT poskytuje takové optimalizace, které obecně překonávají rychlost stejně dobrého kódu napsaného v C++, nezačnu tomu hned věřit, ale prohlídnu si jeho argumenty. Do té doby, pánové, se připojím k Bla a budu Vám dělat opozici.
-
Já vím, že pro linuxáka je to urážka něco takového vytahovat, ale co takhle jazyk
C++
myslim ze medzi Linuxakmi je prave C++ omnoho preferovanejsi ako Java. Java je platforma pre "pojedacov kolacov" a lepicov databazovych enterprise apps, intranetov a bastlenie server side casti weboviek.
-
[...]
A nějaký relevantní argument by nebyl? Nehledě na to, že když si pořádně prečteš, na co jsem tu reagoval a co jsem psal, tak zjistíš, že zde netvrdím, že je Java díky JITu rychlejší než C, ale jen to, že nelze jen tak tvrdit opak, protože JIT může provádět optimalizace, které normální kompilátor dělat nemůže. Což tu bylo zatím "vyvraceno" hlavně jen urážkami.
-
Až Tišňovský napíše, že JIT poskytuje takové optimalizace, které obecně překonávají rychlost stejně dobrého kódu napsaného v C++, nezačnu tomu hned věřit, ale prohlídnu si jeho argumenty.
Nikdo tady nepíše o tom, že by nějaké optimalizace obecně překonávaly nějakou rychlost. Na vyvrácení tvrzení, že Java musí být vždy pomalejší, úplně stačí, když ty optimalizace budu lepší v některých případech.
Jinak od pana Tišnovského zrovna vychází na Rootu seriál o JVM, kde se optimalizacím věnoval. A byly tam i příklady srovnání kódu z JIT a z gcc.
-
Jinak od pana Tišnovského zrovna vychází na Rootu seriál o JVM, kde se optimalizacím věnoval. A byly tam i příklady srovnání kódu z JIT a z gcc.
Ano, to vím a proto říkám, že je asi jediný schopný toto tvrzení vyvrátit a nebo potvrdit.
Ten seriál nečtu a proto mi tyto testy unikly, Javu už delší dobu nepoužívám, ale nemohl jsem si nevšimnout úrovně jeho znalostí a hloubky, do které to probírá.
Hovoříme tu o tomto nesmyslu:
To právě není tak jisté. JIT kompilátor může mít třeba k dispozici informace, které C kompilátor nemá, a díky tomu může být pak rychlejší.
Tvrdí, že Java potažmo libovolný JIT je rychlejší než C, protože má víc informací než C kompilátor.
Naprostá většina z Vás se tohoto jeho názoru zastává.
Já se k Vám nemohu připojit, ano, JIT může vyhodit určitou část kódu, ale tu může vyhodit i překladač C a Java už z principu nemůže být rychlejší než dobrý C kód.
-
Hovoříme tu o tomto nesmyslu:
To právě není tak jisté. JIT kompilátor může mít třeba k dispozici informace, které C kompilátor nemá, a díky tomu může být pak rychlejší.
Tam se píše může mít/může být a ne že má/je. A nikdo tady dosud neukázal, že tyto informace nejde využít. Vždyť díky nim jde například z kódu odstranit spoustu skoků, pokud se ukáže, že už tam být nemusí.
JIT může vyhodit určitou část kódu, ale tu může vyhodit i překladač C a Java už z principu nemůže být rychlejší než dobrý C kód.
Díval ses na ten můj příklad s třídou Foo? Tam máš příklad kódu, který je možné vyhodit, ale určitě by nemohl být vyhozen klasickými překladači.
-
Java už z principu nemůže být rychlejší než dobrý C kód.
Mohl bys ten "princip" lépe popsat? Java totiž taky překládá do nativního kódu a má k dispozici víc informací, než které má C překladač.
-
Java už z principu nemůže být rychlejší než dobrý C kód.
Mohl bys ten "princip" lépe popsat? Java totiž taky překládá do nativního kódu a má k dispozici víc informací, než které má C překladač.
Třeba je ten princip to, že java překládá až za běhu, takže nějaký čas zabije tím překladem a optimalizací běhu.
-
Nejlepší informaci o tom, co se bude dít, má autor kódu. Pokud ji neumí nebo nechce použít, měl by místo matlání kódu jít dělat něco užitečného.
Nesmysl. Software se často používá úplně jinak, než autor zamýšlel. I když se používá tak, jak bylo zamýšleno, používá se různým způsobem.
Proč by třeba Linuxové jádro mělo tolik konfiguračních voleb, když podle vás mají jeho autoři nejlepší informace, co se bude dít? Když už jsme u jádra, tam bylo také dost případů, kdy autoři ručně vynucovali nebo zakazovali nějakou optimalizaci, která byla špatně a kompilátor by to udělal správně. Kdyby všichni ti matlalové kódu šli dělat něco jiného, zbyl byste na celém světě na programování jen vy a možná pár dalších supermanů, kteří programují tak, že mají otevřeno několik desítek terminálů, a tam píšou rovnou nativní instrukce optimalizované pro konkrétní procesor. Jak byste zvládli všechen ten software napsat?
Z tohohle blábolení jsem si odnesl jenom to, že linuxové jádro se používá jinak, než autoři zamýšleli ;D
-
Třeba je ten princip to, že java překládá až za běhu, takže nějaký čas zabije tím překladem a optimalizací běhu.
Ale to nedokazuje, že java nemůže být rychlejší. Co když java stráví na optimalizaci 1 sekundu a 2x zrychlý kód, který normálně běží 100 sekund?
Tady někdo tvrdí, že C předkladač bude vždy rychlejší než java překladač, ale C překladač nemá žádnou konkurenční výhodu, protože dělá to stejné jako java překladač s menším množstvím informací.
-
Mě by zajímalo, jakou informaci o tom, co se bude dít, má autor u tohoto kódu:
for (;;)
{
if (getchar() < 'A')
{
printf("neni pismeno\n");
}
else
{
printf("je pismeno\n");
}
}
Nebude o těch datech třeba vědět víc java kompilátor, který může udělat runtime branch optimalizaci podle dat, které to skutečně zpracovává?
Místo těhle zábavných a nesmyslných útržků kódu zkuste přijít s kódem, který opravdu běží v javě rychleji než jeho ekvivalent v c. Pořád tu operujete s tím, že to jde, tak přece nemůže být až takový problém to na něčem malém demonstrovat. Nebo ne?
-
Místo těhle zábavných a nesmyslných útržků kódu zkuste přijít s kódem, který opravdu běží v javě rychleji než jeho ekvivalent v c. Pořád tu operujete s tím, že to jde, tak přece nemůže být až takový problém to na něčem malém demonstrovat. Nebo ne?
http://paulbuchheit.blogspot.cz/2007/06/java-is-faster-than-c.html
-
Třeba je ten princip to, že java překládá až za běhu, takže nějaký čas zabije tím překladem a optimalizací běhu.
Ale to nedokazuje, že java nemůže být rychlejší. Co když java stráví na optimalizaci 1 sekundu a 2x zrychlý kód, který normálně běží 100 sekund?
Tady někdo tvrdí, že C předkladač bude vždy rychlejší než java překladač, ale C překladač nemá žádnou konkurenční výhodu, protože dělá to stejné jako java překladač s menším množstvím informací.
Ale nedokazuje ani opak. Toto sú to len teoretické bláboly a reklamné business keci. Závidím vám vašu naivitu chlapci. Sám programujem v .NET a už pre 15timi rokmi som počúval ako JIT kompilácia urýchli beh .NET apps ako budú rýchlejšie jak natívne - teória pekná, ale v praxi to nefunguje. Prečo?
-
Třeba je ten princip to, že java překládá až za běhu, takže nějaký čas zabije tím překladem a optimalizací běhu.
A startom VM ;-)
Pri dlhobeziacich aplikaciach sa to IMHO vyvazi.
teória pekná, ale v praxi to nefunguje. Prečo?
Asi nik netvrdi, ze .NET/Java predbehne C, ale sa k nemu zacne blizit vymenou za vyvojarov komfort.
Inak co je vo vasom svete "pomala aplikacia"?
-
Tvrdí, že Java potažmo libovolný JIT je rychlejší než C, protože má víc informací než C kompilátor.
Netvrdí. Tvrdí, že zpomalení způsobené překladem bajtkódu do nativního kódu může být kompenzováno nebo dokonce překonáno tím, že kód vytvořený JIT kompilátorem může být efektivnější, než kód vytvořený statickým kompilátorem při překladu ze zdrojového kódu.
Já se k Vám nemohu připojit, ano, JIT může vyhodit určitou část kódu, ale tu může vyhodit i překladač C a Java už z principu nemůže být rychlejší než dobrý C kód.
Jednak JIT může překládat kód pro platformu, na které právě běží. C kód je často překládán pro nějakou obecnou platformu, aby nebylo nutné distribuovat spoustu variant binárek. Za druhé, JIT má informace z běhu programu, které C kompilátor nemá. V případě C se to obchází tím, že se kód spustí v profileru, používá se typickým způsobem a podle toho se upraví zdrojový kód. Jenže typické způsoby použití se od sebe mohou lišit. Takže efektivní nativní kód jedné aplikace se může lišit podle způsobu použití. Opět by bylo možné přeložit C s různými optimalizacemi a uživatel by si vybral – ale jednak nikdo nemá čas něco takového vyrábět, jednak uživatelé si nechtějí z něčeho takového vybírat.
V teoretické rovině máte pravdu, že JIT nemůže být rychlejší, než ten nejefektivnější kód v C. Přinejhorším se v tom C dá naprogramovat vlastní VM s vlastním JIT kompilátorem. Prakticky se ale něco takového dělá jen velmi výjimečně a je snaha tyhle věci zobecňovat a dostat je už do vývojářských nástrojů (právě ty různé VM).
Ono porovnávat rychlost na CPU nemá moc smysl, ale když už se to dělá, porovnává se běžně napsaný kód jedním způsobem a druhým způsobem. Tedy žádná vlastní VM s JIT v C a žádné JNI v Javě. A v téhle praktické rovině platí, že zátěž, kterou způsobuje překlad bajtkódu, je oproti ostatním vlivům zanedbatelná.
-
tak jsem zusil jak je ta Java rychlejší, když ví víc, než programátor, a nějak to nevyšlo
#include <stdio.h>
int main(int argc, char **argv) {
int cnd = 0;
int i;
if (argc == 2)cnd = 1;
int counter = 0;
for (i = 0; i < 2000000000; i++) {
if (cnd) {
counter++;
} else {
counter--;
}
}
printf("%d\n", counter);
} public class JavaApplication1 {
/**
* @param args the command line arguments
*/
public static void main(String[] args) {
// TODO code application logic here
boolean upCounting=false;
if(args.length==2)upCounting=true;
final boolean cnd = upCounting;
int counter = 0;
for (int i = 0; i < 2000000000; i++) {
if (cnd) {
counter++;
} else {
counter--;
}
}
System.out.println(counter);
}
}
C jsem přeložil gcc -Os -o pok1 pok1.c a javu za mě nějak zpatlalo NetBeans.
Výsleldek je real 0m4.272s pro javu a real 0m2.078s pro C. Takže C je 2-krát rychlejší. Java mě pozitivně překvapila, čekal jsem, že na tom bude mnohem hůř. Jestli je nějaká možnost, jak javu donutit ještě více optimalizovat, tak sem s ní.
-
Místo těhle zábavných a nesmyslných útržků kódu zkuste přijít s kódem, který opravdu běží v javě rychleji než jeho ekvivalent v c. Pořád tu operujete s tím, že to jde, tak přece nemůže být až takový problém to na něčem malém demonstrovat. Nebo ne?
http://paulbuchheit.blogspot.cz/2007/06/java-is-faster-than-c.html
Supr, takže java 6,875 versus c 6.12, to mi nepřijde rychlejší. Kromě toho: "In the computer industry, there are three kinds of lies: lies, damn lies, and benchmarks." To je ten třetí případ.
-
tak jsem zusil jak je ta Java rychlejší, když ví víc, než programátor, a nějak to nevyšlo
#include <stdio.h>
Výsleldek je [b]real 0m4.272s [/b] pro javu a [b]real 0m2.078s[/b] pro C. Takže C je 2-krát rychlejší. Java mě pozitivně překvapila, čekal jsem, že na tom bude mnohem hůř. Jestli je nějaká možnost, jak javu donutit ještě více optimalizovat, tak sem s ní.
[/quote]
Neukazuje to jen, ze JVM chvili trva, nez nastartuje?
-
Supr, takže java 6,875 versus c 6.12, to mi nepřijde rychlejší. Kromě toho: "In the computer industry, there are three kinds of lies: lies, damn lies, and benchmarks." To je ten třetí případ.
Že nerozumíš psanému textu, to už není můj problém.
-
Místo těhle zábavných a nesmyslných útržků kódu zkuste přijít s kódem, který opravdu běží v javě rychleji než jeho ekvivalent v c. Pořád tu operujete s tím, že to jde, tak přece nemůže být až takový problém to na něčem malém demonstrovat. Nebo ne?
http://paulbuchheit.blogspot.cz/2007/06/java-is-faster-than-c.html
U mě je největší rozdíl mezi tím, jestli se výsledek vykresluje, nebo jen počítají * a mezery. Při výpisu trval běh desítky sekund a byl ovlivněný systémovým voláním. Při počítání * a ' ' je u mě C rychlejší i bez optimalizace na platformu (gcc -O3 -o pok1 pok1.c). Java Elapsed 1.651 a C Elapsed 1.49
-
U mě je největší rozdíl mezi tím, jestli se výsledek vykresluje, nebo jen počítají * a mezery. Při výpisu trval běh desítky sekund a byl ovlivněný systémovým voláním. Při počítání * a ' ' je u mě C rychlejší i bez optimalizace na platformu (gcc -O3 -o pok1 pok1.c). Java Elapsed 1.651 a C Elapsed 1.49
Také jsem si to přiohnul, aby to moc neprintilo:
Java Elapsed 1.045
C/gcc Elapsed 0.96
C/icc Elapsed 0.90
-
porovnavanie na hracickovych programoch, co bezia sekundu, srsly?
jit sa tam ani nezahreje
-
Java Elapsed 1.045
C/gcc Elapsed 0.96
C/icc Elapsed 0.90
Takže rozdíl mezi Javou a C je v tomto případě skoro stejný, jako rozdíl mezi dvěma kompilátory C. Na tom je vidět, jak nesmyslné je porovnávat programovací jazyky z hlediska rychlosti spuštěného kódu.
-
Napriklad u me je rozdil mezi Java kodem a kodem napsanem v jazyce D vic nez 100% ve prospech jazyka D.
Takze porovnavat jazyky dle rychlosti kodu smysl urcite ma. Teda ono spis jde o porvnani jednotlivych implementaci kompilatoru ci JIT (prece jen samotny jazyk nezarucuje ze bude vysledny program nezet rychleji :)).
Kazdopadne na takto trivialnim priklade se toho moc nepozna. Napriklad u nas v praci jsme prepisovali kod s PHP do jazyka D. A ackoliv ruzne mikrobenchmarky ukazovali ze jazyk D je neporovnatelne rychlejsi, tak realne zrychleni bylo mozna jen tak 3x az 5x. Duvod je prosty, samotny problem rychlosti aplikace je zcela jinde (databazove operace a zpusob jak je aplikcae navrzena - pro kazdy soubor ktery se ma zpracovat se spousti novy program).
-
jit sa tam ani nezahreje
Je to čas až toho třetího běhu a upavil jsem CompileThreshold, aby si JIT zahrál. Ale jinak jo, chtělo by to větší příklad.
-
Java Elapsed 1.045
C/gcc Elapsed 0.96
C/icc Elapsed 0.90
Takže rozdíl mezi Javou a C je v tomto případě skoro stejný, jako rozdíl mezi dvěma kompilátory C. Na tom je vidět, jak nesmyslné je porovnávat programovací jazyky z hlediska rychlosti spuštěného kódu.
V tomto pripade bych zduraznil. JVM se dobre optimalizuji prave takove jednoduche smycky s par vyrazama (aritmetika, jednoduche operace s retezci). Daleko horsi to je u strukturovanejsiho nehomogenniho kodu s hlubokymi vnorenimi volanimi. Jinymi slovy tyhle mikrobenchmarky nic nevypovidaji o rychlosti behu "realnych" aplikaci. Puvodni autor zvolil teda hodne spatny priklad pro porovnani.
-
V tomto pripade bych zduraznil. JVM se dobre optimalizuji prave takove jednoduche smycky s par vyrazama (aritmetika, jednoduche operace s retezci). Daleko horsi to je u strukturovanejsiho nehomogenniho kodu s hlubokymi vnorenimi volanimi. Jinymi slovy tyhle mikrobenchmarky nic nevypovidaji o rychlosti behu "realnych" aplikaci. Puvodni autor zvolil teda hodne spatny priklad pro porovnani.
Jako benchmark jazyků je to rozhodně špatný příklad. Prohodit ten if a smyčku může kompilátor klidně na základě analýzy kódu, k tomu běhové informace nepotřebuje. A vůbec bych se nedivil, kdyby třeba icc tu smyčku spočítalo už v době kompilace a vygenerovalo jenom if se dvěma konstantama.
Spíš to ukazuje, že ten strašák "musí nastartovat JVM a přeložit kód" je nesmysl. A docela by mne zajímalo, co se vlastně změřilo - třeba jak moc by ta čísla byla jiná, kdyby se ta konstanta vydělila dvěma nebo by se naopak načítala dvě počítadla najednou.
-
tak jsem zusil jak je ta Java rychlejší, když ví víc, než programátor, a nějak to nevyšlo
#include <stdio.h>
int main(int argc, char **argv) {
int cnd = 0;
int i;
if (argc == 2)cnd = 1;
int counter = 0;
for (i = 0; i < 2000000000; i++) {
if (cnd) {
counter++;
} else {
counter--;
}
}
printf("%d\n", counter);
} public class JavaApplication1 {
/**
* @param args the command line arguments
*/
public static void main(String[] args) {
// TODO code application logic here
boolean upCounting=false;
if(args.length==2)upCounting=true;
final boolean cnd = upCounting;
int counter = 0;
for (int i = 0; i < 2000000000; i++) {
if (cnd) {
counter++;
} else {
counter--;
}
}
System.out.println(counter);
}
}
C jsem přeložil gcc -Os -o pok1 pok1.c a javu za mě nějak zpatlalo NetBeans.
Výsleldek je real 0m4.272s pro javu a real 0m2.078s pro C. Takže C je 2-krát rychlejší. Java mě pozitivně překvapila, čekal jsem, že na tom bude mnohem hůř. Jestli je nějaká možnost, jak javu donutit ještě více optimalizovat, tak sem s ní.
Tak tady skutečně Java příjemně překvapila, když si uvědomíte, že v čase je zahrnuto i spuštění JVM, JIT atd.
Jinak pro informaci do další diskuze.
1) Javovský bytekód Tvého příkladu vypadá následovně:
http://fpaste.org/70140/13902523/
2) Takto to vypadá po JITování client JVM (i386, tedy 32bit):
http://fpaste.org/70141/02523841/
3) A takto, když se na to pustí server JVM (trošku pomícháno s println...)
http://fpaste.org/70142/39025240/
Jen poznámka na okraj - JIT zde neprovedl žádné optimalizace, protože celá smyčka proběhla jen jednou. Kdyby byla umístěna do samostatné metody a volala se vícekrát, tak se JIT trošku zapotí a vygeneruje odlišný kód... lze snadno odzkoušet.
-
Tak tady skutečně Java příjemně překvapila, když si uvědomíte, že v čase je zahrnuto i spuštění JVM, JIT atd.
ono je dost mozne, ze JVM je uz spustena (spolu s NetBeansom), co moze "deformovat" vysledky.
-
Dovolim si nesouhlasit - pokud napisu aplikaci v OS DOS like, tak se na x86 da realtime aplikace napsat. Pokud se mylim, prosim o zduvodneni - drzme se OS, ktery jsem uvedl a pro priklad uvedme aplikaci, ktera bude snimat data z detektoru, zanalyzuje data a dle vyhodnoceni provede urcitou cinnost - napr. zaslani TCP paketu (priklad berte s rezervou ;))
Tohle není realtime aplikace. Realtime je třeba ABS v autě, kde se řeší úlohy typu snímám otáčky kola a když zjistím, že se to netočí dost rychle, musím do 10 ms (zaručeně!) sepnout čerpadlo ABS, jinak se stane něco nehezkého. V tom DOSu je třeba ovladač myši, který si občas vezme řízení v přerušení. Když nedokážu zaručit, že to bude do 10 ms (včetně všech ostatních věcí, které se mohou stát), tak DOS použít nemůžu.
no jeste me napadlo prepsat si preruseni svyma procedurama, ale precejen pouziti jednocipu by bylo nejspis rychlejsi i levnejsi :)
-
Jo, je to sranda s těmi překladači. Vzal jsem 1000 vektorů délky 300 (3*300 double) a spočítal RMSD každý s každým (1000*1000). Beželo to čtyřikrát, aby se JIT mohl "zahřát". Počítal se čas posledního běhu:
Java: 14.984s
C++/icc: 5.58s
C++/g++: 2.64s
-
Java: 14.984s
C++/icc: 5.58s
C++/g++: 2.64s
Tak jsem si s tou Javou ještě trochu pohrál a dostal jsem z ní čas 5.893s.
-
5.188s :)
-
Beželo to čtyřikrát, aby se JIT mohl "zahřát".
To pocitas nieco zle alebo je niekde chyba. Odporucam bezat citlive kusy kodu tak 20 000 krat, aby to zacalo davat vyznam.
-
Beželo to čtyřikrát, aby se JIT mohl "zahřát".
Čtyřikrát v rámci jednoho procesu? Jak to pak měříte, jak k tomu připočítáte čas startu JVM a kompilace? Pokud to bylo čtyřikrát spuštěno z příkazového řádku a tedy čtyři různé procesy, JIT se nijak „nezahřeje“ – při každém běhu běží znova od začátku. JIT si neukládá žádné informace mezi jednotlivými spuštěními aplikace, každé spuštění aplikace je pro něj poprvé. Opakované spuštění pomůže nejvýš tomu, že OS načte potřebné soubory do cache. Ale k tomu by mělo stačit spustit to dvakrát. A dělá se to tak u všech testů a první se neměří, protože doba načítání z disku nás zpravidla nezajímá. Nebo je možné to spouštět rovnou z RAMdisku.
-
To pocitas nieco zle alebo je niekde chyba. Odporucam bezat citlive kusy kodu tak 20 000 krat, aby to zacalo davat vyznam.
Čemu říkáš citlivý kus kódu? RMSD výpočet proběhl 3000000 krát, než se začalo něco měřit.
-
[...]
Zase až tak mne nepodceňuj. Počítalo se to podobně jako u toho Mandelbrota. Viz:
http://paulbuchheit.blogspot.cz/2007/06/java-is-faster-than-c.html
-
Zase až tak mne nepodceňuj. Počítalo se to podobně jako u toho Mandelbrota. Viz:
Takže se měří jen doba provádění toho kódu, start JVM v tom započítán není a kompilace nejspíš také ne. To je řekl bych dost podstatné…
-
Jo, je to sranda s těmi překladači. Vzal jsem 1000 vektorů délky 300 (3*300 double) a spočítal RMSD každý s každým (1000*1000). Beželo to čtyřikrát, aby se JIT mohl "zahřát". Počítal se čas posledního běhu:
Java: 14.984s
C++/icc: 5.58s
C++/g++: 2.64s
Muzu poprosit o zdrojaky?:)
-
Takže se měří jen doba provádění toho kódu, start JVM v tom započítán není a kompilace nejspíš také ne. To je řekl bych dost podstatné…
Přesně tak, meří se jen provádění vlastního výpočtu, ale stejně je to u té C++ verze.
-
Muzu poprosit o zdrojaky?:)
Pošlu ti je na mail, pokud chceš.
-
Muzu poprosit o zdrojaky?:)
Pošlu ti je na mail, pokud chceš.
dik, shini@centrum.cz
-
dik
Máš je tam.
-
Jo, je to sranda s těmi překladači. Vzal jsem 1000 vektorů délky 300 (3*300 double) a spočítal RMSD každý s každým (1000*1000). Beželo to čtyřikrát, aby se JIT mohl "zahřát". Počítal se čas posledního běhu:
Java: 14.984s
C++/icc: 5.58s
C++/g++: 2.64s
No ja si vzal ten priklad Mandelbrot a jen minimalne jej upravil a vysledkem je ze
v jazyce Java to trva cca 1.148s
v jazyce D to trva : 0s
Tady se ukazuje jak snadno se da v benchmarcich fixovat. ;D
-
zde jsou ukazky kodu:
Jazyk D: http://pastebin.com/w7VaPYYj
Java: http://pastebin.com/ncuqtyZX
-
och, v tej jave tolko hovnokod.cz peral :-)
-
zde jsou ukazky kodu:
Jazyk D: http://pastebin.com/w7VaPYYj
Java: http://pastebin.com/ncuqtyZX
Tu konkatenaci řetězců máš udělánu hodně nevhodně. Tvá verze (metoda run) u mne běží 0.418s, pokud ale použiji StringBuffer, tak běží jen 0.043s. Pokud navíc do bufferu zapisuju po znacích (namísto jednoznakových řetězců), tak běží jen 0.036s.
-
jn, v tom java kodu je hodne prasecin. asi byl zamer to co nejvic zpomalit
-
To lepeni retezcu v Jave je zacatecnicka chyba. Na druhou stranu, nekdy tohle umi prekladac prehodit na pouziti StringBuilderu (tady od oka uz ne, na to je to dost slozite, ale nejsem si zdaleka jisty).
-
pokud ale použiji StringBuffer
Protože to bezpečně běží v jednom vlákně, je špatně použití i StringBufferu se zbytečnou synchronizací, správné je použít StringBuilder. Ostatně javac to sčítání řetězců na StringBuilder přeloží, akorát že tady bude každé sečtení vytvoření samostatného builderu, spojení a zahození builderu – protože to kompilátor neodhalí, že by se to dalo celé udělat s jedním.
-
zde jsou ukazky kodu:
Jazyk D: http://pastebin.com/w7VaPYYj
Java: http://pastebin.com/ncuqtyZX
Tu konkatenaci řetězců máš udělánu hodně nevhodně. Tvá verze (metoda run) u mne běží 0.418s, pokud ale použiji StringBuffer, tak běží jen 0.043s. Pokud navíc do bufferu zapisuju po znacích (namísto jednoznakových řetězců), tak běží jen 0.036s.
To ja samozrejme vim, to byl ucel ukazat ze vzdy se da napsat kod tak aby jeden jazyk bezel rychle a druhy pomalu. Napriklad v ruby existuji dva operatory pro zretezeni kde pouziti jednoho znamena lepsi vykon nez druheho.
Kazdopadne jde o to ze oba dva kody jsou napsany co mozna nejpodobneji. I v tom jazyku D je pouzit operator konkatenace a ne zadny StringBuilder atd.
-
och, v tej jave tolko hovnokod.cz peral :-)
Tak ten kod neni muj je to v podstate prevzate z jiz zminovane stranky
-
To lepeni retezcu v Jave je zacatecnicka chyba. Na druhou stranu, nekdy tohle umi prekladac prehodit na pouziti StringBuilderu (tady od oka uz ne, na to je to dost slozite, ale nejsem si zdaleka jisty).
No prave, tady jde o to ze spousta lidi tu tvrdi ze java muze delat spousty optimalizaci, ktere kompilovany kod nedela. Coz v tomto pripade nedela, samozrejme to ma asi sve duvody. Jde o to ze maloktery jazyk naz dokaze zachranit od toho aby kod bezel pomalu. Napriklad pokud bychom v kode pro jazyk D, nahradily static x = run3() za auto x = run3(), tak se kod pro D zpomali
-
Kazdopadne jde o to ze oba dva kody jsou napsany co mozna nejpodobneji. I v tom jazyku D je pouzit operator konkatenace a ne zadny StringBuilder atd.
Napsány co možná nejpodobněji syntakticky, ne však sémanticky.
-
Prave ze i semanticky, teda az na ten podvod v tom ze jazyk D cely ten kod provede uz v dobe kompilace. Ale jinak je to i semanticky stejne. Oba operatory konkatenace delaji totez. Pokud bych v Jave pouzil StringBuffer tak pak bych v D musel Pouzit Appender. V tom pripade bych dosahl toho ze je Java je jen o minimum (20ms) pomalejsi nez jazyk D. Coz ja prece nechci ;-).
-
Prave ze i semanticky, teda az na ten podvod v tom ze jazyk D cely ten kod provede uz v dobe kompilace. Ale jinak je to i semanticky stejne. Oba operatory konkatenace delaji totez. Pokud bych v Jave pouzil StringBuffer tak pak bych v D musel Pouzit Appender. V tom pripade bych dosahl toho ze je Java je jen o minimum (20ms) pomalejsi nez jazyk D. Coz ja prece nechci ;-).
Aha :)
-
Java: 14.984s
C++/icc: 5.58s
C++/g++: 2.64s
Tak jsem si s tou Javou ještě trochu pohrál a dostal jsem z ní čas 5.893s.
Tak jsem to díky Shiniho nápadu stáhnul až na 4.23s.
-
Bezva, vybavil bych všechny JIT stroje vlastním Galounkem a to bude panečku zrychlení! Kam se hrabe turbo!
PS: A teď to ty chytrolíne udělej jako plně generickou metodou!
-
zde jsou ukazky kodu:
Jazyk D: http://pastebin.com/w7VaPYYj
Java: http://pastebin.com/ncuqtyZX
Spojovani retezcu uz tady lidi resili, k tomu se nemusim vyjadrovat, ale jeste je lepsi merit cas pres System.getCurrentTimeMillis(), na co se drbat s nejakym zbytecnym Calendar. Nerikam, ze to usetri nejaky cas (samozrejme usetri, ale asi pod presnost prikazu time v tomto pripade), ale obecne je to pouziti kanonu na vrabce a ve vetsich aplikacich se tyto veci budou scitat, coz je jeden z duvodu, proc je java *povazovana* za pomalejsi jazyk.
-
Bezva, vybavil bych všechny JIT stroje vlastním Galounkem a to bude panečku zrychlení! Kam se hrabe turbo!
PS: A teď to ty chytrolíne udělej jako plně generickou metodou!
Má takovéto křiklounky (navíc ještě anonymní) root.cz zapotřebí?
-
No lol, jak vidím jméno, říkám si, to bude argument ad hominem a taky že je!
Galounku, rád bys vyháněl z fóra lidi, co?
-
No lol, jak vidím jméno, říkám si, to bude argument ad hominem a taky že je!
Galounku, rád bys vyháněl z fóra lidi, co?
Tak hlavne ze tento tvuj komentar je velmi prinosnej
-
No lol, jak vidím jméno
Tak se na něj příště koukni pořádně ;)
-
zde jsou ukazky kodu:
Jazyk D: http://pastebin.com/w7VaPYYj
Java: http://pastebin.com/ncuqtyZX
Spojovani retezcu uz tady lidi resili, k tomu se nemusim vyjadrovat, ale jeste je lepsi merit cas pres System.getCurrentTimeMillis(), na co se drbat s nejakym zbytecnym Calendar. Nerikam, ze to usetri nejaky cas (samozrejme usetri, ale asi pod presnost prikazu time v tomto pripade), ale obecne je to pouziti kanonu na vrabce a ve vetsich aplikacich se tyto veci budou scitat, coz je jeden z duvodu, proc je java *povazovana* za pomalejsi jazyk.
Čas prosím měřit aspoň přes System.nanoTime(). A pokud by člověk chtěl měřit opravdu přesně, tak lze použít MX beany. Použití Date je tady trochu WTF. :)