Изпечатай

[clovenhoof]

Къде ги четеш тези неща?

Java генерира по-бърз код от c++?!
GC е по-бърз от free?!

 

[gat3way]

Ами всъщност - да, може да генерира по-добър код. Има оптимизации, които не могат да се направят в compile-time. Много прост пример:

d = a*b + c;

Ако стойностите на а и/или b не са ти известни в compile-time (демек не са константи), това ще се компилира до MUL и ADD инструкция. JIT компилатора обаче може да вземе предвид че a или b ти е равно на 0 и да ти спести умножението и събирането. Примерът е доста прост, но предполагам го илюстрира.

Що се отнася до malloc/free vs garbage collection-а - да, възможно е, поради ред причини, garbage collector-а при определени обстоятелства да ти свърши по-добра работа. Това зависи от ред неща и според мен в общият случай malloc/free е по-бърз вариант, особено ако имаш много голям heap size и GC алгоритъма се събуди да го чисти Но теоретично - да, възможно е. malloc() примерно може да включва system call - sbrk(), който да ти накара ядрото да ти задели памет и да я мапне в адресното ти пространство. При java, това става само веднъж в началото на изпълнението. Склонен съм да вярвам, че в общият случай malloc/free имплементацията на glibc работи по-бързо, но не мога да го подкрепя с някакви доказателства и това силно зависи от workload-а и настройките на jvm-то.

[Odido]

Код

GeSHi (Java):
public class HelloWorld {
 
    public static void main(String[] args) {
        System.out.println("Hello, World");
    }
 
}

Код

GeSHi (PHP):
echo "Hello world"

а сега открийте разликите 

[bop_bop_mara]

Ми в единия низ world е с главна буква и има запетайка пред него...

[b2l]

Сравняваш Java с PHP  ...

Ми в единия низ world е с главна буква и има запетайка пред него...

+1

[lkr]

Ами всъщност - да, може да генерира по-добър код. Има оптимизации, които не могат да се направят в compile-time. Много прост пример:

d = a*b + c;

Ако стойностите на а и/или b не са ти известни в compile-time (демек не са константи), това ще се компилира до MUL и ADD инструкция. JIT компилатора обаче може да вземе предвид че a или b ти е равно на 0 и да ти спести умножението и събирането. Примерът е доста прост, но предполагам го илюстрира.

Това е най-малкото, което може да направи. Въпреки това няма да спечелиш много, освен ако не си в tight nested loop, което пак ще бъде hoisted. Ето една интересна статия JIT based interpreter (LuaJIT) http://article.gmane.org/gmane.comp.lang.lua.general/75426.

А GC-то е generational, рядко трябва да се обхожда целия heap. В повечето случаи мястото за short living objects се преизползва и чистенето става изключително бързо заради доброто locality на датата.

[clovenhoof]

Ами всъщност - да, може да генерира по-добър код. Има оптимизации, които не могат да се направят в compile-time. Много прост пример:

d = a*b + c;

Ако стойностите на а и/или b не са ти известни в compile-time (демек не са константи), това ще се компилира до MUL и ADD инструкция. JIT компилатора обаче може да вземе предвид че a или b ти е равно на 0 и да ти спести умножението и събирането. Примерът е доста прост, но предполагам го илюстрира.

Що се отнася до malloc/free vs garbage collection-а - да, възможно е, поради ред причини, garbage collector-а при определени обстоятелства да ти свърши по-добра работа. Това зависи от ред неща и според мен в общият случай malloc/free е по-бърз вариант, особено ако имаш много голям heap size и GC алгоритъма се събуди да го чисти Но теоретично - да, възможно е. malloc() примерно може да включва system call - sbrk(), който да ти накара ядрото да ти задели памет и да я мапне в адресното ти пространство. При java, това става само веднъж в началото на изпълнението. Склонен съм да вярвам, че в общият случай malloc/free имплементацията на glibc работи по-бързо, но не мога да го подкрепя с някакви доказателства и това силно зависи от workload-а и настройките на jvm-то.

