Автор Тема: Защо никой не обича Java?/Sprechen Sie Java? (слети теми)  (Прочетена 18147 пъти)

clovenhoof

  • Напреднали
  • *****
  • Публикации: 534
  • Distribution: Mac OSX 10.9.2
    • Профил
Къде ги четеш тези неща?

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

 :D
« Последна редакция: Jun 01, 2011, 14:51 от bop_bop_mara »
Активен

We are just a moment in time
A blink of an eye
A dream for the blind
Visions from a dying brain

gat3way

  • Напреднали
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Ами всъщност - да, може да генерира по-добър код. Има оптимизации, които не могат да се направят в 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-то.
« Последна редакция: Jun 01, 2011, 14:51 от bop_bop_mara »
Активен

"Knowledge is power" - France is Bacon

Odido

  • Напреднали
  • *****
  • Публикации: 627
  • Distribution: Arch Linux
  • Window Manager: Gnome
    • Профил
Код
GeSHi (Java):
  1. public class HelloWorld {
  2.  
  3.    public static void main(String[] args) {
  4.        System.out.println("Hello, World");
  5.    }
  6.  
  7. }

Код
GeSHi (PHP):
  1. echo "Hello world"
а сега открийте разликите  ;D
« Последна редакция: Jun 01, 2011, 14:52 от bop_bop_mara »
Активен

"Congratulations, you broke the Internet
Look at what you did! Are you happy now?"

bop_bop_mara

  • Напреднали
  • *****
  • Публикации: 2433
  • Distribution: Debian Testing
  • Window Manager: LXDE
  • Cute and cuddly
    • Профил
Ми в единия низ world е с главна буква и има запетайка пред него...
« Последна редакция: Jun 01, 2011, 14:52 от bop_bop_mara »
Активен

b2l

  • Напреднали
  • *****
  • Публикации: 4786
  • Distribution: MCC Interim
  • Window Manager: - // - // -
  • ...sometimes I feel like screaming... || RTFM!
    • Профил
    • WWW
Сравняваш Java с PHP  :o :o :o...

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

+1
« Последна редакция: Jun 01, 2011, 14:52 от bop_bop_mara »
Активен

"Човекът е въже, опънато между звяра и свръхчовека, въже над пропаст. Човекът е нещо, което трябва да бъде превъзмогнато." - Фр. Ницше

lkr

  • Напреднали
  • *****
  • Публикации: 81
    • Профил
Ами всъщност - да, може да генерира по-добър код. Има оптимизации, които не могат да се направят в 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 на датата.

« Последна редакция: Jun 01, 2011, 14:52 от bop_bop_mara »
Активен

clovenhoof

  • Напреднали
  • *****
  • Публикации: 534
  • Distribution: Mac OSX 10.9.2
    • Профил
Ами всъщност - да, може да генерира по-добър код. Има оптимизации, които не могат да се направят в 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. Така че заделяне/освобождаване на памет мога да сведа до преместване на указатели.
« Последна редакция: Jun 01, 2011, 14:52 от bop_bop_mara »
Активен

We are just a moment in time
A blink of an eye
A dream for the blind
Visions from a dying brain

v_badev

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

Сега очаквам lkr да даде списък с популярни игри написани на Java, заради по-високата производителност и по-лесното писане в сравнение със C++. Може и Web сървъри (без да включваме неща като Tomcat и GlasFish) или браузъри. Единствените Java браузъри използвани в момента са в малките мобилни телефони, но това не е заради по-високата производителност.
« Последна редакция: Jun 01, 2011, 14:53 от bop_bop_mara »
Активен

lkr

  • Напреднали
  • *****
  • Публикации: 81
    • Профил
Всъщност често където се търси голяма производителност в код на 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.
« Последна редакция: Jun 01, 2011, 14:53 от bop_bop_mara »
Активен

v_badev

  • Напреднали
  • *****
  • Публикации: 1355
    • Профил
Модерните 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.
« Последна редакция: Jun 01, 2011, 15:27 от v_badev »
Активен

lkr

  • Напреднали
  • *****
  • Публикации: 81
    • Профил
Модерните 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

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

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

clovenhoof

  • Напреднали
  • *****
  • Публикации: 534
  • Distribution: Mac OSX 10.9.2
    • Профил
Като говорим за JIT че използва повече информация при компилиране, то се сетих че за C++ има profile guided optimization или PGO.

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

We are just a moment in time
A blink of an eye
A dream for the blind
Visions from a dying brain

lkr

  • Напреднали
  • *****
  • Публикации: 81
    • Профил
Аз само цитирах противоречието между мненията ти. Веднъж казваш че модерните 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

  • Напреднали
  • *****
  • Публикации: 534
  • Distribution: Mac OSX 10.9.2
    • Профил
Щях да правя нещо подобно, но го намерих наготово -> Java vs. C++: The Performance Showdown
за да не си чешем езиците.

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

We are just a moment in time
A blink of an eye
A dream for the blind
Visions from a dying brain

Подобни теми
Заглавие Започната от Отговора Прегледи Последна публикация
приложение на Java
Общ форум
laik 3 2247 Последна публикация Jun 17, 2004, 13:10
от JOKe
JAVA програмиране
Общ форум
smitev 8 3137 Последна публикация Jul 13, 2004, 00:26
от JOKe
За Java програмисти
Общ форум
smitev 1 1894 Последна публикация Sep 15, 2004, 21:49
от JOKe
Стартиране на Java приложение !
Общ форум
Diabolic_Soul 4 3229 Последна публикация Feb 22, 2005, 00:22
от JOKe
Java IDE?
Идеи и мнения
toxigen 9 3775 Последна публикация Apr 06, 2005, 23:00
от Ivozen