Vlákno názorů k článku Pohled pod kapotu JVM – přednosti a zápory využití JNI při optimalizacích od x86 - "takže se může stát, že nativní kód přeložený...
-
x86 (neregistrovaný)
"takže se může stát, že nativní kód přeložený optimalizujícím překladačem bude ve skutečnosti pomalejší než obdobný kód naprogramovaný v Javě a přeložený někdy poněkud naivním JIT překladačem."
1. Omlouvám se, pokud je to v článku uvedeno a já to přehlédnul. Ale, takový kód může být pomalejší ne kvůli kódu přeloženému např. z C++, ale díky režii volání JNI. Aneb mi z citované věty vyplývá, že samotný kód přeložený např. z C++ může být až tak pomalý.
2. Pokud budeme mít programátora píšícího naivní kód, neboť dnešní CPU to stejně upočítá tak rychle, že si uživatel nevšimne, pak JIT takový kód dokáže urychlit podstatně více než např. i icc. Tohle mi tam při srování "Java vs. C++" chybí uvést.
3. Pokud budeteme mít programátora (doopravdy, ne těch co si o o sobě jen myslí) píšícího skutečně efektivní kód, pak neznám jeden jediný důvod, proč by JIT mohl být rychlejší než třeba v článku zmíněné icc. Stručně řečeno, JIT v takovém případě hledat místo pro optimalizace tam, kde mu je dobrý programátor nenechal, takže už jenom tohle jeho hledání ho bude stát strojový čas, který nativní kód využije k dřívějšímu dokončení výpočtu.
Píšu to na základě dvou postřehů z praxe:
a) ještě jsem neviděl řádně napsanou aplikaci v Asm, C, C++, která by byla pomalejší než Java řešení (u špatně napsaných aplikací jsem to viděl, to ano)
b) celkem často se setkávám s programátory, kteří se pod dojmem vět, jako je ta citovaná v tomhle komentáři, rozhodli pro Javu, aby o pár let později zjistili, že to nebylo na základě platných faktů.
c) A když se pak takoví programátoři učí efektivně programovat v C++ (protože je to třeba), je to pro ně strašně bolestné. Ssnad horší, než kdyby se začínali teprve učit programovat - následek let osvojování se návyků z Javy.
-
Pavel TišnovskýZlatý podporovatelDobry den,
ad 1) myslel jsem to samozrejme vcetne rezie spojene s JNI, ten kod (treba dejme tomu fibonacci() ve treti verzi) je rychlejsi uz pri pohledu na generovany assembler.
ad 2) hodne zalezi na konkretnim algoritmu, dokonce jsme jeden algoritmus prepisovali z assembleru do cisteho ANSI C a ukazalo se, ze uz na starobylem gcc 2.x to je pri rozbaleni smycek rychlejsi nez puvodni asm, ktery ale nebyl napsany evidentne spatne, jen proste vychazel z toho, jak funguje 386/486 :)
ad 3) v tomto pripade JIT rychlejsi nebude, on je nekdy hodne naivni, i kdyz par veci dokaze diky RT informacim odstranit - typicky u smycek (jeste se k tomu budu muset vratit) a synchronizaci (to se v C zasekate dost rychle :)
-
Kolemjdoucí (neregistrovaný)
Diskuze rychlost Java versus okolní svět je zbytečná a nemá smysl se do ní pouštět. Zkušený programátor ASM dá do pěti minut na p*del GCC, Javu překoná se zavřenýma očima. Zkušený programátor GCC dá do deseti minut na p*del Javě.
Orientoval bych to tím směrem že buďme rádi že z Javy můžeme spouštět nativní kód, zdaleka ne v každém jazyku je tato možnost.
-
Pavel TišnovskýZlatý podporovatel
No ten clanek byl myslenej prave ve smyslu - "je fajn ze mame JNI, ale pozor na to, ze i kdyz algoritmus v gcc bude (skoro vzdy) rychlejsi, rezie JNI to nekdy muze zabit".
Jinak samozrejme souhlas, i kdyz dneska je to dost problem - ASM je uz hodne nizko na multijadrove masiny a C/C++ zase nemaji vhodne konstrukce pro vyuziti vektorovych instrukci (MMX, SSE2, nemluve o gfx. cipech: )
-
x86 (neregistrovaný)
Aha, tak to ano:)
Na multijádrove výpočty používám Intel Threading Building Blocks. Tam je někdy celkem zajímavé se podívat na kód v ASM, jak je použit. Ale kdo se má normálně zabývat např. latencí XADD a jejím efektem na cache:)
Moderní C++ překladače mají možnost autovektorizace. Snaží se překládat standardní C++ konstrukce vektorově a mohou během překladu vypsat, jak se jim to povedlo. Takže programátor může případně kód trošku poupravit, aby překladači pomohl "vidět".
A na gfx, holt OpenCL:)
Ale tohle už je offtopic...
-
Filip JirsákStříbrný podporovatelMyslím, že tyhle diskuse rychlost ASM vs C vs Java patří do minulého století. Dnes už těch případů, kdy rychlost aplikace záleží na instrukcích pro CPU, je velmi málo a je to pár specifických oblastí IT. Větší význam má např. zpracování na více procesorových jádrech a přepínání kontextů – a tam se ještě optimalizace v ASM teoreticky může uplatnit, C i Java už jsou na tom víceméně stejně, protože záleží na schopnostech optimalizátoru. No a zdaleka největší vliv na rychlost aplikace z pohledu uživatele mají věci jako architektura aplikace, síťová komunikace, uložení dat apod. A tam už na programovacím jazyce nebo běhovém prostředí nezáleží vůbec.
-
Kolemjdoucí (neregistrovaný)
Diskuzi na toto téma nemá cenu načínat. Vždy se dojde k závěru, že průměrný ASM programátor dá Javě na p*del kdykoliv a GCC také když se bude mírně snažit. Z hlediska business se shodneme, že ASM je out.
Na přepínání kontextů ASM nemá vliv žádný, cache-miss se nedá nijak obkecat.
-
Filip JirsákStříbrný podporovatel
Dá se (někdy) zařídit, aby k tomu cache-miss nedošlo – třeba tím, jak se data v paměti uspořádají. Což jde samozřejmě i v Javě nebo C, ale z ASM k tomu máte blíž.
Průměrný programátor v ASM Javu nepřekoná kdykoli, ale pouze ve velmi úzké skupině velmi krátkých a výpočetně náročných úloh.
-
Filip JirsákStříbrný podporovatel
Nemusí se ani dál vyvíjet produkt samotný, zamíchá tím i jen vývoj procesorů nebo překladačů...
-
Pavel TišnovskýZlatý podporovatel
A jeste dekuji za prinosny komentar.
Jeste dodam sice casto opakovanou, ale o to casteji :-) porusovanou zasadu - profilujte. Ja proste uz neverim tvrzeni, ze tento algoritmus je proste rychlejsi v C/Jave/Fortranu(numericke algoritmy) dokud neuvidim vystup z profileru, kde se treba ukaze nejaka uplna malickost, ktera cely vystup rozhodi. Coz me pripomina - zminovat se o profilingu casteji ;)