Доколкото се спомням JIT генерира код по време на (преди) изпълнение. За фрагмент от сорса ако вече е генериран код, при повторно му изпълнение вече се изпълнява генерирания код.
(Това е на база мой спомени от преди около 5 години. Вече не ползвам Java.)
Примера който си дал предполага генериране на код най-малко един път, защото a и b са променливи а не константи.

За сравнението със C++ на база работа с паметта... Само да припомня че в C++ мога да си напиша собствен memory pool. Така че заделяне/освобождаване на памет мога да сведа до преместване на указатели.

[v_badev]

Всъщност често където се търси голяма производителност в код на C и C++ не се ползва malloc или new, а собствен memory pool. Например в рънтайм библиотеките на Apache (apr) и Mozilla (nspr).

Сега очаквам lkr да даде списък с популярни игри написани на Java, заради по-високата производителност и по-лесното писане в сравнение със C++. Може и Web сървъри (без да включваме неща като Tomcat и GlasFish) или браузъри. Единствените Java браузъри използвани в момента са в малките мобилни телефони, но това не е заради по-високата производителност.

[lkr]

Всъщност често където се търси голяма производителност в код на C и C++ не се ползва malloc или new, а собствен memory pool. Например в рънтайм библиотеките на Apache (apr) и Mozilla (nspr).

Сега очаквам lkr да даде списък с популярни игри написани на Java, заради по-високата производителност и по-лесното писане в сравнение със C++. Може и Web сървъри (без да включваме неща като Tomcat и GlasFish) или браузъри. Единствените Java браузъри използвани в момента са в малките мобилни телефони, но това не е заради по-високата производителност.

Minecraft добър пример ли е ? Или това не е достатъчно успяла игра. Вярно е че Java все още не може да се сравнява с RAW performance, но това че била бавна е абсурдно твърдение. Никъде не съм написал, че има по-висока производителност, а че в *някои* случаи JIT кодът е по-добър от този генериран от обикновен компилатор. Съответно това не е безплатно, има runtime overhead, а и трябва profiler-a да "загрее" преди да прави каквото и да е. Това е недопустимо при FPS игри, където latecy-то е от изключително значение. Да не говорим за неща като autoboxing, nondeterministic GC, reference types, virtual function inlining & co.  Факт е обаче, че Java за application/web programming е значително стабилна, дори и за server-side неща като Cassandra, Flock, etc.

[v_badev]

Модерните JIT компилатори са изключително ефективни, генериращи код по-добър от обикновен компилатор. Да не говорим за GC, който в много случаи е по-бърз от ръчен malloc/free! Има доста материали по темата, който не вярва може да провери.

Никъде не съм написал, че има по-висока производителност, а че в *някои* случаи JIT кодът е по-добър от този генериран от обикновен компилатор. Съответно това не е безплатно, има runtime overhead, а и трябва profiler-a да "загрее" преди да прави каквото и да е. Това е недопустимо при FPS игри, където latecy-то е от изключително значение. Да не говорим за неща като autoboxing, nondeterministic GC, reference types, virtual function inlining & co.  Факт е обаче, че Java за application/web programming е значително стабилна, дори и за server-side неща като Cassandra, Flock, etc.

Само на мен ли ми се струва че не си спомняш какво си написал вчера?
Minecraft е частен случай. Ако не го осъзнаваш проблема си е твой. Не всяка игра е FPS. Очевидно никой не пише на Java и стратегии, дори и походови, където не е толкова важна производителността. Там „по-лесното писане“ би трябвало да помага.

Много обичам да гледам как Java феновете се отказват от думите си колко е производителна любимата им платформа и започват да говорят за стабилност като им зададеш един прост въпрос.

редакция:
Просто не успях да се сдържа . Който смята че термините, дето lkr е извадил от презентациите на Oracle са специфични за Java да вдигне ръка. Знам че любимият спорт на Java програмистите е да обясняват колко е по-готина тяхната платформа в сравнение със C, ама понякога прекалявате. Поне като ще сравнявате принципно различни неща си намерете някой който е във вашата пазарна ниша. Още малко някой ще заяви че Java-та на Oracle е по-готина от асемблера за ARM7, защото автоматично конвертирала double в Double.

[lkr]

Модерните JIT компилатори са изключително ефективни, генериращи код по-добър от обикновен компилатор. Да не говорим за GC, който в много случаи е по-бърз от ръчен malloc/free! Има доста материали по темата, който не вярва може да провери.

