Vlákno názorů k článku Pohled pod kapotu JVM – přednosti a zápory využití JNI při optimalizacích (3) od Petr Menšík - Chápu pokus o relativní jednoduchost příkladů. Ale je...

Chápu pokus o relativní jednoduchost příkladů. Ale je trochu nefér porovnávat nativní kód bez optimalizace na moderní procesor s optimalizací na moderní procesor přes JIT. Samozřejmě, test je poměrně dost syntetický a asi nedává příliš smysl řešit složitě inicializaci různých kompilovaných knihoven podle procesoru na tomto příkladu. Nicméně kompilace pro procesory s MMX a SSE instrukcemi by mohl celkem pomoct. Zkuste si schálně přidat k GCC parametrům ještě -march=native. Sice se tento kód tímto stane nepřenosným, ale zase překladač bude moci využít plně možností daného CPU, stejně jako to může JIT.

Pravda, prakticky se asi vyplatí buildovat tak 2 verze. Jednu pro moderní procesory s podporou několika rozšíření a jednu záložní, co bude šlapat na všem. Potom ozkoušet, jestli přínos pro výpočet vůbec stojí za tu námahu.

Každopádně díky za upozornění, že nativní kód sám o sobě zrychlení nepřináší automaticky. Ne, že by to bylo překvapující, ale je dobré mít na to čísla. Ještě si sám ověřím čísla pro různé optimalizace. (Základ, i686, presscot, core2... :))

Diky za poznamku, je to samozrejme pravda, ale tento priklad byl puvodne ziskan ze skutecne aplikace, ktera se snazila provadet operace nad obrazky (byte[][] a float[][]) v nativnim kodu, coz ale nevedlo k prakticky zadnemu urychleni prave kvuli neustalym kopiim poli.

A pouziti vice verzi knihoven bylo prakticky nemozne kvuli nutnosti udrzovat aplikaci a jeji instalace (uz tak dodavat ctyri verze bylo skoro nad sily vyvojaru - linux i686/x86_64 + Windows to same).

Pokud si budete vysledky overovat, slo by je prosim potom pridat do diskuze? Sam jsem zvedavy, jestli se vubec neco podari urychlit, resp. jestli to bude poznat na vysledcich.

Jestli ona to neni cela podstata JITu. Bud to napisete jednou dost dobre a nechate JIT aby si s tim poradil na vsemoznych platformach, nebo se rozhodnete pro nativni a pak budete s neskutecnym nasazenim udrzovat neskutecne mnozstvi binarek pro vsechny podporovane kombinace OS+HW (a to navic v case do minulosti i budoucnosti). Pokud to neudelate, tak se lehce muze stat ze ten program bude za pet let rychlejsi v ciste jave nez v nativu a cele to usili prijde vnivec.

Je to tak, nejvic to asi boli na mobilnich platformach, proto taky Android pouziva VM - s nativnimi aplikacemi by asi byl brzy v koncich (vim, zatim to jsou nejvic ARMy, ale vyvoj pujde dal).