Názory k článku Pohled pod kapotu JVM – přednosti a zápory využití JNI při optimalizacích

"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.

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.

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...

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.

Díky:)

Jj, profilovat je důležité. Osobně používám VTune Intel Amplifier, protože mi umožní vidět výkonostní countery přímo procesoru. Tj. countery, které překladač nemůže eliminovat jako mrtvý kód, jako tomu bývá u sw benchmarků.

Jeste by bylo zajimave vedle toho srovnat JNA. To mi prijde, ze ma mnohem lip navrzeny interface, ale pry je to na ukor rezie.

Ještě bych přihodil JNR. To by mělo mít podstatně menší režii než JNA a přitom by mělo být přinejmenším stejně snadno použitelné. A už existuje nějakou dobu, stojí za tím mj. chlapci od JRuby.