Никъде не съм написал, че има по-висока производителност, а че в *някои* случаи JIT кодът е по-добър от този генериран от обикновен компилатор. Съответно това не е безплатно, има runtime overhead, а и трябва profiler-a да "загрее" преди да прави каквото и да е. Това е недопустимо при FPS игри, където latecy-то е от изключително значение. Да не говорим за неща като autoboxing, nondeterministic GC, reference types, virtual function inlining & co.  Факт е обаче, че Java за application/web programming е значително стабилна, дори и за server-side неща като Cassandra, Flock, etc.

Само на мен ли ми се струва че не си спомняш какво си написал вчера?
Minecraft е частен случай. Ако не го осъзнаваш проблема си е твой. Не всяка игра е FPS. Очевидно никой не пише на Java и стратегии, дори и походови, където не е толкова важна производителността. Там „по-лесното писане“ би трябвало да помага.

Много обичам да гледам как Java феновете се отказват от думите си колко е производителна любимата им платформа и започват да говорят за стабилност като им зададеш един прост въпрос.

То май и ти не си спомняш, защото в първото изречение съм написал още, че смятам C++/Java за пълен провал. Толкова беше с Java "феновете". След изключването на игрите за телефони (защото явно и те са частен случай) няма какво повече да коментираме. Виждам обаче, че явно си съгласен за динамичното компилиране, ако не е така, prove me wrong.

[v_badev]

Аз само цитирах противоречието между мненията ти. Веднъж казваш че модерните JIT компилатори генерират по-добър код от останалите, а после казваш че „в *някои* случаи JIT кодът е по-добър“. Лично аз съм съгалсен с второто твърдение, но не и с първото. Понеже и двете си ги писал ти, не мога да кажа че съм съгласен с теб А и темата е за Java, а не по принцип за JIT срещу нормални компилатори.

Логиката че щом се пишат много игри за малките телефони на Java ME, значи платформата е добра е като логиката че щом повечето GUI софтуер по света ползва MFC, значи това е добър GUI framework.

[clovenhoof]

Като говорим за JIT че използва повече информация при компилиране, то се сетих че за C++ има profile guided optimization или PGO.

Помня че имаше версия на FireFox компилирана с PGO.

[lkr]

Аз само цитирах противоречието между мненията ти. Веднъж казваш че модерните JIT компилатори генерират по-добър код от останалите, а после казваш че „в *някои* случаи JIT кодът е по-добър“. Лично аз съм съгалсен с второто твърдение, но не и с първото. Понеже и двете си ги писал ти, не мога да кажа че съм съгласен с теб А и темата е за Java, а не по принцип за JIT срещу нормални компилатори.

Логиката че щом се пишат много игри за малките телефони на Java ME, значи платформата е добра е като логиката че щом повечето GUI софтуер по света ползва MFC, значи това е добър GUI framework.

Почвам да се съмнявам дали има смисъл да отговарям. Никъде не става въпрос колко игри се пишат като брой, твърдението беше, че Java е бавна и не става. Е щом се пишат игри за телефони (и то колко) явно е достатъчно бърза. JIT кодът винаги е по-добър, при наличието на достатъчно данни, това си е факт, практически няма начин да генерираш по-добър код с обикновен компилатор. Проблемът е, че писането на JIT компилатор е изключително трудно, особено за език като Java, затова не винаги е ефективно. Това беше цялата идея с "някои" - кодът винаги е по-добър, а тези случаи, когато не е, просто са свързани с това, че опитът е много по-малък. Въпреки това резултатите се виждат:

 - http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php
 - http://lambda-the-ultimate.org/node/3851

Темата не знам дали е за Java, тъй като Java като език не представлява нищо. Всичко идва от платформата. Нещата отидоха в посоката на JIT, за да разберат някои хора, че модерните VM-та не са това, което бяха през 90-те.

[clovenhoof]

Щях да правя нещо подобно, но го намерих наготово -> Java vs. C++: The Performance Showdown
за да не си чешем езиците.

Всъщност за малко да се хвана да тествам, но ме домързя да тегля и слагам JDK.